8. Arbeitstreffen der GI-Fachgruppe 1.1.5/7.0.1

Intelligente Lehr-/Lernsysteme

Christian Herzog (Hrsg.), Institut für Informatik, TU München,

TUM-I9736, August 1997

D3-WWW-Trainer

Entwicklung einer Oberfläche für die Netzanwendung

Sven Faulhaber, Bettina Reinhardt

Universität Würzburg,

Lehrstuhl für Künstliche Intelligenz und Angewandte Informatik,

Allesgrundweg 12, 97218 Gerbrunn

Email: reinhard@informatik.uni-wuerzburg.de

 

Zusammenfassung

Die weite Verfügbarkeit des Internets eröffnet viele neue Möglichkeiten. Gerade in dem Bereich des Computerunterstützen Lernens ist ein web-basiertes Lernen von Vorteil, da die gängigen Probleme, wie Plattformabhängigkeit, Wartung oder Erweiterbarkeit wegfallen, bzw. entschärft werden. Bei den meisten Systemen, die im Moment im Internet verfügbar sind, handelt es sich um reine Lehrsysteme ohne oder nur mit geringer Lerntestabfrage. In diesem Beitrag wird vorgestellt wie ein hochgradig interaktives Intelligentes Tutorsystem zu einem webfähigen System erweitert wird.

 

Schlüsselwörter

Computer Basiertes Training (CBT), Intelligente Tutorsysteme, Internet

 

Einleitung

Durch die sich ständig erweiternde Zugriffsmöglichkeit auf das Internet und die Zurverfügungstellung von Intranetzen an Universitäten und Kliniken eröffnen sich für das computerunterstützte Lernen neue Möglichkeiten. Ein wesentlicher Vorteil von web-basiertem Lernen ist die relative Plattformunabhängigkeit der WWW-Programme und -Dokumente. Kosten und Entwicklungszeit lassen sich dadurch drastisch reduzieren. Da die Software über das Netz abgerufen werden kann, entfallen bei den Studenten oder auf den von den Universitäten und Kliniken zur Verfügung gestellten Rechnern die zeitraubenden und oft nicht unproblematischen Installationen der Lernsysteme. Ein weiterer Vorteil der zentralen Wartbarkeit ist die Möglichkeit, kurzfristige Erweiterungen einzuspielen. So kann ein Dozent, der in seiner Medizinvorlesung einen Patienten vorgestellt hat, nach der Veranstaltung einen ähnlichen Fall im Lernprogramm erstellen und ihn über das Internet verfügbar machen. Die Studenten können diesen Fall abrufen und die Vorlesung praxisnah nacharbeiten. Der Dozent kann das Internet auch nutzen, um eine Rückkopplung über den Wissensstand seiner Studenten zu erhalten und bei Bedarf auf Schwierigkeiten in der nächsten Vorlesung einzugehen.

Leider hat das web-basierte Lernen aber auch einige Nachteile. Wenn die Software im Internet angewandt werden soll, haben multimediale Dokumente oftmals lange Ladezeiten, insbesondere wenn der Student über einen kommerziellen Provider auf das Internet zugreifen muß. Ein vernünftiges Arbeiten ist unter diesen Umständen häufig nicht möglich. Benötigen die Webdokumente spezielle Plug-Ins (Viewer) zum Abspielen, müssen diese vorher installiert werden, was oftmals schwieriger ist als die eigentliche CBT-Software zu installieren. Ein weiterer Nachteil ist die fehlende Unterstützung von echter Interaktivität durch HTML. Sieht man einmal von Formularen ab, bedeutet jede Interaktivität das Versenden eines neuen HTML-Dokuments. Abhilfe schaffen hier entweder spezielle Plug-Ins oder Java-Applets.

