Computerunterstützte Regelinduktionsaufgaben

Autoren: Rupert Rockinger, Matthias Schmauß

Das Programmpaket

Das in dieser Dokumentation beschriebene Programmpaket besteht aus folgenden Einzelanwendungen:

ODeLa Sprache zur Definition von Objekten mit ihren Attributen
RUDOLF Sprache zur Formulierung von Regeln
GASTON Software zum Steuern und Überwachen von Regelinduktionsaufgaben durch den Versuchsleiter
CARINEX Software für die Versuchspersonen
RuleTool Graphisches Hilfsmittel für den Versuchsentwickler. Dient zur Erstellung von Regeln, die in RUDOLF formuliert sind.
RIGen Analysehilfsmittel für den Versuchsentwickler. Dient zur Bestimmung aller Objektsequenzen, die von einer RUDOLF-Regel erlaubt werden.

Am Ende jeder Beschreibung einer Software befindet sich ein kurzer Hinweis zu interessanten Aspekten der Implementierung. Dazu gibt es Verweise auf die detaillierte Beschreibung der Java-Klassen, die den Programmen zugrundeliegen.



[genauere Übersicht] folgt am Ende

Das Experiment

Einleitung

Wenn man die Lösung für ein Problem sucht, hängt die Qualität von Lösungsweg und Lösung von vielen Faktoren ab. Unter anderem sind dies die Tagesform der jeweiligen Person, die Intensität der Vorbereitung auf die Aufgabe und der Umfang der Möglichkeit, in der Gruppe verschiedene Lösungswege zu besprechen und diese gegeneinander abzuwägen. Letzteres wird von der Forschungsgruppe "Empirische und Angewandte Sozialpsychologie" am Institut für Psychologie der Fakultät für Psychologie und Pädagogik der Ludwig-Maximilians-Universität München mit Hilfe von Regelinduktionsaufgaben untersucht. Dies geschieht im Rahmen des Projektes "Effektivität und Leistung durch soziales Lernen" (ELSOL), das von der Deutschen Forschungsgemeinschaft (DFG) gefördert wird. Dabei interessieren sowohl die Bedingungen, unter denen Versuchspersonen gute Leistungen zeigen als auch diejenigen Bedingungen, unter denen diese Leistungen des Einzelnen zum Erfolg bzw. Mißerfolg in der Gruppe führen.

Beschreibung des Experiments

Regelinduktionsaufgaben und Regeln

Bei einer Regelinduktionsaufgabe muß eine Objektsequenz vervollständigt werden. Die Versuchsperson kennt die Regel, nach der die Objektsequenz aufgebaut ist, nicht. Sie muß jedesmal, nachdem sie die Sequenz um ein Objekt erweitert hat, eine Hypothese über die zugrundeliegende Regel aufstellen, die dann durch den Versuchsleiter verifiziert oder falsifiziert wird. Nach einer gewissen Anzahl an Versuchen gibt die Versuchsperson eine endgültige Hypothese (Schlußhypothese) über die zugrundeliegende Regel ab.

Dabei interessiert neben der Entwicklung der Teilhypothesen zur Schlußhypothese vor allem die Zeit, die die Versuchsperson zur Entscheidung für ein bestimmtes Objekt benötigt.

Die Regeln können auf unterschiedliche Art und Weise dargestellt werden, z.B. mit Spielkarten. Eine Spielkarte hat die Attribute Farbe (schwarz, rot) und Wert (As, 2, 3, 4, 5, 6, 7, 8, 9, 10, Bube, Dame, König). Damit lassen sich die folgenden drei Regeln (mit der Sequenzlänge 4) beschreiben:

   (1. Karte: Pik, 2. Karte: Pik, 3. Karte: Kreuz, 4. Karte: Kreuz); 
   oder kurz: (P) (P) (K) (K)
   
   (Herz Dame, Kreuz 2, Herz König, Kreuz 3); 
   oder kurz: (H, Dame) (K, 2) (H, König) (K, 3)
   
   (Herz gerade, Herz ungerade, Pik ungerade, Pik gerade);
   oder kurz: (H, g) (H, u) (P, u) (P, g)

Durchführung des Experiments

