UNIVERSITÄT DUISBURG-ESSEN FAKULTÄT INGENIEURWISSENSCHAFTEN ABTEILUNG INFORMATIK

Größe: px
Ab Seite anzeigen:

Download "UNIVERSITÄT DUISBURG-ESSEN FAKULTÄT INGENIEURWISSENSCHAFTEN ABTEILUNG INFORMATIK"

Transkript

1 UNIVERSITÄT DUISBURG-ESSEN FAKULTÄT INGENIEURWISSENSCHAFTEN ABTEILUNG INFORMATIK Diplomarbeit Entwicklung einer Monitoring-Komponente mit Interventionsmöglichkeit für einen grafischen Lernprozess-Editor Marcel Pokrandt Matrikelnummer: Fakultät Ingenieurwissenschaften Abteilung für Informatik Universität Duisburg-Essen 19. Februar 2008 Betreuer: Prof. Dr. H. U. Hoppe Dipl.-Inform. Nils Malzahn

2

3 Inhaltsverzeichnis 1 Einleitung Motivation Aufgabenstellung Aufbau der Arbeit Grundlagen Das CoSSICLE-Framework Komponenten Mechanismen Grafische Sprache MoCoLaDe und Einbettung in den Editor Teilnehmer Gruppenbildung Gruppen Ressourcen und Rollen Komponentenzuteilung Aktivitäten Ablaufsteuerung Der MoCoLaDe-Editor Simulationsmodus IMS Learning Design IMS/LD-Export des Editors CopperCore Runtime Java Enterprise CopperCore Komponenten Ansatz Anforderungen Funktionsumfang Nutzung von Standards Minimale Invasivität Entwurf der Monitoringfunktionen Identifikation der UOL Automatischer Zustandsupdate Darstellung der Teilnehmerpositionen Ermittlung der Teilnehmerpositionen Ermittlung der Teilnehmerhistorie Globale Teilnehmer-/Gruppenübersicht Ressourcenverteilung Ermittlung der Gruppenproperties Model- vs. Simulation-Export i

4 Inhaltsverzeichnis Logging Entwurf der Interventionsfunktionen Teilnehmerverwaltung Gruppen- und Rollenverwaltung Modifikation der Gruppenproperties Aktivitätsabschluss Nachrichtenversand Gesamtkonzept Meta-Datei Architektur Struktur des Entwicklungsprojekts Implementierung CopperCore-Erweiterung Ant-Build Definition des JMS-Topics Notifications Notification EJB und Topic Notification Client Applet MoCoLaDe-Erweiterung XML-Verarbeitung Integration der Metadatei in den IMS/LD-Export Palettenmodus Verbindungsaufbau Zustandsermittlung und -update Globale Gruppen- und Teilnehmerübersicht Node-Details Highlighting Logging Interventionsfunktionen Anwendungsbeispiel Social Script Verzweigungen und Gruppenproperties Nutzung des Property-Editors Zusammenfassung und Ausblick 89 A Nutzung des vorkonfigurierten JBoss-Servers 91 B XSD-Schema der Metadatei 93 C CopperCore-Patch 95 D Lizenz Iconpack 97 Literaturverzeichnis 99 ii

5 1 Einleitung 1.1 Motivation In vielen Arbeiten wurde sich mit verschiedenen Möglichkeiten auseinandergesetzt, kollaborative Lernskripte zu formulieren und dabei verschiedene Formen der Notation entwickelt. Sollen diese Lernskripte von einem Computer interpretiert werden und in einer Laufzeitumgebung ablaufen, ist eine exakte und eindeutige Beschreibung dieser computerunterstützten kollaborativen Lern-Skripte (engl. Computer-supported collaboration learning, CSCL) vonnöten ([K + 05]). Deren Spezifizierung ist eine große Herausforderung, um möglichst alle Facetten möglicher wünschenswerter Abläufe formalisieren zu können. Dem Computer muss es möglich sein, aus der Skript-Definition für ihn eindeutige Instruktionen ableiten zu können ([HH08]). Diese umfassen den geplanten Ablauf im CSCL-Skript und damit verbundene Zustandsänderungen, wie z.b. die Vergabe von Ressourcen und Rollen. Ein Vertreter der grafischen Sprachen zur Formulierung von CSCL-Skripten soll in dieser Arbeit näher betrachtet werden. Im Rahmen seiner Diplomarbeit ([Sch06]) entwickelte Dominik Schweers eine grafische Sprache zur Modellierung kooperativer Lernprozesse, der die Spezifikationen des European Research Team (ERT) Computer-Supported Scripting of Interaction in Collaborative Learning Environments (CoSSICLE) für CSCL- Skripte zugrunde lagen. Zur Modellierung von grafischen Skripten auf Basis dieser Sprache implementierte D. Schweers ein Plugin (MoCoLaDe) für den von der Collide-Gruppe entwickelten grafischen Editor FreeStyler ([COL08]), mit Hilfe dessen diese grafischen Lernskripte erstellt und in einem Simulationsmodus mögliche Abläufe simuliert werden können. Zur praktischen Anwendung sollte das Plugin außerdem über eine Funktion zum Export des Skriptes für eine Lernprozess Laufzeitumgebung verfügen. Aufgrund der praktischen Relevanz wurde das IMS/LD-Format spezifiziert durch das IMS Global Learning Consortium ([IMS03c]) gewählt und als Ziel-Laufzeitumgebung die IMS/LD-Referenzimplementierung CopperCore. IMS/LD ist zwar das derzeit einzige im Editor verfügbare Export-Format für eine CSCL-Laufzeitumgebungen, die grafische Sprache ist an diese jedoch nicht untrennbar gebunden und Exportfunktionen für andere Umgebungen sind grundsätzlich denkbar (vgl. [Rot08]). 1.2 Aufgabenstellung CSCL-Skripte reduzieren den Aufwand des Betreuers in Bezug auf die Koordinierung der Lernenden u.a. dadurch, dass der Computer den Lernenden die auszuführenden Aktivitäten zuweist und sie ihnen anzeigt ([KWD + 07]). Der Computer führt die Lernenden damit auf den vorgegebenen Pfaden durch das Lernskript und präsentiert ihnen die 1

6 1 Einleitung notwendigen zusätzlichen Informationen. Mit dem MoCoLaDe-Editor (Model for Collaborative Learning Activity Design) existiert nun ein Werkzeug, mit dem CSCL-Skripte nach dem CoSSICLE-Modell erstellt, bearbeitet, simuliert und für die CopperCore Laufzeitumgebung im IMS/LD-Format exportiert werden können. Im praktischen Einsatz problematisch ist an dieser Stelle für den potenziellen Tutor jedoch die Tatsache, dass mit den derzeit gegebenen technischen Hilfsmitteln eine Feedback-Möglichkeit fehlt, mit der der Zustand des CSCL-Skripts auf dem CopperCore- Server visualisiert werden kann und ggf. korrigierend Einfluss genommen werden kann. So ist es ohne tiefergehende spezifische technische Kenntnisse nicht möglich, einfache Fragen bzgl. des Zustands zu beantworten wie: Welche Benutzer nehmen an dem Kurs teil?, Welchen Gruppen und Rollen sind sie zugeordnet?, Welche Aktivität führt ein bestimmter Benutzer derzeit aus und was hat er zuvor getan?. Ziel dieser Arbeit ist es, einen Rückkanal von der CopperCore Engine zum Editor zu schaffen, so dass dieser genutzt werden kann, um die Fortschritte der einzelnen Nutzer oder Gruppen auf ihren jeweiligen Lernpfaden widerzuspiegeln (Monitoring). Diese Funktionalität soll den Verantwortlichen für die Lernprozesse einen besseren Überblick über die Lernsituation geben, damit helfend eingegriffen werden kann, wenn Problemsituationen auftreten. Um den Benutzer von MoCoLaDe bei der Bereinigung der Problemsituationen zu unterstützen, soll es Interventionsmöglichkeiten aus dem Editor heraus geben. 1.3 Aufbau der Arbeit Im nachfolgenden Kapitel wird zunächst auf die Grundlagen dieser Arbeit eingegangen. Vorgestellt werden das CoSSICLE-Framework und die daraus abgeleitete grafische Sprache des MoCoLaDe-Editors sowie die technischen Grundlagen der CopperCore- Laufzeitumgebung. Das darauffolgende Kapitel 3 umfasst die Definition der Anforderungen an die geplante Implementierung, die zu lösenden Problemstellungen und die Dokumentation der Entscheidungsfindungen des gewählten Lösungsweges und der jeweiligen Alternativen. Dem schließt sich die Dokumentation der Implementierung in Kapitel 4 an, die einen Überblick über die wichtigsten technischen Details liefert als auch der dabei gelösten Probleme. Im Kapitel 5 wird die entwickelte Software anhand eines Anwendungsbeispiels vorgestellt. Ein abschließendes Fazit der Ergebnisse dieser Arbeit wird in Kapitel 6 gezogen und es wird ein kurzer Ausblick auf künftige Entwicklungsmöglichkeiten gegeben. 2

7 2 Grundlagen 2.1 Das CoSSICLE-Framework Das Europäische Forschungsprojekt CoSSICLE gebildet im Rahmen des Kaleidoscope Network of Excellence (concepts and methods for exploring the future of learning with digital technologies) befasst sich mit der Spezifikation und Formalisierung von CSCL-Skripten. Aufgrund des Umstandes, dass bisherige Ansätze CSCSL-Skripte zu modellieren und formalisieren stark voneinander abweichen, bestand der Bedarf eines gemeinsamen konzeptuellen Rahmens, auf den in weiteren Arbeiten in Wissenschaft und Forschung zurückgegriffen werden kann ([K + 05]). Die CoSSICLE-Gruppe hat ein solches Rahmenwerk zur Spezifikation von CSCL-Skripten entwickelt (im Folgenden CoSSICLE-Framework genannt), welches in [K+ 05] beschrieben wird. Das CoSSICLE-Framework selbst basiert auf früheren Arbeiten von Dillenbourg, Jerman, Kollar, Fischer und Hesse und kann als Zusammenfassung dieser Arbeitsergebnisse gesehen werden ([K + 05]). Es gibt verschiedene Facetten vor, durch die ein CSCL-Skript hinreichend definiert werden kann, die ihre Entsprechung in der von Schweers entwickelten grafischen Sprache ([Sch06]) finden, wie in Kapitel 2.2 gezeigt werden wird. Unterschieden wird dabei zwischen Mechanismen und Komponenten. Diese Unterteilung stellt eine Neuheit gegenüber den vorherigen oben genannten Arbeiten dar. Während Komponenten die grundsätzlichen Bestandteile des Skripts darstellen, beschreiben die Mechanismen deren Zusammenspiel. Zum Beispiel wird eine Rolle als Komponente gesehen und das Prinzip der Rollenverteilung auf die Teilnehmer (die Teilnehmer sind ebenfalls eine Komponente) als Mechanismus ([Sch06]). Im Folgenden soll ein kurzer Überblick über die definierten Komponenten und Mechanismen gegeben werden, der im wesentlichen auf [K + 05] basiert Komponenten Im CoSSICLE-Framework werden die folgenden Komponenten definiert: Teilnehmer (eng.: participants) stehen als Abstraktion für konkrete Individuen. Diesen können Eigenschaften zugeschrieben werden (wie z.b. Geschlecht, Alter), auf die im Skriptverlauf und bei der Gruppenbildung zurückgegriffen werden kann. Gruppen (eng.: groups) bilden eine hierarchische Struktur, in der größere Gruppen aus kleineren Gruppen bestehen können, die wiederum Teilnehmer enthalten. Alle Teilnehmer gehören einer Gruppe an. Wurde keine definiert, ist diese mit All participants zu bezeichnen. Rollen (eng.: roles) dienen zur Abgrenzung von speziellen Teilnehmern zu den restlichen Teilnehmern. Mit Rollen können besondere Aufgaben oder Privilegien verbunden sein. 3

8 2 Grundlagen Aktivitäten (eng.: activities) sind die von den Teilnehmern auszuführenden Tätigkeiten und sind abhängig von der Gruppen- und Rollenzugehörigkeit. Aktivitäten können außerdem als hierarchische Struktur gebildet werden, in der komplexe Aktivitäten in eine Abfolge einfacherer Aktivitäten zerlegt wird (vgl. [HM06]). Ressourcen (eng.: resources) stehen für virtuelle oder physische Objekte, die einem Teilnehmer zugewiesen/gegeben werden und auch wieder entzogen/abgegeben werden können. Als Beispiel seien hier z.b. Texte genannt, die an die Teilnehmer verteilt und von diesen bearbeitet werden sollen. Virtuelle Ressourcen könnten z.b. der Zugang zu einem Online-Dokument sein. Wie die physischen Ressourcen können auch die virtuellen Ressourcen evtl. nur in begrenzter Zahl zur Verfügung stehen und so kann diese Limitierung in der Skriptdefinition festgehalten werden Mechanismen Die Prinzipien, Teilnehmer zu Gruppen zusammenzufassen, werden als Gruppenbildung (eng.: group formation) bezeichnet. Diese kann nach einfachen Regeln durchgeführt werden (z.b. bestimmte Anzahl von Gruppen oder bestimmte durchschnittliche Gruppengröße ) oder sich als Aufteilungskriterium auf die Eigenschaften der Teilnehmer stützen (z.b. Aufteilung nach Geschlecht in Frauen- und Männergruppe). Die Komponentenzuteilung (eng.: component distribution) umfasst Angaben, welche Teilnehmer/Gruppen welche Ressourcen bekommen oder zurückgeben müssen, wie die Rollen verteilt werden und welcher Teilnehmer welche Aufgabe zu bearbeiten hat. Um nicht nur einen einfachen linearen sequenziellen Ablauf durch eine Abfolge von Aktivitäten zu ermöglichen sondern auch wiederholende Aktivitätsfolgen mit evtl. leichter Veränderung, wird die Ablaufsteuerung (eng.: sequencing) definiert. Hier können diverse Kriterien in Form von Konditionen für den Aktivitätsfluss vorgegeben werden. An die Ablaufsteuerung kann außerdem ein sogenanntes Fading oder eine Rotation gebunden sein. Die Rotation beschreibt eine Permutation der Verteilung von Ressourcen oder Rollen innerhalb einer Gruppe und kann z.b. sinnvoll sein, eine bestimmte Aktivität mehrfach mit unterschiedlicher Ressourcen- oder Rollenverteilung zu wiederholen. Das Fading beschreibt hier das zeitlich gesteuerte Hinzufügen und Entfernen von Ressourcen. 4

9 2.2 Grafische Sprache MoCoLaDe und Einbettung in den Editor 2.2 Grafische Sprache MoCoLaDe und Einbettung in den Editor Im Folgenden soll auf die in [Sch06] beschriebene Umsetzung des oben beschriebenen CoSSICLE-Frameworks in eine grafische Sprache und den dazugehörigen grafischen Editor MoCoLaDe eingegangen werden. Wie bereits zuvor erwähnt, finden alle oben genannten Konzepte bezüglich der Komponenten und Mechanismen ihre Widerspiegelung in der zu betrachtenden grafischen Sprache (im Folgenden MoCoLaDe-Sprache genannt). Sie basiert auf der Notation von Statecharts und gefärbten Petrinetzen, um bei der Modellierung der Skripte auf vertraute Konzepte zurückzugreifen. Wie diese besteht sie als Graphenstruktur daher aus verschiedenen Typen von Knoten und gerichteten Kanten. Um die konzeptionelle Unterscheidung des Frameworks zwischen Komponenten und Mechanismen beizubehalten, werden Komponenten als Knoten und Mechanismen als gerichtete Kanten repräsentiert. Als Unterscheidungskriterium der Komponenten dienen unterschiedliche Knotensymbole und für die Mechanismen unterschiedliche Farbkonventionen der Kanten. Aufgrund der im Framework vorgegebenen logischen Zusammenhänge sind nur bestimmte Verbindungen zwischen den einzelnen Knotentypen und Kanten sinnvoll und erlaubt. Die logischen Beziehungen zwischen Komponenten und Mechanismen sind in Tabelle 2.1 dargestellt. Gruppenbildung Komponentenzuweisung Ablaufsteuerung Teilnehmer X X Gruppen X X Ressourcen X Rollen X Aktivitäten Tabelle 2.1: Beziehungen zwischen Komponenten und Mechanismen (bzw. Knoten und Kanten), Quelle: [Sch06] X Teilnehmer Teilnehmer sind als CoSSICLE-Komponente definiert. Nach der oben genannten Konvention sind sie in MoCoLaDe also als Knoten zu modellieren. Schon bei der Vorstellung, die Teilnehmer einer Gruppe von der Größe einer Klasse (also etwa 30 Teilnehmer) als einzelne Knoten zu modellieren, wird deutlich, dass mit dieser Methode die Übersicht verloren ginge und die Wiederverwendbarkeit des CSCL-Skripts extrem eingeschränkt wäre. Für die Verwendung des Skripts mit einer anderen Teilnehmergruppe müsste das komplette Skript umgestellt werden, obwohl an der eigentlichen Semantik sonst keine Änderungen vorgenommen werden würden. Anstatt jeden einzelnen Teilnehmer als eigenständigen Knoten zu definieren, werden in MoCoLaDe eine Menge von Teilnehmern zu einem einzigen Knoten zusammengefasst und deren Definition abgetrennt (Abbildung 2.1). Zum einen hat dies den Vorteil, auch 5

10 2 Grundlagen bei einer größeren Teilnehmerzahl eine gute Übersicht zu gewährleisten. Zum anderen verbessert sich dadurch die Wiederverwendbarkeit des Skripts, da die konkrete Modellierung der Teilnehmer von der Modellierung des Skripts getrennt wird. Jedes Skript nach diesem Modell muss über mindestens einen solchen Teilnehmer-Knoten verfügen. Abbildung 2.1: Symbol für Teilnehmer-Knoten und zugehöriger Participant-Editor Im Editor ist die Definition der durch den Teilnehmer-Knoten repräsentierten Teilnehmermenge durch einen über ein Kontextmenü aufrufbaren Participant-Editor gelöst (Abbildung 2.1). Den Teilnehmern können Attribute wie z.b. Name, Alter und Geschlecht zugewiesen werden, die zu deren Unterscheidbarkeit dienen. Das System kann diese Attribute für den Gruppenbildungs-Mechanismus auswerten und so z.b. zwei geschlechterspezifisch getrennte Gruppen Männer und Frauen erzeugen Gruppenbildung Im Gegensatz zu Teilnehmern gilt die Gruppenbildung im Framework als ein Mechanismus und wird daher in der MoCoLaDe-Sprache als Kante dargestellt genauer: als rote Kante zwischen einem Teilnehmer- und einem Gruppenknoten. Regeln für die Gruppenbildungs-Prinzipien werden als Annotation entlang der Kante dargestellt (Abbildung 2.2). Der Gruppenknoten (s.u.) steht für alle durch die Gruppenbildung generierten Teilnehmergruppen. Abbildung 2.2: Gruppenbildung: Teilnehmer- und Gruppenknoten werden über eine Group-Formation -Kante verbunden, Gruppenbildungs-Prinzipien werden per Annotation an der Kante symbolisiert hier: 2er-Gruppen bilden Der Editor bietet sowohl die Möglichkeit der manuellen Gruppenbildung durch den Bearbeiter des Skripts, als auch die Nutzung verschiedener algorithmischer Prinzipien 6

11 2.2 Grafische Sprache MoCoLaDe und Einbettung in den Editor konfigurierbar im Kontexteditor der Kante (Abbildung 2.5): Nach Anzahl Es wird versucht, die vorgegebene Anzahl von Gruppen mit möglichst gleichmäßiger Verteilung der Teilnehmer zu bilden. Die resultierenden Gruppengrößen werden automatisch bestimmt. Nach Größe Gruppen mit der vorgegebenen Größe werden gebildet. Lässt sich die gegebene Zahl der Teilnehmer nicht gleichmäßig anhand der vorgegebenen Gruppengröße aufteilen (Anzahl der Teilnehmer nicht glatt durch Gruppengröße teilbar), wird versucht, die Abweichungen der Gruppengrößen zu minimieren. Die dafür benötigte Anzahl von Gruppen wird vom Algorithmus bestimmt (Abbildung 2.2). Separierung nach Attribut Die Bildung der Gruppen erfolgt anhand eines vorgegebenen Teilnehmer-Attributs. Für jede vorhandene Ausprägung des Attributs wird eine eigene Gruppe gebildet. Bei Separierung nach Alter würden also jeweils Personen zu Gruppen zusammengefasst, die dasselbe Alter haben bei einer Separierung nach Geschlecht würden max. zwei Gruppen gebildet (Abbildung 2.3). Abbildung 2.3: Gruppenbildung: Separierung nach Wert der Teilnehmerattribute Filterung nach konkretem Attributwert Die Filterung nach einem Attributwert filtert jene Teilnehmer, deren Attributwert mit dem vorgegebenem Wert (oder mit einem in einer Menge vorgegebenen möglichen Werte) übereinstimmt. So lassen sich Teilnehmergruppen auftrennen und abhängig vom Attributwert unterschiedliche Aktivitätspfade vorgeben. Der Nachteil dieser Methode ist, dass alle möglichen Ausprägungen des Attributs bekannt sein müssen und jeweils einzeln behandelt werden müssen, um alle Teilnehmer in das Skript mit einzubeziehen. Sonst würden Teilnehmer, die einen nicht im Skript betrachteten Attributwert aufweisen, ausgefiltert. Sie würden keiner Gruppe zugeordnet und ihnen könnte keine Aktivität zugeteilt werden. Als Beispiel sei hier wieder die Trennung nach Geschlechtern angeführt, wie sie in Abbildung 2.4 dargestellt ist. Hier sind die beiden möglichen Ausprägungen des Attributs Geschlecht ( Männer und Frauen ) getrennt zu behandeln und daher jeweils mit einem eigenen Gruppenknoten zu versehen. Abbildung 2.4: Gruppenbildung: Filterung nach spezifischem Wert der Teilnehmerattribute 7

12 2 Grundlagen Alle genannten Kriterien können im Editor kombiniert werden und so lassen sich sehr komplexe Gruppenbildungs-Prinzipien definieren. Zum Beispiel lassen sich die Prinzipien Separierung nach Attribut: Geschlecht und Nach Größe: 2 kombinieren, um Männerund Frauen zu trennen und diese jeweils in Zweiergruppen aufzuteilen (Abbildung 2.5). Abbildung 2.5: Group Formation Editor hier: Separierung nach Gender (Geschlecht) kombiniert mit in Zweiergruppen aufteilen 8

13 2.2 Grafische Sprache MoCoLaDe und Einbettung in den Editor Gruppen Ähnlich wie bei der Definition der Teilnehmer werden aufgrund der besseren Übersichtlichkeit und Flexibilität mehrere Gruppen zu einem Knoten zusammengefasst (Abbildung 2.6). Der Gruppenknoten repräsentiert die durch die Gruppenformation gebildeten Gruppen. Abbildung 2.6: Symbol für Gruppen und Property-Editor mit den Initialwerten der Gruppen-Attribute Eine Besonderheit der grafischen Sprache im Vergleich zum CoSSICLE-Framework ist die Tatsache, dass den Gruppen auch Attribute zugewiesen werden können (Abbildung 2.6). Diese können zum Zeitpunkt der Gruppenbildung mit einem initialen Startwert belegt werden und in der Ablaufsteuerung ausgewertet und modifiziert werden (s.u.). Dagegen findet die in CoSSICLE vorgesehene hierarchische Verschachtelung von Gruppen in MoCoLaDe keine Entsprechung Ressourcen und Rollen Ähnlich den Teilnehmern und Gruppen werden Mengen von gleichartigen Ressourcen zu einem einzelnen Knoten zusammengefasst (Abbildung 2.8), um das grafische Modell übersichtlich und wiederverwendbar zu halten. Die einzelnen Ressourceninstanzen sind im Editor wieder über einen Kontexteditor bearbeitbar, in dem sich eine beliebige Anzahl von Ressourcen anlegen, benennen und entfernen lassen (Abbildung 2.7). Sie sind Stellvertreter der realen Ressourcen und daher nur in begrenzter Anzahl vorhanden nämlich genau der Anzahl wie sie im Editor angelegt wurden. Rollen werden einzeln explizit als Knoten modelliert (Abbildung 2.8). Von ihnen wird allerdings angenommen, dass sie in unbegrenzter Anzahl gleichartig zur Verfügung stehen. Die maximale Anzahl ihrer Verteilung auf die Teilnehmer ist also nicht begrenzt und wird ausschließlich durch den Mechanismus der Komponentenzuteilung vorgegeben. 9

14 2 Grundlagen Abbildung 2.7: Ressourcen-Editor Komponentenzuteilung Der Mechanismus der Komponentenzuteilung wird in MoCoLaDe als blaue Kante symbolisiert und steht in Beziehung mit den Komponenten Rolle und Ressource. Die Komponentenzuteilung steuert deren Verteilung an die Teilnehmer nach definierbaren Kriterien, die als Annotation entlang der Kante dargestellt werden (Abbildung 2.8). Die Ausrichtung der Kante (ob vom Hilfsknoten eingehend oder abgehend) steuert dabei, ob eine Komponente zugeteilt oder entzogen wird. So lässt sich nicht nur die Zuteilung und Rückgabe von Ressourcen modellieren sondern auch die Produktion von Ressourcen durch die Teilnehmer. Dieser Mechanismus stellt insofern einen Sonderfall in MoCoLaDe dar, dass er leicht von der Semantik im CoSSICLE-Framework abweicht. Während in CoSSICLE auch die Zuteilung von Aktivitäten an die Teilnehmer als Teil der Komponentenzuteilung gilt, wird dies in MoCoLaDe ausschließlich durch die Aktivitätssteuerung gelöst und wird deshalb an späterer Stelle betrachtet (siehe Abschnitt 2.2.7). Des Weiteren wird für die Komponentenzuteilung aus Gründen der besseren semantischen Darstellung ein eigener Hilfsknoten eingeführt, der in den Prozessfluss eingebunden wird 1. Ausschließlich Instanzen dieses Hilfsknotens können mittels einer Component- Distribution -Kante mit einem Rollen- oder einem Ressourcenknoten verbunden werden. 1 Die konkreten Gründe für die Einführung des Hilfsknotens werden in [Sch06] S geschildert 10