Bei den meisten Systemen, die momentan im Internet verfügbar sind, handelt es sich um reine Lehrsysteme mit in der Regel nur geringer Interaktivität (Beispiele für solche Systeme finden sich z.B. in Kaminski et al. 97, Brünken et al. 97, oder Osada et al. 97). Um aber ein hochgradig interaktives Intelligentes Tutorsystem webfähig zu machen, reichen HTML-Dokumente nicht mehr aus. Der häufige Datenaustausch würde ein zügiges Arbeiten nicht mehr zulassen. Es wird deswegen eine Benutzerschnittstelle benötigt, die die speziellen Darstellungen der Informationen ermöglicht und gleichzeitig die Anzahl der Kommunikation mit dem Server auf ein Minimum reduziert. Zur Implementierung bietet sich hier die plattformunabhängigen Code erzeugende Programmiersprache JAVA an.

Im folgenden wird nun beschrieben, wie die Umsetzung eines hochgradig interaktiven Tutorsystem zu einem webbasierten System geplant und umgesetzt wurde. Dazu wird erst kurz das ursprüngliche System vorgestellt, bevor auf die genau Umsetzung der Oberfläche eingegangen und das webbasierte System genauer betrachtet wird.

Grundzüge des D3 Trainers

Der Expertensystembaukasten D3 [siehe Puppe et al. 96] besitzt eine tutorielle Komponente, den TRAINER, der das Problemlöseverhalten eines Studenten aufgrund der "heuristischen" Regeln einer Wissensbasis kritisieren kann. Der TRAINER [siehe Puppe&Reinhardt 95, Reinhardt 96, Reinhardt&Puppe 97] arbeitet fallorientiert mit den Studenten, d.h. sie bekommen einen Patienten vorgestellt, den sie diagnostizieren können.

In dem einfachsten Modus, dem geführten Test, werden dem Studenten die Patientendaten schrittweise in Gruppen (in der Medizin z.B. Anamnese, körperliche Untersuchungen, Labor und technische Untersuchungen) präsentiert, wobei die Symptome hierarchisch angeordnet sind. Der Student muß nach jeder Gruppe einen Verdacht äußern. Die Verdachtsäußerung geschieht über die Auswahl einer oder mehrerer Diagnosen aus einer geordneten Hierarchie und wird im Vergleich zu den von dem Expertensystem hergeleiteten Diagnosen kritisiert. In diesem Szenario lernt der Student explizit die Schlußfolgerung von Diagnosen aus gegebenen Symptomen.

In dem zweiten Modus, dem ausführlichen Test, erscheinen bei Fallbeginn nur die Basissymptome. Der Student muß hier zusätzlich weitere Untersuchungen anfordern. Auch hier kann er im Vergleich zu dem Wissen des Expertensystems bewertet werden. In diesem Modus lernt der Student zusätzlich zu den Schlußfolgern aus den gegebenen Daten außerdem das gezielte Nachfragen nach neuen Daten aufgrund diagnostischer Gesichtspunkte.

Die dritte Teilaufgabe in der Diagnostik neben Schlußfolgern und Nachfragen ist das Erkennen von Symptomen, das durch ein zusätzliches multimediales Dokument unterstützt wird. Der Student muß in den Bildern und Texten des Dokuments Symptome erkennen und diese in die Liste der Patientendaten eintragen. Da das System weiß, welche Symptome in den verschiedenen Elementen dargestellt werden, kann es diese Symptomerkennung ebenfalls vollständig kritisieren.

Der Experte kann einen neuen Fall innerhalb von wenigen Minuten der Fallbasis hinzufügen. Es besteht auch die Möglichkeit, über die fallvergleichende Problemlösung einen ähnlichen, schon existierenden Fall zu finden und diesen ebenfalls im Trainer zur Verfügung zu stellen. Ein Dozent kann so zu einem realen Patienten, der im Rahmen eines Kurses untersucht wurde, einen ähnlichen Fall erstellen bzw. suchen und zur Verfügung stellen.

Umsetzung der Oberfläche

