ViPLab ist ein ILIAS-Plugin zur Durchfu¨hrung von Programmieraufgaben mit C, C++, Java, Matlab und DuMux [4] im Browser. Dieser Artikel beschreibt eine neue Komponente der ViPLab 2.0 Architektur, die eine automatische Bewertung von studentischen Lo¨sungen erlaubt und so insbesondere bei der Durchfu¨hrung von Grundlagenkursen eine erhebliche Erleichterung fu¨r das Lehrpersonal ermo¨glicht. Das Ziel des ViPLab-Projektes der Universita¨t Stuttgart [2] ist die Durchfu¨hrung von Programmieru¨bungen und elektronischer Pru¨fungen im ILIAS Lernmanagement-System der Universita¨t Stuttgart. Historisch entstand das Projekt aus der Notwendigkeit heraus, Studierende in den Bachelor-Studienga¨ngen so rasch wie mo¨glich an Programmiersprachen und numerische Software wie Matlab heran zu fu¨hren, wofu¨r traditionelle Umgebungen wie Eclipse oder auch die graphische Oberfla¨che von Matlab nur bedingt geeignet sind. Einerseits entstehen hier zusa¨tzliche Barrieren durch die Installation von zusa¨tzlicher Software auf den Rechnern der Studierenden, andererseits entfa¨llt ein nicht unerheblicher Zeitanteil des Semesters auf die Einarbeitung in die Bedienung der Oberfla¨che. Zugleich sind die in den ersten Semestern zu erstellenden Programme derart einfach, dass ein Großteil der Komplexita¨t von Entwicklungsoberfla¨chen nicht notwendig ist und von der zu lo¨senden Aufgabe lediglich ablenkt. Aus diesem Grunde starteten Jahr 2009 drei Institute - das Institut fu¨r Wasser- und Umweltmodellierung (IWS), das Institut fu¨r Aero- und Gasdynamik (IAG) und das Institut fu¨r Angewandte Mathematik - und das Rechenzentrum der Universita¨t (heute TIK) ein Projekt zur Einbettung einer einfachen Programmierumgebung in das Lern-ManagementSystem der Universita¨t. In seiner ersten, im Jahr 2011 abgeschlossenen Implementierung stellte das Projekt einen Code-Editor als ein aus dem ILIAS-System heraus gestarteten Java-Applets zur Verfu¨gung. MatLab oder Eclipse brauchten nicht installiert werden. Studentische Lo¨sungen werden dabei vom Applet u¨ber eine Middleware an die Server des Rechenzentrums geschickt, dort berechnet und die Lo¨sung im Browser der Studierenden dargestellt. Weitere Details zur Architektur sind in Abschnitt 2 erla¨utert. Im Jahr 2011 startete ein Nachfolgeprojekt mit dem Ziel, u¨ber ViPLab sowohl elektronische Pru¨fungen durchfu¨hren zu ko¨nnen, als auch den Korrekturaufwand von abgegebenen Hausaufgaben zu senken. Hierbei sind Studierendenzahlen von u¨ber 400 Teilnehmern pro Kurs in den Grundlagenkursen nicht ungewo¨hnlich, wobei ein Großteil der von den
2
Die ViPLab-Architektur gliedert sich grob in drei Schichten, siehe auch Abb. 1: Zuoberst eine graphische Nutzeroberfla¨che, die zusammen mit den ILIAS-Webseiten ausgeliefert wird. Diese Nutzeroberfla¨che bietet einen Editor mit Syntax-Highlighting nebst Textausgabe sowie einen interaktiven Funktionsplotter. In der Version 1.0 von ViPLab war die Oberfla¨che in Java implementiert und erforderte deshalb von den Nutzern, das Java-Plugin zu installieren. Mittlerweile kommt mit GWT [1] zu Javascript compilierter Java-Code zum Einsatz; der compilierte Code kann somit nativ von allen Browsern ausgefu¨hrt werden, ohne dass weitere Software installiert werden muss. ILIAS liefert hierbei Daten an das Frontend u¨ber Javascript-Aufrufe, wohingegen das Front-End u¨ber Javascript unsichtbare Eingabemasken mit Datensa¨tzen belegt und diese u¨ber das http-Protokoll verschickt werden.
Die vom Studierenden erstellten Lo¨sungen werden in das JSON-Format [3] codiert und vom Frontend an eine Middleware, den ECS-Community-Server verschickt. Diese Middleware u¨bernimmt die Lastverteilung an diverse Backend-Server und diente bei ViPLab 1.0 auch zur Speicherung der Programmru¨mpfe der Aufgabenstellungen. Die Speicherung von Aufgaben u¨bernimmt in der 2.0-Architektur komplett das ILIAS-System. Der Aufbau von ViPLab-Aufgaben wird genauer in Kapitel 3 beschrieben. ViPLab GUI Browser User js html html
Javascript
GUI PHP
Code ViPLab Plugin AufgabenDatenbank ILIAS json json
ECS Middleware KorrekturServer
C Backend Mathlab Backend C Backend Abb. 1: Die ViPLab-Architektur, bestehend aus dem ILIAS-System, dem Plugin nebst dem Javascript-Frontend, der ECS Middleware, dem Korrekturserver und den numerischen Backends. Zwecks Lastverteilung ko¨nnen identische Backends auch mehrmals vorhanden sein. Die Compilierung bzw. der Ablauf von studentischem Code erfolgt auf den Servern des Rechenzentrums der Universita¨t. Um eine Kompromittierung der Server auszuschließen, werden die Compiler und der compilierte Code in einem chroot-Ka¨fig gestartet, innerhalb dessen ein ablaufendes Programm nur sehr eingeschra¨nkten Zugriff auf Systemresourcen hat. Zusa¨tzlich findet wa¨hrend der Compilierung eine syntaktische Vorfilterung des abgegebenen Codes statt, so dass etwa die Verwendung von Bibliotheksfunktionen aus didaktischen oder technischen Gru¨nden eingeschra¨nkt werden kann. Ein typischer Einsatzzweck fu¨r eine derartige Filterung bestu¨nde etwa bei einer Aufgabe zur Erstellung einer numerischen Approximation einer transzendenten Funktion wie sin ohne die Verwendung der in der C-Bibliothek vorhandenen Implementierung.
Ergebnisse einer Berechnung werden vom Backend an den ECS (Middleware) geschickt, an welchem das Frontend nach Nachrichten u¨ber Rechenergebnisse pollt. Diese beschra¨nken sich hierbei nicht auf Text, sondern ko¨nnen auch vom Backend in einer GNUplota¨hnlichen Syntax erzeugt werden, die dann vom Frontend geplottet wird (siehe Abb. 2). Dabei werden entsprechende Bibliotheksfunktionen zum Plotten in Matlab u¨berladen, so dass aus studentischer Sicht die gleiche Syntax wie bei einer lokalen MatLab-Installation verwendet wird. Die Plot-Funktionen beschra¨nken sich dabei nicht auf zweidimensionale Graphen, auch dreidimensionale Fla¨chen und Objekte ko¨nnen vom Frontend gerendert werden.
Der Ablauf im Korrekturbetrieb unterscheidet sich aus technischer Sicht nicht grundsa¨tzlich vom U¨bungsbetrieb, wobei zwei verschiedene Abla¨ufe der Korrektur mo¨glich sind: Manuelles Starten des Korrekturalgorithmus mit der Mo¨glichkeit der Nachkorrektur des Ergebnisses, oder vollautomatische Korrektur aller Teilnehmer. In beiden Fa¨llen werden Teile des Aufgabencodes durch einen Korrekturcode ersetzt und dieser Gesamtcode u¨ber den ECS an das Backend genauso wie oben verschickt, siehe Abb. 3. Der Aufbau und Zweck dieses Korrekturcodes wird genauer in Abschnitt 3 beschrieben. Die Ru¨ckmeldung des Servers entha¨lt dann zusa¨tzlich zur textuellen oder graphischen Ausgabe die vom Korrekturcode ermittelte Punktzahl, welche vom ILIAS-System u¨bernommen und in der Datenbank hinterlegt wird. Abb. 2: Eine ViPLab-Aufgabe aus Sicht der Studierenden. Ganz links die Auswahlleiste der U¨ bersetzungseinheit, daneben invarianter Code (grau) und darunter vera¨nderbarer Code (weiß). Rechts daneben eine graphische Ausgabe des Codes.
Die manuelle Korrektur erfolgt u¨ber eine separate Eingabemaske des ILIAS-Systems, siehe Abb. 5: Nach Durchfu¨hrung der Klausur muss hier der Dozent fu¨r jeden Teilnehmer einzeln den abgegebenen Code einsehen. Durch eine Schaltfla¨che auf dieser Eingabemaske wird dann der Korrekturalgorithmus angeworfen und eine Punktzahl ermittelt. Diese Punktzahl wird dann von der Eingabemaske u¨bernommen, wobei hier der Dozent die Mo¨glichkeit hat, die Punktzahl zu vera¨ndern und somit die Bewertung des Korrekturalgorithmus zu u¨berstimmen. Dies ist bei komplexen Aufgaben dann sinnvoll, wenn etwa durch triviale Flu¨chtigkeitsfehler der Korrekturalgorithmus zu einer unstimmigen Bewertung kommen sollte.
Die vollautomatische Korrektur erfolgt im Batch-Betrieb nach der Durchfu¨hrung der Klausur und kann in der Konfiguration der Aufgabe selbst angefordert werden. Hierbei werden, fu¨r den Dozenten unsichtbar, alle studentischen Abgaben vom ILIAS-System u¨ber den ECS an den separaten Korrekturserver verschickt, die den im Abschnitt 3 beschriebene Zusammenfu¨gung von Aufgabe, studentischer Abgabe und Korrekturcode u¨bernimmt und selbst den resultierenden Code an die Backends verschickt. Er extrahiert dann aus den Ausgaben des Backends die Punktzahl und liefert diese an das ILIAS-System zuru¨ck, welches die Punktzahl dann in seine Datenbank eintra¨gt. Auch hier ist nachtra¨glich eine A¨ nderung der Bewertung mo¨glich, jedoch wird anders als bei der manuellen Bewertung der Dozent nicht dazu gedra¨ngt, die studentische Lo¨sung auch wirklich anzusehen. 3
Eine ViPLab-Aufgabe besteht a¨hnlich wie ein C-Programm aus mehreren U¨ bersetzungseinheiten, die aus Header-Dateien, Quellcode-Dateien oder reinen Rohdaten (etwa Datensa¨tzen zur numerischen Auswertung) bestehen ko¨nnen. Eine U¨bersetzungseinheit kann grob mit einer einzelnen Quell-Datei auf dem numerischen Server identifiziert werden.
source.c #include<stdio.h> ... double solve_dgl(double t...) { ….
plot_graph(..) } int main (int argc,char **argv) {
solve_dgl(...); } double plot_graph(...) {
... } int main (...) { points=abs(solve_dgl(...)-correct); } double plot_graph(...) {
/* do not plot */ } header.h Abb. 3: Eine ViPLab-Aufgabe besteht aus mehreren U¨ bersetzungseinheiten, von denen jede aus mehreren Codeblo¨cken besteht. Einige der Blo¨cke (grau) sind invariant, von denen wieder einige unsichtbar sein ko¨nnen (schraffiert). Im Korrekturmodus ko¨nnen invariante Codeteile durch Korrekturalgorithmen ersetzt werden.
Jede U¨ bersetzungseinheit besteht aus mehreren Blo¨cken von Zeilen des Quellcodes oder der Quelldaten. Ein Block kann entweder durch die Studierenden gea¨ndert werden oder invarianten Code, etwa ein vorgegebenes Hauptprogramm, enthalten. Invarianter Code kann angezeigt werden, kann dann aber nicht bearbeitet werden, oder kann vollsta¨ndig verborgen werden, siehe Abb. 4. Invarianter sichtbarer Code dient oft zur Vorgabe von Rumpfcode durch den Dozenten, etwa zur Definition eines festen Hauptprogrammes, zur Fixierung der erlaubten Include-Dateien fu¨r C usw., wohingegen unsichtbarer Code Bibliotheksfunktionen entha¨lt, die fu¨r die Didaktik der Aufgabe ohne Belang, fu¨r die eigentliche Funktion und den Betrieb aber notwendig ist. Mit unsichtbarem Code werden etwa die Matlab-Funktionen zur graphischen Ausgabe u¨berladen, so dass diese Ausgabe statt auf dem Server letztendlich im ILIAS-System am studentischen Rechner angezeigt wird. ViPLab-Aufgaben sind dabei ILIAS-Entita¨ten wie alle anderen Aufgaben auch, d.h. ko¨nnen mit den bereits verfu¨gbaren Mechanismen des LMS zwischen Dozenten ausgetauscht und geteilt werden.
Zwecks automatischer Korrektur ko¨nnen invariante Codeteile weiterhin beim Korrekturvorgang durch einen Korrekturalgorithmus ersetzt werden, siehe Abb. 5: Steuert etwa im U¨ bungsbetrieb das invariante Hauptprogramm die Ausgabe des studentischen Codes auf die Konsole oder plottet diese, so kann das Hauptprogramm im Korrekturbetrieb den studentischen Algorithmus gezielt mit Testdaten versorgen und die Korrektheit der Lo¨sung anhand der zuru¨ckgelieferten Resultate evaluieren. Die Korrektur besteht also einem vom Dozenten zu erstellenden Algorithmus, der als invariante Code-Teile in den studentischen Code eingefu¨gt wird und der Daten oder Programmteile des U¨ bungsbetriebes ersetzt. Abb. 4: Der ViPLab-Editor aus Dozentensicht. Oben ein vera¨nderbarer Codeteil, darunter ein invarianter Codeteil mit einem Ersatzcode fu¨r die automatische Korrektur Der Korrekturcode stellt somit keine Musterlo¨sung dar, sondern fu¨ttert das studentisches Hauptprogramm mit Testdaten und evaluiert die Korrektheit der zuru¨ckgelieferten Resultate. Besteht etwa die Klausuraufgabe in der Implementierung einer numerischen Lo¨sung einer gegebenen parametrisierten Differentialgleichung, so wu¨rde im U¨ bungsbetrieb das vom Dozenten erstellte invariante Hauptprogramm die Anfangsbedingungen liefern und das Resultat des studentischen Codes ausdrucken oder plotten. Bei der automatischen Korrektur wird dieser invariante Code durch einen Korrekturcode ersetzt, der den studentischen Code etwa mit randomisierten Ausgangsdaten ansteuert und die Resultate mit der korrekten Lo¨sung vergleicht. Im einfachsten Falle ergibt sich eine Punktzahl aus der Abweichung der vom studentischen Code gelieferten Lo¨sung mit der korrekten Lo¨sung. Eine anderweitige algorithmische Bewertung des Codes selbst, etwa durch Codemetriken oder durch Beurteilung der Implementientierungsqualita¨t findet momentan nicht statt, wa¨re aber prinzipiell durch den Korrekturserver mo¨glich. Wir haben momentan vom Einsatz komplexerer Verfahren abgesehen, da fu¨r die in den ersten Semestern behandelten Probleme einfachere Auswertungsverfahren momentan noch ausreichend sind. 4
Nach sechs Jahren im Einsatz ist ViPLab fu¨r die Studierenden der Universita¨t Stuttgart zu
einer Selbstversta¨ndlichkeit geworden, es ist ein Dienst des Rechenzentrums, von dem man
erwartet, dass er stabil funktioniert. In [
Technische Anregungen der Nutzer wurden dabei im Rahmen der Weiterentwicklung des ViPLab-Systems realisiert: Basierten die erste Version noch auf Java, so zeigte sich im Betrieb schnell, dass die Notwendigkeit der Installation und Aktualisierung des JavaPlugins eine Hu¨rde fu¨r die Nutzer darstellte. Ebenso musste in der Anfangsphase ein Virtual Network Client (VPN) installiert werden, um den Dienst von außerhalb des Universita¨tsnetzes nutzen zu ko¨nnen; auch dessen Installation erzeugte unno¨tige Barrieren. Aufgrund dieser Ru¨ckmeldungen basiert die Version 2.0 auf Javascript und funktioniert auch aus o¨ffentlichen Netzen heraus. Die Installation eines Web-Browsers ist fu¨r die Bedienung ausreichend, wobei ViPLab mit Firefox, Chrome, dem Internet-Explorer, Opera und Safari problemlos zusammenarbeitet.
Auf Wunsch der Dozenten ergab sich rasch die Notwendigkeit einer engeren
Integration in das ILIAS-System: Die erste Version von ViPLab bestand aus einem
SCORMkompatiblen [
Die Einfachheit der automatischen Bewertung, d.h. eine Bewertung durch den Austausch des Hauptprogrammes durch ein vom Dozenten zu erstellendes Bewertungsprogramm hat sich fu¨r die Anwendung im ersten Semester nicht als hinderlich erwiesen. Fu¨r gro¨ßere Programmierprojekte ist ViPLab nicht entwickelt worden, und wir raten in diesem Falle Dozenten, stattdessen eine vollsta¨ndige IDE einzusetzen. Der typische Einsatzzweck von ViPLab besteht in der Durchfu¨hrung elementarer Aufgaben aus der numerischen Mathematik, die sich ha¨ufig auf wenige Zeilen Quellcode beschra¨nken und die auf das Wesentliche reduziert sind. 5
Mit dem Aufbau des Korrekturservers hat sich die Mo¨glichkeit ergeben, zur Bewertung auch komplexere Code-Metriken verwenden zu ko¨nnen, die dann auf dem Korrekturserver ablaufen. Auf diese Weise la¨sst sich auch eine Ru¨ckmeldung u¨ber den Programmierstil einer studentischen Lo¨sung geben. In unseren Einsatzszenario ist dies allerdings meist von untergeordneter Bedeutung. Eine Plagiatserkennung findet momentan nicht statt, wa¨re aber im Rahmen des Korrekturservers durchaus mo¨glich, indem dieser identische oder sehr a¨hnliche Abgaben identifiziert. Durch Randomisierung der Testdaten kann der Korrekturcode in begrenztem Umfang zumindest das Raten von Lo¨sungen erkennen und verhindern.
[1] GWT : Productivity for developers, performance for users. http://www.gwtproject.org/.