15 2.2 Grafische Sprache MoCoLaDe und Einbettung in den Editor Abbildung 2.8: Komponentenzuteilung: Ressource und Rolle über Component- Distribution -Kante mit Hilfsknoten verbunden durch Verbindung mit dem Hilfsknoten in den Prozessfluss eingebunden: eingehende und ausgehende Sequencing -Kanten (s. Abschnitt 2.2.7) In MoCoLaDe definierbare Zuteilungskriterien für die Komponenten Rolle und Ressource sind (x steht dabei für eine definierbare Anzahl von Rollen oder Ressourcen, die zugewiesen werden): x Ressourcen pro Gruppe Die Ressourcen werden der gesamten Gruppe zugewiesen und jeder Teilnehmer der Gruppe kann die Ressourcen nutzen x Ressourcen pro Teilnehmer Die Ressourcen werden explizit dem Teilnehmer zur Verfügung gestellt und nur dieser kann sie nutzen x Ressourcen pro Rolle Inhaber der angegebenen Rolle bekommen die Ressourcen zugewiesen. Im Falle einer Rollenrotation wird die Ressource nicht weitergegeben, sondern bleibt an den konkreten Teilnehmer gebunden. x Rollen pro Gruppe 2 x Gruppenmitglieder bekommen die spezifizierte Rolle zugewiesen x Rollen pro Teilnehmer Die Rolle wird jedem betrachteten Teilnehmer zugewiesen. Die Angabe der Anzahl der Rollen hat hier keine weitere Bedeutung, wurde jedoch aus Konsistenzgründen beibehalten. x Rollen pro Rolle Besitzer der angegebenen Rolle können die spezifizierte weitere Rolle zusätzlich annehmen. Beispiel aus [Sch06]: So kann es durchaus gewünscht sein, dass z.b. der Teilnehmer mit der Rolle des Fallanalytikers zusätzlich die Rolle des Protokollanten in der Gruppe übernimmt Aktivitäten Aktivitäten beschreiben die von den Teilnehmern auszuführenden Tätigkeiten und werden in MoCoLaDe wie alle CoSSICLE-Komponenten als Knoten modelliert (Abbildung 2.9). Zur Spezifizierung der Tätigkeiten sollten sie mit einem möglichst aussagekräftigen Namen versehen werden. Aktivitäten selbst können in MoCoLaDe bisher mit keinen weiteren Eigenschaften versehen werden, sodass deren Namen für sich selbst sprechen 2 Die Semantik dieser Zuweisung ist nicht eindeutig ([Sch06] S.47-49). Der MoCoLaDe-Editor weist x zufällig ausgewählten Gruppenmitgliedern die angegebene Rolle zu vornehmlich denjenigen, die noch keine andere Rolle haben 11

16 2 Grundlagen muss. Wohl möglich ist die bereits erwähnte hierarchische Zerlegung von komplexen Aktivitäten in eine Abfolge von einfacheren Sub-Aktivitäten. Eine solche komplexe Aktivität dient somit als Container für ein komplettes (Teil-)Skript. Der Editor löst dies elegant durch die Implementierung eines Kontextmenüs, das die Erstellung eines nested Graph als Unterskript ermöglicht und dies als eine Miniaturansicht in den Knoten der Aktivität einbindet und so wesentlich zur guten Übersicht beiträgt (Abbildung 2.10). Leider weist der Editor bzgl. der Subaktivitäten einige Einschränkungen auf, auf die später noch eingegangen wird (siehe Abschnitte und 2.3.1). Abbildung 2.9: Symbol für Aktivität in MoCoLaDe Abbildung 2.10: Aktivität mit Miniaturansicht des Unterskripts, Quelle: [Sch06] Ablaufsteuerung Der Mechanismus der Ablaufsteuerung definiert die sequenzielle Abfolge der Aktivitäten, die die Teilnehmer zu absolvieren haben. In MoCoLaDe anlehnend an die Semantik von Statecharts als (grüne) gerichtete Kante realisiert, geben diese Kanten sozusagen die möglichen Pfade vor, die die Teilnehmer durch das Skript nehmen können bzw. müssen. In MoCoLaDe übernimmt sie also mit die Funktion der Komponentenzuteilung der Aktivitäten an die Teilnehmer (siehe Abschnitt 2.2.5), was eine Abweichung vom CoSSICLE-Framework darstellt. An eine solche Sequencing -Kante lassen sich sowohl die in Abschnitt erwähnten Prinzipien der Rotation und Fading binden als auch Konditionen für den Übergang über diese Kante. Beides wird wieder als Annotation neben der Kante dargestellt. MoCoLaDe ermöglicht hier auch die Auswertung der Werte der Gruppen-Attribute als auch deren Modifikation wie z.b. die In-/Dekrementierung eines Zahlen-Attributs. Möglich werden so nicht nur sequenzielle Abläufe sondern auch recht komplexe Verzweigungen, deren Verlauf abhängig von Attributwerten ist, die im Verlauf außerdem modifiziert werden können. So ist auch die Implementierung von Schleifen durch Nutzung eines Attributs als Zähl-Variable möglich (Abbildung 2.11). In MoCoLaDe ist festgelegt, dass sich Gruppen stets gemeinsam durch das Skript bewegen. Jede Gruppe beginnt gemeinsam die erste Aktivität, schließt diese ab und bewegt sich geschlossen zur nächsten Aktivität. Diese Konvention ist nicht ganz unproblematisch, wie in noch gezeigt werden wird. 12

17 2.3 Der MoCoLaDe-Editor Die Ablaufsteuerung beginnt daher bei einem Gruppenknoten. Von dort aus führt mindestens eine Sequencing-Kante zu einer Aktivität oder mehreren Aktivitäten und von da aus wiederum zu weiteren Aktivitäten und bildet den Prozessfluss. An beliebiger Stelle kann außerdem ein Hilfsknoten für die Komponentenzuweisung eingefügt werden. Zur Indikation eines Skript-Endes, definiert MoCoLaDe einen schwarzen End-Knoten (ebenfalls den Statecharts entlehnt). Bei dessen Erreichen kann das Skript für die betreffenden Teilnehmer als abgeschlossen gelten. 2.3 Der MoCoLaDe-Editor Abbildung 2.11: Ein einfaches grafisches MoCoLaDe-Skript im Editor rechts die Palette Der Editor wurde als Plugin für den grafischen Editor FreeStyler entwickelt und gliedert sich daher in zwei Bereiche: Einen Inhaltsbereich, der das zu bearbeitende Skript enthält, und einer Palette, die alle Werkzeuge zum Zeichnen des Skripts und weitere Optionen erreichbar über Karteireiter bereithält (Abbildung 2.11). Um eine Instanz eines Komponenten-Knotens im Skript anzulegen, kann der entsprechende Knotentyp von der Palette per Drag n Drop in den Inhaltsbereich gezogen werden. Verbunden werden die Knoten durch das Zeichnen einer Kante einer der drei zuvor 13

18 2 Grundlagen beschriebenen Typen: Sequencing, Component-Distribution und Group Formation Simulationsmodus Eine wichtige Funktion im MoCoLaDe-Editor ist der Simulations-Modus. Er stellt eine einfache interne Test-Umgebung für das Skript zur Verfügung, in der beobachtet werden kann, wie sich die definierte Gruppenaufteilung auswirkt, wie die Ressourcen und Rollen auf die Teilnehmer verteilt werden würden und wie sich die evtl. definierten Konditionen in der Aktivitätssteuerung auf den Ablauf des Skripts auswirken. Für diese Analysezwecke bietet der Editor die Ansicht Simulation-Details (Abbildung 2.12). Angezeigt wird der Inhalt eines zuvor ausgewählten Knotens. Da sich nach MoCoLaDe-Konvention Gruppen gemeinsam durch das Skript bewegen, interpretiert MoCoLaDe die an der Aktivitätssteuerung beteiligten Knoten Gruppe, Aktivität, Hilfsknoten Komponentenzuweisung und den End-Knoten als Container für Gruppen. Der Inhalt dieser Knoten sind also Gruppen, die sich gerade in diesem Knoten aufhalten (z.b. gerade eine Aktivität ausführen). Dargestellt werden sowohl die Gruppen als auch deren Teilnehmer, Rollen, Ressourcen und Attribute in einer intuitiven Baumstruktur. Abbildung 2.12: Simulationsmodus eines einfachen MoCoLaDe-Skripts und Ansicht Simulation-Details mit ausgewähltem Knoten Activity 1 Um Gruppen im Simulationsmodus von einem Knoten zum nächsten bewegen zu können, werden an den Sequencing-Kanten Buttons eingeblendet. Beim Klick auf einen solchen Button wird der jeweilige Übergang aktiviert und die Skript-Simulation in den Folgezustand überführt. 14

19 2.4 IMS Learning Design Als Einschränkung des Editors ist anzumerken, dass die in Abschnitt erwähnten Sub-Aktivitäten vom Simulationsmodus nicht beachtet werden. 2.4 IMS Learning Design IMS Learning Design (IMS/LD) ist die Fortentwicklung der Educational Modelling Language (EML) der Open University of the Netherlands (OUNL) eine computerinterpretierbare Sprache zur Lernprozessmodellierung. Sie wird fortan vom IMS Global Learning Consortium fortentwickelt, das auch für die Entwicklung und Herausgabe der verschiedenen Teil-Spezifikationen zuständig ist, wie die für diese Arbeit wichtigsten: IMS/LD Information Model [IMS03b], IMS/LD XML Binding [IMS03c], IMS/LD Content Packaging [IMS04] und IMS/LS Best Practice and Implementation Guide [IMS03a]. Mit dem Namen IMS/LD-Skript verbindet man im Allgemeinen ein Unit of Learning (UoL) Content Package, das als ZIP-Archiv sowohl aus einem sog. Manifest als auch einer Sammlung von optionalen Dateien den Ressourcen besteht. Das Manifest baut auf einem XML-basierendem Datenformat auf und gliedert sich grob in drei Blöcke: Meta- Data, Organizations: Learning Design und Resources. Für IMS/LD sind derzeit drei verschiedene Levels of Inplementation and Compliance definiert, die aufeinander aufbauen: Level A, Level B und Level C. Die hier betrachtete IMS/LD-Spezifikation bezieht sich auf Level C. Meta-Data enthält die Metadaten des Pakets, wie Autor und Name des Skripts. Der Block Organizations umfasst den eigentlichen Learning Design Inhalt, also die logische Beschreibung des Lernskripts. In Resources werden die für das Skript benötigten Ressourcen definiert, die dann im LD-Skript genutzt werden können und als physische Datei Teil des Archivs sein können. Die Definition des LD-Skripts nutzt die Metapher eines Theaterstücks und definiert den Ablauf des Skripts durch die Verwendung von Rollen, Akten und Aktivitäten. Weitere mögliche Konstrukte sind Ressourcen, Properties, Konditionen und Notifications. Im einfachsten Fall werden eine Folge von Akten definiert, die aus einer Folge von einzelnen Aktivitäten bestehen. Für den Lerner stellt sich dies als eine lineare sequenzielle Abfolge von Aktivitäten dar, die er nacheinander ausführen muss und jeweils als abgeschlossen markiert. Die Aktivitäten werden dem Lerner im Standardfall mit einem beschreibenden Dokument präsentiert, das die Arbeitsanweisungen enthält. Dies kann jede im Archiv enthaltene Ressource sein, wie z.b. ein HTML-Dokument, ein Word-Text aber auch implementierungsspezifische Ressourcen. Durch das Hinzufügen von Konditionen, kann der starre sequenzielle Ablauf um Sichtbar- /Unsichtbarmachen von Aktivitäten und weitere dynamische Elemente erweitert werden. So können auch die Werte von Properties ausgewertet und modifiziert werden. Notifications können genutzt werden, um einem Lerner beim Eintreten eines Ereignisses (z.b. dem Abschließen einer bestimmten Aktivität) eine Nachricht zu schicken. Im derzeitigen Standard ist als Implementierung der Notifications ausschließlich der Versand von s via SMTP standardisiert [IMS03b]. Es wird im weiteren Verlauf zu prüfen 15

20 2 Grundlagen sein, ob evtl. die IMS/LD-Notifications geeignet sind, sie als eine mögliche Form der Intervention zu nutzen. Um das IMS/LD Content Package zu nutzen, muss es von einer geeigneten Laufzeitumgebung interpretiert werden, die den Lernern und dem Tutor eine entsprechende Benutzeroberfläche anbietet. Die IMS/LD-Referenzimplementierung ist CopperCore und wird in Abschnitt 2.5 betrachtet IMS/LD-Export des Editors Teilziel bei der Entwicklung des MoCoLaDe-Editors war die Implementierung einer Exportfunktion, um das Skript in einer vorhandenen Laufzeitumgebung nutzen zu können. IMS/LD fehlen diverse Konzepte zur Implementierung von kollaborativen Lernprozessen auf Basis des CoSSICLE-Frameworks wie z.b. Gruppenformationen und Rollenrotationen. Andere Konzepte wie die der Ablaufsteuerung haben in IMS/LD eine abweichende Semantik. Aufgrund des Stellenwerts von IMS/LD im Umfeld der Lernprozessmodellierung wurde sich jedoch bewusst für dieses Format entschieden und damit Informationsund Funktionalitätsverluste in Kauf genommen. Teilweise sind diese bereits in [Sch06] erörtert, andere werden hier erörtert. Es ist abzusehen, dass eine Reihe davon Auswirkungen auf die Implementierung einer Monitoring-Komponente haben werden. Im Kapitel 3 wird zu erörtern sein, inwieweit diese möglichst umgangen werden können oder wie sie sich auf das Monitoring auswirken werden. Der Editor implementiert zwei grundsätzlich zu unterscheidende Exportstrategien: Der Model-Export exportiert das Skript nach Möglichkeit mit allen durch die Ablaufsteuerung vorgegebenen Verzweigungen und Konditionen. Limitierungen von IMS/LD haben jedoch dazu geführt, dass der Export von Schleifen in der Aktivitätsabfolge mit MoCoLaDe nicht möglich ist (vgl. [Sch06]). Leider ist die Untersuchung auf Schleifen im Editor nicht vollständig korrekt implementiert, was dazu führt dass auch der Export von Skripten fehlschlägt, die Knoten enthalten, die das Ziel mehr als einer Sequencing-Kante sind. Zum Beispiel bricht der Export des Skripts in Abbildung 2.13 beim Aktivitätsknoten Check ab und das IMS/LD-Skript ist nicht fehlerfrei lauffähig. Enthält das MoCoLaDe-Skript eine Schleife, besteht die derzeit einzige Möglichkeit darin, den Simulation-Export zu nutzen. Während des Durchlaufs einer Simulation im Editor werden die Bewegungen der Gruppen durch das Skript aufgezeichnet. Beim LD-Export werden die aufgezeichneten Gruppenbewegungen in eine starre Abfolge von Aktivitäten umgesetzt, sodass alle Verzweigungen im generierten LD-Skript verloren gehen. Leider geht damit eine der Stärken von CoS- SICLE, die flexible Ablaufsteuerung, verloren. Des Weiteren werden die Gruppen- Properties nicht in den Export einbezogen, die somit auch verloren gehen. Diese sind in MoCoLaDe aber hauptsächlich für die Ablaufsteuerung von Interesse. Da in diesem Fall keine bedingte Verzweigungen exportiert werden, in denen diese Properties eine Rolle spielen, mag dies evtl. eine untergeordnete Rolle spielen. 16

21 2.4 IMS Learning Design Abbildung 2.13: Beispiel eines MoCoLaDe-Skripts ohne Schleifen, dessen Model-Export nicht erfolgreich ist Gruppen und Teilnehmer IMS/LD fehlen Möglichkeiten zur Definitionen von Gruppen. Daher existiert derzeit auch keine Möglichkeit, Gruppenformationsalgorithmen zu definieren, wie bereits in vorherigen Arbeiten wie [HAD04] und [MHHH05] festgestellt wurde. Der Editor versucht die Gruppendefinition durch die laut IMS-Spezifikation mögliche hierarchische Verschachtelung von Rollen nachzubilden. Es wird eine ein- oder zweistufige Hierarchie aufgebaut. In der ersten Stufe werden die Gruppen auf IMS/LD-Rollen abgebildet und in der optionalen zweiten Stufe die eventuell vorhandenen Rollen, sodass sich folgende Struktur ergibt (Quelle: [Sch06]): Gruppe 1 Rolle 1 Rolle 2 Rolle 3 Gruppe 2 Rolle 1 Rolle 2 Rolle 3 17

22 2 Grundlagen Das hat zur Folge, dass die Anzahl der zu bildenden Gruppen während der Modellierungsphase zur Zeit des Exports feststehen muss. Die im IMS/LD-Export des Editors erzeugte Gruppenstruktur basiert daher auf den in MoCoLaDe definierten Teilnehmern und Gruppenformationen. In der IMS/LD-Laufzeit können daher keine zusätzlichen Gruppen mehr angelegt oder überflüssige Gruppen gelöscht werden. IMS/LD selbst definiert auch keine einzelnen Teilnehmer und so besteht auch keinerlei Möglichkeit, die zuvor beschriebenen Teilnehmer-Properties zu nutzen. IMS/LD bietet die Möglichkeit, eine locpers-property zu definieren, deren Wert zur Laufzeit für jeden Teilnehmer einzeln gespeichert wird ([IMS03c]). Da diese Property jedoch für alle Teilnehmer einen einheitlichen Initialwert definiert, ist deren Semantik aber nicht mit den Teilnehmerattributen in MoCoLaDe vergleichbar, deren Werte für jeden Teilnehmer individuell festgelegt werden können. Da die Teilnehmer-Properties bei MoCoLaDe derzeit aber nur zur Gruppenformation genutzt werden können und die Implementierung von Gruppenformationsalgorithmen in IMS/LD derzeit sowieso nicht implementierbar ist, sind die zu erwartenden Implikationen bzgl. des Monitorings wahrscheinlich vernachlässigbar. Ein gewisser Komfortverlust geht dagegen damit einher, dass auch die definierte Teilnehmerliste nicht in IMS/LD exportiert werden kann. Dies macht es notwendig, die Teilnehmer in der Laufzeitumgebung manuell anzulegen und sie den korrekten Gruppen und Rollen zuzuweisen Rollen und Ressourcen Ferner können in IMS/LD auch die CoSSICLE-Konzepte zur dynamischen Rollen- und Ressourcenzuteilung nicht ausgedrückt werden. Die Rollen müssen daher den Teilnehmern manuell durch den Tutor zugewiesen werden. Ein automatischer Wechsel der Rollen ist in IMS/LD ebenfalls nicht definierbar, wodurch auch das Prinzip der Rollenrotation im exportierten Skript wegfällt. Dies ließe sich in der derzeitigen Form nur durch manuelles Wechseln der Rollen während der Laufzeit durch den Tutor emulieren. Das Fehlen einer dynamischen Ressourcenzuteilung in IMS/LD versucht der MoCoLaDe- Editor durch die Definition von sogenannten Environments auszugleichen. Environments werden in IMS/LD mit Aktivitäten verknüpft und definieren u.a. eine Liste von für die Aktivität zur Verfügung zu stellenden Ressourcen. Diese Definition kommt der von MoCoLaDe recht nahe. Die Informationen über die in einer bestimmten Aktivität vorhandenen Ressourcen kann jedoch nur im Simulation-Export bestimmt werden ([Sch06]). In MoCoLaDe definierte Ressourcen stehen daher beim Model-Export nicht zur Verfügung. Problematisch sind aber trotzdem fehlende Angaben bezüglich des Besitzers der Ressourcen. Wird in MoCoLaDe einem Teilnehmer eine Ressource zugeteilt, ist dieser per Definition der alleinige Besitzer, während bei der Zuteilung von Ressourcen an eine Gruppe alle Mitglieder den Zugriff haben und sich die Ressourcen teilen. Die Gruppe ist in diesem Fall der Besitzer. In IMS/LD fehlen diese Informationen. Hier zeichnet sich neben dem Informationsverlust evtl. ein Darstellungsproblem ab. 18

23 2.4 IMS Learning Design Aktivitätssteuerung Ein eher größeres Problem für den Skriptablauf als auch für das Monitoring bedingt der Umstand, dass sich in MoCoLaDe gemäß Vorgabe ganze Gruppen stets gemeinsam durch das Skript bewegen, in IMS/LD jedoch der einzelne Benutzer weitestgehend unabhängig von den anderen agiert. In MoCoLaDe bearbeiten per Konvention stets alle Teilnehmer einer Gruppe die gleiche Aktivität, wie es für kollaborative Szenarien notwendig sein kann. IMS/LD betrachtet den Aktivitätsfluss jedoch individuell für jeden Teilnehmer getrennt von allen anderen. Dies hat zunächst zwei Auswirkungen zur Folge: Gruppen können auseinanderdriften. Ein Teilnehmer kann eine Aktivität für sich selbst bereits als abgeschlossen markiert haben und schon zur nächsten Aktivität fortgeschritten sein, während die anderen Gruppenmitglieder noch die alte Aktivität bearbeiten, womöglich ohne von dem Aktivitätsabschluss des einzelnen Benutzers zu erfahren. Die Teilnehmer können so beliebig weit auseinanderdriften, was für gerade kollaborative Aktivitäten sicherlich nicht wünschenswert ist. Bei der Nutzung des Model-Exports kommt erschwerend hinzu, dass im Falle einer Verzweigung auch die Entscheidung, welche Aktivität bearbeitet wird, von jedem Teilnehmer einzeln getroffen werden kann. So kann es zum einen passieren, dass ein Gruppenmitglied sich für eine andere Aktivität entscheidet, als alle anderen Mitglieder der Gruppe. Kennzeichnet er diese Aktivität auch noch als abgeschlossen, bewegen sich die Gruppenteilnehmer u.u. auf unterschiedlichen Pfaden durch das Skript und können evtl. gar nicht mehr zusammenfinden. Beide Fälle können und werden vom Export nicht abgefangen. Ihre Auswirkungen werden beim Monitoring bei der Suche nach einer geeigneten Darstellung zu bedenken sein. Dieser Semantikunterschied zwischen MoCoLaDe und IMS/LD führt aber auch zu einer fehlerhaften Behandlung der Gruppenproperties. Angenommen mit einer Sequencing- Kante wäre die Inkrementierung einer Gruppen-Property verbunden, dann würde in MoCoLaDe jedes Mal, wenn die Gruppe über diese Kante zur nächsten Aktivität wechselt, die Property einmal inkrementiert werden. Da sich in IMS/LD jedoch die Benutzer einzeln durch das Skript bewegen, produziert fälschlicher Weise jedes einzelne Gruppenmitglied bei diesem Übergang eine Inkrementierung dieser Property. Der Wert der Property wird im IMS/LD-System also von dem nach MoCoLaDe erwarteten Wert abweichen. Ein weiterer Unterschied bei der Behandlung des Aktivitätsflusses besteht in der unterschiedlichen Behandlung von Übergängen von einer Aktivität zur nächsten. Bei den derzeit exportierten IMS/LD-Skripten kennzeichnet ein Teilnehmer eine Aktivität als abgeschlossen und die nachfolgenden Aktivitäten werden für ihn sichtbar. Im Falle einer Verzweigung (betrifft nur Model-Export) hat der Nutzer nun die freie Wahl zwischen mehreren Aktivitäten. Von denen wird er schließlich eine bearbeiten allerdings ohne seine Entscheidung vorher bekannt geben zu müssen und sich damit festzulegen. Er kann also beliebig zwischen allen sichtbaren Aktivitäten hin- und herschalten. Für das System wird die Wahl des Benutzers erst durch das als abgeschlossen Markieren einer Aktivität sichtbar. In MoCoLaDe dagegen werden die Übergänge diskret durch das Aktivieren einer Sequencing-Kante ausgelöst. Semantisch umfasst dies sowohl den Abschluss der Aktivität (für 19

24 2 Grundlagen die gesamte Gruppe) als auch die Festlegung der Folgeaktivität. Für das Monitoring des IMS/LD-Systems wird der oben beschriebene Zustand schwerlich auf das MoCoLaDe- Skript abzubilden sein, da die Festlegung auf die Folgeaktivität nicht entschieden ist und damit nicht beobachtbar sein wird. Verschiedene Ansätze werden in Kapitel 3 diskutiert werden Weitere Einschränkungen Die beiden Knotentypen End-Zustand und Hilfsknoten Komponentenzuweisung finden keine Entsprechung in IMS/LD. Sie werden beim Export übergangen, sodass hier eine semantische Lücke entsteht, die evtl. durch andere Informationen zu rekonstruieren ist. In [Sch06] wurde gezeigt, dass an Sequencing-Kanten gebundene Aktionen, wie z.b. die Modifikation einer Gruppen-Property, beim Export das Einfügen einer sog. Dummy- Aktivität notwendig macht (Abbildung 2.14). Eine in MoCoLaDe definierte Aktivität wird somit auf zwei IMS/LD-Aktivitäten abgebildet. Auch dieser Sonderfall wird im Monitoring-Modul betrachtet werden müssen. Des Weiteren werden Zerlegungen in Subaktivitäten im Export nicht berücksichtigt. Sie werden daher auch vom Monitoring nicht erfasst werden können. Abbildung 2.14: Aktionen, die an eine Sequencing-Kante gebunden sind (a), müssen beim IMS/LD-Export durch das Einfügen einer Dummy-Aktivität (b) abgebildet werden, Quelle [Sch06] 20