Die Akzeptanz eines Lernprogramms hängt sehr stark von seiner Benutzerschnittstelle ab. Die allgemeinen Prinzipien zur Gestaltung von Benutzerschnittstellen sind hier eher noch wichtiger als in anderen Dialogprogrammen, weil lange Einarbeitungszeiten, aufwendige Bedienung, mangelnde Robustheit und Fehlertoleranz den erhofften Nutzen eines Tutorsystems völlig zunichte machen können [vgl. Puppe 92, S. 201].

Untersuchungen zur Verbesserung der Benutzerschnittstelle

Aus Rückmeldungen von Benutzern des D3-Trainers ist bekannt, daß in der momentanen Version der Benutzerschnittstelle des D3-Trainers einige Punkte kritisch zu betrachten sind. Der Entwicklung der WWW-Oberfläche gingen deswegen Untersuchungen voraus, wie die Benutzeroberfläche gestaltet werden kann, so daß ein möglichst effektives Arbeiten gewährleistet ist. Es wurden dazu bei einigen fallbasierten CBT-Systemen die Prinzipien der Überwachung und Bewertung des Studenten sowie die Lehrstoff- und Fallpräsentation untersucht.

Bei den Prinzipien der Überwachung und Bewertung des Studenten wurde betrachtet, wer (Benutzer oder Programm) zu welchem Zeitpunkt (sofort, nach Abschluß eines Abschnitts, am Ende des Fallbeispiels) eine Intervention der Lernsoftware auslösen kann. Außerdem wurde der Umfang des Kommentars analysiert, d.h. ob das Programm nur mitteilt, daß eine Aktion falsch bzw. richtig war oder ob eine falsche Aktion auch erklärt und verbessert wird.

 

Bei der Fallbearbeitung wurde untersucht,

Wenn das Lernprogramm neben Fallsimulationen auch Lehrstoffpräsentationen enthalten hat, wurde betrachtet, ob und wie der Lehrstoff mit den Fallbeispielen verknüpft ist, welchen Führungsgrad die Präsentationen haben und aus welchen Elementen (Text, Bilder, Animationen, Videoclips, Geräusche) der Inhalt besteht.

Abbildung 1: Symptomerkennung in der Orginal-Trainerversion. Während in mehreren Fenster die zu erkennenden Symptome gezeigt werden, muß das erkannte Symptom in der Klapphierarchie eingegeben werden, in der auch die restlichen Symptome des Falls angezeigt werden.

Als Beispiel für solch eine Umsetzung sei die Darstellung der Symptomerkennung genannt. Die Erkenntnisse aus dieser Untersuchung wurden der Benutzerschnittstelle des D3-Trainers gegenübergestellt. Es wurde verglichen, wie bestimmte Aufgaben in anderen Programmen vielleicht besser gelöst wurden und um welche Komponenten der D3-Trainer eventuell noch ergänzt werden kann.

Desweiteren wurden Erfahrungen und Erkenntnisse aus Standardwerken zum Design von Benutzerschnittstellen [vgl. Shneiderman 93] einbezogen. Als Ergebnis entstand eine Liste von Vorschlägen, wie der Trainer verbessert werden kann. Die wesentlichen Punkte dieser Liste sind:

In der "Standalone" Trainer-Version muß der Benutzer die Symptome in einem Bild erkennen und in der normalen Fallpräsentation die Symptome eingeben (Abb. 1). Die restlichen Funktionalitäten zu der Symptomerkennung sind in Buttons der beiden Fenster sowie in Menus verteilt. In der "verbesserten" Symptomerkennung des WWW-Trainers sind nun die alle Funktionalitäten zu der Symptomerkennung in einem Fenster integriert (Abb. 2).

Abbildung 2: Neu gestaltetes Fenster zur Symptomerkennung. Während die verschiedenen Bilder zu einem Fall über die Karteikarten zu erreichen sind, ist in dem linken Teil des Fenster immer angezeigt, welche Symptome grundsätzlich in diesem Fenster erkannt werden können.

Konzepterstellung für die WWW-Oberfläche