Üblicherweise ist die Anzahl der Objekte (im folgenden Spielkarten), die die Versuchsperson legen darf, auf 15 und die Zeit, in der dies geschehen soll, auf 10 Minuten beschränkt. Das Experiment wird mit Kleingruppen von 3 Personen durchgeführt. Um mit dem Experiment vertraut zu werden, absolvieren die Versuchspersonen einige Übungsdurchgänge. Danach wird ihnen eine zu einer Regel passende Anfangskonfiguration (normalerweise eine Karte) vorgelegt, aus der die Versuchspersonen dann, wie oben beschrieben, Hypothesen über die zugrundeliegende Regel aufstellen müssen. Dies geschieht so, daß sich die Versuchspersonen sowohl am Gruppenexperiment (d.h. durch Aufstellen von Gruppenhypothesen) beteiligen als auch ein individuelles Experiment durchführen und somit individuelle Hypothesen aufstellen. Ausgewertet werden neben der Entscheidungszeit für eine bestimmte Karte auch die Unterschiede in der Entscheidungsfindung zwischen dem Gruppenexperiment und den Individualexperimenten.

Computerunterstützung

Die Unterstützung dieses Experiments durch Computer soll nun soweit gehen, daß die Auswahl der Regeln, die Durchführung des Experiments und das Aufzeichnen der Experimentdaten durch den Computer geschehen können. Jedes Gruppenmitglied sitzt dabei vor einem eigenen Computer, und ist dabei mit den anderen Gruppenmitgliedern über ein Netzwerk verbunden, so daß sich die Versuchspersonen Nachrichten zukommen lassen können.

Die Objekte werden auf einem ausgezeichneten Computer ausgewählt. Diese Auswahl erscheint dann auf den Bildschirmen der anderen Gruppenmitglieder, die, nachdem jeder Einzelne seine Individualhypothese abgegeben hat, zusammen eine Gruppenhypothese formulieren. Diese Hypothesen und die einzelnen "Reaktionszeiten" werden über das Netzwerk an eine Sammelstelle, den Experimentserver, geschickt und dort, für eine spätere Auswertung, abgespeichert. Dieser Server wählt auch die zu erratenden Regeln aus einer festgelegten Liste aus. Sind alle Regeln aus dieser Liste abgearbeitet, endet das Experiment.

Die Regeln

Motivation

Wie die Regeln für computerunterstützte Regelinduktionsaufgaben aussehen können, wurde bei der Beschreibung des Experiments bereits gezeigt. Allerdings befinden sich diese Regeln, wie die meisten Informationen, die der Mensch an den Computer weitergibt, in einer für einen Computer nicht verständlichen Form. Da eine Regel etwas reproduzierbares, "regelmäßiges" beschreibt, ist es möglich, diese mit einer Programmiersprache in eine Form zu "verwandeln", die der Computer versteht.
[Hinweis: Technische Details zur Implementierung der Software finden sich in der JavaDoc Dokumentation]

Viele Programmiersprachen (z.B. Java, die Implementierungssprache der computerunterstützten Regelinduktionsaufgaben), sind jedoch nicht geeignet, Regeln, wie sie in diesem Fall benötigt werden, effizient darzustellen. Aus diesem Grund wurde mit Hilfe des Parsertools JavaCC eine Regelsprache entwickelt, mit der Regeln über Objekte, die durch verschiedene Attribute definiert sind, leicht beschrieben werden können: Die Sprache RUDOLF (RUle DefinitiOn Language Format). Um nun auch unabhängig von den Objekten zu werden wurde eine weitere deskriptive Sprache entwickelt:

ODeLa

Bei der Erstellung dieser Software wurde sehr viel Wert auf Flexibilität gelegt. Um sicherzustellen, daß auch zukünftige Aufgaben ohne großen Aufwand mit dieser Software bewältigt werden können ist die Objektbeschreibung vom Programm getrennt worden. Mit ODeLa (Object Definition Language) - einer extra hierfür entwickelten Sprache - kann man die im Experiment benutzten Objekte beschreiben.

Wie funktioniert ODeLa?

Eine ODeLa-Datei kann auch ohne spezielle Programmierkenntnisse erstellt oder veraendert werden. Es genügt ein einfacher Texteditor, wie er auf jedem System verfügbar ist um solche Änderungen durchzuführen.
Die Sprache ermöglicht es die Objekte zu benennen, festzulegen welche Attribute ein Objekt hat und welche Ausprägungen es dafür geben kann. Im ursprünglichen Experiment handelt es sich um Karten, die als Attribute eine Farbe und einen Wert haben.
Um nun auch Sammelbegriffe (zB 'rot' als Farbe) in ODeLa ausdrücken zu können wurden zusätzlich Makro-Definitionen ermöglicht. Um einen Sammelbegriff einzuführen muß lediglich festgelegt werden wofür er steht (zB 'rot' bedeutet entweder 'Karo' oder 'Herz' als Farbe). Diese Makro-Definitionen können auch als mögliche Ausprägung eines Attributs angegeben werden, um eine Zuordung zu diesem Attribut herzustellen. Insbesondere werden Makros so im Programm zur Regelentwicklung (RuleTool) als mögliche Attributwerte sichtbar. Es handelt sich jedoch um eine rein textuelle Ersetzung und nicht um weitere Attributswerte. Dadurch können also beliebige RUDOLF Ausdrücke bzw. auch Teile von RUDOLF Ausdrücken in Makros angegeben werde. Alle in einer Regel verwendeten Makros müssen definiert werden.