25 2.5 CopperCore Runtime 2.5 CopperCore Runtime CopperCore gilt als die Referenzimplementierung einer IMS/LD-Laufzeitumgebung und wird von der OUNL entwickelt. Der IMS/LD-Export des Editors wurde für diese Laufzeitumgebung optimiert und darauf getestet. So wird sich auch die Implementierung der zu entwickelnden Erweiterung auf dieses System konzentrieren. Im Folgenden soll u.a. auf die technischen Grundlagen von CopperCore eingegangen werden, da diese maßgeblich spätere Entscheidungen bezüglich der Implementierung beeinflussen werden. Die Software steht unter einer OpenSource-Lizenz und kann unter [OUNa] als Paket (CopperCore Runtime, CCRT) bezogen werden. CopperCore setzt als Laufzeitumgebung einen JBoss Application Server >= 4.0 voraus, der kostenlos von [JBo07] bezogen werden kann. JBoss stellt CopperCore eine zu Java Enterprise (Java EE 3 ) kompatible Umgebung und einige properitäre Erweiterungen zur Verfügung Java Enterprise Die Java EE-Spezifikation baut auf der Java Standard Edition (Java SE) auf und definiert eine Laufzeitumgebung für skalierbare mehrschichtige (Multi-Tier-)Systeme ([Sun07]). Java EE spezifiziert außerdem die in der Laufzeit zur Verfügung stehenden APIs und Services (Abbildung 2.15), die ein kompatibler Applikationsserver implementieren muss. Abbildung 2.15: Nutzbare APIs und Services einer Java EE Applikation, Quelle [Sun07] CopperCore nutzt von den Java EE Services u.a. JNDI und JMS. Beide werden wahrscheinlich auch von der Monitoringkomponente zu nutzen sein und sollen daher kurz vorgestellt werden. 3 Akronyme für Java Enterprise 1.2 bis 1.4: J2EE, >= 1.5: Java EE 21

26 2 Grundlagen Java Naming and Directory Interface Das Java Naming and Directory Interface (JNDI) ist ein Namensverzeichnis für Objekte. In einem Client wird es genutzt, um über den Namen einer Komponente eine Objekt-Referenz auf diese zu bekommen. Mit der Referenz können die Methoden des Objekts aufgerufen werden. Das besondere an dieser Technik ist, dass dieser Mechanismus auch transparent über das Netzwerk funktioniert. Das JNDI muss u.a. genutzt werden, um die von CopperCore zur Verfügung gestellten EJB-Schnittstellen (s.u.) nutzen zu können. Die CopperCore-Schnittstellen sind im JN- DI unter festgelegten Namen verzeichnet, die der Client kennt und darüber durch das JNDI die Referenz zu den Schnittstellen bekommt. Java Message Service Der Java Message Service (JMS) ermöglicht es verteilten Anwendungen, transparent und asynchron Nachrichten auszutauschen. Dabei müssen Sender und Empfänger nicht unbedingt zur gleichen Zeit verfügbar sein. JMS unterstützt Techniken zur zuverlässigen Nachrichtenzustellung und zur Zwischenspeicherung von Nachrichten, wenn der Empfänger vorübergehend ausgefallen ist. Dabei werden zwei Zustellungstechniken unterschieden (Abbildungen 2.16 und 2.17): Point-to-Point Messaging Domain Clients schicken ihre Nachrichten an eine Queue. Die Queue hat genau einen Empfänger. JMS stellt sicher, dass die Nachrichten zuverlässig und in korrekter Reihenfolge den Empfänger erreichen. Abbildung 2.16: JMS: Point-to-Point (PtP) Betiebsmodus (Quelle: [Sun07]) Publish/Subscribe Messaging Domain Clients senden JMS-Nachrichten an ein Topic. Für das Topic können sich beliebig viele Clients als Empfänger registrieren und dabei bestimmte Eigenschaften der Benachrichtigung selbst bestimmen, wie z.b. ob die Zustellung zuverlässig sein muss oder nicht. JMS stellt sicher, dass alle registrierten Clients die Nachrichten in korrekter Reihenfolge erhalten. Das Konzept ähnelt grob dem EventListener-Modell von Java-AWT. CopperCore nutzt JMS zur internen Verteilung bestimmter Ereignistypen 4. 4 CopperCore definiert einen Timer, der in regelmässigen Abständen über JMS eine MessageDrivenBean (MDB) informiert, die dann in IMS/LD definierbare zeitabhängige Aufgaben abarbeitet. 22

27 2.5 CopperCore Runtime Abbildung 2.17: JMS: Publish/Subscribe Betiebsmodus (Quelle: [Sun07]) CopperCore Komponenten CopperCore ist als Java EE Applikation implementiert und gliedert sich daher in mehrere Komponenten, die sich unterschiedlichen Schichten zuordnen lassen. Dazu gehören die drei Folgenden: Engine (Business Tier) Diese Komponente stellt das eigentliche Herz von CopperCore dar und umfasst die gesamte Laufzeitumgebung für IMS/LD-Skripte. UOL-Pakete werden auf der CopperCore-Engine publiziert, wobei sie auf Validität geprüft und gespeichert werden. Die publizierten Skripte können in der Engine beliebig oft instanziert werden. Jede einzelne Instanz der sogenannte Run verfügt über einen eigenständigen Satz von Zustandsinformationen. Die Engine kümmert sich um die Verwaltung dieser Zustände als auch um alle in IMS/LD definierten Abläufe. Die CopperCore Engine stellt ihre Dienste ausschließlich über zwei EJB-Objekte zur Verfügung, die auch als WebService ansprechbar sind ([OUNc]): LDCourseManager und LDEngine (Abbildung 2.19). Alle Software, die CopperCore-Dienste nutzen möchte, um z.b. Zustandsinformationen eines Skripts zu erfragen, Ereignisse auszulösen (z.b. das Abschließen einer Aktivität) oder um Verwaltungsaufgaben auszuführen, muss auf diese beiden Schnittstellen zurückgreifen. Auch die bei CopperCore mitgelieferten Komponenten nutzen diese Schnittstellen Webplayer (Web Tier) Der Webplayer bietet eine webbasierte Benutzerschnittstelle für Lernende. Im Browser sieht der Lerner u.a. seine aktuell zu bearbeitenden Aktivitäten und die dafür zur Verfügung stehenden Ressourcen (Abbildung 2.18). An dieser Stelle sollte angemerkt werden, dass der Webplayer nur eine mögliche Implementierung eines Clients für CopperCore darstellt. Ein CopperCore-Client muss nicht zwingend als Webanwendung implementiert werden. Clicc (Client Tier) Der Webplayer verfügt über keinerlei Verwaltungsfunktionalität für die CopperCore-Engine. Die einzige mitgelieferte Benutzerschnittstelle mit Möglichkeit, in CopperCore z.b. Benutzer anzulegen oder ihnen in einem Skript eine Rolle zuzuweisen, ist das Command Line Interface to CopperCore (Clicc). Clicc stellt über eine Kommandozeile nahezu den gesamten Funktionsumfang der zwei zentralen EJBs von CopperCore zur Verfügung. 23

28 2 Grundlagen Abbildung 2.18: CopperCore Webplayer stellt ein nach IMS/LD exportiertes MoCoLaDe-Skript dar Das Tool ist aber nur eine Art Wrapper zum Aufruf der EJB-Methoden und gibt auch deren Rückgabe ungefiltert auf der Kommandozeile aus. Da viele der EJB- Methoden teils recht komplexe XML-Strukturen als Rückgabewert haben, ist dessen Benutzung jedoch wenig komfortabel. 24

29 2.5 CopperCore Runtime Abbildung 2.19: Die CopperCore EJB-Schnittstellen LDCourseManager und LDEngine (und die Home-Interfaces) 25

30 2 Grundlagen 26

31 3 Ansatz 3.1 Anforderungen Entwickelt werden soll die Erweiterung des MoCoLaDe-Editors um einen Rückkanal von der CopperCore Engine zum Editor. Dieser soll genutzt werden, um die Fortschritte der einzelnen Nutzer oder Gruppen auf ihren jeweiligen Lernpfaden widerzuspiegeln (Monitoring). Damit soll dem Verantwortlichen ein besserer Überblick über die Lernsituation gegeben werden, damit dieser helfend in ggf. auftretenden Problemsituationen eingreifen kann. Zur Unterstützung der Bereinigung dieser Problemsituationen sollen Interventionsmöglichkeiten angeboten werden, mit denen auf den Lernprozess Einfluss genommen werden kann. Diese sollen durch Nutzung der CopperCore API oder durch den Nachrichtenversand an Kursteilnehmer implementiert werden. Die geplante Erweiterung des Editors, sollte sich optisch nahtlos integrieren. Wenn möglich sollen bisherige im Editor verfügbare Visualisierungen für das Monitoring und die Intervention wiederverwendet werden, um die Bedienung einheitlich und damit intuitiv zu gestalten Funktionsumfang Um die Entwicklung der geplanten Erweiterung zielgerichtet durchführen zu können, soll zunächst der geplante Funktionsumfang spezifiziert werden Verbindungsaufbau und Monitoring Die Komponente wird zu Beginn eine Verbindung zu einem CopperCore-Server aufbauen müssen, die anschließend als Grundlage des Monitorings und der Interventionsmechanismen dienen soll. Bezüglich Verbindungsaufbau und Monitoring sind folgende Funktionen geplant: Konfigurierbarkeit des Servernamens Der Servername sollte weder fest im Quellcode definiert, noch in einer Property-Datei verborgen sein, sondern in der GUI definierbar sein, um dem Benutzer die Möglichkeit zu bieten, sich mit beliebigen verfügbaren CopperCore-Servern zu verbinden. 27

32 3 Ansatz Erkennung der korrekten UOLs Aus den auf dem CopperCore-Server verfügbaren UOLs müssen diejenigen bestimmt werden, die auf Basis des gerade im Editor geladenen MoCoLaDe-Skripts exportiert wurden. Alle anderen dürfen nicht für den Verbindungsaufbau zur Verfügung stehen. So soll sichergestellt werden, dass die Monitoring- und Interventionsfunktionen sich auf das korrekte Skript beziehen. Automatischer Zustandsupdate Der Zustand der IMS/LD-Laufzeit soll regelmäßig automatisch aktualisiert werden, um Zustandsänderungen zeitnah beobachten zu können. Logging Um dem Tutor die Möglichkeit zu bieten, den Überblick über mehrere gleichzeitige Skriptläufe zu behalten, soll ein Logfile mitgeschrieben werden. Dies sollte auch im Editor einsehbar sein und möglichst alle beobachtbaren Zustandsänderungen festhalten, um auch nachträglich den kompletten Verlauf nachvollziehen zu können. Globale Teilnehmerübersicht Eine der wichtigsten Funktionen für das Monitoring wird die globale Teilnehmerübersicht sein. Hieraus soll hervorgehen, welche Teilnehmer an dem Kurs angemeldet sind, welche Aktivitäten sie gerade ausführen und welcher Gruppe/Rolle sie angehören. Teilnehmerposition Hier soll außerdem die Möglichkeit geboten werden, die Position eines Teilnehmers oder mehrerer Teilnehmer im MoCoLaDe-Skript darzustellen. Hierzu wird es notwendig sein, ein geeignetes Mapping zur Abbildung von IMS/LD-Aktivitäten auf die Aktivitätsknoten im MoCoLaDe-Skript zu entwickeln. Node Details Die bisherige Ansicht Simulation Details soll für das Monitoring wiederverwendet werden und soll bezogen auf einen zuvor selektierten Knoten die in diesem Knoten befindlichen Teilnehmer/Gruppen darstellen. Da die Sicht dann neben der Simulation auch für das Monitoring genutzt werden wird, soll diese in Node-Details umbenannt werden. Indikator für inkonsistenten Zustand Wie zuvor beschrieben (Abschnitt ), können in IMS/LD im Gegensatz zu MoCoLaDe Gruppen auseinandergerissen werden, sodass Gruppenteilnehmer unterschiedliche Aktivitäten ausführen. Tritt ein solcher für MoCoLaDe inkonsistenter Zustand ein, soll dies optisch kenntlich gemacht werden. Des Weiteren sollte es möglich sein, die Positionen aller Gruppenmitglieder auf einen Blick erfassen zu können, um erkennen zu können, wieso eine Gruppe als auseinandergerissen markiert wird. Ressourcen und Properties Auch die Verteilung der Ressourcen (sofern ermittelbar) und die Werte der Properties sollen in geeigneter Weise visualisiert werden Intervention Die Interventionsfunktionen sollen Einflussmöglichkeiten auf die Skriptausführung bieten. Geplant sind derzeit die folgenden Funktionen: Gruppen-/Rollenzuweisung Da IMS/LD Mechanismen zur Gruppenformation und zur automatischen Rollenzuweisung fehlen, soll eine entsprechende manuelle Zuweisungsmöglichkeit implementiert werden. Damit soll es auch möglich sein, während der Laufzeit die den Teilnehmern zugewiesenen Rollen zu wechseln, um 28

33 3.1 Anforderungen ggf. die in IMS/LD nicht abbildbare Rollenrotation manuell nachahmen zu können. Außerdem ist es mit dieser Funktion möglich, die Rollen ausgefallener Teilnehmer mit anderen Teilnehmern zu besetzen, um ein Fortschreiten zu ermöglichen. Aktivitätsabschluss für Benutzer Ist ein Benutzer einer Gruppe nicht verfügbar, mag es wünschenswert sein, dass der Tutor die Möglichkeit hat, stellvertretend für den fehlenden Teilnehmer zu agieren und eine Aktivität als abgeschlossen zu markieren, damit die Gruppe fortfahren kann. Benutzer anlegen/hinzufügen Auch die Definition der Teilnehmerliste ist in IMS/LD nicht möglich. Also soll auch eine Möglichkeit geschaffen werden, Teilnehmer in der Laufzeit anzulegen und für den beobachteten Kurs anzumelden. Nach Möglichkeit soll hier auch eine Funktion geschaffen werden, die Teilnehmerliste aus MoCoLaDe zu übernehmen und sie gleich den jeweiligen Gruppen zuzuordnen. Nachrichtenversand Um indirekten Einfluss auf das Geschehen nehmen zu können, soll eine Funktion geschaffen werden, den Teilnehmern eine Nachricht schicken zu können. Ohne eine solche Funktion bestünde technisch gesehen keine Möglichkeit mit den Teilnehmern in Kontakt zu treten. Modifikation von Properties Properties spielen im Zusammenhang mit bedingten Verzweigungen eine große Rolle für die Ablaufsteuerung in MoCoLaDe- Skripten. So erscheint es sinnvoll, auch eine Funktion zur Modifikation der Property-Werte zu implementieren Nutzung von Standards Soweit möglich sollten im Sinne der Interoperabilität und späteren Wartbarkeit weitestgehend auf Standards und etablierte Frameworks zurückgegriffen werden. Dies betriff z.b. sowohl die mögliche Ausnutzung der Standard-CopperCore-API, Nutzung der standardisierten JavaEE-Laufzeitumgebung als auch die Nutzung standardisierter Datenformate und etablierter Visualisierungsmöglichkeiten im Bereich des Monitorings Minimale Invasivität Wahrscheinlich wird es zur Implementierung des geplanten Funktionsumfangs unumgänglich sein, technische Modifikationen an CopperCore vorzunehmen. Da nicht ohne weiteres davon auszugehen ist, dass die entstehenden Modifikationen kurzfristig in den offiziellen CopperCore-Quellcode einfließen werden, sollte nach dem Prinzip der minimalen Invasivität vorgegangen werden, um die eigentlichen Änderungen am CopperCore- Quellcode so gering wie möglich halten. Umfangreichere Funktionen sind hier so weit wie möglich zu kapseln, sodass die eigentliche Modifikation im CopperCore-Quellcode auf das minimal Notwendige reduziert wird. 29

34 3 Ansatz 3.2 Entwurf der Monitoringfunktionen Identifikation der UOL Soll eine UOL auf dem Server im Editor beobachtet werden, muss sichergestellt werden, dass das korrekte Skript geladen ist, das für den Export dieser UOL verantwortlich war. Andernfalls kann nicht sichergestellt werden, dass eine vernünftige Abbildung des Server-Zustands auf das MoCoLaDe-Skript gefunden werden kann, da evtl. eine ganz andere Aktivitätsstruktur vorliegt. Naheliegend ist es daher, beim Verbindungsaufbau einen Vergleich zwischen geladenem MoCoLaDe-Skript und den verfügbaren UOLs durchzuführen und nur den Start einer Monitoring-Session zu UOLs zuzulassen, die mit diesem Skript exportiert wurden. UOL und MoCoLaDe-Skript lassen sich jedoch nicht direkt auf Übereinstimmung vergleichen und so muss ein geeigneter Mechanismus gefunden werden. Denkbar sind die folgenden zwei Vergleichsmethoden: Skript-ID Eine UOL verfügt in ihrem Manifest neben einem beschreibenden Namen über eine eindeutige ID, über die sie von den anderen UOLs unterschieden werden kann. Auf einem CopperCore-Server können nie mehrere UOLs mit derselben ID parallel publiziert werden. Ein MoCoLaDe-Skript bietet eine solche ID derzeit jedoch nicht, die man hierfür heranziehen könnte. Denkbar wäre, den Dateinamen des Skripts als ID heranzuziehen oder eine UUID (Universally Unique Identifier) künstlich einzufügen. Beide Methoden hätten allerdings den Nachteil, dass auch gravierende Veränderungen des Skripts wie z.b. das Löschen von Aktivitäten keine Auswirkungen auf die ID hätten. Das Skript würde jedoch nicht mehr mit dem übereinstimmen, das die Grundlage des IMS/LD-Exports war. So wären Inkonsistenzen beim Monitoring nicht auszuschließen. Als Alternative könnte man zusätzlich noch die Modifikationszeitstempel der Skript- Datei mit in den Vergleich einbeziehen. Dieser würde sich allerdings schon bei einem Kopiervorgang ändern und eine Übereinstimmung trotz gleichen Inhalts ausschließen. Hash Basierend auf der Freestyler-Datei, die das MoCoLaDe-Skript enthält, könnte ein Hash berechnet werden, der beim Export in die UOL eingebettet wird. Dieser wäre theoretisch unabhängig vom Modifikationszeitstempel der Datei und dem Dateinamen und würde sich nur auf die Inhaltsgleichheit der Datei stützen. Dies wird jedoch evtl. die Vorbedingung mit sich bringen, dass MoCoLaDe-Skripte vor dem IMS-Export gespeichert werden, damit der Hash berechnet werden kann. Die Berechnung des Dokumentenhashs bietet wesentliche Vorteile und soll als Vergleichsmethode herangezogen werden. Der Hash soll an geeigneter Stelle in die UOL eingebettet werden, sodass er beim Verbindungsaufbau ausgewertet werden kann. Hier bieten sich mehrere Möglichkeiten der Einbettung an: Name/ID der UOL Der Hash könnte als Name oder ID der UOL übernommen werden. Bei der Nutzung des Namens würde dieser allerdings als beschreibendes Element wegfallen. Die Nutzung der ID zieht nach sich, dass immer nur genau eine vom Skript exportierte UOL auf dem Server gleichzeitig publiziert werden kann. Das heißt, dass auch nur ein einziger Simulationsablauf publiziert werden könnte. 30

35 3.2 Entwurf der Monitoringfunktionen Um jedoch verschiedene Skriptabläufe mit unterschiedlich gewählten Aktivitäts- Pfaden exportieren zu können, ist eine solche mehrfache Publizierung notwendig. IMS/LD-Property Eine IMS/LD-Property würde sich auch eignen, den Hashwert aufzunehmen. Die CopperCore-API verfügt jedoch leider über keine Möglichkeit, eine Property auszulesen, ohne dass ein Benutzer an einem Skript-Run angemeldet ist. Wurde eine UOL gerade erst publiziert, ließe sich der Hash der UOL unter Nutzung der CopperCore-API so also nicht bestimmen. Eine Möglichkeit zur Abhilfe bestünde in der Modifikation von CopperCore. Ressource Eine meiner Ansicht bessere Alternative stellt die Speicherung des Hashs in einer externen Datei dar. Da die UOL als ZIP-Archiv exportiert wird, ließe sich diese mit in das Archiv als LD-Ressource einbetten. Diese Methode soll weiterverfolgt werden, da außerdem die Möglichkeit bestünde, im Bedarfsfall weitere Meta-Daten in diese Datei aufzunehmen Automatischer Zustandsupdate Um den Nutzer automatisch über Zustandsänderungen auf dem Server informieren zu können, kommen zwei Strategien in Frage: regelmäßiges Polling des kompletten Zustands ein Mechanismus zur Benachrichtigung des Clients bei Zustandsänderungen Das Polling hat den Vorteil, dass es ohne Veränderungen an CopperCore auskommt. Die Nachteile, die meiner Meinung jedoch überwiegen, sind Trägheit, erzeugter Netzwerk- Traffic und eine massive Serverbelastung durch die überwiegend unnötigen Update- Anfragen. Möchte man die Belastung des Servers reduzieren, bietet sich nur die Möglichkeit, die Zeitabstände zwischen den Polling-Updates wesentlich zu vergrößern. Damit einher käme allerdings das Kriterium der damit gleichermaßen erhöhten Latenz. Eine wesentlich elegantere Methode, die allerdings einer Modifikation am CopperCore bedarf, ist den Client über potenzielle Statusänderungen zu informieren. Hierzu kann entweder ein geeigneter Mechanismus selbst entwickelt werden oder z.b. auf eine Message Oriented Middleware (MOM) zurückgegriffen werden. Die Java EE-Laufzeitumgebung, in der CopperCore abläuft, bringt eine solche in Form von JMS gemäß der Spezifikation bereits mit (siehe Abschnitt 2.5.1). CopperCore müsste also zur Implementierung dieser Funktionalität nur an geeigneter Stelle derart modifiziert werden, bei intern auftretenden Ereignissen, die Zustandsänderungen hervorrufen können, über JMS dieses Ereignis auf einem Topic zu publizieren. Der Editor könnte sich als Listener für dieses Topic registrieren, sodass er vom JBoss-Server über das Ereignis informiert wird und kann dann das Update seines Zustands veranlassen. Der Ansatz, CopperCore um die Verteilung der inneren Ereignisse über ein JMS-Topic zu erweitern, wurde bereits in [HMW] beschrieben und erfolgreich für die Benachrichtigung eines Clients genutzt. Bei der in [HMW] genutzten Implementierung wurden auf CopperCore-Seite alle für den Client benötigten Zustandsinformationen gesammelt, in eine JMS-Message verpackt und auf dem Topic publiziert. 31

36 3 Ansatz Dass die Zustandsinformationen schon auf der Serverseite gesammelt und als einzige JMS-Nachricht publiziert werden, hat sicherlich einen nicht vernachlässigbaren Performancevorteil. Erkauft wird dies jedoch mit der impliziten Annahme, alle für den Client notwendigen Zustandsdaten zu kennen, damit dieser keine weiteren Anfragen zur Darstellung des Zustands mehr senden muss. Diese Lösung ist weder minimal invasiv implementierbar noch für weitere Projekte universell einsetzbar, da die enthaltenen Daten für einen bestimmten Clienttyp ausgelegt sind. Damit wäre wahrscheinlich von vornherein ausgeschlossen, dass die Modifikation in den offiziellen CopperCore-Code übernommen werden könnte. Die Beschränkung auf die Übermittlung einer einfachen Nachricht, die nur Informationen über das ausgelöste Ereignis enthält, macht die Benachrichtigungsfunktion auch für andere Clienttypen universell einsetzbar und ist daher an dieser Stelle sinnvoller. Die Beschaffung der zur Abbildung des Zustands notwendigen Daten soll auf die Client- Implementierung verlegt werden, wo nachfolgende Abfragen durchführt werden können. Dadurch wird die Servermodifikation vergleichsweise leichtgewichtig ausfallen und ist Client-unabhängig. Sollte sie in das offizielle CopperCore-Projekt einfließen, wäre sie damit auch von anderen Anwendungen als der hier geplanten ohne Einschränkungen nutzbar Darstellung der Teilnehmerpositionen Zur Darstellung der Teilnehmerposition(en) in der Aktivitätensequenz muss eine geeignete Darstellung gefunden werden. Um die Darstellung intuitiv zu gestalten, ist es naheliegend, sich an die Visualisierungskonzepte anderer Monitoringtools für grafische Prozessflüsse anzulehnen. Exemplarisch sollen hierzu kurz betrachtet werden das Workflow-Monitoring in BEA WebLogic Studio (Abbildung 3.1) und der Workflowmonitor als Teil von Microsoft Visual Studio 2005 (Abbildung 3.2). Beide Tools nutzen unterschiedliche Diagrammtypen zur Visualisierung der Prozessflüsse (BEA WebLogic: Flussdiagramm, Microsoft Visual Studio: Statechart), im Grundkonzept ähneln sie sich jedoch und sind grundsätzlich mit der Darstellung des Aktivitätsverlaufs in MoCoLaDe vergleichbar: Aktivitäten werden als Knoten dargestellt, Übergänge zwischen diesen als Kanten. Beiden gemeinsam ist außerdem, dass sie die Aktivitäten in drei unterschiedlichen Zuständen optisch auszeichnen: aktuell aktive Aktivität abgeschlossene Aktivitäten inaktive/nicht besuchte Aktivitäten BEA WebLogic nutzt zur Auszeichnung eine farbliche Unterlegung der Aktivitätsknoten, während bei dem Produkt von Microsoft kleine Symbole den Status kenntlich machen. Ähnlich soll die Darstellung des Aktivitätsverlaufs eines Teilnehmers auch in MoCoLaDe dargestellt werden. 32