Der erste Schritt bei der Konzepterstellung für die WWW-Oberfläche bestand darin, festzustellen, welche Fenster mit welchem Inhalt implementiert werden müssen. Dazu wurde ein Ablaufdiagramm der Benutzerschnittstelle des D3-Trainers erstellt, aus der insbesondere auch zu ersehen ist, von welchem Fenster durch welche Funktion zu welchem Fenster gewechselt werden kann. Danach wurden die erforderlichen Schnittstellen zum D3-Trainer definiert. Anschließend wurde der Ablaufplan der Benutzerschnittstelle hinsichtlich der Verbesserungsvorschläge sowie der Einsatzbedingungen im Netz optimiert:

Die Anzahl der Übertragungen soll möglichst gering gehalten werden. Vom UNIX-Filesystem her ist bekannt, daß es insgesamt gesehen günstiger ist, mit wenigen Kommunikationen viele Daten zu übertragen, die eventuell teilweise nicht benötigt werden, als mit vielen Übertragungen nur die wirklich notwendigen Daten anzufordern [vgl. Hieronymus 93, S 64-65].

Daten, die bereits von einer früheren Übertragung her ganz oder teilweise bekannt sind, und in gleicher oder ähnlicher Form wieder benötigt werden, sollten nach Möglichkeit nicht ein weiteres Mal übertragen werden. Stattdessen sollte versucht werden, die vorhandenen Daten wiederzuverwenden.

Kommunikationsfreie Zeiten sollten für vorausschauendes Laden von eventuell in Zukunft benötigten Daten verwendet werden, d.h. während sich der Benutzer Daten anschaut und dafür keine Kommunikation zwischen Client und Server erforderlich ist, kann diese Zeit genutzt werden, im Hintergrund Daten zu laden, die sich der Benutzer wahrscheinlich in Zukunft anschauen wird.

 

Es entstand ein Konzept für ein Java-Applet, das viele Interaktionen selbständig ausführen kann, ohne dafür mit dem D3-Trainer auf der Server-Seite kommunizieren zu müssen. Dazu werden die erforderlichen Daten in der Regel am Anfang eines Programmabschnitts komplett übertragen, auch auf die Gefahr hin, daß sie teilweise eventuell nicht benötigt werden.

Weiterhin ist das Java-Applet in die Lage, bereits einmal übertragene Daten bei einer erneuten Anforderung als vorhanden zu erkennen und somit auf eine zweite Anforderung vom Server zu verzichten. So muß zum Beispiel die Liste der möglichen Diagnosen nur einmal geladen werden, weil sich daran im Verlauf des Fallbeispiels nichts mehr ändert. Dieselben Daten können außerdem auch zur Begründung einer angeforderten Untersuchung verwendet werden.

Desweiteren nutzt das Applet die Multithreading-Fähigkeit von Java aus, um bestimmte Daten vorausschauend zu laden. Beispielsweise kann die Liste der möglichen Diagnosen geladen werden, während sich der Student parallel dazu die Präsentation die Symptome anschaut.

Der Trainer im Internet

Eine Kommunikation zwischen der in Java erstellten Oberfläche des Client und dem in Lisp programmierten TRAINER auf der Server-Seite wird immer durch den Client eingeleitet. Dieser ruft den TRAINER wie ein CGI-Script auf, allerdings mit dem Unterschied, daß als Parameter Lisp-Funktionen übergeben werden. Diese Lisp-Funktionen realisieren die im Konzept definierten Schnittstellen. Außerdem enthalten sie die Eingaben, die der Student gemacht hat und die zur Beantwortung der Anforderung (Request) des Clients benötigt werden. Der TRAINER führt diese Lisp-Funktionen aus und das Ergebnis, welches wie bei CGI-Scripts üblich auf die Standardausgabe geschrieben wird, leitet der HTTP-Server an das Java-Applet weiter. Das Applet interpretiert anschließend diese Daten und baut damit bei Bedarf das bzw. die nächste(n) Dialogfenster auf.

