Wiederverwendbarkeit von Programmieraufgaben durch Interoperabilität von Programmierlernsystemen

Unterstützungssysteme für die Programmierausbildung sind weit verbreitet, doch gängige Standards für den Austausch von allgemeinen (Lern-) Inhalten und Tests erfüllen nicht die speziellen Anforderungen von Programmieraufgaben wie z. B. den Umgang mit komplexen Einreichungen aus mehreren Dateien oder die Kombination verschiedener (automatischer) Bewertungsverfahren. Dadurch können Aufgaben nicht zwischen Systemen ausgetauscht werden, was aufgrund des hohen Aufwands für die Entwicklung guter Aufgaben jedoch wünschenswert wäre. In diesem Beitrag wird ein erweiterbares XMLbasiertes Format zum Austausch von Programmieraufgaben vorgestellt, das bereits von mehreren Systemen prototypisch genutzt wird und das mittelfristig den Austausch über ein gemeinsam genutztes Aufgabenrepository ermöglichen soll. 1 Einleitung und Problemstellung Der Bedarf für Lehrende, Aufgaben für den Einsatz in verschiedenen Lernszenarien aus einem Pool von bestehenden Testinhalten zu nutzen, wächst mit steigendem EAssessment Einsatz an Hochschulen. Dies gilt aufgrund des vergleichsweise hohen Entwicklungsaufwands im besonderen Maße für Programmieraufgaben. Dabei handelt es sich um offene Aufgabentypen, da es wichtig ist, dass die Lernenden eigene Lösungen entwickeln und diese geprüft werden können [Ro07]. Neben der textuellen Beschreibung der jeweiligen Programmieraufgabe sind zur Vorbereitung der (automatisierten) Bewertung oder Generierung von Feedback in der Regel abhängig vom Programmbewertungssystem Tests, wie im Falle der Programmiersprache Java z. B. JUnit-Tests, zu implementieren oder auch im Falle von z. B. SQL oder Prolog Musterlösungen vorzubereiten. Der erforderliche, partiell sehr hohe Aufwand bei der Erstellung derartiger Aufgaben kann deutlich reduziert werden, wenn Testinhalte systemunabhängig genutzt und zwischen den Lehrenden ausgetauscht werden können. Obwohl seit deutlich mehr als zehn Jahren an Unterstützungssystemen für die Programmierausbildung bzw. (automatischen) Bewertungssystemen für unterschiedliche Programmiersprachen gearbeitet wird [KSZ02, Ed04, Hü05, Sp06, Mo07, Tr07, ASS08, HQW08, SBG09, Ih10, SOP11, PJR12, RRH12], gibt es bislang kein gemeinsames Austauschformat. Trotz des großen Aufwands für die Konzeption von (Übungs-)Aufgaben besitzen nur wenige Systeme, die in der Programmierausbildung eingesetzt werden (z. B. DUESIE, eAIXESSOR, JACK), einen auf Wiederverwendung ausgerichteten Aufgabenpool oder streben diesen an. Insbesondere bei Systemen, von denen mehrere Instanzen existieren, könnte zumindest eine Import/Export-Funktion innerhalb dieser Systeme den Arbeitsaufwand durch Wiederverwendung von Aufgaben reduzieren. Dennoch ist ein Imbzw. Export von Aufgaben bislang nur selten möglich (JACK, Praktomat). In anderen Bereichen (z. B. Mathematik) gibt es hingegen Learning Management Systeme (LMS, z. B. LONCAPA), bei denen der (weltweite) Austausch einen zentralen Systembestandteil darstellt. Im Folgenden wird ein Ansatz für ein gemeinsames Austauschformat vorgestellt, das genau diese Lücke für Programmieraufgaben systemübergreifend schließen soll. 2 Anforderungen an ein Austauschformat und existierende Formate In diesem Abschnitt werden anhand von im Einsatz befindlichen Systemen Anforderungen an ein systemübergreifendes Austauschformat hergeleitet, existierende Austauschformate vorgestellt und mit den hergeleiteten Anforderungen verglichen. 2.1 Anforderungen an ein Austauschformat für Programmieraufgaben Programmieraufgaben können in sehr verschiedener Form und sehr unterschiedlichem Umfang gestellt werden: Im einfachsten Fall müssen möglicherweise nur wenige Zeilen Programmcode in einem vorgegebenen Codegerüst ergänzt werden, während in komplexen Fällen zahlreiche Klassen zu erstellen sind, die vorgegebene Schnittstellen realisieren oder selber vorgegebene Schnittstellen ansprechen. Zudem kann es je nach Programmiersprache und Entwicklungsumgebung Verzeichnisund Dateistrukturen geben, die von den Lernenden beachtet werden müssen. Anders als bei geschlossenen Fragetypen, bei denen die korrekten Antworten vorab bekannt sind und die Korrektheit einer Einreichung über einen Soll-Ist-Vergleich bestimmt werden kann, gehören Programmieraufgaben, sofern es sich nicht um sehr einfache Fill-in-the-Gap-Aufgaben handelt, zu den offenen Fragetypen, bei denen eine Einreichung nach verschiedenen Kriterien beurteilt werden kann. Hier kann beispielsweise eine statische Analyse des Quellcodes erfolgen (mit verschiedenen Zielen, z. B. Kompilierfähigkeit, Verwendung bestimmter Konstrukte, Einhaltung eines Programmierstils). Zudem sind dynamische Analysen (z. B. Unitoder Blackbox-Tests), mit denen die Korrektheit eines eingereichten Programms überprüft werden kann, denkbar [Al05]. Für die Durchführung derartiger Analysen werden möglicherweise verschiedene Ausführungsumgebungen oder zusätzliche Dateien benötigt, die für die Lernenden nicht