37 3.2 Entwurf der Monitoringfunktionen Abbildung 3.1: Workflow-Monitoring in BEA WebLogic Studio weiss: inaktive, grau: abgeschlossene, grün: aktive Aktivität, Quelle: [BEA01] Abbildung 3.2: Microsoft Visual Studio 2005, Workflowmonitor kein Symbol: inaktive, Haken: abgeschlossene, Play-Icon: aktive Aktivität, Quelle: [Sme06] 33

38 3 Ansatz Zur optischen Hervorhebung von Knotenelementen in FreeStyler entwickelte bereits Michael Vetter 2007 [Vet07] eine Highlighting-Funktion. Diese nutzt zur optischen Hervorhebung einen farbigen Rahmen um das Knotenelement (Abbildung 3.3). Abbildung 3.3: Highlighting im FreeStyler, Quelle [Vet07] Derzeit unterstützt die API nur das Ein- und Ausschalten des Highlightings es lassen sich so also nur zwei Auszeichnungen unterscheiden. Das Ziel ist aber, wie die zuvor betrachteten Monitoring-Tools drei optische Auszeichnungen darstellen zu können. Ich werde daher die vorhandene API um die Vorgabe der Rahmenfarbe erweitern. Inaktive/nicht besuchte Aktivitäten sollen ohne Rahmen dargestellt werden, abgeschlossene Aktivitäten mit einem grünen Rahmen und die aktuell aktive Aktivität eines Teilnehmers soll mit einem roten Rahmen umrandet werden. In ersten Mockup-Tests hat sich jedoch gezeigt, dass die Darstellung gerade bei Verzweigungen noch schneller erfassbarer ist, wenn zusätzlich noch die am bisherigen Aktivitätsverlauf beteiligten Kanten optisch hervorgehoben werden, sodass dies in der verwendeten Darstellung genutzt werden soll (Abbildung 3.4). Abbildung 3.4: Geplante Darstellung des Aktivitätsverlaus durch Highlighting Wird mit dem Simulationsexport ein MoCoLaDe-Skript exportiert, das eine Schleife enthält, und soll anschließend im Monitoring-Modus die Aktivitätshistorie eines Teil- 34

39 3.2 Entwurf der Monitoringfunktionen nehmers dargestellt werden, so ist diese Darstellung jedoch nicht immer eindeutig. Hat der betrachtete Teilnehmer die Schleife bereits einmal durchlaufen, so ist zwar durch das Highlighting ersichtlich, dass er die Schleife bereits durchlaufen hat und welche Aktivität er gerade ausführt, jedoch ist die Information, wie oft er die Schleife bereits durchlaufen hat, durch die Darstellung nicht bestimmbar (Abbildung 3.5). Abbildung 3.5: Highlighting des Aktivitätsverlaufs in einer Schleife Dies ist eine wichtige Information, um daraus z.b. schließen zu können, wie oft er die Aktivitäten noch wiederholen wird oder ob alle Gruppenmitglieder im Skript gleich weit fortgeschritten sind. Es soll daher eine Funktion geschaffen werden, die durchlaufene Aktivitätshistorie textuell als Liste anzuzeigen, die dann wie folgt aussehen könnte (Fettdruck als Indikator für aktuelle Aktivität): 1. writing ideas 2. rotate papers 3. continue ideas 4. rotate papers 5. continue ideas 6. rotate papers Verzweigungen Wie bereits in Abschnitt erwähnt, unterscheidet sich die Steuerung des Aktivitätsflusses von MoCoLaDe zu dem von IMS/LD. Während mit der Aktivierung einer Sequencing-Kante in MoCoLaDe damit der Aktivitätsabschluss als auch die Festlegung auf die Folgeaktivität verbunden sind, kennzeichnet der Kursteilnehmer in der IMS/LD-Umgebung eine Aktivität nur als abgeschlossen, ohne sich auf die Folgeaktivität festzulegen. Der Teilnehmer befindet sich im Falle einer Verzweigung also in einer Art Zwischenzustand, der so im MoCoLaDe-Skript nicht vorgesehen ist: eine Aktivität ist abgeschlossen, aber noch keine der nachfolgenden kann als aktive Aktivität angesehen werden. 35

40 3 Ansatz Zur Darstellung dieses Zustandes bieten sich u.a. folgende Alternativen an: Black box Die einfachste Möglichkeit bestünde darin, diesen Zustand als nicht beobachtbar zu werten und die Position den Benutzers als unbekannt zu betrachten. Die zuvor abgeschlossene Aktivität würde entsprechend der obigen Konvention mit einem grünen Rahmen versehen und die nachfolgenden da keine Folgeaktivität ohne optische Auszeichnung belassen (Abbildung 3.6). Abbildung 3.6: Betrachtung der Teilnehmerposition als Black Box Diese Darstellung ist sehr einfach zu implementieren, erscheint jedoch als wenig befriedigend, da keinerlei Indikator für eine aktuelle Position gegeben wird. Künstlicher Zwischennode Eine weitere Möglichkeit bestünde darin, an allen Verzweigungsstellen einen künstlichen Hilfsknoten einzufügen, der in diesem Fall als Position des Teilnehmers betrachtet würde und entsprechend optisch hervorgehoben werden könnte. In Frage käme dafür z.b. der Hilfsknoten der Komponentenzuweisung (Abbildung 3.7). Semantisch wird die Position des Teilnehmers zufriedenstellend dargestellt, jedoch wird das Skript durch das Einfügen der Zwischenknoten unnötig aufgebläht, ohne dem eigentlichen MoCoLaDe-Skript etwas an Semantik hinzuzufügen. Highlighting der Sequencing-Edges Des Weiteren ließe sich diese Zwischenposition eines Teilnehmers so darstellen, dass die an der Verzweigung beteiligten Sequencing-Edges als aktuelle Position des Teilnehmers aufgefasst werden. Sie Abbildung 3.7: Darstellung mit künstlichem Zwischennode 36

41 3.2 Entwurf der Monitoringfunktionen würden dementsprechend wie eine Aktivität farblich rot unterlegt, um diesen Zustand darzustellen (Abbildung 3.8). Abbildung 3.8: Highlighting der Sequencing-Edges Die Darstellung setzt keine Modifikation der MoCoLaDe-Skripte voraus und ist trotzdem in der Lage, den Zwischenzustand darzustellen. Sie weicht jedoch leicht von der bisherigen Semantik von Knoten und Kanten in MoCoLaDe ab. In MoCo- LaDe kann eine Kante nicht als Teilnehmerposition gelten, aber gerade hier besteht ja der bereits beschriebene Konflikt im Monitoring des Zustandes des IMS/LD- Skripts und so halte ich diese Lösung für die bestmögliche Alternative unter den hier Vorgestellten. Diese Darstellung soll also in der Implementierung Verwendung finden. Mehrere Teilnehmer Die bisher gefundene Visualisierung erscheint zur Darstellung der Aktivitätshistorie und der aktuellen Position eines einzelnen Teilnehmers als ausreichend und intuitiv. Allerdings soll es auch möglich sein, die Teilnehmerpositionen einer beliebigen Gruppe von Teilnehmern zu visualisieren, die nicht grundsätzlich dieselbe Position im Skript haben müssen. In diesem Falle würde sich also die Darstellung mehrerer unterschiedlicher Aktivitäts- Historien überlagern, was sich in Versuchen als recht unübersichtlich erwiesen hat. Bei der Darstellung der Positionen von Teilnehmergruppen mit unterschiedlichen Historien sollen daher nur die jeweils aktuellen Positionen der Teilnehmer optisch hervorgehoben werden Ermittlung der Teilnehmerpositionen Das wichtigste Problem bei der Darstellung der Teilnehmerposition ist die Frage, wie diese zunächst technisch ermittelt werden können. Die CopperCore API bietet zur Ermittlung der für einen Benutzer sichtbaren Aktivitäten die Methode getactivitytree(). Ihr Rückgabewert ist eine komplexe XML-Datenstruktur, deren Syntax auf dem Schema von IMS/LD basiert ([OUNd]), davon jedoch nur einen kleinen Ausschnitt enthält. Ihr kann entnommen werden, welche Aktivitäten für den Benutzer sichtbar sind und welche davon evtl. bereits abgeschlossen sind. 37

42 3 Ansatz Eine konkrete Information, mit welcher Aktivität der Benutzer sich derzeit tatsächlich beschäftigt, ist nicht vorhanden. Theoretisch könnte der Teilnehmer beliebig zwischen allen sichtbaren Aktivitäten hin- und herspringen. So kann er auch bereits abgeschlossene Aktivitäten öffnen, ohne dass dies systemseitig festgestellt werden könnte. Im Allgemeinen wird dies für den Teilnehmer jedoch keinen Sinn machen und da an dieser Stelle keine weiteren Informationen zur Verfügung stehen, muss die Konvention getroffen werden, dass aktuell für den Benutzer sichtbare Aktivitäten, die noch nicht als abgeschlossen markiert wurden, seine aktuelle Position im Skript definieren. Ist für den Benutzer keine solche noch nicht abgeschlossene Aktivität sichtbar, stehen dem Teilnehmer keine Aktivitäten mehr zur Bearbeitung zur Verfügung. Es kann davon ausgegangen werden, dass entweder der Endzustand erreicht wurde oder eine Verklemmung vorliegt. Da der Endzustandsknoten aus MoCoLaDe keine Entsprechung in IMS/LD hat, können beide Fälle nur durch Prüfung dahin gehend unterschieden werden, ob die letzte abgeschlossene Aktivität durch eine Sequencing-Kante mit einem Endknoten verbunden ist oder nicht. Ist sie mit einem Endknoten verbunden, wird daraus gefolgert, dass der Endzustand erreicht ist und der entsprechende Knoten im MoCoLaDe-Skript wird hervorgehoben. Ermittelt werden kann so also theoretisch die aktuelle IMS/LD-Aktivität oder im Falle einer Verzweigung eine Liste von aktuellen Aktivitäten als Ausschnitt aus der XML- Datenstruktur von getactivitytree() (Listing 3.1). <learning - activity completed =" false " environment =" Activity -0" identifier =" Activity -0" isvisible =" true " time - limit =" false " user - choice =" true "> <title > Activity 1</ title > </ learning - activity > Listing 3.1: XML-Struktur einer IMS/LD-Aktivität Aus diesen Informationen muss für die zuvor beschriebene Darstellung das grafische Knotenobjekt im MoCoLaDe-Skript bestimmt werden, das im Folgenden entsprechend optisch markiert werden würde. Der Titel der IMS/LD-Aktivität stimmt bei den derzeitigen Exportstrategien mit dem Titel der MoCoLaDe-Aktivität überein, ist jedoch im Skript nicht zwingend eindeutig und kann daher so nicht zur Bestimmung des Knotens genutzt werden. IMS/LD-Aktivitäten können eindeutig über ihren identifier identifiziert werden (s. Listing 3.1). Knotenobjekte in FreeStyler und daher auch die Aktivitätsobjekte in MoCoLaDe verfügen ebenfalls über einen eindeutigen (Universally Unique) Identifier, beide weichen jedoch voneinander ab und können so nicht direkt verglichen werden. Da beim IMS/LD-Export von Schleifen (Simulation-Export) und beim Einfügen einer Dummy-Aktivität (Abschnitt ) eine MoCoLaDe-Aktivität auf mehrere IMS/LD- Aktivitäten abgebildet wird, kann auch nicht einfach der UUID von MoCoLaDe als Identifier für die IMS/LD-Aktivitäten herangezogen werden, da dieser im IMS/LD-Skript nicht mehr eindeutig wäre. Daher ist es notwendig, beim IMS/LD-Export das Mapping der MoCoLaDe Aktivitäts-UUIDs auf die generierten IMS/LD-IDs festzuhalten. In der Monitoring-Phase können mit diesen Mapping-Informationen wiederum die IMS/LD Aktivitäts-IDs in die korrekten UUIDs des MoCoLaDe-Skripts übertragen werden, wodurch 38

43 3.2 Entwurf der Monitoringfunktionen sich der korrespondierende grafische Knoten im Skript ermitteln lässt. Zur Speicherung dieses Mappings könnte die bereits in Abschnitt angesprochene Meta-Datei entsprechend erweitert werden Ermittlung der Teilnehmerhistorie Wie zuvor erwähnt, können aus dem AcitivtyTree auch die für einen Benutzer als abgeschlossen markierten Aktivitäten bestimmt werden. Der ActivityTree enthält aber keine Information darüber, wann eine bestimmte Aktivität abgeschlossen wurde, so dass diese nicht problemlos in eine sequenzielle zeitliche Abfolge übertragen werden können. An dieser Stelle werde ich mir die Eigenart der derzeitigen Exportstrategien zu Nutze machen, alle Aktivitätsstrukturen stets als sequenzielle Abfolge zu exportieren, die vom Benutzer (bezogen auf IMS/LD) nur in einer Richtung durchlaufen werden kann. So entspricht die sequenzielle Anordnung der abgeschlossenen Aktivitäten im ActivityTree auch der zeitlichen Abfolge, wie sie der Benutzer nacheinander bearbeitet hat. Sollte es später einmal durch eine Erweiterung von IMS/LD möglich werden, den Model- Export von MoCoLaDe um den Export von Schleifen zu erweitern, wird diese Strategie zu überarbeiten sein Globale Teilnehmer-/Gruppenübersicht Es soll eine Visualisierungsmöglichkeit gefunden werden, die es ermöglicht, auf einen Blick die Namen der an dem Kurs angemeldeten Teilnehmer und ihre Gruppen- und Rollenzugehörigkeit zu erfassen. Die bisher schon in der Ansicht Simulation Details verwendete Baumstruktur erscheint mir für diese Zwecke geeignet. Sie bietet nicht nur eine Übersicht über die Benutzer-Gruppen- und Rollenzugehörigkeit sondern auch über die Werte der Gruppen-Properties und der Verteilung der Ressourcen (Abbildung 3.9). Des Weiteren verfügt diese Komponente bereits über einen farblichen Indikator für ungültige Gruppenformationen (Abbildung 2.3), der wiederverwendet werden könnte, um eine auseinandergerissene Gruppe zu kennzeichnen. So lassen sich diese Informationen alle in einer Visualisierungskomponente darstellen und sich gleichzeitig bekannte Darstellungskonzepte nutzen. Derzeit nicht darstellbar in dieser Ansicht sind Benutzer, die noch keiner Gruppe zugeordnet sind, und die aktuelle Aktivität, die ein Teilnehmer gerade ausführt. Daher soll die Baum-Komponente um eine zweispaltige Tabelle ergänzt werden, die alle angemeldeten Teilnehmer und deren aktuelle Aktivität auflistet (Tabelle 3.1). User Position Paul writing ideas Alice rotate papers Alex writing ideas Bob no group assigned Tabelle 3.1: Schema der geplanten Benutzer-Positions-Tabelle 39

44 3 Ansatz Abbildung 3.9: Baumstrukturkomponente der Ansicht Simulation-Details Bei der Selektion eines Teilnehmers oder mehrerer Teilnehmer soll die aktuelle Position der Teilnehmer durch Highlighting im MoCoLaDe-Skript visualisiert werden. Validierung der Gruppenformationen Nach Möglichkeit sollen die Gruppenbesetzungen des IMS/LD-Runs hinsichtlich der im MoCoLaDe-Skript definierten Gruppenformations-Regeln validiert werden. Bei Verletzung der Regeln, soll die Gruppe in der globalen Teilnehmer- und Gruppenübersicht analog zur Simulationsansicht als ungültig gekennzeichnet werden. MoCoLaDe bietet derzeit drei Algorithmen für die Gruppenformation (Abschnitt 2.2.2): Nach Anzahl Nach Größe Separierung nach Attribut Die Gruppenstruktur für IMS/LD wird durch den Export fest definiert und lässt sich nachträglich nicht mehr modifizieren (Abschnitt ). Es lassen sich in der IMS/LD- Laufzeit also weder zusätzliche Gruppen anlegen noch welche entfernen. Das Kriterium Nach Anzahl muss also nicht validiert werden, da stets die beim Export gebildete Gruppenanzahl vorhanden ist, die entweder bereit zur Zeit des Exports als nicht korrekt dargestellt wird oder auch zur Zeit des Monitorings zulässig ist. Die Separierung nach Attribut stützt sich auf die Teilnehmerattribute, die in MoCoLaDe definiert sind, nach IMS/LD jedoch nicht exportiert werden können (Abschnitt ) und daher nicht ausgewertet werden können. Daher kann auch dieses Kriterium beim Monitoring nicht validiert werden. In der Implementierung werden also Gruppenformationen ausschließlich hinsichtlich der Gruppengröße geprüft werden, sofern dieses Kriterium im MoCoLaDe-Skript Verwendung findet. 40

45 3.2 Entwurf der Monitoringfunktionen Ressourcenverteilung Wie bereits in Abschnitt erwähnt, fehlen in IMS/LD Informationen zum Besitzverhältnis einer Ressource ob sie einer Gruppe oder einem spezifischen Benutzer allein zuzuordnen ist. Darum ist zunächst auch nicht klar, wie diese Ressourcenverteilung im Editor dargestellt werden soll. Die Liste der jeweils in einer IMS/LD-Aktivität verfügbaren Ressourcen wird zu einem environment zusammengefasst, das über seinen Identifier mit einer Aktivität verknüpft wird (Attribut environment in Listing 3.1). Im Normalzustand nach MoCoLaDe- Konvention sollten alle Teilnehmer einer Gruppe stets die gleiche Aktivität ausführen, womit damit das gleiche Environment und damit dieselbe Liste von Ressourcen verknüpft sind. Es spräche also vieles dafür, diese Ressourcen als geteilte Gruppen-Ressourcen zu betrachten und entsprechend in der Baum-Struktur der Gruppe zuzuordnen, wie in Abbildung 3.9 angedeutet. In dem Fall, dass alle Gruppenteilnehmer dieselbe Aktivität ausführen, soll die Ressourcenverteilung so dargestellt werden. Führen die Gruppenmitglieder jedoch unterschiedliche Aktivitäten aus, sind damit unterschiedliche Ressourcenlisten (Environments) verknüpft. Eine Möglichkeit zur Darstellung bestünde darin, in diesem Fall die Ressourcen für jeden Teilnehmer getrennt darzustellen und den jeweiligen Teilnehmerknoten zuzuordnen (Abbildung 3.10). Abbildung 3.10: Mögliche Darstellung der Ressourcenverteilung bei auseinandergerissenen Gruppen Nicht mit jeder Sequencing-Kante muss jedoch eine Änderung der Ressourcenzuteilung verknüpft sein. In diesem Fall werden die in der vorhergehenden Aktivität vorhandenen 41

46 3 Ansatz Ressourcen wiederverwendet und die mit den Aktivitäten verknüpften Environments enthalten die gleichen Ressourcen. Es wäre im Sinne der Konsistenz und Übersichtlichkeit von Vorteil, die Environments dahin gehend zu überprüfen, ob sie für alle Mitglieder einer Gruppe dieselben Ressourcenlisten umfassen. Nur wenn sie sich vom Inhalt her unterscheiden, sollen die Ressourcen den Teilnehmerknoten zugeordnet werden. Andernfalls sollen die Ressourcen weiterhin als Gruppenressourcen betrachtet werden. Eine solche Prüfung ist derzeit mit CopperCore leider nicht ohne weiteres durchzuführen, wie im Folgenden dargelegt werden wird. Im IMS/LD-Skript können die Aktivitäten wie oben beschrieben mit einem Environment verknüpft werden. Dieses wiederum enthält eine Liste von Referenzen zu learning-object s, die widerrum auf eine resource verweisen (Abbildung 3.11). Abbildung 3.11: Beziehungen der Entitäten activity, environment, learning-object und resource in IMS/LD Alle vier genannten Entitäten sind mit einem eigenen Identifier versehen, der zur Referenzierung genutzt wird. Zum Vergleich des Inhalts der Environments müssen die IDs der referenzierten Ressourcen-Definitionen bestimmt und verglichen werden. Der Name der Ressourcen ist mehrdeutig und kann deshalb nicht als Vergleichskriterium herangezogen werden kann. Zur Ermittlung des Inhalts der sichtbaren Environments für einen Teilnehmer dient in der CopperCore-API die Methode getenvironmenttree(). Sie liefert als Rückgabewert eine XML-Datenstruktur. XML-Rückgaben von CopperCore-Schnittstellen sollen laut [OUNd] auf den IMS/LD-Datenstrukturen basieren mit der Ausnahme, eine für den Teilnehmer personalisierte Sicht zu liefern 1. Leider weicht die CopperCore-API hier jedoch von den IMS/LD-Strukturen zur Definition eines Environments ab. < environment identifier =" Versailles_Aims " > <title >Aims of the Versailles Experience </ title > <learning - object identifier =" Versailles_Aims_LO " > <item identifier =" V_Aims_item " identifierref =" V_Aims_res "/ > </ learning - object > </ environment > Listing 3.2: Environment-Definition in IMS/LD, Quelle: [IMS03c] < environment identifier =" Environment -23 " isvisible =" true " > <title >Write 2. Critic - Environment </ title > <learning - object identifier =" Learning - Object -23 " isvisible =" true " > <title > Resource89 </ title > </ learning - object > </ environment > Listing 3.3: Ausschnitt aus der Rückgabe von getenvironmenttree() 1 Some of the API calls return data in XML form. The XML schemas resemble the original IMS Learning Design, with the exception that they represent a personalized version of it., Quelle: [OUNd] 42

47 3.2 Entwurf der Monitoringfunktionen Im Vergleich der XML-Strukturen einer Environment-Definition von IMS/LD (Listing 3.2) und der Rückgabe von CopperCore (Listing 3.3) fällt auf, dass die Ressourcen-ID (Attribut identifierref des Knotens item in Listing 3.2) in der CopperCore-Rückgabe fehlt. Es wäre denkbar, an dieser Stelle die Methode getcontent() der CopperCore-API zu nutzen, um die ID der Ressource zu ermitteln. Laut Javadoc-Dokumentation der API liefert diese Methode den Inhalt eines bestimmten angeforderten LD-Elements. Die Dokumentation der XML-Rückgabe [OUNd] zeigt jedoch, dass auch hier das entsprechende Feld fehlt. Spätere Tests zur Zeit der Implementierung hatten zum Ergebnis, dass die Ressourcen- ID jedoch tatsächlich wohl doch in der Rückgabe von getcontent() eingebettet wird in dem undokumentierten Attribut resource-identifier. Da das Feld jedoch nicht Teil der Spezifikation [OUNd] ist und dazu noch von der Namens-Konvention von IMS/LD abweicht, ist nicht klar, ob das Feld absichtlich in die XML-Struktur eingefügt wird und ob dies in zukünftigen CopperCore-Versionen noch der Fall sein wird. Ich habe mich daher dazu entschieden, die bereits zuvor erwähnte Meta-Datei um ein entsprechendes Mapping für die Ressourcen-IDs zu erweitern. Mit diesen Informationen können in der Implementierung die Environments auf gleiche Ressourceninhalte verglichen werden Ermittlung der Gruppenproperties Um mit der CopperCore-API mit der Methode getpropery() die Werte der Gruppenproperties auszulesen, muss u.a. der identifier der Property bekannt sein. Die Beschränkungen der CopperCore-API ermöglichen es jedoch leider nicht, eine Liste der einer Gruppe zugeordneten Property-IDs oder generell aller Properties zu ermitteln. Des Weiteren ist es auch mit gegebener Property-ID nicht möglich, deren Namen und Datentyp zu bestimmen. Diese Informationen sind für die geplante Darstellung jedoch wichtig und müssen daher anderweitig beschafft werden. Die einfachste Lösung wäre das Einlesen des IMS/LD-Manifests des zu beobachtenden Runs und die Filterung nach definierten Properties. Aber auch dieser Weg ist versperrt, da die API keine Möglichkeit bietet, das Manifest auszulesen. Eine Lösungsmöglichkeit besteht darin, die CopperCore-API dahin gehend zu erweitern, dass sie entweder ausreichende Informationen über die definierten Properties liefert, oder als Alternative das Manifest zurückgeben kann. Eine andere Möglichkeit ist, die Property-Definitionen zur Zeit des Export in der Meta- Datei zu speichern, damit sie für das spätere Monitoring zur Verfügung stehen. Diese Methode ist meiner Meinung nach vorzuziehen, da sie gänzlich ohne Modifikationen an CopperCore zu implementieren ist, und bzgl. Funktionalität keine Einschränkungen bietet. 43

48 3 Ansatz Model- vs. Simulation-Export Die geplanten Darstellungsmethoden des Monitorings sind nun nahezu vollständig definiert. Es sollen aber nochmal die in Abschnitt erwähnten Unterschiede der beiden Export-Strategien des Editors und wie diese sich auf das Monitoringverhalten auswirken werden zusammengefasst werden. Der Model-Export exportiert die Gruppenproperties und durch den Export der Verzweigungen kommen die zuvor beschriebenen Zwischenpositionen der Teilnehmer (Abschnitt 3.2.4) im MoCoLaDe-Skript zustande. Nicht exportiert werden dagegen die Ressourcen und Teilnehmerproperties. Sie sind damit im Monitoring auch nicht sichtbar. Im Simulation-Export fehlen dagegen die Gruppenproperties und die Verzweigungsmöglichkeiten, wodurch die Zwischenzustände entfallen. Ressourcen sind aber ermittelbar, wenn auch die Besitzstandsfrage nicht korrekt abgebildet werden kann. Teilnehmerproperties stehen auch hier nicht zur Verfügung. Model-Export Teilnehmerproperties Gruppenproperties X Ressourcen X Verzweigungen, X Zwischenzustand Dummy-Aktivitäten X Tabelle 3.2: Vergleich der beiden Exportstrategien Simulation-Export Beim Monitoring eines durch den Model-Export erzeugten Skripts wird also die Darstellung der Ressourcenverteilung nicht verfügbar sein, während beim Monitoring von Skripten, die auf dem Simulation-Export basieren, die Ressourcen dargestellt werden können, dafür jedoch die Gruppenproperties nicht beobachtet werden können Logging Die Implementierung eines Loggings soll es dem Tutor ermöglichen, Zustandsänderungen eines Kurses auch nach Momenten der Unaufmerksamkeit nachvollziehen zu können oder das entstehende Logfile zur nachträglichen Auswertung heranzuziehen. Das Logfile sollte daher möglichst alle relevanten beobachtbaren Ereignisse umfassen. Dazu zählen: (neu) angemeldete Teilnehmer, Änderung der Gruppen-/Rollenzugehörigkeit, Aktivitätsabschluss und Positionsänderung eines Teilnehmers und die Ressourcenzuteilung. Diese Anforderung könnte bereits durch ein einfaches rein textbasiertes menschenlesbares Logformat erfüllt werden. Eine weitere denkbare Anwendung eines solchen Logfiles wäre jedoch die anschließende computergestützte Auswertung der Vorgänge und deren zeitlichen Zusammenhänge. Für diesen Zweck muss das Logfile anschließend vom Computer nach einer fest definierten Syntax und Semantik lesbar sein. Ein XML-basierendes Datenformat kann diese Anforderungen erfüllen, wenn ein fest definiertes Schema vorhanden ist. 44