Da die "normale" Traineroberfläche viel häufiger mit dem internen Komponenten kommuniziert, wurde auf der Serverseite ein spezielle Kommunikationskomponente benötigt, die eine Anforderung des Clients in mehrere interne Anforderungen umsetzt und deren Antworten dann wieder zu einer Antwort bündelt. Desweiteren verwaltet sie die aktiven Benutzer, so daß mehrere Studenten gleichzeitig mit dem TRAINER arbeiten können. Dazu mußten auch die internen Komponenten des Trainers multiuserfähig gemacht werden. Für die Verwaltung mehrerer Anwender wurde ein Konzept entwickelt, welches ermöglicht das gesamte dynamische und somit benutzer-, bzw. falldefinierte Wissen für die einzelnen Anwender zwischenzuspeichern. Bei den Abfragen durch den Server wird somit das dynamische Wissen immer auf den aktuellen Anwender umgesetzt.

Das Java-Applet läuft in einem eigenen Frame ab, so daß der Browser zur Fallbearbeitung eigentlich nicht benötigt wird. Dieses Umstand nutzt die Online-Hilfe aus und zeigt die Hilfetexte im Browser an. Das hat nicht nur den Vorteil, daß so relativ einfach ein hypertextbasiertes Handbuch erstellt werden kann, sondern auch, daß der Caching-Mechanismus des Browsers ausgenutzt werden kann. Hilfetexte sind so unter Umständen über eine Sitzung hinaus im Browser-Cache und brauchen nicht ein weiteres Mal übertragen zu werden. Das Java-Applet basiert auf dem JDK 1.1, da das AWT des JDK 1.0 bei einigen Windows-Implementationen noch Unzulänglichkeiten aufweist.

 

Um den Datenfluß zwischen Server und Client und die Aufgabenverteilung darzustellen, wird nachfolgend in vereinfachteter Form der Anfang eines Ablaufs einer typischen Sitzung beschrieben:

Benutzer: Ruft HTML-Seite auf, Applet ( = Client) wird gestartet

Client: Schickt Anmeldung an Server

Server: Antwortet mit Benutzer-ID und einer Liste alle verfügbaren Wissensbasen

Benutzer: Wählt eine Wissensbasis aus

Client: Teilt Server die Auswahl der neuen Wissensbasis mit

Server: Antwortet mit Liste der verfügbaren Fälle für Wissensbasis

Client: Fordert Einstellungen des TRAINERS an

Server: Antwortet mit Liste der Einstellungen

Benutzer: Wählt ein Fallbeispiel aus

Client: Teilt Server die Auswahl eines Fallbeispiels mit

Server: Antwortet mit Basisdaten zum Fall

Client: Fordert Symptomhierarchie zum Fall an

Server: Stellt Grunddaten aller bekannten Symptome in einer Liste zusammen und schickt Daten als Antwort zurück

Client: Interpretiert Symptomliste und baut Klapphierarchie auf

Client: Fordert Liste von Diagnosen als Hintergrundübertragung an

Server: Beginnt mit der Übertragung der Liste von Diagnosen

Client: Fordert Liste von weiteren Untersuchungsmöglichkeiten als Hintergrundübertragung an

Benutzer: Schaut sich die Symptome in der Klapphierchie an

Benutzer: Will eine erste Verdachtsdiagnose stellen und klickt entsprechenden Button an

Client: Überprüft, ob Server bereits auf die Anfrage "Liste von Diagnosen" geantwortet hat. Falls nicht, erhält Anfrage höchste Priorität und Client wartet auf Eintreffen der Antwort

Client: Interpretiert Diagnoseliste und baut Klapphierarchie auf

Benutzer: Wählt eine oder mehrere Diagnosen aus

Client: Schickt ausgewählte Diagnosen an Server (höchste Priorität)

Server: Trainer analysiert und kommentiert die Diagnoseauswahl. Server antwortet mit Kommentar

Client: Zeigt Kommentar an

Benutzer: Liest Kommentar durch und will Symptompräsentation wieder sehen