ODeLa in EBNF (Erweiterte Backus Naur Form)

Die genaue Syntax der Sprache ergibt sich aus der folgenden vereinfachten EBNF Spezifikation: 
      ODeLadatei ::= objektdef attributdef { attributdef } { makrodef }.
      objektdef ::= 'object :=' name.
      attribdef ::= name ':=' ausprägungen.
      ausprägungen ::= '{' wert {',' wert} '}'.
      macrodef ::= '#'name ':= "' ZEICHENFOLGE '"'.
      name ::= BUCHSTABE { ZIFFER | BUCHSTABE }.
      wert ::= ['#']name | ZIFFER.
Der Parser für ODeLa ist mit Hilfe des JavaCC Tools implementiert. Um eine ODeLa Datei einzulesen übergibt man einfach den entsprechenden FileInputStream an den Konstruktor. Mit der Methode getAttribhash() bekommt man dann die entsprechenden Informationen in einem OdlTable Objekt.
[Details zur Implementierung]

Beispiel

Eine ODeLa Definitionsdatei für Spielkarten: 
object := karte
farbe := { kreuz, pik, herz, karo, #rot, #schwarz }
wert  := { as, 2, 3, 4, 5, 6, 7, 8, 9, 10, bube, dame, koenig, #gerade, #ungerade }
#rot     := "(herz | karo)"
#schwarz := "(kreuz | pik)"
#gerade  := "(2 | 4 | 6 | 8 | 10 | dame)"
#ungerade:= "(as | 3 | 5 | 7 | 9 | bube | koenig)"

Die Regelsprache RUDOLF

Die Sprache RUDOLF ist eine Regelsprache. Eine Regel läßt sich damit, in jedem beliebigen Texteditor, formulieren. Wer sich jedoch nicht mit der Regeldefitionssprache auseinandersetzen will, kann Regeln mit dem Werkzeug RuleTool erstellen. Im Folgenden werden der Aufbau und die Bestandteile der Regelsprache Rudolf beschrieben. Am Ende dieses Kapitels folgen weitere Beispiele.
[Details zur Implementierung]

Aufbau einer RUDOLF-Regel

Eine RUDOLF-Regel besteht aus dem Schlüsselwort sequence und einer beliebig langen Liste von Objekten (durch Kommas getrennt). Die genaue Syntax lautet folgendermaßen:

sequence ( Objekt 1 , Objekt 2 , ... , Objekt n )

Objekte und Attribute

Jedes Objekt hat gewisse Eigenschaften (Attribute), durch die es sich von anderen Objekten unterscheidet. So hat z.B. ein Objekt aus der Klasse der Autos, unter anderem, die Attribute Farbe und Gewicht.

Die Syntax solcher Objekte in RUDOLF sieht folgendermaßen aus:

ObjektBezeichner ( Attribut 1 , Attribut 2 , ... , Attribut m )

Dabei ist ObjektBezeichner eine beliebig lange Zeichenkette, bestehend aus Buchstaben und/oder Zahlen, die mit einem Buchstaben oder dem Zeichen "_" beginnt. Attribute werden in RUDOLF mit

AttributBezeichner ( Wert_Formel_Referenz )

dargestellt. Ein AttributBezeichner ist wie ein ObjektBezeichner aufgebaut. Der Inhalt eines Attributes ist entweder ein Wert oder eine Formel oder eine Referenz. Ein grüner, 1.2 t schwerer VW Käfer läßt sich in RUDOLF mit

Kaefer ( Farbe ( grün ) , Gewicht ( 1200 ) )

beschreiben. Kaefer, Farbe und Gewicht sind Bezeichner. Die Inhalte grün und 1200 sind Werte. Diese Werte sind konstante Formeln. Die Darstellung von Referenzen und komplexeren Formeln folgen in den nächsten beiden Abschnitten.

Bemerkungen:

Arithmetische und logische Formeln

Um einer Regel mehr Flexibilität zu geben, können die Attribute durch Formeln beschrieben werden. Sehr häufig finden dabei logische Formeln, d.h. Konjunktionen oder Disjunktionen, Anwendung.

Syntax einer Konjunktion:

AttributBezeichner ( Wert_Formel_Referenz & Wert_Formel_Referenz )

Syntax einer Disjunktion:

AttributBezeichner ( Wert_Formel_Referenz | Wert_Formel_Referenz )

Ein 1,2 t schwerer VW Käfer, der rot oder grün sein kann, läßt sich in RUDOLF mit

Kaefer ( Farbe ( rot | grün ) , Gewicht ( 1200 ) )

beschreiben. Das Komma zwischen den Attributen Farbe und Gewicht hat ebenfalls die Bedeutung einer Konjunktion. Der Regelparser speichert die Attribute eines Objektes jedoch in einer Liste. Daher sind Disjunktionen, genauso wie andere komplexe Ausdrücke, auf dieser Ebene nicht erlaubt. Dies vereinfacht die Implementation, begrenzt aber die Mächtigkeit der Sprache nicht, da Disjunktionen innerhalb eines Attributes (wie oben) beschrieben werden können. Arithmetische Operatoren (+, -, *, /) werden in gleicher Weise wie "&" und "|" verwendet. Sie entfalten ihre Mächtigkeit jedoch erst mit der Verwendung von Referenzen.

Referenzen

Mit Hilfe von Referenzen kann man auf den Inhalt eines Attributes eines schon in der Sequenz beschriebenen Objektes zugreifen.

Syntax von Referenzen:

AttributBezeichner ( ^Objekt.Attribut )

Objekt muß ein bereits definiertes Objekt in der Regelsequenz sein, das das Attribut Attribut besitzt. Referenzen lassen sich mit arithmetischen und logischen Formeln kombinieren.

Beispiel:

sequence (
    auto1 ( farbe ( rot ), gewicht( 1000 ) ),
    auto2 ( gewicht ( ^auto1.gewicht + 500 ) );
    auto3 ( farbe( blau ), gewicht( ^auto2.gewicht + 500 ) )
)
Das zweite Auto in der Sequenz wiegt 500 kg mehr als das erste Auto und das dritte Auto wiegt 500 kg mehr als das zweite Auto.

RUDOLF in EBNF (Erweiterte Backus Naur Form)

Die genaue Syntax von RUDOLF ergibt sich aus folgender EBNF-Spezifikation:

rule ::= 'sequence' '(' object { ',' object } ').'.
object ::= identifier '(' attribute { ',' attribute } ')'.
attribute ::= identifier '(' formula ')'.
formula ::= ( formula atomic_formula ) | ( formula binop formula ).
atomic_formula ::= number | reference | ( '(' formula ')' ).
reference ::= '^' identifier '.' identifier.
binop ::= arithop | boolop.
arithop ::= '+' | '-' | '*' | '/'.
boolop ::= '|' | '&'.
identifier ::= ( '_' | string ) { number | string }.

Beispiele

  1. Auto ist rot und wiegt 1000 kg
  2. Auto ist gelb oder blau und wiegt 500 kg mehr als das erste Auto 
sequence (
    auto1( farbe( rot ), gewicht( 1000 ) ),
    auto2( farbe( gelb | blau), gewicht( ^auto1.gewicht + 500 ) )
)

  1. Auto ist rot und wiegt 1000 kg
  2. Auto ist gelb oder blau, jedes Gewicht ist gültig
  3. Auto wiegt 7.5mal soviel wie das 1. Auto, jede Farbe ist gültig 
sequence (
    auto1( farbe( rot ), gewicht( 1000 ) ),
    auto2( farbe( gelb | blau) ),
    auto3( gewicht( auto1.gewicht * 7.5 ) )
)

  1. Karte ist schwarz und ist ein As
  2. Karte ist rot, jeder Wert ist gültig
  3. Karte ist schwarz oder rot, jeder Wert ist gültig; d.h. jede Karte passt zu dieser Objektregel 
sequence (
    As_Schwarze_Karte( farbe( #schwarz ), wert( as ) ),
    Rote_Karte( farbe( #rot ) ),
    Alles_Karte( farbe( ^As_Schwarze_Karte.farbe |
                    ^Rote_Karte.farbe ) )
)

  1. Karte ist rot oder schwarz, Wert ist Ass.
  2. Karte ist rot, der Wert ist um 2 höher, als der der 1. Karte
  3. Karte ist schwarz, der Wert ist um 2 höher, als der der 2. Karte
  4. Karte hat die Farbe der 2. Karte, der Wert ist um 2 höher, als der der 3. Karte 
sequence (
    karte1( farbe( #rot | #schwarz), wert( as ) ),
    karte2( farbe( #rot ), wert( karte1.wert + 2 ) ),
    karte3( farbe( #schwarz ), wert( karte2.wert + 2 ) ),
    karte4( farbe( ^karte2.farbe ), wert( karte3.wert + 2 ) )
)

RIGen

Eine Teilaufgabe der Software bestand in der Analyse der erstellten Regeln. Es sollte für eine Regel ermittelt werden wieviele mögliche Kombinationen von Karten sie zulässig macht, bzw. wie hoch die Wahrscheinlichkeit für einen Zufallstreffer liegt.

Was macht RIGen?

RIGen (Rule Instances Generator) erstellt zu einer Regel rekursiv sämtliche legalen Objektsequenzen und gibt diese aus. Abschliessend wird noch der Quotient aus legalen und möglichen Sequenzen bestimmt.
Da dieses Tool nicht für den eigentlichen Experimentablauf benötigt wird, ist zu diesem Zeitpunkt nur eine Kommandozeilen-Version implementiert. Die Funktionalität beschränkt sich auf die Ausgabe aller Informationen auf die Standardausgabe. Im Programm ist die Anpassung zur Ausgabe auf einen beliebigen OutputStream vorgesehen, so daß die Informationen leicht in zB. ein Textfenster umgeleitet werden können. Die Erweiterung von RuleTool um eine Analysefunktion mit eingebettetem RIGen würde sich zum Beispiel anbieten.
In der aktuellen Version können als Kommandozeilen-Parameter angegeben werden, welche ODeLa- und RUDOLF-Dateien benutzt werden, sowie welche Länge die zu bildende Sequenz hat. Falls keine Länge angegeben ist, wird die Anzahl der in der RUDOLF-Datei angegebenen Objekte angenommen.
[Details zur Implementierung]

RuleTool

Um Regeln für ein Experiment möglichst leicht in RUDOLF-Regeln umsetzen zu können wurde die graphische Eingabehilfe RuleTool entwickelt. RuleTool zeigt sich dem Benutzer in der für Windows-Anwendungen üblichen Weise und macht es jedem Benutzer solcher Software so leicht, sich zurechtzufinden.
Sowohl die Steuerung per Maus als auch mit Tastatur wird für die meisten Funktionen unterstützt. Zum einen kann jeder Benutzer so sofort mit der Erstellung einfacher Regeln beginnen, zum anderen ist für den fortgeschrittenen Benutzer die schnelle und effiziente Erstellung auch komplexer Regeln leicht.
Die Knopfleiste ist abhängig von der zu Grunde liegenden ODeLa-Datei für die Regeln. Für jedes Attribut wird ein Knopf und ein Pulldown-Menü mit dessen möglichen Ausprägungen angelegt. Als Standard wird die Datei 'cards.odl' im gleichen Verzeichniss wie RuleTool angenommen. Es kann aber auch jede beliebige andere ODeLa-Datei als command-line-Argument übergeben werden. In zukünftigen Versionen wäre eine Konfigurationsdatei denkbar, die diese und andere Informationen über eine Sitzung hinaus speichert.
Objekte werden im Hauptfenster als Rechtecke dargestellt, in denen zeilenweise die Enschränkungen auf die Attribute geschrieben werden. Dabei steht jede Zeile für genau ein Attribut. Wenn eine Ausprägung von der Knopfleiste auf ein Objekt fallen gelassen wird, wird diese in die entsprechende Zeile des Objekts eingetragen. Sollte diese Zeile bereits Ausprägungen enthalten, werden diese mit der neuen oder-verknüpft. Um eine und-Vernüpfung zu erreichen, muß lediglich während des Vorgangs die [Strg]-Taste gedrückt werden.
Leider unterstützt die vorliegende Java-Version 1.1 kein drag&drop. Die entsprechenden Features mußten also von Hand implementiert werden und sind deshalb nicht sehr ausgereift. Am besten umgeht man als Benutzer die Schwierigkeiten, indem man zwei komplette Klicks mit der Maus durchführt anstatt mit gedrückter Taste die Attribute zu verschieben. Drag&drop wurde so umgesetzt, daß beide Eingabearten als gleichwertig angesehen werden.
Eine andere Möglichkeit, den Inhalt von Attributfeldern zu ändern, ist der Objekteditor. Er ist entweder über die Menüleiste erreichbar oder man klickt über dem entsprechenden Objekt die rechte Maustaste. Der Editor erlaubt für alle Attribute eines Objekts beliebige Texteingaben. Auf diese Weise kann die volle Mächtigkeit von RUDOLF-Ausdrücken genutzt werden.
Um Referenzen auf den Laufzeitinhalt anderer (vorangehender) Objekte zu erzeugen, kann der Benutzer mit der Maus auf des Attribut eines Objekts klicken und dieses mit drag&drop auf ein anderes Objekt ziehen. Dabei muß die shift-Taste gedrückt gehalten werden. Im Zielobjekt wird dann in der entsprechenden Zeile die nötige Anweisung eingetragen.

Zur Implementierung:

Die Implementierung erfolgte ohne Entwicklungstools, da diese oft sehr langen, unlesbaren Code erzeugen und so eine Wartung der Software sehr schwer wird. Die Hauptanzeige arbeitet getrennt von dem umgebenden Fenster mit den Menüs und Knöpfen. So ist es denkbar, jeweils nur eine Komponente bei Bedarf auszuwechseln. Zusätzlich ist die Methode zur Darstellung der Objekte innerhalb der Anzeigeklasse modular gehalten, um auch hier eine Änderung leicht zu ermöglichen.
[Details zur Implementierung]

Gaston

Für ein Experiment ist es nötig, die einzelnen Arbeitsplätze, auf denen CARInEx läuft, zu koordinieren. Diese Aufgabe übernimmt der Server Gaston. Als Benutzer ist lediglich der Versuchsleiter vorgesehen, der mit Hilfe von Gaston die für dieses Experiment gültigen Parameter setzt und die Durchführung anstößt. Nachdem Gaston gestartet wurde, wartet das Programm zuerst auf Anmeldungen von CARInEx Clients über das Netzwerk. Dabei können Server Port und andere fundamentalen Parameter beim Start als command-line Argumente übergeben werden (diesbezüglich verfügt Gaston über eine command-line Hilfe). Sobald alle gewünschten Clients angezeigt werden, startet der Versuchsleiter die Sitzung.

Beim Start eines Experiments

Vor dem ersten Experimentdurchlauf einer Sitzung erscheint automatisch der Properties Bildschirm. Hier können nun alle Rahmenbedingungen für das Experiment festgelegt werden. Insbesondere welche RUDOLF Regeldateien verwendet werden sollen, wie lange ein Einzelexperiment in Sekunden dauern soll und wie viele Objekte gelegt werden dürfen.
Zusätzlich kann noch ein Prefix für die Datenspeicherung angegeben werden. Sämtliche im Experiment anfallenden Daten werden dann unter diesem Prefix mit der Erweiterung '<Client Nr.>-<Einzelexperiment Nr.>.dat' abgelegt.
Hier kann auch entschieden werden, ob recorded sessions für die Versuchsreihe verwendet werden sollen.

Recorded Sessions...?

Bei den recorded sessions handelt es sich um ein Konzept, um die Vorgabe von Objekten zu ermöglichen. Im aktuellen Experiment bekommt eine Versuchsperson ein Objekt (Karte) als Starthilfe. Mit recorded sessions kann aber auch jede beliebige andere Vorgabe realisiert werden. Es handlet sich lediglich um eine Aufzeichnung einer früheren Sitzung mit dieser Regel, so daß alle bis zu diesem Zeitpunkt richtig, bzw. falsch gelegten Objekte erscheinen. Ebenso auch alle bereits abgegebenen Hypothesen. Der Versuchsleiter kann eine Versuchsperson so in jede Situtation eines laufenden Experiments versetzen.
Um eine Sitzung aufzunehmen muß lediglich Gaston mit der Option '-record' gestartet werden. Die Windows Version hat hierfür ein extra Icon. Danach läuft alles wie bei einem normalen Experiment ab. Alle nötigen Informationen über die Sitzung werden in einer Datei gespeichert, die den gleichen Namen hat wie die Datei der betreffenden Regel mit der zusätzlichen Endung '.session'.

Bei einem Durchlauf

Der Menüpunkt Experiment in der Menüleiste erlaubt es einen neuen Durchlauf des Versuchs zu starten, die Versuchsparameter für den nächsten Lauf zu verändern und die Sitzung zu beenden.

Während der Durchführung der Experimente wird im Hauptfenster von Gaston ein Trace angezeigt. Alle Daten von den Clients sowie einige zusätzliche Informationen über die jeweiligen Einzeldurchgänge werden hier zusammengestellt.

Zur Implementierung

Die Klasse Gaston benutzt mehrfache Nebenläufigkeit. Jede Verbindung zu einem Client ist ein eigenständiger Thread. Koordiniert wird alles von dem übergeordnetem Thread der Klasse Gaston selbst. Die Kommunikation zwischen den Threads erfolgt über synchronisierte Datenfelder der Klasse Gaston.
[Details zur Implementierung]


CARINEX

Was ist CARINEX

CARINEX (Computer Aided Rule INduction EXperiment) ist die Client-Seite der Anwendung, die Regelinduktionsaufgaben auf einem Computer automatisiert. Während der Durchführung des Experiments bekommt CARINEX Informationen vom Serverprogramm Gaston. Dieses kann gleichzeitig mehrere Instanzen von CARINEX "bedienen".

Definitionsdateien

Um Regelinduktionsaufgaben durchführen zu können, müssen die Objekte, auf die sich die Regeln beziehen, bildlich dargestellt werden. Weiterhin muß der Computer die Objekte eindeutig zu den Bildern zuordnen können. Dazu sind folgende Dateien zu erstellen.

Die Objektdefinitionsdatei

In der Objektdefinitionsdatei werden die Objekte, über die Regeln aufgestellt werden, mit der Objektdefinitionssprache ODeLa definiert. Sie muß die Endung "odl" besitzen.

Beispiel: cards.odl

Die Objektbilderdatei

In der Objektbilderdatei werden die einzelnen Bilder, die die Objekte darstellen, sequentiell nebeneinander abgespeichert. Sie sollten alle die gleiche Höhe, Breite und den gleichen Abstand voneinander besitzen (alle Angaben in Pixel). Die Datei muß im GIF-Bildformat abgespeichert sein.

Die Attribut- und Dimensionendatei

Diese Definitionsdatei enthält Informationen über die Bilddimensionen und die Anordnung der Bilder in der Bilddatei bezüglich ihrer Attribute. Die einzelnen Werte werden durch Kommas getrennt in die Datei geschrieben:

<Bildbreite> "," <Bildhöhe> "," <Gesamtbreite> "," <Attribut1> "," <Attribut2> "," ...

Bedeutung der Begriffe:

Bildbreite Breite eines einzelnen Objektbildes
Bildhöhe Höhe eines einzelnen Objektbildes
Gesamtbreite Summe der Breiten aller Objektbilder, d.h. Bildbreite*Anzahl der Bilder

Danach werden die Attribute in der Reihenfolge angegeben, nach der die Attribute der Objektbilder in der Bilderdatei sortiert sind.

Beispiel:

In einer Bilderdatei, in der ein Kartenspiel dargestellt ist, sind die Bilder zuerst nach der Farbe sortiert. Innerhalb jeder Farbe sind die Bilder nach ihrem Wert sortiert. Ein Bild ist 55 Pixel breit und 73 Pixel hoch. Außerdem hat die Bilderdatei eine Gesamtbreite von 2860 Pixel (52 Karten mit jeweils 55 Pixel Breite). Der Inhalt der Attribut- und Dimensionendatei sieht also folgendermaßen aus:

55,73,2860,farbe,wert

Die Datei muß die Endung "attr" besitzen.

Wie wird CARINEX gestartet

Parameter in der HTML-Datei

Für den Aufruf von CARINEX, muß eine HTML-Datei erstellt werden, die eine Applet-Marke mit folgenden Parametern enthält.

host Die IP Adresse des Computers, auf dem der Server läuft. Ist dies der Computer auf dem CARINEX laufen soll, kann "localhost" angegeben werden.
port Nummer der Anschlußstelle, an der der Server auf anmeldungswillige Clients wartet
dwidth Zahl der Objektbilder, die auf einmal angezeigt werden sollen
type Modus, in dem CARINEX gestartet werden soll: "passive" bedeutet, daß CARINEX im Gruppenexperiment gestartet wird und keine Objektauswahlmöglichkeit besteht. Der Alternativmodus ist "active". In diesem Modus kann der Benutzer die Objekte per Maus auswählen.

Ein Aufruf des Applets CARINEX in einer HTML-Datei könnte also wie folgt aussehen:

    <applet code="Carinex.class" height="800" width="600">
    <param name="host" value="ares.cip.informatik.uni-muenchen.de">
    <param name="port" value="8888">
    <param name="dwith" value="13">
    <param name="type" value="active">
    </applet>

Aufruf

Da CARINEX ein Java-Applet ist, wird es mit dem Appletviewer (JDK 1.1.5) gestartet:

appletviewer index.html

index.html ist eine HTML-Datei die ein Applet-Marke in der oben beschriebenen Form enthält. Wichtig ist, daß der Server GASTON auf dem in index.html angegebenen Rechner bereits läuft.

Graphische Benutzeroberfläche und Funktionalität des Applets

Wird CARINEX im active-Modus gestartet, so teilt sich die Benutzeroberfläche in drei Bereiche auf:

  1. die Objektbilderliste
  2. das Ergebnisfeld
  3. die Funktionsleiste

Außerdem wird noch ein Hypothesen- und Nachrichtenfenster geöffnet:

In der Objektbilderliste, werden alle Objekte, die in den Regeln verwendet werden können dargestellt. Wenn mehr Objekte vorhanden sind, als angezeigt werden können, hat der Benutzer die Möglichkeit, mit den Knöpfen previous und next (in der Funktionsleiste), die Objektbilder durchzublättern. Aus der Objektbilderliste können Objekte ausgewählt werden, um eine Teilhypothese aufzustellen.

Im Ergebnisfeld wird dann angezeigt, ob diese Teilhypothese richtig oder falsch war. Im ersteren Fall positioniert CARINEX das ausgewählte Objektbild rechts neben das zuletzt gelegte Objekt. Ist die Teilhypothese falsch wird das Objektbild unter das zuletzt gelegte Objekt positioniert. Wenn mehr als fünf falsch ausgewählte Objekte im Ergebnisfeld liegen, kann der Benutzer die verdeckten Objekte mit den Knöpfen up und down ansehen.

Nach dem Auswahlvorgang erscheint das Hypothesen- und Nachrichtenfenster. Der Benutzer wird damit aufgefordert, seine Teilhypothese schriftlich zu formulieren. Durch Betätigen der Eingabetaste, wird die Teilhypothese zum Server GASTON geschickt und dort gespeichert. Im unteren Teil des Hypothesen- und Nachrichtenfensters kann der Benutzer mit anderen Versuchspersonen kommunizieren, indem er schriftliche Nachrichten verschickt. Diese Nachichten werden an alle angemeldeten Teilnehmer verschickt.

Nach der schriftlichen Eingabe der Teilhypothese kann der Benutzer, sofern das Experiment noch nicht beendet ist, ein weiteres Objekt auswählen.

Im passive-Modus fehlt die Objektbilderliste. Dieser Modus ist dazu gedacht, CARINEX im Gruppenexperiment laufen zu lassen. Dazu muß eines der Gruppenmitglieder mit einer aktiven CARINEX- Instanz, und der Rest der Gruppen mit einer passiven CARINEX- Instanz arbeiten. Der Benutzer hat in diesem Fall keine Auswahlmöglichkeit. Er kann lediglich den Verlauf des Versuchs verfolgen und nach jeder Teilhypothese seine eigene Hypothese formulieren und zum Server schicken.

[Details zur Implementierung]

Übersicht über die CARINEX-Suite

Was bringt die Zukunft?

Ausbau der Automatisierung des Experiments

Zu diesem Zeitpunkt kann die CARInEx Suite zwar bei der Erfassung der Experimentdaten helfen, aber die Auswertung dieser Daten muss noch weitgehend 'von Hand' erfolgen. In einem nächsten Schritt sollte es für die Software möglich sein zwischen 'falschen', 'falschen aber plausiblen' und 'richtigen' Hypothesen zu unterscheiden. Hierfür ist insbesondere ein Parser nötig, der menschliche Sprache zumindest teilweise interpretieren kann. Der Einsatz einer kontrollierten, stark vereinfachten natürlichen Sprache ist hier denkbar.

Ausbau der Benutzerfreundlichkeit

Das Softwarepaket beruht bereits vollständig auf einer graphischen Benutzeroberfläche, was den Umgang mit ihm relativ einfach macht. Es gibt aber immer noch einige Punkte, die den Komfort in der Benutzung noch wesentlich verbessern würden. So ist zB. die Installation der Software noch nicht automatisiert. Gerade für eine Windows Umgebung wäre dies wünschenswert.
Ein anderer Punkt ist die Speicherung von Preferenzen bei Auswahlmenüs. Etwa könnte Gaston die letzten Einstellungen beim nächsten Start wiederherstellen, oder sogar das Abspeichern aller für ein Experiment nötigen Daten unterstützen.
Des weiteren könnte ein Ausbau der online-Hilfe zu einigen Komponenten sinnvoll sein (wie zB. status-zeilen-/ oder ballon-Hilfen).