49 3.3 Entwurf der Interventionsfunktionen Es besteht die Möglichkeit, ein eigenes spezifisches XML-Schema zu definieren oder ein bereits vorhandenes Schema zu übernehmen. Für eine Eigenentwicklung spricht, dass die zu beobachtenden Ereignisse und vorhandenen Daten u.u. besser abgebildet werden können und sich die Entwicklung wahrscheinlich einfacher gestalten wird, da das Format flexibel nach den vorhandenen Bedürfnissen definiert werden könnte. Ein entscheidendes Argument, das gegen eine Eigenentwicklung spricht, ist jedoch, dass keine Fremdapplikation existiert, die dieses Format zur Auswertung nutzen könnte und man damit den Vorteil der Computerlesbarkeit aktuell nicht ausnutzen könnte. Ich habe mich daher entschieden, ein bereits vorhandenes auf XML basierendes Datenformat für das Logging zu nutzen, für das bereits Auswertungstools ([Moh08]) existieren: Das im Rahmen des Argunaut-Projektes genutzte CommonFormat. 3.3 Entwurf der Interventionsfunktionen Teilnehmerverwaltung Das Fehlen der Teilnehmerdefinitionen im IMS/LD-Export macht es notwendig, dem Tutor ein Werkzeug zu bieten, mit dem in der CopperCore-Laufzeit auf einfache Weise Benutzer angelegt und als Teilnehmer für den entsprechenden Kurs angemeldet werden können. Diese Aufgabe lässt sich mit verhältnismäßigem Aufwand mit dem Kommandozeilentool Clicc bewältigen (Abschnitt 2.5.2). Der Vollständigkeit halber soll diese Funktionalität jedoch als Form der Interventionsmöglichkeit in das Tool mit aufgenommen werden, um einen Bruch im Bedienkonzept zu vermeiden. Als weitere Verbesserung dieser Funktion ist geplant, die Möglichkeit zu bieten, die im MoCoLaDe-Skript definierten Teilnehmer (wenn noch nicht existent) als CopperCore- Benutzer anzulegen und direkt für den Run anzumelden. Die Teilnehmerliste könnte sowohl direkt dem MoCoLaDe-Skript entnommen werden als auch als Information in die geplante Meta-Datei eingebettet werden Gruppen- und Rollenverwaltung Des Weiteren fehlen im IMS/LD-Export die Gruppenformationsalgorithmen und Mechanismen zur dynamischen Rollenzuweisung bzw. -rotation. So muss der Tutor in die Lage versetzt werden, die Teilnehmer bestimmten Gruppen und Rollen zuzuweisen, um auch die Rollenzuweisung manuell emulieren zu können. Spätestens für diese Funktion scheidet Clicc aufgrund der komplexen XML-Datenstrukturen bei der Rollenzuweisung als Werkzeug für den Tutor aus und eine entsprechende Funktionalität muss durch die geplante Erweiterung implementiert werden. Dabei ist wieder der besonderen Abbildung von MoCoLaDe-Gruppen auf eine verschachtelte IMS/LD-Rollenstruktur (Abschnitt ) Rechnung zu tragen und die recht komplexe technische Abwicklung ist vor dem Bediener durch eine verständliche GUI zu verbergen. Auch die Gruppenformationen könnten wieder dem MoCoLaDe-Skript als Information entnommen werden und automatisiert auf den CopperCore-Run angewendet werden. Da die Kriterien für die Gruppenformationsalgorithmen im MoCoLaDe-Skript gespeichert sind, könnte die Gruppenformation neu ausgeführt werden. Diese Informationen sollten 45

50 3 Ansatz jedoch besser bereits zur Zeit des Exports gespeichert werden und sollen daher ebenfalls zusammen mit der Teilnehmerliste in der Meta-Datei Platz finden. So kann sichergestellt werden, dass genau die Gruppenformation, die in der dem Export zugrunde liegenden Simulation durchgespielt wurde, die gleiche ist, die auch bei der Intervention angewendet wird. Die Rollenverteilungen können beim Export dagegen nicht in der Metadatei gespeichert werden, da diese mit Hilfe des Hilfsknotens an beliebiger Stelle in den Aktivitätsfluss eingefügt werden kann (Abschnitt 2.2.5) und die Rollenverteilung daher nicht zwingend bereits mit Beginn der ersten Aktivität feststeht Modifikation der Gruppenproperties Im Falle eines Model-Exports können die Gruppenproperties entscheidend den Skriptverlauf beeinflussen. Es ist wünschenswert, die Properties während der Laufzeit durch ein geeignetes Eingabefeld manipulieren zu können. Fehlerhafte Eingabewerte wie z.b. das Zuweisen eines Strings an eine Integer-Property sind durch eine Fehlermeldung abzufangen Aktivitätsabschluss Ist ein Gruppenmitglied ausgefallen und nicht verfügbar oder es vergisst, seine Aktivität abzuschließen, mag es vonnöten sein, dass der Tutor stellvertretend die Möglichkeit hat, den Teilnehmer manuell zur nächsten Aktivität zu verschieben und damit die Gruppe wieder zusammenzuführen, um kollaboratives Arbeiten nicht zu behindern. Denkbar ist zunächst auch die Idee, eine vom Teilnehmer bereits abgeschlossene Aktivität wieder als nicht abgeschlossen zu markieren. Die IMS/LD-Spezifikation sieht solch eine Modifikation jedoch nicht vor und die CopperCore-API implementiert eine solche Funktion daher ebenfalls nicht. Die gedachte Implementierung eines solchen Zurückversetzen eines Teilnehmers müsste beachten, dass durch den Übergang ausgelöste Zustandsänderungen wie z.b. das Setzen einer Property oder das Sichtbar-/Unsichtbarmachen von Aktivitäten wieder rückgängig gemacht werden müssten vergleichbar mit dem Rollback einer Transaktion. Die Bestimmung dieser inversen Aktionen, die den vorhergehenden Zustand wiederherstellen könnten, ist jedoch nicht in jedem Fall möglich. Angenommen Benutzer A löst durch Aktivitätsabschluss die Modifikation einer Property aus und Benutzer B löst nachfolgend ebenfalls durch Aktivitätsabschluss die Modifikation der gleichen Property aus, ließe sich nicht mehr bestimmen, welcher Wert wiederhergestellt werden müsste, wenn der Abschluss von A rückgängig gemacht werden sollte. Die Modifikation von B könnte auf der von A basieren. Das Rückgängigmachen von Aktivitätsabschlüssen oder das freie Versetzen eines Benutzers an eine andere Skriptposition sollen daher nicht betrachtet werden, sondern nur der manuelle Aktivitätsabschluss als Form der Intervention implementiert werden. Befindet sich der betrachtete Teilnehmer im in Abschnitt besprochenen Zwischenzustand und hat die Wahl zwischen mehreren Aktivitäten, muss dem Tutor ebenfalls die Wahl der Aktivität, die abgeschlossen werden soll, ermöglicht werden. 46

51 3.3 Entwurf der Interventionsfunktionen Der Zwischenzustand ist auch Ursache dafür, dass der Aktivitätsabschluss nicht wie in der Simulationssicht (Abbildung 3.12) durch das Aktivieren des Übergangs einer Sequencing-Kante dargestellt werden kann, da die Folgeaktivität des Benutzers bei Verzweigungen nicht festgelegt werden kann. Abbildung 3.12: Aktivierung eines Aktivitätsübergangs in der Simulations-Ansicht Daher wird der Aktivitätsabschluss durch das Drücken eines Buttons im Palettenbereich des Editors ausgelöst werden. Dieser wird sich dann auf alle in der globalen Teilnehmerübersicht (Abschnitt 3.2.6) selektierten Teilnehmer auswirken Nachrichtenversand Die Werkzeuge, die in der CopperCore-Umgebung zur Verfügung stehen, bieten dem Tutor keine Möglichkeit, einem Kursteilnehmer eine Nachricht zukommen zu lassen, um mit ihm zu kommunizieren. So ist also keine technische Möglichkeit vorhanden, den Teilnehmer auf eventuelle Probleme hinzuweisen oder ihn durch weitere Informationen bei seiner Aktivität zu unterstützen. Eine solche Funktion wäre aber durchaus hilfreich, um so auch indirekt Einfluss auf den Skriptverlauf nehmen zu können. IMS/LD ermöglicht es in der aktuellen Spezifikation, beim Eintreten von Ereignissen sog. notifications auszulösen, die an den Teilnehmer geschickt werden ([IMS03b]). Spezifiziert wird hierfür standardmäßig der Versand von s über SMTP. Die CopperCore- API bietet mit der Methode notify() eine Möglichkeit, einen solchen Notification- Versand auch manuell anzustoßen. So nährte sich in der Entwurfsphase die Idee, durch eine kleine Modifikation an CopperCore den SMTP-Versand um einen Mechanismus zur sofortigen Nachrichtenzustellung erweitern zu können. So hätte eine dem Notification- Standard folgende Lösung zum Nachrichtenversand entwickelt werden können. < imsld:notification > < imsld: - data - property - ref ="P- "> <imsld:role - ref ref ="R- tutor "/> </ imsld: - data > < imsld:subject >Test advising report submitted </ imsld:subject > </ imsld:notification > Listing 3.4: XML-Struktur einer IMS/LD-Notification, Quelle: [IMS03c] Weitere Nachforschungen hatten jedoch zum Ergebnis, dass diese Lösung so nicht in Frage kommt. Die Methode notify() erwartet als Parameter eine XML-Datenstruktur, die der Notification-Struktur von IMS/LD folgt (Listing 3.4). Vorgesehen ist hier aber leider nicht der Versand von Nachrichten an Teilnehmer sondern an Rollen. Da IMS/LD- Rollen fast immer von mehr als einem Teilnehmer besetzt werden, würde die Nachricht 47

52 3 Ansatz nicht nur einen Teilnehmer erreichen, sondern alle Teilnehmer, die dieser Rolle zugewiesen wurden. Dies entspricht nicht dem erwarteten Anwendungsfall und soll daher nicht weiter verfolgt werden. Das Ziel ist nunmehr die Eigenentwicklung einer kleinen Serverkomponente zur Nachrichtenverteilung und eines einfachen Clients, der empfangene Nachrichten als ein Popup auf dem Bildschirm darstellt. Als einfachen Nachrichtenvermittler auf der Server-Seite kam wieder die Definition eines JMS-Topics in Frage, wie es auch zur Benachrichtigung des Clients bei Zustandsänderungen Verwendung finden soll (Abschnitt 3.2.2). Die Technologie ist auf dem Java EE Server laut Spezifikation verfügbar und die Definition und Verwendung eines Topics ist technisch gesehen recht einfach zu realisieren. Dazu bietet JMS durch die Nutzung von dauerhaften (eng.: durable) Verbindungen die Möglichkeit, Nachrichten für temprorär nicht verfügbare Clients zwischenzuspeichern. Der Client würde über die verpassten Nachrichten beim nächsten Start informiert werden. Theoretisch käme die Nachrichtenvermittlung ohne weitere Serverschnittstelle neben dem JMS-Topic aus, da jeder Client auch selbst direkt Nachrichten auf einem Topic veröffentlichen könnte. Aus Konsistenzgründen zur CopperCore-API und zur Abstraktion des eigentlichen Nachrichtenversands soll jedoch eine entsprechende EJB entwickelt werden, die das publizieren der Notification übernimmt. So könnte später auf Serverseite das JMS basierende Protokoll durch ein anderes ersetzt werden, ohne dabei die Schnittstelle modifizieren zu müssen. Eine denkbare Alternative wäre z.b. die Adaption eines beliebigen Instant Messaging Protokolls. Da keine direkten Berührungspunkte zu CopperCore bestehen, soll die Entwicklung der Serverkomponente von CopperCore getrennt als Java EE Serverapplikation stattfinden. So muss CopperCore zu deren Implementierung nicht modifiziert werden. Der Notification-Client zum Empfang der Nachrichten sollte sich möglichst nahtlos in vorhandene Playerarchitekturen einbetten lassen. In Frage kommen dabei sowohl webbasierte Lösungen wie der CopperCore-Webplayer, grafische Java-Clients als auch Clients in anderen Sprachen oder Architekturen. Für webbasierte Player soll sich der Client als Applet einbinden lassen, um eine nahtlose Oberfläche zu bieten. Für Java-Applikationen soll eine grafische Komponente entwickelt werden, die sich einfach in eine Java AWT- Oberfläche einbinden lässt und den Rest der Kommunikation abstrahiert. Clients, die in anderen Programmiersprachen entwickelt wurden, wird ein eigenständig lauffähiger Notification-Client zur Seite gestellt werden. 48

53 3.4 Gesamtkonzept 3.4 Gesamtkonzept Meta-Datei In den vorangehenden Abschnitten wurden mehrere Informationsartefakte bestimmt, die in der geplanten Meta-Datei als Teil des exportierten UOL-Archivs Platz finden sollen, um dann für das spätere Monitoring und die Interventionen zur Verfügung zu stehen. Dazu zählen die Folgenden: Dokumentenhash zur Identifikation der korrekten UOL (Abschnitt 3.2.1) Mapping der Aktivitäten: IMS/LD-Identifier MoCoLaDe-Knoten UUID (Abschnitt 3.2.4) Informationen zum Namen und Datentyp der Gruppenproperties (Abschnitt 3.2.8) Integration der Teilnehmerliste mit Angaben zur Gruppenzugehörigkeit (Abschnitt 3.3.1, 3.3.2) Informationen zu den in den Environments referenzierten Ressourcen-IDs (Abschnitt 3.2.7) Es müssen also eine ganze Reihe strukturierter Daten zu einer Datei zusammengefasst werden. Für diese Aufgabe eignet sich ein auf XML basierendes Datenformat, dessen Syntax später noch als XML Schema (XSD) oder Document Type Definition (DTD) definiert werden wird. Einen Ansatz für das Grundgerüst dieser Meta-Datei, in der die oben genannten Informationen abgebildet werden können, findet sich in Listing 3.5. <cossicle - meta version =" 1.0 "> <export - method > simulation </ export - method > <activity - mapping > < activity mapfrom =" Activity - ImsId -0" mapto =" MoCoLaDe -Node -UUID -0"/>... </ activity - mapping > <property - mapping > < property mapfrom =" Property - ImsId -0" mapto =" Group - ImsId -0" name ="x" datatype =" integer " initial - value ="0"/>... </ property - mapping > < participants > < participant name =" Alice " group =" Group - ImsId -0"/>... </ participants > <resource - mappings > < resource mapfrom =" Learning - Object -0" mapto =" Resource -0 - Paper7 " name =" Paper7 " href =" Resource -0 - Paper7. html "/>... </ resource - mappings > <origin - file - hash >22 bc0c050402eeb0653cd7c22cdaa974 </ origin - file - hash > </ cossicle - meta > Listing 3.5: XML-Struktur der Meta-Datei 49

54 3 Ansatz Neben den oben angeführten Informationen wurden noch weitere Felder für die eventuelle spätere Verwendung eingefügt: Das Attribut version des Wurzelknotens cossicle-meta ist vorgesehen, um bei evtl. späterer Änderung der Spezifikation der Meta-Datei Abwärtskompatibilität gewährleisten zu können oder um zumindest erkennen zu können, dass es sich um eine unbekannte Version des Datenformats handelt. Der Knoten export- -method soll angeben, durch welche Export-Strategie des Editors die UOL generiert wurde (simulation oder model) Architektur Aufgrund der in den vorhergehenden Abschnitten diskutierten Entscheidungen zum Implementierungsansatz kann nun der Aufbau der geplanten Zielarchitektur zusammengefasst werden (vgl. Abbildung 3.13). CopperCore wird um die Benachrichtigung von Zustandsänderungen auf einem JMS- Topic (CopperCore Event Topic) erweitert werden. MoCoLaDe wird als Monitoring- Anwendung von diesem Topic über Events informiert werden und die CopperCore-API nutzen, den CopperCore-Zustand zu ermitteln. Intern werden semantische Mappings zur Visualisierung des Zustands angewendet werden. Zur Implementierung der Interventionsfunktionen wird MoCoLaDe die CopperCore- APIs (LDEngine und LDCourseManager) als auch den zu entwickelnden Notification- Service nutzen. Letzterer wird zur Publizierung von Nachrichten auf einem JMS-Topic (NotificationTopic) zuständig sein. Die Nachrichten werden von einem Notification- Client empfangen werden, der in bestehende Player-Anwendungen eingebettet werden kann und so in die Schnittstelle für den Lerner eingebunden wird Struktur des Entwicklungsprojekts Die Entwicklung wird sich in drei grundlegende Teilprojekte gliedern, die teilweise voneinander abhängig sein werden: MoCoLaDe-Plugin Dieses Projekt wird den eigentlichen Kern der Entwicklungsarbeiten umfassen: die Erweiterung des bestehenden FreeStyler-Plugins Mo- CoLaDe um den Export der Meta-Datei mit den enthaltenen Mapping-Informationen, den Verbindungsaufbau zum CopperCore-Server und die spätere Implementierung der Monitoring- und Interventionsfunktionen. CopperCore-Patch Umfasst die Codebasis des um die JMS-Benachrichtigung der Zustandsänderungen erweiterten CopperCore-Servers. MoCoLaDe wird von den in diesem Projekt definierten Datentypen und Service-Schnittstellen abhängig sein. Notification-Service Da die Implementierung der Notifications getrennt von CopperCore stattfinden soll, soll für diese EJB-Serverapplikation ein eigenes Projekt eingerichtet werden. Als weiteren Teil des Projektes sehe ich die Entwicklung des Clients als Java-Applikation, Applet und AWT-Komponente. Die entstehende EJB-Schnittstelle und das JMS-Topic wird durch das MoCoLaDe-Plugin genutzt werden. 50

55 3.4 Gesamtkonzept Abbildung 3.13: Komponentendiagramm der geplanten Zielarchitektur 51

56 3 Ansatz Als viertes Teilprojekt ist die Kapselung der Logik für einen JMS-Client geplant, dessen sich sowohl der Notification-Client als auch das MoCoLaDe-Plugin für den Verbindungsaufbau bedienen sollen. 52

57 4 Implementierung 4.1 CopperCore-Erweiterung Zur Implementierung der geplanten Erweiterung von CopperCore ist dessen interner Aufbau sehr vorteilhaft. CopperCore löst seine Zustandsänderungen durch die interne Verteilung von Ereignissen aus. Die Methode postmessage() der Klasse EventDispatcher ist für diese Verteilung zuständig ([HMW]) und leitet die Ereignisse an die internen Komponenten weiter, die für die eigentliche Zustandsänderungen zuständig sind. Meine Implementierung fängt ähnlich wie in [HMW] beschrieben den Methodenaufruf an dieser Stelle ab und publiziert das Ereignis auf dem JMS-Topic. Da das Ziel eine minimalinvasive Implementierung ist, ist die eigentliche Logik für die JMS-Publizierung zu kapseln. Definiert wurde dazu eine neue Klasse (EventPublisher) mit der statischen Methode publishevent(), die für diese Aufgabe zuständig ist. Sie sucht im JNDI die Referenz für das Topic und verpackt alle über das Ereignis vorhandenen Datenfelder in eine JavaBean (CopperCoreEvent), die dann auf dem Topic platziert wird (Abbildung 4.1). Der JMS-Server kümmert sich transparent um die Zustellung der JMS-Nachrichten an die registrierten Empfänger also u.a. an das MoCoLaDe-Tool. Durch die Kapselung der gesamten JMS-Logik in einer statischen Methode kann die Modifikation der Klasse EventDispatcher stark begrenzt werden: Das Einfügen einer einzigen Zeile am Ende der Methodendefinition von postmessage() reicht an dieser Stelle aus (s. Anhang C). Die der Methode postmessage() übergebenen Datenfelder, die in der Bean CopperCore- Event gekapselt werden, umfassen den Ereignistyp, die betroffene UOL, den Run und den User, der das Ereignis ausgelöst hat. Bei der Implementierung der Klasse Copper- CoreEvent ist jedoch zu beachten, dass es im J2EE-Umfeld ein oft genutztes Pattern ist, Entity-Beans nur lokal zu verwenden ([Rup05]) und für Remote-Aufrufe deren Datenfelder in sog. Data Transfer Objects (DTOs) zu verpacken. Diese Konvention wird auch von den bisherigen CopperCore-Schnittstellen verfolgt und die entsprechenden DTO-Klassen stehen somit bereits zur Verfügung. Die von der Methode postmessage() übergebenen Entity-Objekte (UOL, Run, User) werden also zunächst in ihre DTO-Pendants (UolDto, RunDto, UserDto) umgewandelt, bevor sie in eine JMS-Nachricht eingebettet werden Ant-Build Teil des CopperCore-Quellcodes ist ein Ant Build-Skript. Apache Ant [Apaa] ist ein quelloffenes Werkzeug zur Automatisierung des Build-Prozesses. Ein solches Build-Skript besteht aus einer Reihe von sog. Targets, die während des Build-Prozesses automatisiert unterschiedliche Artefakte produzieren. 53

58 4 Implementierung Abbildung 4.1: UML Klassendiagramm der auf CopperCore-Seite beteiligten Klassen zur Publizierung der JMS-Nachricht 54

59 4.1 CopperCore-Erweiterung Im CopperCore Build-Skript sind u.a. Targets zur Erstellung der Client-Klassenbibliotheken (coppercore-client.jar, coppercore-common.jar) und des Archivs für die CopperCore-Serverapplikation (coppercore.ear, EAR Abk. für Enterprise Archive) enthalten. Dieses Skript musste entsprechend angepasst werden, um die Bean Copper- CoreEvent beim Buildprozess in die Client-Bibliothek mit einzubeziehen und die Klasse EventPublisher zum EJB-Archiv hinzuzufügen (betroffene Targets EjbModuleNode und archive) Definition des JMS-Topics Das Vorgehen zur Definition eines neuen JMS-Topics ist nicht in Java EE standardisiert. Da CopperCore jedoch derzeit nur auf dem JBoss Applikationsserver lauffähig ist, kann sich die Implementierung zunächst auf diesen beschränken. Der JBoss-Server implementiert seine Services als eine Sammlung von sog. Management Beans (MBeans). Auch ein JMS-Topic wird als eine solche MBean definiert, die durch eine Service-Definition konfiguriert wird. Die Service-Definition ist eine XML-Datei, deren Name auf -service.xml endet und Angaben zur MBean enthält (Listing 4.1). Dazu gehört u.a. der Typ (hier org.jboss.mq.server.jmx.topic) und der JNDI-Name, unter dem die Referenz der MBean gespeichert wird (hier CopperCoreEventTopic). <? xml version =" 1.0 " encoding ="UTF -8"?> < server > <mbean code =" org. jboss.mq. server. jmx. Topic " name =" jboss. mq. destination:service = Topic, name = CopperCoreEventTopic " > </ mbean > </ server > < depends optional - attribute - name =" DestinationManager " > jboss. mq:service = DestinationManager </ depends > Listing 4.1: Erstellung eines JMS-Topics in JBoss durch Konfiguration einer MBean: coppercore-event-mq-service.xml Diese Service-Konfiguration wird entweder manuell direkt im JBoss deployd oder als Teil eines Service-Archivs (SAR) zusammen mit der Java EE-Applikation ausgeliefert. Da der für CopperCore definierte Ant-Build bereits das Packen eines solches SARs vorsieht, habe ich mich für die Integration der Servicedefinition in das SAR entschieden. Somit steht das definierte Topic automatisch beim Start der CopperCore-Applikation im JNDI zur Verfügung. 55

60 4 Implementierung 4.2 Notifications Die Entwicklung des Notification-Services wird sich grob in drei Teile gliedern: Implementierung des EJB-Services und des JMS-Topics Implementierung der Client-Komponente Erstellung eines Applets, das ein in Webarchiv eingebunden wird, um es im J2EE Webcontainer nutzen zu können Notification EJB und Topic Aufgabe der Notification EJB ist es, die Logik der Zustellung einer Nachricht an den Empfänger serverseitig in einer fest definierten Schnittstelle zu kapseln (Abschnitt 3.3.5). Da die Entwicklung des Notification-Services neben CopperCore als eigenständiges Projekt entwickelt wird, kann anstatt der bei CopperCore verwendeten Spezifikation der Enterprise Java Beans 2.1 auf die aktuelle Version 3.0 [EJB05] von Java EE 5 zurückgegriffen werden. Im Vergleich zur Version 2.1 wurden in der Spezifikation von EJB 3.0 viele Entwicklungsschritte vereinfacht. Anstatt die Deployment-Informationen dem EJB-Container durch das Schreiben von XML-Deskriptoren zur Verfügung zu stellen, können diese Informationen bei Java EE 5 durch die Nutzung von Annotationen in den Quelltext eingebettet werden. Letztlich besteht die eigentliche EJB Serverapplikation daher nur aus zwei Klassen und einem Interface (Abbildung 4.2). Abbildung 4.2: UML Klassendigramm der Notification-Service Serverapplikation Das Interface NotificationService stellt das vom Client genutzte Remote-Interface zum Zugriff auf die EJB dar. Durch die wird dem EJB-Container 56