Client: Zeigt Symptompräsentation wieder an ....

Zusammenfassung und Ausblick

Die Entwicklung der WWW-Oberfläche hat gezeigt, daß auch hochgradig interaktive Trainingssysteme im Internet bzw. einem Intranet sinnvoll eingesetzt werden können. Durch die oftmals geringe Bandbreite im Internet bedarf es bei der Datenübertragung besonderer Anstrengungen, damit der Benutzer effektiv arbeiten kann. Zur Implementierung solcher Anwendungen ist Java ideal, da es nicht nur plattformunabhängig und multithreading-fähig ist, sondern auch ein leistungsstarkes Paket zur Netzwerk-Programmierung zur Verfügung stellt.

Bei der Oberflächenerstellung hat Java zwar in einigen Punkten etwas enttäuscht (z.B. bei der Ereignisbehandlung), allerdings wurden diese Schwachstellen bereits größtenteils im JDK 1.1 verbessert. Java wird in Zukunft sicher nicht nur bei Web-Anwendungen eine wichtige Rolle spielen, sondern auch bei konventionellen Dialogprogrammen, die auf unterschiedlichen Plattformen lauffähig sein sollen.

Der Trainer wird in Zukunft mit mehreren Anwendungen im Netz verfügbar sein und durch die somit erweiterte Anzahl an möglichen Benutzern weitere Verbesserungen erfahren.

Literatur:

Brünken et al. 97 Brünken, R., Leutner, D., Tolxdorff, T.: RADIOLIS: Ein Lehr- und Informationssystem für die Radiologie. In: H. Conradi, R. Kreutz, K. Spitzer (Hrsg.) CBT in der Medizin - Methoden, Techniken, Anwendungen. Augustin Buchhandlung Aachen, 97

Hieronymus 93 Hieronymus, A: UNIX-Systemarchitektur und Programmierung, Vieweg 1993

Kaminski et al. 97 Kaminski, R.; Buchner, H., Brünken, R., Schulz-Brünken, B, Pelikan, E., Leutner, D.: ELIS: Lehr- und Information-System zur klinischen Elektroneurophysiologie-Konzept und Realisation. In: H. Conradi, R. Kreutz, K. Spitzer (Hrsg) CBT in der Medizin - Methoden, Techniken, Anwendungen. Augustin Buchhandlung Aachen, 97

Osada et al. 97 Osada, N., Schaarschmidt, K., Prokosch, H.U., Höfner, J., Preuss, C.: Entwicklung eines Lehrsystems über die Behandlung der Analtresie. In: H. Conradi, R. Kreutz, K. Spitzer (Hrsg.) CBT in der Medizin - Methoden, Techniken, Anwendungen. Augustin Buchhandlung Aachen, 97

Puppe 92 Puppe, Frank: Intelligente Tutorsysteme. In: Informatik Spektrum (1992) 15, S. 195-207.

Puppe&Reinhardt 95 Puppe F., Reinhardt B.: Generating Case-Oriented Training from Diagnostic Expert Systems. In: Machine-mediated learning, 5 (3&4), 1995.

Puppe et al. 96 Puppe F., Bamberger S., Gappa U., Poeck K.: Diagnose- und Informationssysteme, Springer 1996.

Reinhardt 96 Reinhardt, Bettina: Expert Systems und Hypertext for teaching diagnostics. In: Proceeding of the european conference of artificial intelligence in education, Lissabon 1996.

Reinhardt&Puppe 97 Reinhardt, Bettina; Puppe, Frank: Didaktische Aspekte in fallorientierten intelligenten Trainingssystemen. In: H. Conradi, R. Kreutz, K. Spitzer (Hrsg.) CBT in der Medizin - Methoden, Techniken, Anwendungen. Augustin Buchhandlung Aachen, 97.

Shneiderman 93 Shneiderman, B.: Designing The User Interface - Strategies For Effective Human-Computer Interaction, 2. ed., Addison-Wesley 1993