-Electronic assessments in E-LearningSystems (e. g. ILIAS) can be used in exercises to reduce personal costs. Question types in computer science or mathematics often require formal inputs like terms or proofs. A string based comparison between the users submission and the solution is not sufficient to evaluate the correctness of the submission. Plugin systems, as used in ILIAS, can be used to implement new question types but this method is complex and error-prone. We show a service-oriented approach to implement new question types in ILIAS based on existing services. A compiler is used to translate user input language in service language which improves users readability and allows syntax checking before invoking a service call.
Eine wichtige Funktion von E-Learning-Systemen ist die Durchfu¨hrung von Tests bzw. das Stellen von Aufgaben, deren Antworten automatisch ausgewertet werden. Diese werden von Dozenten erstellt und von Studenten beantwortet. Ha¨ufig auftretende Fragetypen sind Multiple-Choice Aufgaben und Lu¨ckentexte. Der Student wa¨hlt dabei eine der vorgegebenen Antworten bzw. ein Bild aus oder gibt einen Begriff ein. Das System pru¨ft anschließend, ob die gegebene Antwort mit einer Musterlo¨sung u¨bereinstimmt und generiert die entsprechende Ru¨ckmeldung. Diese Ru¨ckmeldung ist i. d. R. eine Punktzahl, kann aber auch aus Erla¨uterungen zur Antwort Beispiel 1 (Fragetyp: Mengenlehre Aufgabe: Bestimmen Sie {a, b, c} ∪ {c, d} L¨osung: {a, b, c, d} oder {d, b, c, a} oder {b, a, c, d} . . . Operatoren).
Hierbei wird deutlich, dass durch Permutation sehr viele korrekte Lo¨sungen existieren. Diese vollsta¨ndig fu¨r einen textbasierten Vergleich aufzulisten ist nicht praktikabel. Daru¨ber hinaus treten weitere Probleme auf, die beim bisherigen U¨ bungsbetrieb bemerkt wurden sind. Die Eingaben enthalten zusa¨tzliche Leerzeichen, die nicht automatisch entfernt werden ko¨nnen. Derartige Eingaben wurden fa¨lschlicherweise als Fehler bewertet und mussten manuell nachkorrigiert werden. Durch diese Fa¨lle ist eine vollsta¨ndige Auflistung aller Lo¨sungen unmo¨glich.
Am Beispiel des an der Universita¨t Halle-Wittenberg
eingesetzten E-Learning-Systems ILIAS [
ILIAS ist modul- bzw. serviceorientiert aufgebaut [
ILIAS wird basierend auf Feature-Requests entwickelt. Das heißt, neue Fragetypen fu¨r automatische Tests werden jedes mal als neues Plugin implementiert. Dadurch entsteht eine Vielzahl an Modulen fu¨r Fragetypen, die alle mit einem a¨hnlichen Grundmuster aufgebaut sind. Funktionen wie Anlegen, Kopieren und Lo¨schen von Tests mu¨ssen implementiert werden, obwohl sich diese nur mi
m u r o F t s e T l u d o m n r e L e l l o r t n o k s iff r g u Z n e t a d a t e
M . . . nimal bis gar nicht unterscheiden. Zusa¨tzlich treten Alterungserscheinungen auf. Einzelne Fragetypen existieren in zwei oder mehr Varianten. Beispielsweise sei hier die Dateieinsendung erwa¨hnt, die sowohl in U¨ bungen als auch in Tests implementiert ist. Beide modellieren den gleichen Anwendungsfall, sind aber doppelt implementiert.
ILIAS unterstu¨tzt ein Feedback u¨ber richtige und falsche Antworten. Dieses wird manuell fu¨r jede erwartete Antwort eingetragen. Fu¨r Entscheidungsfragen wie MultipleChoice ist dies vo¨llig ausreichend. Bei Textfeldern beno¨tigt man allerdings ein angepasstes Feedback, das sich auf individuelle Lo¨sungen bezieht. Hier ist es nicht mehr mo¨glich, alle gu¨ltigen Lo¨sungen manuell zu erfassen.
Wird ein Fremdsystem zur Auswertung verwendet, z. B.
das Computer-Algebra-System Maxima [
In dieser Arbeit wird eine geplante Architektur gezeigt, die auf Herausforderungen bei der Erstellung neuer Fragetypen eingeht. Im Wesentlichen soll die Architektur dabei • externe Werkzeuge effizient einbinden lassen, • minimal in das bestehende System (ILIAS) eingreifen, • umfangreiches Feedback dem Anwender bereitstellen sowie • fehlerhafte Eingaben bzw. Eingaben mit ungewollten Nebeneffekten detektieren und anzeigen.
Kapitel II zeigt verwandte Arbeiten, die sich bereits mit automatischer Testauswertung und den damit verbundenen Architekturen auseinandersetzen. Kapitel III stellt unseren Architekturansatz vor. In Kapitel IV werden die verschiedenen Herausforderungen bei der bisherigen Umsetzung bzw. bei der Arbeit mit ILIAS diskutiert. In Kapitel V werden die Ergebnisse zusammengefasst und ein Ausblick auf die geplanten Arbeiten gegeben.
Im Umfeld von E-Learning und im speziellen der
automatisierten Auswertung von Fragestellungen im Bereich
von U¨ bungen und Tests gibt es viele Arbeiten. Schon
in [
Serviceorientierte Implementierungen automatisierter
Tests, hier im speziellen die Auswertung von
Programmcode, finden sich in [
Erweiterbarkeit um neue Fragetypen + + 0 0 + +
Integrierbarkeit in ILIAS 0 0 + + 0 +
Feedbackmo¨glichkeiten
Eingabepru¨fung Arbeiten sind auf Programmieru¨bungen spezialisiert. Eine Erweiterung um beliebige Eingabeformate wurde nicht diskutiert.
Das automatische U¨bungs- und Pru¨fungssystem Jack [
Eine serviceorientierte Architektur, im Speziellen fu¨r
Freitext-Fragen, findet sich in [
Eine Umsetzung fu¨r mathematische Fragestellungen als
Plugin fu¨r ILIAS ist das Stack-Plugin [
Die hier vorgestellten Arbeiten beschreiben eigensta¨ndige Systeme und Erweiterungen bestehender Systeme. Der Fokus liegt dabei entweder auf der Bereitstellung von Feedback sowie der Integration in ein bestehendes Lernsystem oder auf einer erweiterbaren Architektur. Eine Arbeit, die sowohl in ein bestehendes E-Learning-System integriert ist, als auch um neue Fragetypen erweiterbar ist und den Studenten Hilfestellungen durch Feedback und Eingabepru¨fungen leistet, gibt es unserer Kenntnis nach noch nicht. Diese Punkte versuchen wir in unserer Arbeit zu erfu¨llen. Tabelle I fasst noch einmal die hier betrachteten Merkmale der verwandten Arbeiten zusammen.
III. Eine Architektur fu¨r modularisierte
Fragetypen
Eine typische Frage besteht aus Aufgabenstellung, Musterlo¨sung sowie einem Algorithmus zur Berechnung einer Punktzahl bzw. Ru¨ckmeldung zur gegebenen Antwort. Lo¨sungen und Antworten sind ha¨ufig textuell und werden in Eingabefelder eingetragen. Es gibt aber auch Fragetypen, die grafische Objekte wie geometrische Zeichnungen oder Diagramme abfragen. Die Algorithmen zur Evaluierung der Eingaben sind fu¨r viele Aufgabenstellungen sehr komplex. Daher sollten diese nicht in dem E-LearningSystem implementiert werden, sondern bestehende Services wie Computer-Algebra-Systeme eingebunden werden.
Derzeit werden solche Schnittstellen explizit im entsprechenden Plugin in ILIAS implementiert. Die Implementierung umfasst außerdem zusa¨tzliche Funktionen, z. B. fu¨r Datenbankzugriffe und Kopierfunktionen. Objektorientierte Programmierung schra¨nkt den Implementierungsaufwand nur zum Teil ein. Neue Plugins sind nicht aus Bestandteilen anderer Plugins erzeugbar. Eine gemeinsame Middleware, welche die Verwaltungsaufgaben u¨bernimmt, ist daher erstrebenswert. Abbildung 2 zeigt, wie verschiedene Komponenten u¨ber eine gemeinsame Middleware angebunden werden.
Durch die Auslagerung der Auswertungsfunktionen lassen sich die bisherigen umfangreichen Plugins fu¨r Fragetypen in mehrere zusammenstellbare Module aufteilen. Die Aufteilung erfolgt dabei anhand der verschiedenen Aspekte des Fragetyps. Diese werden in Abbildung 3 gezeigt.
Nach der Eingabe einer Antwort in eine entsprechende Eingabemaske erfolgt zuna¨chst eine U¨berpru¨fung auf syntaktische bzw. statisch semantische Fehler durch einen geeigneten U¨bersetzer oder eine vergleichbare Methode. Die Auswertung der Lo¨sung geschieht dann durch einen Service, welcher eventuell u¨ber Adapter aufgerufen werden muss. Da die Eingabesprache der externen Services
K o m p o n e n t e
K o m p o n e n t e Abbildung 2. Anbindung von Komponenten fu¨r Vergleichsfunktionen nicht fu¨r die Eingabe von bestimmten Fragestellungen konzipiert ist, sollte ein lesbares Eingabeformat durch den U¨bersetzer bereitgestellt werden. Dadurch kann die Eingabesprache auf das abgefragte Themengebiet beschra¨nkt werden, was Vorteile fu¨r die Studenten bringt.
Die Middleware aus Abb. 3 soll als Fragetypen-Plugin in ILIAS umgesetzt werden. Geplant ist ein einziger Fragetyp, bei dem die Textfelder durch verschiedene Services ausgewertet werden ko¨nnen, welche zuvor im Plugin registriert werden ko¨nnen. Dies hat den weiteren Effekt, dass die Anzahl der Fragetypen nicht mit jedem Service ansteigt, was die U¨bersichtlichkeit erho¨ht. Ein neuer Fragetyp beno¨tigt Komponenten fu¨r • Syntaxpru¨fung und einfache Konsistenzpru¨fungen, • U¨bersetzer bzw. Formatierer zwischen Eingabespra
che und Fremdsystemsprache, • Schnittstellen aufzurufender Services, • Feedbackfunktionen, die Antworten der Services auf
Punkte und sonstige Meldungen abbilden sowie • Eingabemaske.
Da alle Eingaben inklusive der Musterlo¨sung textuell erfolgen sollen, entfallen zusa¨tzliche Datenbankeintra¨ge.
Sicherheitskritische Aspekte, wie der uneingeschra¨nkte
Zugriff durch Plugins, werden dadurch entscha¨rft. Wird der
gleiche Service verwendet, ko¨nnen die Anbindungen und
der U¨ bersetzer zu großen Teilen erneut verwendet bzw.
erga¨nzt werden. Eingabemasken fu¨r grafische Elemente,
z. B. Diagramme oder geometrische Skizzen, mu¨ssen im
Hintergrund ein textuelles Format wie XML zur
Verarbeitung verwenden. Eine Anbindung von Systemen zur
grafischen Eingabe wie WIRIS ([
Beispiel 2 (Mengenlehre - Fortsetzung). Das erste hier betrachtete Beispiel ist die Umsetzung eines Fragetyps fu¨r Mengenaufgaben. Der Student tr¨agt dazu die Ergebnismenge einer Aufgabe in ein Textfeld ein, und die eingegebene Menge wird anschließend mit einer Ergebnismenge verglichen.
Fu¨r die Umsetzung des Fragetyps ist es notwendig, die Eingabe zun¨achst geeignet zu formatieren und anschließend einen Vergleich zwischen zwei Mengen durchzufu¨hren, beispielsweise mit Maxima. Schreibfehler, wie vergessene Kommata oder Klammern, k¨onnen zu Fehlern fu¨hren, sodass der Term nicht ausgewertet werden kann. Diese sollten dem Studenten also schon vor dem Berechnen der Punktzahl angezeigt werden. Die dabei ben¨otigten Funktionalit¨aten sollten soweit wie m¨oglich nicht innerhalb des Moduls stehen, sondern als Service angeboten werden.
Im Falle der Mengenaufgabe k¨onnte man das MaximaWerkzeug verwenden, um die Menge aus der Eingabe mit der Menge der Musterl¨osung zu vergleichen. Eine typische Fragestellung wurde in Beispiel 1 gezeigt.
Als Musterl¨osung kann direkt der Term der Aufgabenstellung verwendet werden. Die Eingabe fu¨r Maxima ergibt sich fu¨r die Beispieleingabe {a, b, d} daraus wie folgt. input: set(a,b,d); muster: adjoin(set(a,b,c),set(c,d)); result: isEqual(x,muster);
Dabei f¨allt auf, dass die Schreibweise der Aufgabenstellung ku¨rzer ist und der schriftlichen Notation angepasst ist.
Der Student muss sich keine neue Syntax aneignen sondern kann die mathematische Notation verwenden.
Weitere Ru¨ckgabewerte von Maxima k¨onnen hierbei auch die Elemente sein, die in der eingesandten L¨osung fehlen oder f¨alschlicherweise in die Menge aufgenommen wurden.
Als Feedback lassen sich diese Elemente dann dem Studenten anzeigen. Auch ist eine differenzierte Punktevergabe m¨oglich, indem Punktabzu¨ge entsprechend den falschen Elementen stattfinden. Dies ist in dieser Art mit einem Identit¨atsvergleich zwischen Texten nicht m¨oglich.
Sp¨ater k¨onnen einige der Komponenten wieder verwertet werden, z. B. bei Fragetypen zu Vielfachmengen. Hier ist die Anbindung an Maxima sowie die Feedback-Auswertung die selbe.
Beispiel 3 (Fragetyp: Abstrakte Datentypen). Das zweite Beispiel, welches derzeit geplant ist, ist ein Fragetyp im Bereich abstrakter Datentypen. Die typische Fragestellung hierbei ist es, Terme eines gegebenen abstrakten Datentyps auf Gleichheit zu untersuchen. Durch Anwendung der Axiome bzw. Regeln auf bestimmte Stellen von Termen ist es m¨oglich, einen Term in einen anderen, im abstrakten Datentypen ¨aquivalenten, Term umzuwandeln. Eventuell mu¨ssen dazu auch Unterterme substituiert werden. Eine beispielhafte Aufgabenstellung nebst L¨osung lautet wie folgt.
Aufgabe: Gegeben Sei der abstrakte Datentyp Mystery mit Nutzer
Syntaxfehler? Eingabemaske
Übersetzer Punkte und Feedback
Musterlösung Auswertungsfunktion
Abbildung 3. U¨ bersicht u¨ber die Architektur fu¨r die automatisch Auswertung von Aufgaben spec Mystery is sorts A, U operations feuer : −> A Konstruktor erde : A −> A Konstruktor wasser : A x A −> A apfel : −> U Konstruktor orange : A x U −> U Konstruktor banane : U x U −> U kiwi : U −> A vars n,m : A x,y : U axioms
B1 : wasser (feuer, n) = n B2 : wasser (erde(n), m)
= erde(wasser (n, m)) C1 : banane(apfel, y) = y C2 : banane(orange(n, x), y)
= orange(n, banane(x, y)) C3 : kiwi(apfel) = feuer C4 : kiwi(orange(n, x))
= wasser (n, kiwi(x)) Zeigen Sie, dass
wasser(kiwi(apfel), kiwi) = kiwi unter Angabe der angewendeten Regeln und Substitutionen.
Markieren Sie die betreffenden Unterterme mit eckigen Klammern! wasser([kiwi(apfel)], kiwi) = [wasser(feuer, kiwi)] mit C3 = kiwi mit B1 und S=[kiwi/n]
Die Schritte mu¨ssen dann in ein entsprechendes Format u¨bersetzt werden und mittels geeigneter Pru¨fer, wie z. B.
PVS [
Verfahren mit Entscheidungsb¨aumen wie sie in [
Dem Studenten kann nach der Auswertung angezeigt werden, welche Umformungsschritte falsch oder unvollst¨andig waren. Dazu wird die Aussage des externen Pru¨fers u¨ber Widerspru¨che bzw. offene Beweisverpflichtungen in den Schritten ausgewertet. Beides stellt ein fu¨r Studenten nu¨tzliches Feedback dar.
Die vorgestellte Architektur soll in ILIAS integriert werden, mit der neue Fragetypen implementiert werden ko¨nnen. Die beiden Beispiele veranschaulichen auch, dass externe Werkzeuge bzw. Services notwendig sind, um Aufgaben korrekt bewerten zu ko¨nnen. Zusa¨tzlich zu der Integration in bestehende bzw. genutzte Systeme ist es wichtig, dass den Studenten ein umfangreiches Feedback gegeben wird. Einfache formale Fehler ko¨nnen durch U¨bersetzer erkannt werden, was Studenten von Flu¨chtigkeitsfehlern entlastet.
Der hier vorgestellte Ansatz soll die in Kapitel I gezeigten Anforderungen erfu¨llen. Insbesondere soll eine Mo¨glichkeit fu¨r die Erweiterung von ILIAS geboten werden, die ohne Neuentwicklung von Plugins fu¨r jeden einzelnen Fragetyp auskommt. Plugins in ILIAS haben den vollen Zugriff auf sa¨mtliche Bereiche der Lernplattform und sind somit zum einen schwerer wartbar und bergen zum anderen auch Sicherheitsrisiken.
Die Entkopplung der einzelnen Komponenten eines Fragetyps stellt dabei ein wesentliches Argument dar. Mo¨chte man beispielsweise einen bestehenden Aufgabentyp nutzen und nur die Eingabemethode vera¨ndern, so tauscht man lediglich die dafu¨r genutzten Komponenten aus. Voraussetzung dafu¨r ist, dass die Eingabe am Ende ein textuelles Format liefert, welches von den Schnittstellen u¨bertragen werden kann. Diese Einschra¨nkung ist fu¨r formale Eingaben vertretbar.
Die Umsetzung der Architektur als Plugin in ILIAS ist noch nicht abgeschlossen. Erste Implementierungen fu¨r den Mengenaufgabentyp aus Beispiel 1 sind erfolgt. Die Umsetzung eines a¨hnlichen Fragetyps fu¨r Vielfachmengen zeigte, dass große Teile der Implementierung erneut verwendet werden konnten. Nur die Funktion fu¨r den Vergleich der Menge wurde angepasst, damit mehrfach auftretende Elemente auch erfasst werden.
Auf Grundlage der fu¨r Plugins genutzten Schnittstellen von ILIAS soll die Middleware umgesetzt werden. In den entsprechenden Funktionsaufrufen wird dann auf die Komponenten, wie U¨bersetzer und Eingabemasken, verwiesen.
Die Erweiterung um weitere Fragetypen erfolgt anschließend in speziellen Modulen. Da diese nur sehr wenige Schnittstellen bereitstellen mu¨ssen, sollte die Implementierung weniger aufwendig sein als die Implementierung eines Plugins. Der Vorteil gegenu¨ber eines objektorientierten Ansatzes liegt dabei bei der anschließenden Kombination der Module. Wie im Beispiel 1 vorgestellt, ko¨nnen Komponenten wie die Maxima-Anbindung erneut genutzt werden.
Die Integration von in Kapitel II vorgestellten Systemen wurde in dieser Arbeit nicht na¨her betrachtet, da diese nicht alle Anforderungen an Erweiterbarkeit, Feedback und Eingabepru¨fung unterstu¨tzen. Die Verwendung vorhandener Plugins, wie dem Stack-Fragetyps, la¨sst die Erweiterung um weitere formale Sprachen nicht zu.
Bei der Umsetzung der Schnittstellen der Middleware sind noch Fragen daru¨ber offen, wie die Kommunikation mit dem Fremdsystem zu erfolgen hat, wenn dieses u¨ber einen la¨ngeren Zeitraum das Ergebnis berechnet. Weiterhin wird die Bereitstellung von Feedback durch die Architektur von ILIAS erschwert. Eine Ru¨ckmeldung fu¨r Studenten muss mit seiner Eingabe verknu¨pft in der Datenbank gesichert werden, bevor sie dem Studenten angezeigt werden kann. Dieses Prinzip erscheint unvera¨nderlich und ko¨nnte zu Problemen beim Generieren bzw. Auswerten der Ru¨ckmeldungen fu¨hren.
Bei einigen Versionsa¨nderungen von ILIAS kam es zu Vera¨nderungen in den Schnittstellen fu¨r Plugins. Inwieweit die Wartbarkeit einer als Plugin entwickelten Middleware gegeben ist, kann nicht abgescha¨tzt werden. Kleinere Anpassungen sind ohne weiteres umsetzbar, aber durch die auf Feature-Requests basierte Entwicklung sind die zuku¨nftigen Entwicklungen von ILIAS nicht absehbar.
Die hier vorgestellte Architektur dient als Vorschlag fu¨r eine effiziente Integration neuer textbasierter Fragetypen in E-Learning-Systemen. Die Auswertung der Eingaben erfolgt dabei u¨ber externe Services. Ein zwischen Nutzereingabe und Komponente zum Auswertealgorithmus geschalteter U¨ bersetzer ermo¨glicht die Formulierung und die syntaktische und semantische U¨berpru¨fung einer auf den Fragetypen angepassten doma¨nenspezifischen Sprache. Der Sprachentwurf und der U¨bersetzer ko¨nnen im einfachsten Fall auch regula¨re Ausdru¨cke sein. Die syntaktische und semantische U¨berpru¨fung ermo¨glicht das fru¨hzeitige Erkennen von Eingabefehlern und senkt den Aufwand fu¨r Nachkorrekturen durch Autoren.
Die Entwicklung und Nutzung derartiger Frameworks sta¨rkt die Anwendbarkeit von E-Learning Systemen und erha¨lt gleichzeitig deren Software-Architektur. Neue Fragetypen ko¨nnen im Idealfall aus bereits bestehenden Komponenten zusammengesetzt werden. Dies sta¨rkt die Wiederverwendbarkeit und beugt der Explosion der Anzahl von Fragetypen vor. Der Aufwand der Entwicklung des notwendigen U¨bersetzers ist im Rahmen des Aufwandes fu¨r die entsprechenden Adapter.
Eine modulare Zusammensetzung neuer Fragetypen aus
bestehenden Vergleichsoperatoren, Fremdsystemen und
im Idealfall auch GUI-Elementen beschleunigt die
Entwicklung angepasster Fragestellungen. Werkzeuge, die die
Eingabe unterstu¨tzen, wie z. B. WIRIS [
Die Architektur soll in ILIAS mithilfe eines Plugin integriert werden. Damit sollen insbesondere auch komplexere Aufgaben wie z. B. Induktionsbeweise, Konstruktion von Grammatiken und Automaten oder Herleitungen im Logikkalku¨l implementiert werden.