61 4.2 Notifications mitgeteilt, dieses Interface als Remote-Interface zu behandeln und im JNDI-Verzeichnis zu registrieren. Zur Verfügung gestellt wird die zentrale Methode sendnotification(), die die drei String-Parameter Absender, Empfänger und Nachricht entgegennimmt und für die Publizierung der Nachricht auf dem JMS-Topic zuständig ist. Gekapselt werden diese Datenfelder in der Bean Notification, die dem Client zugestellt wird. Die Klasse NotificationServiceBean stellt die eigentliche EJB-Implementierung dar und erbt daher vom Remote-Interface (Listing 4.2). Die deklariert sie dem EJB-Container als Stateless Session Bean. sorgen dafür, dass der EJB-Container dem EJB-Objekt bei der Initialisierung per Dependency-Injection die entsprechenden Ressourcen aus dem JNDI-Verzeichnis zur Verfügung stellt. Dadurch kann in der EJB-Implementierung auf den JNDI-Lookup des JMS-Topics und der Factory verzichtet werden und die Implementierung wird noch ( name =" NotificationService ") public class NotificationServiceBean implements NotificationService ( mappedname =" topic / CopperCoreNotificationTopic ") Topic notificationtopic ( mappedname =" UIL2ConnectionFactory ") TopicConnectionFactory topicfactory ; } public boolean sendnotification ( String sender, String userid, String message ) { //... } public boolean sendnotification ( Notification notification ) { //... } public int getsentnotificationscount () { //... } Listing 4.2: Grundgerüst der EJB NotificationServiceBean Die Definition des JMS-Topics erfolgt analog zu der in Abschnitt beschriebenen Definition. Auch für diese Serverapplikation müssen das Service-Archiv (SAR) und das Enterprise-Archiv (EAR) für das Deployment im JBoss-Server erstellt werden. Für diese Aufgabe wurde ein entsprechendes Ant-Buildskript entwickelt, wie es auch ähnlich für den Build-Prozess der CopperCore-Applikation genutzt wird Notification Client Der Notification Client soll sowohl als einbettbare AWT GUI-Komponente implementiert werden als auch als selbst lauffähige Anwendung und als Webapplet. Da alle drei Implementierungen auf einer AWT GUI basieren werden, macht es Sinn, die gesamte Logik für den JMS-Nachrichtenempfang und das Darstellen der Popup-Nachrichten in der AWT-Komponente zu integrieren. Diese kann sowohl vom Applet als auch von der Java-Anwendung in die GUI eingebettet werden. Die Anwendung und das Applet müssen dann nur noch die Konfiguration der Komponente übernehmen und für die Einbettung in die GUI sorgen. 57

62 4 Implementierung Sowohl die MoCoLaDe-Monitoringerweiterung als auch der Notification-Client werden als JMS-Listener betrieben. Deshalb wurde die relativ komplexe Aufgabe der Client- Registrierung und der Exceptionbehandlung nach dem Fassade-Pattern in der gemeinsam genutzten Klasse TopicSubscriptionBroker gekapselt. Der Client ruft zum Starten der Verbindung die Methode start() auf, der der Naming-Context, der JNDI- Topicname und eine Referenz auf den Client übergeben wird, der über Nachrichten informiert werden soll. Danach wird der Client fortan über JMS-Nachrichten mittels der Event-Methode onmessage() informiert. Vor Beendigung des Clients sollte die Methode close() aufgerufen werden, die die geöffneten Serverressourcen wieder schließt und freigibt. In der Client-Implementierung wurde zwischen der GUI-Komponente und dem TopicSubscriptionBroker noch eine weitere Klasse (NotificationManager) als Zwischenschicht eingefügt, die u.a. für die Umsetzung der empfangenen JMS-Nachricht in das Bean-Objekt Notification zuständig ist. Außerdem implementiert diese Klasse die Logik zum Verbindungsaufbau zur EJB-Applikation, die für den Monitoring-Client genutzt werden wird (Abschnitt 4.3.4). So ergibt sich die in Abbildung 4.3 dargestellte Struktur der Client-Implementierung. Abbildung 4.3: UML Klassendigramm der Notification Client-Implementierung Funktionsweise und Verhalten des eingebetteten Notification-Clients Die Klasse NotificationClientComponent erwartet bei der Instanzierung mindestens die beiden Parameter Naming-Context und den Benutzernamen, für den Nachrichten empfangen werden sollen. Der Naming-Context wird von den Komponenten initialisiert, die die Klasse einbetten also vom Applet und der Java-Anwendung. Die Initialisierung des Naming-Context ist abhängig von dem verwendeten Applikationsserver. Da in dieser Implementierung jedoch nur der JBoss AS betrachtet werden soll, wird zur Konfiguration nur die Server IP-Adresse benötigt. Alle anderen Werte können durch die Applikation passend für den JBoss AS vorgegeben werden. 58

63 4.2 Notifications Die Java-Anwendung erwartet daher als ersten Kommandozeilenparameter die IP-Adresse des JBoss-Servers und als optionalen zweiten Parameter die User-ID. Wird kein Benutzername übergeben, öffnet sich ein Eingabedialog, in dem der Benutzername eingegeben werden kann (Abbildung 4.4). Abbildung 4.4: Eingabedialog des Notification-Clients zur Anmeldung Der Notification-Client öffnet daraufhin eine dauerhafte JMS-Verbindung. Danach ist der Benutzer am Notification-Client angemeldet und die Komponente bleibt solange inaktiv im Hintergrund, bis eine Nachricht für den angegebenen Benutzer eintrifft. Dann öffnet sich ein Popup-Dialog, in dem Absender, Empfänger und die erhaltene Nachricht dargestellt werden (Abbildung 4.5). Abbildung 4.5: Nachrichten-Popup des Notification-Clients Zum Aufbau einer dauerhaften JMS-Verbindung wird eine eindeutige Session-ID benötigt, die dem Server zur Wiedererkennung des Clients beim nächsten Start dient. Diese wird aus dem angegebenen Benutzernamen gebildet, was zur Folge hat, dass mit demselben Benutzernamen immer nur ein einziger Notification-Client gleichzeitig geöffnet sein darf. Der Versuch, eine weitere Verbindung mit gleichem Benutzernamen zu öffnen, bricht mit einer Fehlermeldung ab. Da in den meisten Fällen ein Benutzer immer nur an einem System gleichzeitig arbeiten wird, ist diese Beschränkung zu vernachlässigen. Die dauerhafte Verbindung hat den positiven Effekt, dass nach dem erstmaligen Anmelden mit einer Benutzerkennung vom Applikationsserver Nachrichten zwischengespeichert werden, die eintreffen wenn der Client nicht aktiv ist. Diese werden automatisch beim nächsten Start zugestellt. Zu Kontrollzwecken kann außerdem der Benutzername * genutzt werden, um die Nachrichten aller Benutzer zu empfangen. Diese Sitzung wird jedoch nicht als dauerhafte Verbindung geöffnet. 59

64 4 Implementierung Applet Die Implementierung des Applets unterscheidet sich auf Quellcodeebene nicht wesentlich von der der Applikation. Ein Applet ist grundsätzlich zur Einbettung in eine HTML- Seite vorgesehen. Die beiden benötigten Parameter Server-Adresse und User-ID müssen daher bei der Einbettung als Applet-Parameter in die HTML-Seite integriert werden (Listing 4.3). < applet archive =" notification - service - client. jar " code =" info. collide. notification. client. gui. NotificationClientApplet. class " width =" 350 " height ="20"> <param name =" serverip " value =" " > <param name =" userid " value =" Alex "> </ applet > Listing 4.3: Einbettung des Notification-Applets in eine HTML-Seite Eine größere Herausforderung an die Implementierung stellt jedoch der Java Security Manager dar. Applets werden zunächst generell als unsicher betrachtet und von daher in einer abgeschotteten Sandbox-Umgebung ausgeführt. Diese bewirkt, dass Applets u.a. keine Dateien auf Datenträgern lesen oder schreiben dürfen und aber auch keine Netzwerkverbindungen zu Serveradressen aufbauen dürfen, die nicht mit der übereinstimmen, von der sie ausgeliefert wurden. Ausserdem dürfen sie auch keine Netzwerkports zum Empfang eingehender Netzwerkanfragen öffnen ([Fla99]). Eine JBoss JMS-Verbindung lässt sich in dieser eingeschränkten Sandbox nicht aufbauen. Signatur Sollen einem Applet z.b. für den Aufbau einer Netzwerkverbindung erweiterte Rechte gewährt werden, müssen alle zu ladenden JAR-Bibliotheken mit einem digitalen Zertifikat signiert werden. Dieses Zertifikat kann entweder kostenpflichtig von einer als vertrauenswürdig eingestuften kommerziellen Zertifizierungsstelle bezogen werden oder zu Testzwecken wird ein selbstsigniertes Zertifikat erzeugt, was dann jedoch als nicht vertrauenswürdig eingestuft wird. Aus Kostengründen habe ich mich für das selbstsignierte Zertifikat entschieden. Dies kann mit dem Kommandozeilentool keytool erstellt werden, das Teil des Java SE SDKs ist. Das selbst erstellte Zertifikat wird dabei mit einem Namen versehen (hier verwendet cossicle ) und passwortverschlüsselt im sog. Keystore gespeichert. Mit dem weiteren Kommandozeilentool jarsigner werden anschließend alle benötigten JAR- Bibliotheken signiert. Die für einen JBoss-Client benötigten Bibliotheken finden sich in {jbosshome}/client und umfassen in der gewählten Version 4.2 des JBoss-Servers derzeit ca. 60 Dateien. Aufgrund der großen Anzahl der zu signierenden Dateien und da dies während des Entwicklungsprozesses eine wiederkehrende Aufgabe darstellt, wurde der bereits für die Serverapplikation definierte Ant-Build um ein Target zur automatischen Signatur der Client-Bibliotheken erweitert. 60

65 4.2 Notifications Einbettung in eine Webapplikation Die eigentliche Implementierung des Java-Applets ist damit abgeschlossen, nachfolgend soll jedoch zu Testzwecken noch eine Beispieleinbettung in eine Webanwendung erstellt werden. Das Ant-Skript wurde dafür nochmals um die Erstellung eines Java EE Webarchivs (notification-service-applet.war) erweitert. Dieses kann im JBoss deployd werden und steht dann als Webapplikation unter der URL zur Verfügung. Zur Einbettung des Applets in eine HTML-Seite wurde eine Java Server Page (JSP) erstellt (applet.jsp), die die URL-Parameter serverip und userid durch entsprechende Anpassung des HTML-Codes (Listing 4.3) an das Webapplet weiterleitet. Der Aufruf der Seite mit applet.jsp?serverip= &userid=alex führt zur gewünschten rudimentären Einbettung des Applets für den Benutzer Alex. Nach einer Sicherheitsabfrage des Webbrowsers aufgrund des nicht vertrauenswürdigen Zertifikates baut das Applet die Verbindung zum JBoss-Server auf und wartet wie die zuvor beschriebene Applikation auf Nachrichten. In einer weiteren JSP (index.jsp) wurde zu Demonstrationszwecken ein HTML-Frameset entwickelt, das im oberen Teil der Webseite das Applet durch Verwendung von applet.jsp einbindet und im unteren Bereich den CopperCore Webplayer (Abbildung 4.6). Abbildung 4.6: Beispieleinbettung des Notification-Applets durch ein Frameset Die oben beschriebene Erstellung der beiden Java Server Pages zeigt, dass die Einbettung des Applets in bestehende Webanwendungen grundsätzlich einfach zu realisieren ist und damit die nahtlose Integration auch in Webanwendungen möglich ist. Die im CopperCore 61

66 4 Implementierung Webplayer verwendeten JavaScript-Skripte erlauben jedoch nicht die Einbettung in ein Frameset, sodass die Applikation so wie in Abbildung 4.6 dargestellt nicht lauffähig ist. 4.3 MoCoLaDe-Erweiterung XML-Verarbeitung Um die im Kapitel 3 definierten Monitoring- und Interventionsfunktionen implementieren zu können, müssen zunächst Hilfsklassen zum Umgang mit den komplexen XML- Datenstrukturen geschaffen werden. Dazu zählen sowohl Parser und Writer für die Datenstruktur der Meta-Datei (Abschnitt 3.4.1), das Logformat CommonFormat (Abschnitt ) und die Rückgabewerte der CopperCore-API als auch passende Datenstrukturen in Java zu deren Abbildung. Im bereits bestehenden MoCoLaDe-Projekt wurde für die Exportfunktion aufgrund der großen Komplexität des Aufbaus der IMS/LD-Strukturen mit DOM-Implementierungen auf die Nutzung von Apache XMLBeans [Apac] zurückgegriffen ([Sch06]). XMLBeans bietet die Funktion, aus einer bestehenden XML Schemadefinition (XSD) eine Reihe von passenden und miteinander verknüpften JavaBeans erstellen zu lassen. Dabei werden die im Schema definierten XML-Datentypen in Java-Klassen transformiert, die jeweils bereits über einen vordefinierten XML-Parser und -Writer verfügen. Durch die ausschließliche Nutzung der API der generierten JavaBeans wird der Umgang mit den Datenstrukturen erheblich vereinfacht und der Aufwand zur Implementierung eines Parsers und Writers minimiert. Ein großer Vorteil besteht auch in der zentralen Definition der Datenstrukturen in der XSD-Datei. Änderungen werden beim nächsten Kompilationsvorgang automatisch in die Implementierung der JavaBeans übernommen. Dieses Framework wird daher auch für die in der Erweiterung zu verarbeitenden XML- Datenstrukturen verwendet. Voraussetzung für die Generierung der XML-Beans ist allerdings, dass für die zu verarbeitenden XML-Daten die passenden Schemadefinitionen vorhanden sind. Entwicklung der Schemadefinitionen Das entwickelte XML-Schema der Meta-Datei (cossicle-meta.xsd, Anhang B) folgt dem in Abschnitt angedachten Format. Die im Schema definierten Strukturen und Datentypen sind in den Abbildungen 4.7 und 4.8 dokumentiert. Die Namen und Vererbungsbeziehungen der durch XMLBeans generierten Java-Klassen stimmen mit denen der XML-Datentypen überein. Die Datenstrukturen der Rückgabewerte von Coppercore sind zwar in [OUNd] dokumentiert, passende XML-Schemata finden sich in den Quellcodearchiven von CopperCore jedoch nicht und der projekteigene CVS-Server ist zum Zeitpunkt der Entstehung dieser Arbeit (2007/2008) noch nicht in Betrieb ([OUNb]). Da die Strukturen, wie bereits in Abschnitt gezeigt wurde, vom IMS/LD-Schema abweichen, können auch die IMS/LD-Schemadefinitionen nicht für diesen Zweck genutzt werden. Für die Rückgaben von CopperCore mussten also eigene Schemadefinitionen erstellt werden. Konkret 62

67 4.3 MoCoLaDe-Erweiterung Abbildung 4.7: Struktur der cossicle-meta.xsd Abbildung 4.8: Datentypen für das Mapping in cossicle-meta.xsd handelt es sich um die Strukturen die durch die CopperCore API-Methoden getroles- Tree(), getactivitytree() und getenvironmenttree() generiert werden. Für das CommonFormat hingegen existiert derzeit eine DTD, die zugrunde gelegt wurde. Zur Transformation der DTD in ein XSD-Schema kam das Tool dtd2xsd [W3C01] des World Wide Web Consortium zum Einsatz. Die entstandene XSD musste anschließend nur in geringem Umfang für die Verwendung mit XMLBeans optimiert werden Integration der Metadatei in den IMS/LD-Export Die Metadatei soll in die IMS/LD-Exportmechanismen des Plugins integriert werden. Die bisherige Architektur sieht zur Implementierung einer Exportstrategie das zentrale Interface IMSLDExporter vor. Dies wird von den Klassen IMSLDModelExporter und IMSLDSimulationExporter geerbt, die die jeweilige Exportstrategie implementieren. Da diese beiden Klassen für die jeweilige Abbildung des MoCoLaDe-Skripts auf IMS/LD verantwortlich sind, wurden diese beiden Klassen entsprechend modifiziert, die benötigten Informationen in die Meta-Datei zu schreiben. Die Exporter-Klassen nutzen als Zwischenschicht für die Generierung des IMS/LD- Manifests jeweils die Klasse IMSLDWriterBeans. Diese abstrahiert die Zugriffe auf die XMLBeans-Klassen ([Sch06]). Analog zu dieser Architektur soll die Generierung der Meta-Daten ebenfalls durch eine Zwischenschicht abstrahiert werden, was die Aufgabe der Klasse CossicleMetaWriterBean ist. Die Klassen IMSLDModelExporter und 63

68 4 Implementierung IMSLDSimulationExporter wurden also an den entscheidenden Stellen, an denen Abbildungen erstellt werden, dahingehen modifiziert, die benötigten Zusatzinformationen an die CossicleMetaWriterBean weiterzugeben. Ist der Export des Manifests fertiggestellt, hat die CossicleMetaWriterBean alle Mappinginformationen erhalten und in der XMLBeans-Datenstruktur gespeichert. Eine Information, die jedoch nicht in den beiden Exporter-Klassen generiert wird, ist der Dokumentenhash, der zur Identifizierung der UOL dienen soll (Abschnitt 3.2.1). Die Berechnung dieses Hashs wurde daher in der Hilfsklasse HashHelper gekapselt. Der Hash wird am Ende des Exports berechnet und ebenfalls der CossicleMetaWriterBean übergeben. Das fertige XML Meta-Dokument wird abschließend als IMS/LD-Webresource mit dem Namen cossicle-meta.xml in die UOL eingebettet. Damit steht die modifizierte Architektur der Exportstrategien, wie in Abbildung 4.9 dargestellt, nun fest. Abbildung 4.9: Integration der CossicleMetaWriterBean und der Klasse HashHelper in die bisherige Implementierung der Exportstrategien Berechnung des Dokumentenhashs Bei den Überlegungen zum Ansatz (Abschnitt 3.2.1) wurde bisher davon ausgegangen, dass es grundsätzlich möglich sein sollte, den Dokumentenhash der FreeStyler-Datei zu berechnen, die das MoCoLaDe-Skript enthält. Dabei wurde implizit angenommen, dass der Hash der Datei bei unverändertem Inhalt auch nach dem erneuten Laden stets gleich sein sollte. Im Verlaufe der Implementierung stellte sich jedoch heraus, dass dem nicht so ist. Die Knoten- und Kanten-Objekte, die das MoCoLaDe-Skript definieren, werden in einer JGraph-Datenstruktur gespeichert. Dabei gilt, dass MoCoLaDe-Knotenklassen sich von AbstractNode und die Kantenklassen sich von SimpleEdge ableiten. Beide Oberklassen 64

69 4.3 MoCoLaDe-Erweiterung implementieren das Interface XMLSerializable, das vom JGraph genutzt wird, seinen eigenen Zustand in ein XML-basierendes Dateiformat zu speichern. Jedes Objekt, das das XMLSerializable-Interface implementiert, muss auch eine Getter- Methode für das Datenfeld ID implementieren. Problematisch ist an dieser Stelle jedoch, dass auch Wrapper-Klassen für die Einbettung einfacher Datentypen wie z.b. java.awt.point (zur Speicherung der Knotenpositionen) genutzt werden, die selbst über keinen eigenen Identifier verfügen (Listing 4.4). Die Wrapperklasse erzeugt daher bei jedem Speichervorgang einen neuen UUID, womit auch der Dokumentenhash zwangsläufig nach dem erneuten Laden stets abweicht. < NodeInfo > < GroupNode ID=" c34cf10ee99eec63:74fad434:10f61b10ed4: -7 fa1 "... </ GroupNode > <Point id=" 583 c10bfdbd326ba: -13 fd64e8:1167e52a416: -7 d7f " x=" 224 " y=" 127 " /> </ NodeInfo > Listing 4.4: XML-Darstellung des Datentyps Point, erstellt durch die Klasse info.collide.xml.helpers.point Die erzeugte XML-Datenstruktur muss daher vor der Hash-Berechnung um solche Attribute oder Knoten, die sich beim erneuten Laden stets verändern, bereinigt werden. Dies ist auch Aufgabe der Klasse HashHelper. Sie nutzt die vom JGraph erzeugte DOM- Struktur und löscht die Elemente Point, Color und resource. Theoretisch würde bei den Elementen Point und Color das entfernen des Attributs id reichen, die gewählte Lösung hat allerdings den positiven Nebeneffekt, dass so die Anordnung der Knotenpunkte im Skript beliebig modifiziert werden kann, ohne dass sich der Hashwert verändert, solange die logischen Verknüpfungen durch die Kantenbeziehungen erhalten bleiben. Auf die Semantik des MoCoLaDe-Skripts hat die Neuanordnung der Knoten keinen Einfluss. Die resource-elemente werden zur Speicherung des Inhalts der Ressource-Knoten verwendet. Sie werden vor der Berechnung des Hashs entfernt, da auch eine vorhergehende Simulation den Hashwert beeinflussen würde und damit der Hashwert der Datei nach einem Simulationsexport zwangsweise von dem Wert nach dem erneuten Laden abweichen würde Palettenmodus Bevor eine Monitoringsitzung gestartet wird, muss sichergestellt werden, dass das Mo- CoLaDe-Skript zur Bearbeitung gesperrt ist. Andernfalls wäre es nicht auszuschließen, dass das Skript durch Modifikation während des Monitorings in einen ungültigen Zustand versetzt wird, der nicht mehr mit den Mappinginformationen übereinstimmt. Bisher unterstützte der Editor zwei Zustände: Model und Simulate umschaltbar durch ToggleButtons in der Palette. Doch keiner von beiden Zuständen erscheint dazu geeignet, für das Monitoring genutzt zu werden. Im Model-Zustand ist das Skript nicht gegen Modifikationen gesperrt und der Simulationsmodus blendet an den Sequencing-Kanten die für das Monitoring ungewünschten Schaltflächen zum Auslösen des Übergangs ein 65

70 4 Implementierung (Abbildung 3.12). Der zusätzliche Zustand Monitoring sperrt das Skript gegen Modifikationen und behält die Darstellungsweise der Knoten und Kanten des Model-Zustands bei. Des Weiteren muss sichergestellt werden, dass während einer aktiven Serververbindung nicht in einen anderen Modus zurückgewechselt werden kann, damit eine aktive Monitoringsitzung nicht mit Zustandsänderungen durch Skriptmodifikation oder des Simulationsmodus kollidiert. Beim Verbindungsaufbau wird automatisch vom Monitoring-Modus in den MonitoringLocked-Modus gewechselt, der die Zustandswahl durch die ToggleButtons bis zum Beenden der Sitzung für den Benutzer unzugänglich macht. Der bisherige Mechanismus des Umschalten des Editor-Zustands sieht vor, dass alle Knoten- und Kantenobjekte des Skripts das Interface CossicleSimulationComponent implementieren und darüber über einen Zustandswechsel informiert werden. Dieser Mechanismus wurde beibehalten, jedoch von der Verteilung eines Booleanwertes zur Unterscheidung der zwei Zustände auf die Verteilung einer Enum-Struktur (Listing 4.5) umgestellt. public enum CossiclePaletteMode { MODELING, SIMULATION, MONITORING, MONITORING_LOCKED } Listing 4.5: Enum-Struktur CossiclePaletteMode Verbindungsaufbau Wird der Editor in den Monitoring-Zustand versetzt, wird der Zugriff auf das neue Tab Monitoring freigegeben, das einen Dialog für den Verbindungsaufbau zum CopperCore- Server bietet (Abbildung 4.10). Abbildung 4.10: Monitoring-Tab: Dialog für Verbindungsaufbau Durch die Modifikation der vorgegebenen JNDI-URL kann die Serveradresse des Copper- Core-Servers angegeben werden, zu dem eine Verbindung hergestellt werden soll. Mit einem Klick auf die nebenstehende Schaltfläche Connect to server wird die Serververbindung aufgebaut. 66

71 4.3 MoCoLaDe-Erweiterung Der Dialog für den Verbindungsaufbau ist Teil der zentralen Klasse MonitorPanel. Das Ziel war es, die Klasse MonitorPanel weitestgehend auf die Implementierung der GUI- Logik zu beschränken und alles andere in spezialisierte Klassen auszulagern, um die Darstellung von der Programmlogik zu trennen. Für die Herstellung der Verbindung greift diese deshalb auf die Klasse ServerConnection zurück, der die JNDI-URL übergeben wird. Diese kapselt die Logik für den Verbindungsaufbau, das Registrieren als JMS-Client und das Lookup der CopperCore EJB Home-Interfaces LDEngineHome und LDCourseManagerHome (Abbildung 2.19). Für die JMS-Registrierung nutzt die Server- Connection-Klasse wieder die schon in Abschnitt erwähnte und für den Notification- Client verwendete Klasse TopicSubscriptionBroker. Für die Verbindung zum Notification-Service wird auch eine Instanz der Klasse NotificationManager initialisiert, die ebenfalls bereits als Abstraktionsschicht bei der Implementierung des Notification- Clients zum Einsatz kommt (Abschnitt 4.2.2). Wirft die ServerConnection-Klasse keine Exception, war die Verbindung erfolgreich, die Referenzen zu den CopperCore-APIs stehen bereit, der NotificationService ist verfügbar und die JMS-Registrierung war erfolgreich. Abbildung 4.11 stellt die am Verbindungsaufbau beteiligten Klassen dar. Abbildung 4.11: Zusammenhang der am Verbindungsaufbau beteilligten Klassen Auswahl von UOL & Run Nach erfolgreichem Verbindungsaufbau wird mit der Klasse HashHelper (Abschnitt 4.3.2) der Hashwert des aktuell im Editor bearbeiteten MoCoLaDe-Skripts berechnet, der nachfolgend mit den auf dem CopperCore-Servern verfügbaren UOLs verglichen werden soll. Als weitere Hilfsklasse für Zugriffe auf CopperCore wurde die Klasse CcServerMapping implementiert. Deren Aufgabe sind Abstraktionen der CopperCore-Rückgaben wie z.b. die Umsetzung der XML-Rückgaben in die XMLBeans Datenstrukturen als auch Methoden für den Zugriff auf die Metadatei. Die Metadatei wird von CopperCore wie eine übliche webcontent-ressource behandelt und sie wird daher per HTTP-Protokoll vom Server geladen und anschließend geparst. Für das Laden der Datei über HTTP nutzt die Klasse CcServerMapping die Bibliotheken des Projektes Jakarta - HTTP Client 67

72 4 Implementierung [Apab] der Apache Software Foundation, die die weitere Logik für das HTTP-Protokoll implementieren. Abbildung 4.12: Dialog zum Start der Monitoring-Sitzung Für das Monitoring angeboten werden nur jene UOLs, die über eine Metadatei verfügen, dessen Inhalt erfolgreich geparst werden konnte und deren darin enthaltener Hashwert mit dem des aktuellen Dokumentes übereinstimmt (Abbildung 4.12). Wichtige Informationen, die dem Tutor für die Wahl der UOL und des Runs durch Tooltips der jeweiligen ComboBox-Listen angezeigt wird, sind Name von UOL und Run, Exportmethode und -zeitpunkt der UOL und Startzeitpunkt des Runs (Abbildung 4.13). Abbildung 4.13: Tooltips bei UOL-/Runauswahl Durch das Klicken des Buttons start monitoring run kann die Monitoring-Sitzung für den ausgewählten Run gestartet werden, oder alternativ mit dem Button create new run zunächst ein Run für die gewählte UOL erzeugt werden Zustandsermittlung und -update Mit dem Start der Monitoring-Sitzung werden die GUI-Komponenten für das Monitoring und die Interventionsaktionen im MonitorPanel sichtbar geschaltet. Während der Monitoring-Sitzung soll der Status u.a. dieser Komponenten nach dem Empfang eines CopperCore-Ereignisses automatisch aktualisiert werden. Eine Möglichkeit besteht darin, das empfangene CopperCore-Ereignis an die Komponenten weiterzuleiten, die selbst je nach Bedarf weitere Zustandsdaten mit der Copper- Core-API ermitteln. Dadurch dass jede Komponente die entsprechenden Daten selbst ermittelt, würden jedoch unnötig viele Daten mehrfach abgefragt werden, wodurch die 68

73 4.3 MoCoLaDe-Erweiterung Performance extrem leiden würde. Z.B. benötigt sowohl die Logik zum Highlighting der Teilnehmerpositionen als auch die Komponente für die Gruppen-/Teilnehmerübersicht die Aktivitätshistorie der jeweiligen Teilnehmer. Daher ist es von Vorteil, alle Zustandsdaten zentral zu ermitteln, in einer Datenstruktur zu speichern und diese an die entsprechenden Komponenten durch eine Listenerarchitektur weiterzuleiten. Dies ist Aufgabe der für das Monitoring zentralen Klasse Global- MonitoringStateManager. Beim Start der Sitzung wird ihr die Referenz der Klasse ServerConnection und die gewählte UOL/Run-Kombination übergeben. Sie registriert sich daraufhin als JMS-Listener für die CopperCore-Events und baut bei einem Ereignis durch Nutzung der CopperCore-APIs und der Mapping-Informationen der Metadatei den Folgezustand auf. Unterschieden werden kann dabei zwischen Informationen, die sich während der gesamten Monitoring-Sitzung nicht ändern, und denen, die bei jedem CopperCore-Event aktualisiert werden müssen. Nicht veränderbare Informationen werden in der Klasse StaticMonitoringState zusammengefasst und beinhalten z.b. die geparste IMS/LD Rollenstruktur des Skripts oder die Mappings der IMS/LD-Aktivitäts-IDs auf die Mo- CoLaDe Aktivitäts-Knotenobjekte. Diese Datenstruktur wird nur einmalig zu Beginn der Monitoringsitzung aufgebaut. Veränderliche Zustandsdaten werden durch die Klasse MonitoringState repräsentiert und umfassen unter anderem eine Liste der aktuell am Skript angemeldeten Benutzer, ihre derzeitigen Positionen im Skript und ihre zugewiesenen Rollen. Beim Empfang eines CopperCore-Events prüft die Klasse GlobalMonitoringStateManager, ob das Ereignis den beobachteten Run betrifft und verwirft das Ereignis andernfalls, was unnötige Updates verhindert. Muss ein Ereignis behandelt werden, füllt sie die Datenfelder einer neuen Instanz von MonitoringState mit Ergebnissen der CopperCore- Abfragen und daraus abgeleiteten Informationen. Dem MonitoringState wird außerdem stets eine Referenz auf den StaticMonitoringState übergeben. Anschließend informiert sie alle als Listener angemeldeten Komponenten über den Folgezustand, die dazu das MonitoringStateListener-Interface implementieren (Abbildung 4.14). Manche Aktionen wie das erstmalige Zuweisen eines Teilnehmers zu einer Gruppe ziehen mehrere direkt aufeinanderfolgende CopperCore-Ereignisse nach sich. Auch das gleichzeitige Abschließen einer Aktivität durch mehrere Teilnehmer ist denkbar, was beides dazu führen kann, dass ein CopperCore-Ereignis empfangen wird, während ein laufendes Zustandsupdate noch nicht abgeschlossen und an die Listener-Komponenten weitergeleitet wurde. Da sichergestellt werden musste, dass immer nur der konsistente Zustand nach dem jeweils letztem Ereignis dargestellt wird, die JMS-Zustellung jedoch durch mehrere Threads gleichzeitig parallel erfolgen kann, wird durch einen Mutex dafür gesorgt, dass immer nur ein Zustandsupdate gleichzeitig erfolgt. Beim Eintreffen eines Ereignisses, während ein Zustandsupdate noch andauert, wird ein Flag gesetzt, das den Updateprozess anweist, das derzeit laufende Update abzubrechen und anschließend ein neues Update zu veranlassen. 69

74 4 Implementierung Abbildung 4.14: Architektur des Zustandsupdates und der Verteilung 70

75 4.3 MoCoLaDe-Erweiterung Globale Gruppen- und Teilnehmerübersicht Die globale Gruppen- und Teilnehmerübersicht (Abschnitt 3.2.6) stellt alle am Skript angemeldeten Teilnehmer, ihre aktuelle Position, Gruppen- und Rollenzugehörigkeit sowie die Werte der Gruppenproperties und die verfügbaren Ressourcen dar. Implementiert wurde sie als eigenständige grafische Komponente GroupUserOverviewComponent, die in das MonitorPanel eingebettet wird (Abbildung 4.15). Abbildung 4.15: Darstellung der Klasse GroupUserOverviewComponent Ihre Darstellung gliedert sich vertikal in zwei Teile. Im oberen Teil wird zur Darstellung der Gruppenstrukturen der schon in der Simulationssicht genutzte GroupTree wiederverwendet. Der untere Teil stellt mit einer Instanz der Klasse JTable die Teilnehmer/- Positionssicht dar. Die Klasse GroupUserOverviewComponent wird durch Implementierung des Monitoring- StateListener-Interfaces (Abbildung 4.14) über Zustandsänderungen informiert und modifiziert bei einer Zustandsänderung selbstständig die Darstellung der beiden integrierten grafischen Komponenten. Der Aufbau der Datenstruktur für den GroupTree geschieht dabei in der Komponente selbst. Für die Darstellung der Tabellendaten wird ein angepasstes TableModel (OverviewUserTableModel) verwendet, das selbstständig aus dem übergebenen Monitoring- 71

76 4 Implementierung State-Objekt die darzustellenden Daten für die einzelnen Zellen bestimmt. Die gewünschte Hervorhebung von Tabellenzeilen, die Teilnehmer enthalten, die bereits alle Aktivitäten abgeschlossen haben, wird durch einen Cellrenderer gelöst, der ebenfalls seine Daten direkt aus dem MonitoringState-Objekt bezieht. Wird in der Tabelle eine Menge von Teilnehmern oder ein einzelner Teilnehmer selektiert, wird diese Selektion analog auch auf den GroupTree übertragen. Dadurch wird sofort ersichtlich, welcher Gruppe der selektierte Teilnehmer angehört. Umgekehrt wird auch die Selektion von Teilnehmerknoten im GroupTree auf die Tabellenselektion angewendet. Zusätzlich führt auch die Selektion eines Gruppenknotens zur Selektion aller zur Gruppe gehörenden Teilnehmer in der Tabelle. Andere Klassen können durch Implementierung des Interfaces GroupUserOverview- Listener (Listing 4.6) über Selektions- und Klickereignisse informiert werden. Implementiert und genutzt wird dies von der Klasse MonitorPanel, wo die Selektionen im Zusammenhang mit der Anwendung der Interventionsfunktionen (Abschnitt ) und des Highlightings (Abschnitt 4.3.8) genutzt wird. Abbildung 4.16: Klassenarchitektur der globalen Gruppen- und Teilnehmerübersicht public interface GroupUserOverviewListener extends EventListener { public void sinlgeuserselected ( String userid ); public void singlegroupselected ( String groupid ); public void singlepropertyselected ( String propertyid ); public void multipleusersselected ( List < String > useridlist ); public void multiplegroupselected ( List < String > groupidlist ); public void multiplepropertyselected ( List < String > propertyidlist ); public void deselectedgroupuseroverview (); } public void propertydoubleclicked ( String propertyid ); public void resourcedoubleclicked ( String resid, String resname ); Listing 4.6: Listenerinterface GroupUserOverviewListener 72

77 4.3 MoCoLaDe-Erweiterung Node-Details Das ehemalige Tab Simulation-Details implementiert durch die Klasse StatusPanel wurde in Node-Details umbenannt, da es auch die Knoteninhalte während der Monitoringsitzung anzeigen soll. In der bisherigen Architektur zur Anzeige der Knoteninhalte im Simulationsmodus implementieren die Knoten, deren Inhalt in dieser Sicht angezeigt werden kann, das Interface GroupContainer, über das dem Knoten Gruppenstrukturen hinzugefügt und entfernt werden können. Mit den korrekten Inhalten befüllt werden die Knoten in der Simulation durch die Implementierungen der Zustandsübergänge der Kanten wie z.b. SequencingEdge und GroupFormationEdge. Die Knoten reagieren auf die Selektion mit der Maus und übergeben dann ihren Inhalt der StatusPanel-Instanz Das Panel nutzt zur Darstellung die bereits angesprochene Komponente GroupTree (Abschnitt 4.3.6). Diese Architektur kann zur Darstellung der Knoteninhalte beim Monitoring größtenteils beibehalten werden. Die Gruppen-Container müssen jedoch durch einen anderen Algorithmus basierend auf dem aktuellen MonitoringState befüllt werden. Außerdem müssen zur Darstellung der Zwischenzustände wie in Abschnitt angedacht auch die Sequencing-Kanten das GroupContainer-Interface implementieren, um ihren Inhalt dem StatusPanel übergeben zu können. Der Algorithmus zur Befüllung der Gruppencontainer gleicht bis auf wenige Abweichungen dem für die Globale Gruppen-/Teilnehmerübersicht verwendeten Algorithmus und wurde in die Klasse StatusPanel integriert, die durch Implementierung des Interfaces MonitoringStateListener über Statusupdates informiert wird. Bei jedem Statusupdate werden alle GroupContainer-Objekte zuerst geleert und anhand des neuen Status befüllt und die Sicht aktualisiert Highlighting Zur Implementierung des Highlightings von Skriptelementen wurde das bereits bestehende HighlightingInterface ([Vet07]) durch das ColorableHighlightingInterface abgeleitet und um das Setzen von Farbwerten erweitert. Farblich hervorhebbar müssen alle Elemente sein, die die aktuelle Position eines Teilnehmers im Skript repräsentieren können. Letztlich sind dies alle Elemente, die auch das GroupContainer-Interface implementieren. Das GroupContainer-Interface ist deshalb eine Erweiterung des ColorableHighlightingInterface. Bei der Selektion eines Teilnehmers oder einer Gruppe von Teilnehmern sollen die Positionen im Skript bzw. die Aktivitätshistorien durch Highlighting dargestellt werden. Das MonitorPanel implementiert das GroupUserOverviewListener-Interface und wird über diese Selektionen informiert (Abschnitt 4.3.6). Um jedoch auch an dieser Stelle wieder die GUI-Implementierung möglichst frei von Programmlogik zu halten, werden alle Aufgaben, die im Zusammenhang mit dem Skript-Highlighting stehen, in der Klasse MonitoringHighlightManager gekapselt. Die komplette resultierende Architektur des Highlightings ist in Abbildung 4.17 dargestellt. 73

78 4 Implementierung Abbildung 4.17: Architektur des Highlightings Bei der Implementierung des Highlightings werden die in der Metadatei gespeicherten Aktivitäts-Mappings (Abschnitt 3.2.4) verwendet, um die Teilnehmerpositionen von CopperCore repräsentiert durch IMS/LD Aktivity-IDs auf die richtigen MoCoLaDe Knoten- und Kantenelemente abzubilden. Da auch die die Aktivitätshistorie beschreibenden Sequencing-Kanten hervorgehoben werden sollen (Abschnitt 3.2.3), müssen auch die sie verbindenden Kanten bestimmt werden. Dabei ist zu beachten, dass zwei in der Historie aufeinanderfolgende Aktivitätsknoten nicht zwingend direkt durch eine Sequencing-Kante verbunden sein müssen. In den Aktivitätsfluss können beliebig viele Hilfsknoten der Komponentenzuteilung eingefügt sein (Abbildung 4.18, vgl. Abschnitt 2.2.5). Abbildung 4.18: Pfad zwischen zwei Aktivitäten, verbunden durch Sequencing-Kanten mit eingefügtem Hilfsknoten Bestimmung durch Tiefensuche 74

79 4.3 MoCoLaDe-Erweiterung Da die Hilfsknoten jedoch keine Entsprechung in IMS/LD finden, sondern nur die besuchten Aktivitätsknoten bekannt sind, muss bei nur indirekter Verbindung der Pfad zwischen den Aktivitäten durch einen Suchalgorithmus auf dem Skriptgraphen bestimmt werden. Der MonitoringHighlightManager implementiert dies durch einen Tiefensuche- Algorithmus, der Verbindungen durch Sequencing-Kanten zwischen zwei Aktivitätsknoten bestimmt, in die beliebig viele Hilfsknoten eingefügt sein können (Abbildung 4.18) Logging Da die durch die CopperCore-Ereignisse empfangenen Informationen nicht ausreichend sind, um die gewünschten Loginformationen wie die Ressourcenzuteilung oder eine neue Rollenzuweisung zu bestimmen, wird jeder generierter MonitoringState mit dem vorhergehenden Zustand verglichen. Für beobachtete Veränderungen werden Logeinträge erzeugt. Da sich nach IMS/LD-Konvention die Teilnehmer einzeln durch das Skript bewegen, können auch Veränderungen nur bezogen auf den Teilnehmer erkannt werden. Bezogen auf den jeweiligen Teilnehmer werden die folgenden Logeinträge generiert: Benutzer hinzugefügt (user added), Benutzer entfernt (user removed), Gruppe-/Rolle zugewiesen (new role), Aktivität abgeschlossen (complete activity), Neue Position im Skript (new position), Ressource bekommen (get res), Ressource abgegeben (release res), Skript abgeschlossen (finish) Für das Logging im CommonFormat wird auf die in Abschnitt beschriebenen generierten XMLBeans zurückgegriffen. Die Architektur des Logwriter gliedert sich dabei in eine Komponente (CossicleStateCommonLogBuilder), die als MonitoringState- Listener die aktualisierten Zustände empfängt, vergleicht und die CommonFormat- Datenstruktur aufbaut und Komponenten, die diese Datenstruktur weiterverarbeiten. Sie werden über Modifikationen an der Datenstruktur vom Log-Builder durch ein Listener-Modell informiert (Abbildung 4.19). Implementiert sind derzeit zwei grafische Komponenten, die das CossicleStateCommon- LogListener-Interface implementieren und in das MonitorPanel integriert sind (Abbildung 4.20): Eine Viewerkomponente, die den Inhalt der Logfiledatenstruktur in Form einer Liste anzeigt Eine Writerkomponente, die das Logfile bei Änderungen in eine Datei schreibt (Listing 4.7) und durch eine Checkbox das Aktivieren und Deaktivieren dieser Funktion bietet 75

80 4 Implementierung Abbildung 4.19: UML-Klassendiagramm der an der Logfile-Generierung beteiligten Klassen Abbildung 4.20: Die Komponenten Log-Viewer und Log-Writer eingebettet in das Monitor-Panel 76

81 4.3 MoCoLaDe-Erweiterung < interactiondata xmlns =" http: // cossicle. collide. info / xml / commonformat "> < preamble > <users > < user_def firstname =" Alex " id=" Alex " / >... </ users > < groups >... </ groups > <roles >... </ roles > < document_information > UOL: SocialScriptBenSmall, Run: testrun </ document_information > </ preamble > < actions > < action time =" "> < actiontype classification =" other " type =" user_added " logged =" false " /> <user id=" Alex " role =" receiver " / > </ action >... < action time =" "> < actiontype classification =" other " type =" new_role " logged =" false " /> <user id=" Alex " role =" receiver " / > < object type =" role " id=" Learner -Role -0"> < properties > < property name =" title " value =" Case Group1 " /> </ properties > </ object > </ action > < action time =" "> < actiontype classification =" other " type =" new_position " logged =" false " /> <user id=" Alex " role =" receiver " / > < object id=" Activity -0" type =" learning - activity " > < properties > < property name =" title " value =" Write 1. Analyisis " /> </ properties > </ object > </ action > </ actions > </ interactiondata > Listing 4.7: Ausschnitt aus einem generierten Logfile 77

82 4 Implementierung Interventionsfunktionen Im Monitor-Panel unterhalb der globalen Gruppen-/Teilnehmerübersicht angeordnet ist eine Buttonleiste zur Nutzung der Interventionsfunktionen (Abbildung 4.21). Mit Ihnen können alle in Abschnitt 3.3 geplanten Interventionsfunktionen genutzt werden. 1: Benutzer anlegen und zum Run hinzufügen, 2: Existierenden Benutzer hinzufügen, 3: MoCoLaDe-Teilnehmer anlegen und hinzufügen, 4: Teilnehmer entfernen, 5: Gruppe/Rolle zuweisen, 6: Nachricht schicken, 7: Aktivität manuell abschliessen, 8: Propertywert bearbeiten, 9: Teilnehmerhistorie anzeigen (keine Intervention) Abbildung 4.21: Buttons für Interventionsfunktionen Aus Platzgründen wurde auf textuelle Beschriftungen der Buttons verzichtet und stattdessen grafische Symbole 1 und Tooltips zur Funktionsbeschreibung eingesetzt. Die durch die Buttons ausgelösten Aktionen beziehen sich immer auf die in der Gruppen-/Teilnehmerübersicht zuvor gemachte Selektion. Das Auswählen eines Teilnehmers und das anschließende Klicken auf Aktivität manuell abschließen würde z.b. den Aktivitätsabschluss für den zuvor ausgewählten Teilnehmer hervorrufen. Je nach Selektion werden die einzelnen Funktions-Buttons freigeschaltet oder deaktiviert. Bei der Selektion einer Gruppen-Property werden z.b. alle Buttons deaktiviert, die eine Intervention für einen Benutzer auslösen würden, dafür wird jedoch der Zugriff zur Aktion Propertywert bearbeiten freigeschaltet. Alle durch die Buttons auszulösenden Interventionsfunktionen werden vom Monitor- Panel lediglich an die Klasse InterventionManager weitergeleitet, die alle Logik zur Ausführung der notwendigen API-Aufrufe an CopperCore kapselt. Dieser Aufbau ist sowohl zur Trennung von GUI und Logik als auch im Hinblick auf eine potenzielle spätere Erweiterung auf eine andere Zielplattform als CopperCore sinnvoll. Im Folgenden soll ein kurzer Überblick über die Funktionen gegeben werden. Benutzer anlegen und zum Run hinzufügen - Öffnet einen Dialog zur Eingabe eines neuen Benutzernamens. Der Benutzer wird in CopperCore angelegt und für den Run angemeldet. 1 Ein Teil der verwendeten Symbole wurde einer kostenlos verwendbaren Iconsammlung von Manentia Software [Man] entnommen Lizenz: Creative Commons (Anhang D) 78

83 4.3 MoCoLaDe-Erweiterung Existierenden Benutzer hinzufügen - In einer ComboBox werden alle verfügbaren existierenden CopperCore-User angezeigt, die nicht bereits am aktuellen Run teilnehmen. Mit dem Bestätigen des Dialogs wird der Benutzer dem Run hinzugefügt. MoCoLaDe-Teilnehmer anlegen und hinzufügen - Die Liste der im Skript definierten Teilnehmer wird für den aktuellen Run übernommen und die in der Metadatei gespeicherte Gruppenformation wird automatisch angewendet. Wenn die CopperCore-Benutzer noch nicht existieren, werden sie angelegt. Teilnehmer entfernen - Nach Bestätigung einer Rückfrage wird der Teilnehmer aus dem Run entfernt. Der CopperCore-Benutzer selbst wird nicht gelöscht. Gruppe/Rolle zuweisen - Öffnet einen Dialog zur Auswahl der Gruppe und optional der Rolle. Die ausgewählte Gruppen-/Rollenkombination wird allen ausgewählten Teilnehmern zugewiesen und andere zuvor gesetzte Rollenzugehörigkeiten entfernt. Gehört der ausgewählte Teilnehmer bereits einer Gruppe oder Rolle an, so werden diese automatisch vorausgewählt. Bei der Gruppen-/Rollenzuweisung wird intern automatisch die Abbildung von Gruppen auf die hierarchische IMS/LD- Rollenstruktur vorgenommen (Abschnitt ). Nachricht schicken - Ermöglicht das verschicken einer Nachricht (Abschnitt 4.2) an alle ausgewählten Teilnehmer. Aktivität manuell abschliessen - Kennzeichnet die jeweils für den Teilnehmer aktuelle Aktivität als abgeschlossen. Befindet sich ein Teilnehmer in einem Zwi- 79

84 4 Implementierung schenzustand, in dem er die Möglichkeit hat, zwischen mehreren Aktivitäten zu wählen, kann der Tutor die abzuschließende Aktivität in einem Dialog auswählen. Propertywert bearbeiten - Öffnet einen Dialog, in dem der Wert der zuvor ausgewählten Gruppenproperty geändert werden kann. Die Eingabe eines nicht zulässigen Wertes wie z.b. einer Zeichenfolge für ein Integerfeld ist nicht möglich. Teilnehmerhistorie anzeigen - Diese Funktion stellt in diesem Zusammenhang einen Sonderfall dar, da es sich um keine Intervention handelt, die Funktion jedoch aus Platzgründen in die gleiche Button-Leiste eingebunden wurde. Es wird ein Fenster geöffnet, in dem die Aktivitätshistorie eines Teilnehmers in Textform dargestellt wird (Abschnitt 3.2.3). 80

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

OpenCms jbpm Workflow Engine. OpenCms und jbpm Workflow Engine

OpenCms jbpm Workflow Engine. OpenCms und jbpm Workflow Engine OpenCms und jbpm Workflow Engine Geschäftliche Abläufe in einem Unternehmen folgen zu einem großen Prozentsatz beschreibbaren Prozessen, den so genannten Geschäftsprozessen. Diese Erkenntnis führte zum

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen

Mehr

Administrative Tätigkeiten

Administrative Tätigkeiten Administrative Tätigkeiten Benutzer verwalten Mit der Benutzerverwaltung sind Sie in der Lage, Zuständigkeiten innerhalb eines Unternehmens gezielt abzubilden und den Zugang zu sensiblen Daten auf wenige

Mehr

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung Use-Cases Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Dieses Dokument beschreibt Netzwerk-Szenarios für den Einsatz von NetWACS. Es soll als Grundlage bei der Definition des NetWACS

Mehr

Software Engineering II

Software Engineering II Software Engineering II Codegenerierung für den SmartIO Editor mit der Modeling Workflow Engine Wintersemester 10/111 Fachgebiet Software Engineering Albert Zündorf / Wiederholung Bisher im Laufe des Semesters

Mehr

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

Mehr

Geschäftsprozessanalyse

Geschäftsprozessanalyse Geschäftsprozessanalyse Prozessmodellierung weitere Begriffe: workflow business process modelling business process (re-)engineering 2 Was ist ein Prozess? Prozesse bestehen aus Aktionen / Ereignissen /

Mehr

Bedienung von BlueJ. Klassenanzeige

Bedienung von BlueJ. Klassenanzeige Im Folgenden werden wichtige Funktionen für den Einsatz von BlueJ im Unterricht beschrieben. Hierbei wird auf den Umgang mit Projekten, Klassen und Objekten eingegangen. Abgeschlossen wird dieses Dokument

Mehr

HTL-Website. TYPO3- Skriptum II. Autor: RUK Stand: 02.06.2010 Gedruckt am: - Version: V0.1 Status: fertig. Qualitätsmanagement

HTL-Website. TYPO3- Skriptum II. Autor: RUK Stand: 02.06.2010 Gedruckt am: - Version: V0.1 Status: fertig. Qualitätsmanagement HTL-Website TYPO3- Skriptum II Autor: RUK Stand: 02.06.2010 Gedruckt am: - Version: V0.1 Status: fertig Qualitätsmanagement Erstellt Geprüft Freigegeben Name RUK Datum 02.06.2010 Unterschrift Inhaltsverzeichnis

Mehr

Oracle Weblogic Administration Grundlagen

Oracle Weblogic Administration Grundlagen Oracle Weblogic Administration Grundlagen Seminarunterlage Version: 1.07 Version 1.07 vom 14. September 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Grid Computing. Einführung. Marc Lechtenfeld. Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen

Grid Computing. Einführung. Marc Lechtenfeld. Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen * Grid Computing Einführung Marc Lechtenfeld Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen Übersicht 1 Problematik 2 Systemanforderungen 3 Architektur 4 Implementation 5 Projekte

Mehr

Ersatzteile der Extraklasse Magento-Module der Shopwerft

Ersatzteile der Extraklasse Magento-Module der Shopwerft Ersatzteile der Extraklasse Magento-Module der Shopwerft MicroStudio - Fotolia.com Viele Produkte eignen sich auch als Geschenk. Wer für den Beschenkten keine eigene Auswahl treffen möchte, der greift

Mehr

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

Mehr

JBoss AS 7. Installation, Konfiguration und Betrieb. Alexander Pacnik Karlsruhe, 13.12.2013

JBoss AS 7. Installation, Konfiguration und Betrieb. Alexander Pacnik Karlsruhe, 13.12.2013 JBoss AS 7 Installation, Konfiguration und Betrieb Alexander Pacnik Karlsruhe, 13.12.2013 Jboss 7 AS... worum es in diesem Vortrag geht. Einführung Installation Konfiguration Management Deployment Betrieb

Mehr

Teamcenter Rapid Start (Rich Client)

Teamcenter Rapid Start (Rich Client) 15.06.15-1 - E:\Stefan\CAD\Teamcenter\TCRS10\Anleitungen\TeamcenterRich.doc Teamcenter Rapid Start (Rich Client) 1. Starten und Beenden - Teamcenter starten (Desktop-Verknüpfung): - Anmeldeinformationen

Mehr

1 YAWL Yet Another Workflow Language

1 YAWL Yet Another Workflow Language 1 YAWL Yet Another Workflow Language Das YAWL Workflow-Management-System wurde von Wil van der Aalst und seinem Team an der Eindhoven University of Technology entwickelt. Das System ist in seiner jetzigen

Mehr

TYPO3 Redaktoren-Handbuch

TYPO3 Redaktoren-Handbuch TYPO3 Redaktoren-Handbuch Kontakt & Support: rdv interactive ag Arbonerstrasse 6 9300 Wittenbach Tel. 071 / 577 55 55 www.rdvi.ch Seite 1 von 38 Login http://213.196.148.40/typo3 Username: siehe Liste

Mehr

7 SharePoint Online und Office Web Apps verwenden

7 SharePoint Online und Office Web Apps verwenden 7 SharePoint Online und Office Web Apps verwenden Wenn Sie in Ihrem Office 365-Paket auch die SharePoint-Dienste integriert haben, so können Sie auf die Standard-Teamsite, die automatisch eingerichtet

Mehr

Aufgabenstellung und Zielsetzung

Aufgabenstellung und Zielsetzung Aufgabenstellung und Zielsetzung In diesem Szenario werden Sie eine Bestellung, vorliegend im XML-Format, über einen Web-Client per HTTP zum XI- System senden. Dort wird die XML-Datei mittels eines HTTP-Interfaces

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

Erste Schritte mit LimeSurvey Pädagogische Hochschule Heidelberg

Erste Schritte mit LimeSurvey Pädagogische Hochschule Heidelberg 1 Dieses Script ist als Schnellstart gedacht, um das Prinzip von LimeSurvey zu verstehen. Zahlreiche Optionen stehen zur individuellen Erstellung von Umfragen zur Verfügung ein ausführliches Benutzerhandbuch

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Das Studiengangsinformationssystem (SGIS)

Das Studiengangsinformationssystem (SGIS) Das Studiengangsinformationssystem (SGIS) Manual für Typo3-Redakteure Version 1.a Mai 2015 Kontakt: Referat 1.4 - Allgemeine Studienberatung und Career Service Christian Birringer, christian.birringer@uni-rostock.de

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Geschäftsprozessmanagement: Einführung in»business Process Modelling Notation«(BPMN)

Geschäftsprozessmanagement: Einführung in»business Process Modelling Notation«(BPMN) Geschäftsprozessmanagement: in»business Process Modelling Notation«(BPMN) Eugen Labun Fachhochschule Gießen-Friedberg Fachbereich MNI Institut für Softwarearchitektur Serviceorientierte Architekturen bei

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

PREMIS Aktuelle Entwicklungen und Perspektiven

PREMIS Aktuelle Entwicklungen und Perspektiven PREMIS Aktuelle Entwicklungen und Perspektiven Olaf Brandt Gliederung Hintergrundinformationen zu PREMIS Aktivitäten Welchen Stand haben wir erreicht? Wohin geht die Entwicklung? Was ist PREMIS? Das Akronym

Mehr

- Entwurfsphase: Entwurfsbeschreibung Gesamtsystem - Version: 1.0

- Entwurfsphase: Entwurfsbeschreibung Gesamtsystem - Version: 1.0 Projektbezeichnung Projektleiter Verantwortlich - Entwurfsphase: Entwurfsbeschreibung Gesamtsystem - Version: 1.0 MSP-13 - Integration eines Semantischen Tagging Systems in Microsoft Sharepoint Martin

Mehr

Dokumentation EGVP-Übertmittlungsfehler bei Server-Engpässen Vorgehensweise Seite 1 von 5

Dokumentation EGVP-Übertmittlungsfehler bei Server-Engpässen Vorgehensweise Seite 1 von 5 Seite 1 von 5 Wie kann dokumentiert werden, dass Anmeldungen zum Handelsregister wegen EGVP-Server-Engpässen nicht versendet werden können? Insbesondere wenn zum 31.8. fristgebundene Anmeldungen vorzunehmen

Mehr

costream Collaborative Media Streaming

costream Collaborative Media Streaming Institut für Betriebssysteme und Rechnerverbund Technische Universität Braunschweig 21. September 2004 1 Inhalt Einleitung Szenarien Proxy-Architektur zur Signalisierung Auffinden von Diensten Gruppenkommunikation

Mehr

Anwendungsbeschreibung des ReNoStar-Druckers

Anwendungsbeschreibung des ReNoStar-Druckers Anwendungsbeschreibung des ReNoStar-Druckers Stand September 2007 Inhalt Inhalt... 2 Anforderung aus der Praxis... 3 Die ReNoStar Drucker-Leiste... 3 Erstellen einer Vorlage... 3 Reihenfolge der Vorlagen

Mehr

Rollen- und Rechtekonzept

Rollen- und Rechtekonzept Inhaltsverzeichnis Rollen- und Rechtekonzept 1. Ziele...1 2. Konzeption zur Realisierung durch Access Control List und im Management-Interface...2 2.1. Ansatz...2 2.2. Safety oder Security...2 2.3. User-

Mehr

A Domain Specific Language for Project Execution Models

A Domain Specific Language for Project Execution Models A Domain Specific Language for Project Execution Models Eugen Wachtel, Marco Kuhrmann, Georg Kalus Institut für Informatik Software & Systems Engineering Inhalt Einführung und Hintergrund Problembereiche

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

SaaS-Referenzarchitektur. iico-2013-berlin

SaaS-Referenzarchitektur. iico-2013-berlin SaaS-Referenzarchitektur iico-2013-berlin Referent Ertan Özdil Founder / CEO / Shareholder weclapp die Anforderungen 1.000.000 registrierte User 3.000 gleichzeitig aktive user Höchste Performance Hohe

Mehr

GroupWise Kurs. erweiterte Funktionen

GroupWise Kurs. erweiterte Funktionen GroupWise Kurs erweiterte Funktionen Gliederung 1. REGEL/ FILTER/ SPAM 2 1.1. Urlaubsregel 2 1.2. Junk-Regel 3 2. GRUPPENARBEIT 4 2.1. Freigaben 4 2.2. Vertretung 7 3. SUCHERGEBNISSORDNER 9 4. EXTERNE

Mehr

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Betriebswirtschaftliche Anwendungen 2: Serviceorientierte Anwendungsintegration Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Umrechnung von Währungen Steffen Dorn, Sebastian Peilicke,

Mehr

Scheinaufgabe im Fach Web Engineering

Scheinaufgabe im Fach Web Engineering Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Scheinaufgabe im Fach Web Engineering Thomas Thüm 07. August 2006 Matrikel: 171046 Lehrveranstaltung: Web

Mehr

Einleitung: Frontend Backend

Einleitung: Frontend Backend Die Internetseite des LSW Deutschland e.v. hat ein neues Gesicht bekommen. Ab dem 01.01.2012 ist sie in Form eines Content Management Systems (CMS) im Netz. Einleitung: Die Grundlage für die Neuprogrammierung

Mehr

Integrationsprozesse. cross component BPM - Steuerung systemübergreifender Szenarien. Konrad Lubenow, FHTW Berlin, Juli 2007

Integrationsprozesse. cross component BPM - Steuerung systemübergreifender Szenarien. Konrad Lubenow, FHTW Berlin, Juli 2007 Integrationsprozesse cross component BPM - Steuerung systemübergreifender Szenarien Konrad Lubenow, FHTW Berlin, Juli 2007 Integrationsprozesse XI(ccBPM) normaler Messageaustausch über den Integrationsserver

Mehr

Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation

Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation WF2Trans Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation Aus unserer langjährigen Erfahrung in Kundenprojekten wissen wir, dass ein klares und eindeutiges

Mehr

Raid-Log-Import: Manual

Raid-Log-Import: Manual Raid-Log-Import: Manual Autor: Hoofy Ein Plugin für: Inhaltsverzeichnis 1. Einführung 2. Einstellungen Was bedeutet welche Option? 2.1. Allgemeine Optionen 2.2. Mitglieder Einstellungen 2.3. Parse-Einstellungen

Mehr

(August 2008 Version basierend auf Clix 7)

(August 2008 Version basierend auf Clix 7) Informationsmaterial Bewertungsassistent Version 1.1 für Übungsgruppen im Lernportal mybtu Benutzerleitfaden für Tutoren (August 2008 Version basierend auf Clix 7) Verfasser: M. Schulze / S. Tschöpel Brandenburgische

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

codia Schriftgutverwaltung / Aktenplan

codia Schriftgutverwaltung / Aktenplan codia Schriftgutverwaltung / Aktenplan codia Software GmbH Auf der Herrschwiese 15a 49716 Meppen Telefon: 0 59 31/93 98 0 Telefax: 0 59 31/93 98 25 E-Mail: info@codia.de Internet: www.codia.de [1] 1 codia

Mehr

Seitenverwaltung und Einrichten neuer TYPO3-Redakteure und -Gruppen

Seitenverwaltung und Einrichten neuer TYPO3-Redakteure und -Gruppen August 2010 Seitenverwaltung und Einrichten neuer TYPO3-Redakteure und -Gruppen In der TYPO3-Standard-Website des RRZN sind bereits einige Redakteursgruppen eingerichtet. Die Gruppe mit den umfangreichsten

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Prototypvortrag. Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning. Projektseminar WS 2009/10

Prototypvortrag. Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning. Projektseminar WS 2009/10 Prototypvortrag Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning Projektseminar WS 2009/10 Eugen Fot, Sebastian Kenter, Michael Surmann AG Parallele

Mehr

Neuerungen im Enterprise Miner 5.2 & Text Miner 2.3

Neuerungen im Enterprise Miner 5.2 & Text Miner 2.3 Neuerungen im Enterprise Miner 5.2 & Text Miner 2.3 Copyright 2005, SAS Institute Inc. All rights reserved. Ulrich Reincke, SAS Deutschland Agenda Der Neue Enterprise Miner 5.2 Der Neue Text Miner 2.3

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

Mitarbeitereinsatzplanung. easysolution GmbH 1

Mitarbeitereinsatzplanung. easysolution GmbH 1 Mitarbeitereinsatzplanung easysolution GmbH 1 Mitarbeitereinsatzplanung Vorwort Eines der wichtigsten, aber auch teuersten Ressourcen eines Unternehmens sind die Mitarbeiter. Daher sollten die Mitarbeiterarbeitszeiten

Mehr

greenitblue CRM-Mailsystem

greenitblue CRM-Mailsystem greenitblue CRM-Mailsystem Das teamfähige Mailsystem zur Abwicklung und Dokumentation Ihrer Kommunikationsprozesse Steffen Pöllot. Hans-Günter Stein Dieses Dokument dient ausschließlich zur Information

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

Neues Projekt anlegen... 2. Neue Position anlegen... 2. Position in Statikdokument einfügen... 3. Titelblatt und Vorbemerkungen einfügen...

Neues Projekt anlegen... 2. Neue Position anlegen... 2. Position in Statikdokument einfügen... 3. Titelblatt und Vorbemerkungen einfügen... FL-Manager: Kurze beispielhafte Einweisung In dieser Kurzanleitung lernen Sie die wichtigsten Funktionen und Abläufe kennen. Weitere Erläuterungen finden Sie in der Dokumentation FLManager.pdf Neues Projekt

Mehr

15 Bilder und Dateien im SQL Server

15 Bilder und Dateien im SQL Server Leseprobe aus Access und SQL Server http://www.acciu.de/asqllesen 15 Bilder und Dateien im SQL Server Eines der großen Probleme von Access-Datenbanken ist der vergleichsweise geringe Speicher platz. Sicher,

Mehr

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel VS12 Slide 1 Verteilte Systeme Vorlesung 12 Sebastian Iwanowski FH Wedel Mögliche Plattformen für Web Services VS12 Slide 2 VS12 Slide 3 Java-Software für verteilte Systeme J2EE: Java 2 Enterprise Edition

Mehr

GlobalHonknet.local. Entfernen von Metadaten aus Active Directory 09.12.2003 13.12.2003. nach Offlineschaltung und fehlgeschlagener DC Herabstufung

GlobalHonknet.local. Entfernen von Metadaten aus Active Directory 09.12.2003 13.12.2003. nach Offlineschaltung und fehlgeschlagener DC Herabstufung GlobalHonknet.local 1 von 14 GlobalHonknet.local Am Rollberg 21, 13158 Berlin Entfernen von Metadaten aus Active Directory nach Offlineschaltung und fehlgeschlagener DC Herabstufung 09.12.2003 13.12.2003

Mehr

Verwendung der Report-Funktion in der ArtemiS SUITE (ab Version 5.0)

Verwendung der Report-Funktion in der ArtemiS SUITE (ab Version 5.0) Verwendung der (ab Version 5.0) In der ArtemiS SUITE steht eine neue, sehr flexible Reporting-Funktion zur Verfügung, die mit der Version 5.0 noch einmal verbessert wurde. Die vorliegende beschreibt den

Mehr

Administration Gruppen (Institution)

Administration Gruppen (Institution) Administration Gruppen (Institution) Kurzanleitung für den Moderator (mit Administrationsrechten) (1) Loggen Sie sich ein und klicken Sie auf den Reiter Institution. (2) Wählen Sie rechts oben über die

Mehr

Manual WordPress - ContentManagementSystem

Manual WordPress - ContentManagementSystem Was ist WordPress? WordPress ist ein ContentManagementSystem (CMS) zur Verwaltung der Inhalte einer Website. Es bietet sich besonders zum Aufbau und Pflege eines Weblogs (Online-Tagebuch) an. Funktionsschema

Mehr

Dokumentation für die Arbeit mit dem Redaktionssystem (Content Management System -CMS) zur Wartung Ihrer Homepage (Website)

Dokumentation für die Arbeit mit dem Redaktionssystem (Content Management System -CMS) zur Wartung Ihrer Homepage (Website) Dokumentation für die Arbeit mit dem Redaktionssystem (Content Management System -CMS) zur Wartung Ihrer Homepage (Website) Redaktion Mit der Redaktion einer Webseite konzentrieren Sie sich auf die inhaltliche

Mehr

Kurzbedienungsanleitung des WebMail-Interfaces Roundcube

Kurzbedienungsanleitung des WebMail-Interfaces Roundcube Kurzbedienungsanleitung des WebMail-Interfaces Roundcube Roundcube Webmail (ebenfalls bekannt als RC) ist ein mehrsprachiger IMAP Client, der als Schnittstelle zu unserem Emailserver dient. Er hat eine

Mehr

Die Erkenntnis von gestern muss heute mit einem neuen. 19.06.2009 TEAM - Ihr Partner für IT 2

Die Erkenntnis von gestern muss heute mit einem neuen. 19.06.2009 TEAM - Ihr Partner für IT 2 Beratung Software Lösungen Integration von Reporting Tools in Oracle ADF 11g Applikation Der Inhalt dieses Vortrages beruht auf den Erfahrungen und Erkenntnissen zu einem bestimmten Zeitpunkt und unter

Mehr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr Aufgabe 8.1: Zeigerverdopplung Ermitteln Sie an folgendem Beispiel den Rang für jedes Listenelement sequentiell und mit dem in der Vorlesung vorgestellten parallelen

Mehr

SemanticMediaWiki+ als Wissensplattform für Unternehmen

SemanticMediaWiki+ als Wissensplattform für Unternehmen SemanticMediaWiki+ als Wissensplattform für Unternehmen Zielgruppengerechte Produktion von Trainingsmaterial am Beispiel der UNESCO Daniel Hansch, hansch@ontoprise.de, ontoprise GmbH Hans-Peter Schnurr,

Mehr

IAWWeb PDFManager. - Kurzanleitung -

IAWWeb PDFManager. - Kurzanleitung - IAWWeb PDFManager - Kurzanleitung - 1. Einleitung Dieses Dokument beschreibt kurz die grundlegenden Funktionen des PDFManager. Der PDF Manager dient zur Pflege des Dokumentenbestandes. Er kann über die

Mehr

Installation des edu- sharing Plug- Ins für Moodle

Installation des edu- sharing Plug- Ins für Moodle Installation des edu- sharing Plug- Ins für Moodle [edu-sharing Team] [Dieses Dokument beschreibt die Installation und Konfiguration des edu-sharing Plug-Ins für das LMS Moodle.] edu- sharing / metaventis

Mehr

Eine Wiederherstellung setzt immer ein vorhandenes Backup voraus. Wenn man nichts sichert, kann man auch nichts zurücksichern.

Eine Wiederherstellung setzt immer ein vorhandenes Backup voraus. Wenn man nichts sichert, kann man auch nichts zurücksichern. Exchange Daten wieder ins System einfügen (Dieses Dokument basiert auf einem Artikel des msxforum) Eine Wiederherstellung setzt immer ein vorhandenes Backup voraus. Wenn man nichts sichert, kann man auch

Mehr

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de Fortgeschrittene Servlet- Techniken Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Servlet Initialisierung Attribute und Gültigkeitsbereiche Sessions

Mehr

Erste Schritte mit Elvis 3 ein Beispielprojekt

Erste Schritte mit Elvis 3 ein Beispielprojekt Erste Schritte mit Elvis 3 ein Beispielprojekt Um Sie mit Elvis 3 vertraut zu machen möchten wir mit Ihnen mit diesem Kapitel ein Beispielprojekt vom ersten Aufruf von Elvis 3 bis zum Testlauf aufbauen.

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Process Mining Tutorial: ProM 6 und Disco. Luise Pufahl 3. Juni 2014

Process Mining Tutorial: ProM 6 und Disco. Luise Pufahl 3. Juni 2014 Process Mining Tutorial: ProM 6 und Disco Luise Pufahl 3. Juni 2014 5 Gliederung 1. Szenario 2. Disco Fluxicon 3. ProM 6 2 Szenario 5 Szenario Purchase Process Requester Request for quotation Request for

Mehr

Zeichnen von Graphen. graph drawing

Zeichnen von Graphen. graph drawing Zeichnen von Graphen graph drawing WS 2006 / 2007 Gruppe: D_rot_Ala0607 Christian Becker 11042315 Eugen Plischke 11042351 Vadim Filippov 11042026 Gegeben sei ein Graph G = (V; E) Problemstellung V E =

Mehr

Dokumentation zur Anlage eines JDBC Senders

Dokumentation zur Anlage eines JDBC Senders Dokumentation zur Anlage eines JDBC Senders Mithilfe des JDBC Senders ist es möglich auf eine Datenbank zuzugreifen und mit reiner Query Datensätze auszulesen. Diese können anschließend beispielsweise

Mehr

Softwaretechnologie für die Ressourcenlinguistik

Softwaretechnologie für die Ressourcenlinguistik Tools und Frameworks FSU Jena Gliederung 1 Pipelines Formate 2 3 Übersicht Details Fazit Pipelines Formate Komponenten bilden eine Pipeline Text Sentence Splitter Tokenizer POS-Tagger Output Texte werden

Mehr

WORKFLOWS. Vivendi NG, Vivendi PD Workflows, CRM VERSION: 6.17. Frage:

WORKFLOWS. Vivendi NG, Vivendi PD Workflows, CRM VERSION: 6.17. Frage: WORKFLOWS PRODUKT(E): KATEGORIE: Vivendi NG, Vivendi PD Workflows, CRM VERSION: 6.17 Frage: Unter Vivendi NG und Vivendi PD finde ich die Schaltfläche: Wofür kann ich diese Funktion nutzen? Antwort: Ab

Mehr

Ein Tool zum Konvertieren von Pegasus Mail Adressbüchern und Verteilerlisten in Novell Groupwise Adressbücher.

Ein Tool zum Konvertieren von Pegasus Mail Adressbüchern und Verteilerlisten in Novell Groupwise Adressbücher. Ein Tool zum Konvertieren von Pegasus Mail Adressbüchern und Verteilerlisten in Novell Groupwise Adressbücher. Inhalt 1. Konvertieren von Adressbüchern und Verteilerlisten 1.1 Grundlagen 1.2 Adressbücher

Mehr

Installation und Benutzung AD.NAV.ZipTools

Installation und Benutzung AD.NAV.ZipTools Installation und Benutzung AD.NAV.ZipTools Version 1.0.0.0 ALTENBRAND Datentechnik GmbH Am Gelicht 5 35279 Neustadt (Hessen) Tel: 06692/202 290 Fax: 06692/204 741 email: support@altenbrand.de Die Komponente

Mehr

Outlook Web App 2010. Kurzanleitung. interner OWA-Zugang

Outlook Web App 2010. Kurzanleitung. interner OWA-Zugang interner OWA-Zugang Neu-Isenburg,08.06.2012 Seite 2 von 15 Inhalt 1 Einleitung 3 2 Anmelden bei Outlook Web App 2010 3 3 Benutzeroberfläche 4 3.1 Hilfreiche Tipps 4 4 OWA-Funktionen 6 4.1 neue E-Mail 6

Mehr

Alerts für Microsoft CRM 4.0

Alerts für Microsoft CRM 4.0 Alerts für Microsoft CRM 4.0 Benutzerhandbuch Der Inhalt des Dokuments ist Änderungen vorbehalten. Microsoft und Microsoft CRM sind registrierte Markenzeichen von Microsoft Inc. Alle weiteren erwähnten

Mehr

Toleranzschema. ArtemiS SUITE

Toleranzschema. ArtemiS SUITE Anzeige von Referenz- und Grenzwertkurven Überprüfung von Analyseergebnissen auf Über- bzw. Unterschreitungen der definierten Grenzwertkurven HEARING IS A FASCINATING SENSATION ArtemiS SUITE Motivation

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

BPMN. Suzana Milovanovic

BPMN. Suzana Milovanovic BPMN Suzana Milovanovic 2 Übersicht Klärung von Begriffen, Abkürzungen Was ist BPMN? Business Process Diagram (BPD) Beispielprozess Entwicklung von BPMN BPMN in der Literatur 3 Grundlegende Begriffe Business

Mehr

Kundeninformation zur neuen Version 5.0

Kundeninformation zur neuen Version 5.0 Kundeninformation zur neuen Version 5.0 Kundeninformation Die Version 5.0 hat teilweise ihr Gesicht verändert. Einige Funktionalitäten wurden auch geändert. Um Ihnen den Umstieg leichter zu machen, finden

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Das nachfolgende Konfigurationsbeispiel geht davon aus, dass Sie bereits ein IMAP Postfach eingerichtet haben!

Das nachfolgende Konfigurationsbeispiel geht davon aus, dass Sie bereits ein IMAP Postfach eingerichtet haben! IMAP EINSTELLUNGEN E Mail Adresse : Art des Mailservers / Protokoll: AllesIhrWunsch@IhreDomain.de IMAP SMTP Server / Postausgangsserver: IhreDomain.de (Port: 25 bzw. 587) IMAP Server / Posteingangsserver:

Mehr

Erstellung eines SharkNet Installers für Windows mit Inno Setup Compiler 5.4.2

Erstellung eines SharkNet Installers für Windows mit Inno Setup Compiler 5.4.2 Erstellung eines SharkNet Installers für Windows mit Inno Setup Compiler 5.4.2 1. Benötigte Software Zur Erstellung des Installers wird folgende Software benötigt. Es wird sich in dieser Dokumentation

Mehr

eclipse - Entwicklungsumgebung und mehr ETIS SS05

eclipse - Entwicklungsumgebung und mehr ETIS SS05 eclipse - Entwicklungsumgebung und mehr ETIS SS05 Gliederung Motivation Geschichte Architektur Platform Runtime Eclipse Platform Java Development Tools (JDE) Plugin Development Environment (PDE) Zusammenfassung

Mehr

Installation Anleitung für JTheseus und MS SQL Server 2000

Installation Anleitung für JTheseus und MS SQL Server 2000 Installation Anleitung für JTheseus und MS SQL Server 2000 Inhaltsverzeichnis 1 Installation der Datenbank 3 1.1 Erstellen der Datenbank 3 1.2 Tabellen und Minimal Daten einlesen 4 1.3 Benutzer JTheseus

Mehr