=Paper=
{{Paper
|id=Vol-2015/ABP2017_paper_07
|storemode=property
|title=Moodle, Grappa, aSQLg, Graja - Neue Entwicklungen bei der Grading-Software der Hochschule Hannover(New Developments in the Grading Software of the Hanover University of Applied Sciences and Arts)
|pdfUrl=https://ceur-ws.org/Vol-2015/ABP2017_paper_07.pdf
|volume=Vol-2015
|authors=Robert Garmann,Peter Fricke,Paul Reiser,Christopher Bersuch,Oliver J. Bott
|dblpUrl=https://dblp.org/rec/conf/abp/GarmannFRBB17
}}
==Moodle, Grappa, aSQLg, Graja - Neue Entwicklungen bei der Grading-Software der Hochschule Hannover(New Developments in the Grading Software of the Hanover University of Applied Sciences and Arts)==
https://ceur-ws.org/Vol-2015/ABP2017_paper_07.pdf
3. Workshop „Automatische Bewertung von Programmieraufgaben“,
(ABP 2017), Potsdam 2017 1
Moodle, Grappa, aSQLg, Graja - Neue Entwicklungen bei
der Grading-Software der Hochschule Hannover
Robert Garmann1, Peter Fricke2, Paul Reiser2, Christopher Bersuch2, Oliver J. Bott3
Abstract: For several years the grading software developed at the Hanover University of Applied
Sciences and Arts has increased the quality of various university courses. Increased quality had
been confirmed by several evaluations. In this paper, we present improvements to the software that
have been achieved in the past two years. We take a look at all software layers involved: the
frontend "Moodle" with its Moodle plugin, the graders "Graja" and "aSQLg" in the backend, as
well as the middleware "Grappa" mediating between these components. We describe some of the
improvements in detail and illustrate them with diagrams and screen photos.
Abstract: Die an der Hochschule Hannover entwickelte Grading-Software steigert seit mehreren
Jahren die Qualität der Lehrveranstaltungen verschiedener Studiengänge der Hochschule.
Qualitätsverbesserungen konnten durch mehrere Evaluierungen belegt werden. Im vorliegenden
Beitrag stellen wir Verbesserungen der Software vor, die in den letzten beiden Jahren erreicht
wurden. Wir werfen einen Blick auf alle beteiligten Softwareschichten: das Frontend „Moodle“
und das hier eingesetzte Moodle-Plugin, die Grader „Graja“ und „aSQLg“ im Backend, sowie die
zwischen diesen Komponenten vermittelnde Middleware „Grappa“. Wir beschreiben einige der
erreichten Verbesserungen im Detail und illustrieren diese durch Diagramme und Bildschirmfotos.
Keywords: Programmieraufgabe, Grader, Moodle, SQL, Java, E-Assessment
1 Einleitung
Seit mehreren Jahren nutzen Lehrende der Hochschule Hannover (HsH) das Lern-
managementsystem (LMS) Moodle zur Verwaltung und Durchführung von Lehr-
veranstaltungen. Durch die an der HsH entwickelte Middleware Grappa können Lehren-
de Programmieraufgaben für verschiedene Programmiersprachen mit einer automati-
schen Bewertung versehen. Grappa kann prinzipiell jedes LMS mit jedem Autobewerter
(Grader) vernetzen [GHW15]. Für die Einbindung von Grappa in Moodle entstand ein
spezielles Moodle-Plugin, welches mit Grappa über einen auch in anderen LMS-Anbin-
dungen einsetzbaren PHP-Client asynchron verbunden ist (s. Abb. 1). Mit den an Grappa
über Backend-Plugins angebundenen Gradern Graja und aSQLg bietet die HsH den
Studierenden derzeit automatisiert bewertete Aufgaben für Java und SQL an.
1
Hochschule Hannover, Fakultät IV Wirtschaft und Informatik, Ricklinger Stadtweg 120, 30459 Hannover,
robert.garmann@hs-hannover.de
2
Hochschule Hannover, ZLB – E-Learning-Center, Expo Plaza 12, 30539 Hannover, peter.fricke@hs-
hannover.de, paul.reiser@stud.hs-hannover.de, christopher.bersuch@stud.hs-hannover.de
3
Hochschule Hannover, Fakultät III Medien, Information und Design, Expo Plaza 12, 30539 Hannover,
oliver.bott@hs-hannover.de
2 Robert Garmann et. al.
Ausgehend von Erfahrungen in früheren Einsatzszenarien [Fri15] wurden in den letzten
beiden Jahren einige Neuerungen erreicht. Die Neuerungen führten einerseits zu einer
verbesserten Usability, andererseits wurden nicht zuletzt durch technische Optimierun-
gen zusätzliche Funktionen ermöglicht. Beispielsweise kann die Konfiguration von Pro-
grammieraufgaben nun zentral und damit benutzerfreundlicher erfolgen. Ein weiteres
Beispiel ist das sog. Gradebook in Moodle, in dem nun auch Programmieraufgaben zu-
sammen mit dem Feedback aufgelistet werden. Als drittes Beispiel seien SQL-Aufgaben
genannt, die nun auch für andere Datenbanksysteme (z. B. H2) realisiert werden können.
Diese und weitere Beispiele für Neuerungen beschreiben die Abschnitte 2 bis 4 dieses
Aufsatzes. Wir beschließen den Aufsatz in Abschnitt 5 mit einer Beschreibung der zu-
künftig geplanten und teilweise schon begonnenen Verbesserungen.
Abb. 1: Softwarekomponenten zur Einbettung von Gradern in Moodle. Die gestrichelt
dargestellten Komponenten und Verbindungen sind in Planung.
2 Neuerungen im Frontend
In diesem Abschnitt beschreiben wir Verbesserungen des Moodle-Plugins, die sich insb.
auf die Benutzungsschnittstelle auswirken.
2.1 Zentrale Konfiguration von Programmieraufgaben
Bei Verwendung des Moodle-Plugins legt die Lehrkraft in einem Kurs zwei Arten von
Artefakten an: Konfigurationsdateien für Grader (kurz Grader-Configs resp. GrdCfg)
und Programmieraufgaben. Programmieraufgaben legen Grader-unabhängige Eigen-
schaften fest, wie Abgabezeitpunkt, Benachrichtigungseinstellungen, etc. Zudem refe-
renzieren Programmieraufgaben jeweils ein oder mehrere GrdCfgs. Eine GrdCfg kann in
mehreren Aufgaben eingesetzt werden. Bspw. wird mit Graja i. d. R. pro Kurs eine ein-
zige Properties-Datei mit globalen Einstellungen für alle Aufgaben genutzt. Diese Datei
ist eine GrdCfg mit der Graja-spezifischen Rolle props. Jede Graja-Aufgabe hat
zusätzlich eine eigene GrdCfg, die die eigentliche Aufgabe im ProFormA-Format enthält
(Graja-spezifische Rolle task).
Moodle, Grappa, aSQLg, Graja – Neues zur Grading-Software der Hochschule Hannover 3
Abb. 2: Liste der im Kurs gespeicherten Grader-Configs (Ausschnitt)
Die Benutzerführung in Moodle wurde inzwischen insofern verbessert, dass GrdCfgs
gemäß ihrem referenzierbaren, zentralen Charakter als Teil der Kurs-Administration ge-
pflegt werden können (s. Abb. 3). Von einer Liste aller im Kurs gespeicherten GrdCfgs
(s. Abb. 2) gelangt man zu den Einstellungen einer einzelnen GrdCfg (s. Abb. 4).
Abb. 3: Zentraler Zugang zu Grader-Konfigurationen Abb. 4: Einstellungen einer GrdCfg
Diese Art der Verwaltung von GrdCfgs ist wesentlich intuitiver als die bisherige
Realisierung als Moodle-Aktivitäten. Auch wurden durch diese Realisierung die
technisch notwendigen Voraussetzungen für summatives Assessment mit Moodle-Tests
geschaffen (vgl. auch Abschnitt 5).
4 Robert Garmann et. al.
2.2 Programmieraufgaben im „Gradebook“
Die vom Moodle-Plugin angebotene Programmieraufgabe entstand als Spezialisierung
des zum Moodle-Standardumfang gehörenden assignments. Dadurch befinden sich Pro-
grammieraufgaben und „normale“ Aufgaben gleichberechtigt im sog. Gradebook eines
Studenten. Üblicherweise werden semesterbegleitend sowohl automatisiert bewertete
Aufgaben als auch einige von Tutoren bewertete Aufgaben gestellt.
... [ gekürzte Darstellung ]
Abb. 5: Ausschnitt eines Gradebooks mit einer „normalen“ und einer automatisiert bewerteten
Aufgabe. Punktzahl und Feedback sind integriert bzw. durch einen Mausklick auf
Bewertungsdetails erreichbar.
Am Ende muss als Teil der Prüfungsleistung ein vorgegebener Prozentsatz aller
Aufgaben erreicht werden. Die Studierenden haben während des Semesters stets einen
Überblick über die bisher erreichten Punkte im Gradebook (s. Abb. 5).
2.3 Programmieraufgaben und normale Moodle-Aufgaben
Die o.g. Programmieraufgaben (programming assignment) basieren ursprünglich auf
den standardmäßig in Moodle integrierten Aufgaben (assignments) einer früheren
Moodle-Version. Letztere wurden in Moodle-Folgeversionen weitgehend verändert. Da-
mit Lehrende, die die Erstellung der normalen Moodle-Aufgaben bereits kennen, sich
weiterhin auf der Benutzeroberfläche zurechtfinden, wurde die Programmieraufgabe der
Aktivität Aufgabe der neuesten Moodle-Version wieder angeglichen. Neue Zusatzfunk-
tionen der Aufgabe sollen bald ebenfalls in der Programmieraufgabe nachprogrammiert
werden. Lediglich in Einstellungsoptionen, die für Programmieraufgaben spezifisch
sind, wie z. B. die Auswahl der unterschiedlichen Grader sowie ihrer GrdCfgs, weicht
die Programmieraufgabe weiterhin von einer Aufgabe ab. Eine weitere hilfreiche Neue-
rung der Programmieraufgabe ist, dass nur noch die GrdCfgs zur Auswahl per Checkbox
angeboten werden, die für den ausgewählten Grader zur Verfügung stehen.
2.4 Technische Neuerungen „unter der Haube“
Zu den Grundfunktionen für sämtliche Aktivitäten innerhalb eines Kurses in Moodle ge-
hört das Kopieren der Aktivität. Dazu bedient sich Moodle einer Sicherungs- und Wie-
Moodle, Grappa, aSQLg, Graja – Neues zur Grading-Software der Hochschule Hannover 5
derherstellungs-Engine4, welche ebenfalls für die Kurssicherung genutzt wird. In
Moodle werden Elemente des Grappa-Domänenmodells (Problem und Result, siehe
[GHW15]) für Informations- und Editierzwecke angezeigt und persistiert. Wegen der
durchaus komplexen Baumstruktur des Domänenmodells wurden die zuvor genannten
Sicherungs- und Wiederherstellungsfunktionen in den ersten Versionen der Program-
mieraufgabe außer Acht gelassen. Die Integration dieser Features wurde vorangetrieben,
so dass es nun möglich ist, eine Programmieraufgabe innerhalb eines Kurses zu kopie-
ren. Ebenfalls kann diese jetzt zwischen Kursen und Moodle-Instanzen ausgetauscht
werden. Für den Austausch zwischen verschiedenen Moodle-Instanzen muss auf beiden
Seiten allerdings eine Grappa-Server-Instanz mit dem gleichen Namen vorhanden sein.
Der Name dient der eindeutigen Identifizierung und Zuordnung von GrdCfgs und
Problems zu einer Grappa-Server-Instanz innerhalb von Moodle. Ein Dialog, der die
Grappa-Server-Instanz abfragt, ist nicht möglich, denn die Moodle interne Restore-API5
muss aufgrund der automatischen Kurssicherung ohne Dialoge auskommen (diese wird
per Batchverarbeitung ausgeführt).
Innerhalb von Moodle werden alle Aktionen des Systems und der Nutzerinnen und Nut-
zer in Berichten geloggt. Seit Moodle Version 2.7 wurde die Event-Api6 grundlegend
überarbeitet. Die Programmieraufgabe (Abschnitt 2.3) entstand vor dieser Moodle-Ver-
sion, so dass eine Anpassung notwendig war. Das Logging der Programmieraufgabe
wurde komplett neu entwickelt und erweitert. Zur Vielzahl verschiedener Events, die für
einen Administrator sichtbar sind, gehören bspw. das Anlegen, Ändern, Löschen und
Bewerten einer Programmieraufgabe, sowie das Abrufen und manuelle Ändern der Auf-
gabenbewertung mit den dazugehörigen Benutzerdaten.
3 Neuerungen in der Middleware
Dieser Abschnitt beschreibt Verbesserungen im Grappa-PHP-Client und im Grappa-
Kern. Da Grappa unabhängig vom LMS konzipiert wurde, stehen die hier beschriebenen
Verbesserungen neben Moodle auch anderen LMS zur Verfügung.
3.1 ProFormA-Format
Grappa entstand vor Entwicklung des ProFormA-Austauschformats für Programmier-
aufgaben [St15]. Das hiervon unabhängig entwickelte Fachdatenmodell von Grappa be-
sitzt jedoch hinreichend Ähnlichkeiten zum ProFormA-Format, die es erlauben, Grappa-
Aufgaben in ProFormA-Aufgaben zu konvertieren und umgekehrt. Abb. 6 zeigt Aus-
schnitte der beiden Fachdatenmodelle. Ein Grappa-ProblemNode entspricht weitgehend
einem ProFormA-test. Die Hierarchie von Grappa-subproblems, die eine hierarchische
4
https://docs.moodle.org/33/en/Backup_and_restore_FAQ
5
https://docs.moodle.org/dev/Restore_API
6
https://docs.moodle.org/dev/Event_2
6 Robert Garmann et. al.
Kategorisierung von Bewertungsaspekten und deren Gewichtung darstellt, lässt sich in
ProFormA-grading-hints als Grappa-spezifische Erweiterung beschreiben. Grappa-
GrdCfgs entsprechen der ProForma-test-configuration und deren filerefs.
Abb. 6: Ausschnitt aus den Fachdatenmodellen des Grappa- und des ProFormA-Formats.
Entsprechungen sind gleichfarbig markiert.
Die Entwicklungsarbeiten zur Konvertierung zwischen den beiden Formaten sind derzeit
noch nicht abgeschlossen. Es gibt jedoch eine einfache Möglichkeit, bereits jetzt Grappa
mit ProFormA-Aufgaben zu nutzen. Ein Grappa-Problem besteht bei diesem Ansatz aus
einem einzigen ProblemNode ohne subproblems. Eines der dem ProblemNode zugeord-
neten GrdCfgs enthält eine vollständige ProFormA-task. Der Vorteil dieses Ansatzes ist,
dass jedes Grappa-kompatible LMS dadurch bereits heute eine Benutzungsschnittstelle
zu ProFormA-kompatiblen Gradern anbieten kann.
Wir binden auf diese Weise derzeit Graja und dessen ProFormA-kompatible Java-Auf-
gaben via Grappa an das Moodle-Plugin an. Der Nachteil dieses vorläufigen Ansatzes
ist, dass Lehrende die Gewichtung von Bewertungsaspekten bei der Einrichtung einer
Aufgabe nicht wie gewohnt auf der Weboberfläche des LMS, sondern nur durch die
etwas umständlichere Editierung der ProFormA-task vornehmen können.
3.2 Technische Neuerungen „unter der Haube“
Die REST-Schnittstelle zu Grappa wurde HTTP-konform angepasst. Ein LMS, das an
Grappa direkt oder über den PHP-Client anbindet, sendet HTTP-Anfragen und erhält
HTTP-Antworten, die mit standardisierten HTTP-Status-Codes versehen sind. Auf Basis
dieser Codes kann das LMS HTTP-Antworten auswerten und auf unterschiedliche Ereig-
nisse geeignet reagieren.
Das Logging von Ereignissen wurde in Grappa umstrukturiert. Lognachrichten werden
pro Grappa- bzw. Grader-Instanz7 gruppiert und in separate Dateien geschrieben. Log-
Nachrichten werden mit Kontextinformationen versehen, um das Auffinden, Analysieren
und Beseitigen von Fehlern zu optimieren. Sämtliche Aktionen laufen im Kontext eines
LMS ab, dessen ID in die Log-Nachrichten aufgenommen wird. Abhängig von der Art
7
Die in Abb. 1 dargestellte Grappa-Komponente wird zur Laufzeit für jedes angeschlossene Grader-Backend
als separate Instanz gestartet. Jede Instanz erhält einen eigenen Zugriffspfad und eine eigene Konfiguration.
Moodle, Grappa, aSQLg, Graja – Neues zur Grading-Software der Hochschule Hannover 7
der Aktion kommen weitere Informationen wie GrdCfg- und Problem-ID, sowie eine ID
des jeweiligen Bewertungsprozesses hinzu.
Programmieraufgaben, bei denen die Dateinamen eingereichter Dateien lösungsrelevant
sind, werden bisher in Moodle als ZIP-Datei abgegeben. Um das manuelle „Zippen“ von
Abgaben, die nur aus einer einzelnen Quellcode-Datei bestehen, zu vermeiden, wurde
das interne Domänenmodell von Moodle und Grappa (inkl. PHP-Client) so erweitert,
dass auch einzelne Quellcode-Dateien zusammen mit ihrem Dateinamen von Moodle
über Grappa an angeschlossene Grader durchgereicht werden können.
Eine weitere Verbesserung betrifft das Management des für den Betrieb eines Grappa-
Servers erforderlichen Datenbanksystems zur Speicherung relevanter Daten und Status-
informationen. Bei Programmstart gestartete Update Scripts aktualisieren nun automa-
tisch die verwendete Datenbank nach einem Grappa-Versionswechsel (getestet mit
MySQL, Oracle und PostgreSQL).
4 Neuerungen im Backend
Die Grader aSQLg und Graja sowie ihre jeweiligen Backend-Plugins für Grappa wurden
verbessert. Die Auswirkungen auf die Benutzungsschnittstelle und die unterstützten
Funktionen werden nun beschrieben. Da beide Grader LMS-unabhängig sind, stehen die
hier beschriebenen Verbesserungen neben Moodle auch anderen LMS zur Verfügung.
4.1 SQL-Aufgaben für weitere Datenbanksysteme
Der Grader aSQLg wurde für das DBMS Oracle entwickelt. Aufgrund von Nachfragen,
ob aSQLg auch einfachere und kleinere Datenbanken unterstützen könne wie bspw. H28,
wurde aSQLg erweitert. Es ist nun möglich, über die Konfigurationsdateien zwischen
Oracle- und H2-Datenbanken zu wechseln. Ein simultaner Betrieb beider Datenbank-
systeme ist ebenfalls möglich und wurde im Sommersemester 2017 erstmals im Lehr-
betrieb genutzt.
4.2 Graja-Feedback interaktiv einblendbar
Graja kategorisiert wie viele Grader sein Feedback nach verschiedenen Bewertungsas-
pekten. Technisch liefert Graja ein einziges HTML-Fragment zurück, in dem die hierar-
chische Bewertungsstruktur durch geschachtelte HTML-Listen ausgedrückt wird. Ein
solches HTML-Fragment lässt sich in beliebige web-basierte LMS einfach integrieren.
8
http://www.h2database.com
8 Robert Garmann et. al.
Abb. 7: Feedback mit eingeblendeten Details der Kategorie Functional correctness und ihrer
zugehörigen Bewertungsaspekte (gekürzt).
Bei komplexen Aufgaben kann das Feedback sehr umfangreich ausfallen, so dass einrei-
chende Studierende den Überblick verlieren können. Damit Studierende interaktiv die-
jenigen Teile des Feedbacks ausblenden können, die nicht im Fokus des Interesses
stehen, wurde das Moodle-Plugin entsprechend erweitert. Genutzt wurde hierfür die Fä-
higkeit der Middleware Grappa, Bewertungsergebnisse als einen Baum von Ergebnis-
knoten an das LMS zu liefern.
Graja und das Backend-Plugin wurden nun dahingehend erweitert, dass sie eine Hierar-
chie von Ergebnisknoten liefern, wobei jeder Ergebnisknoten einen Teil des ursprüngli-
chen HTML-Fragments enthält. Abb. 7 zeigt ein Beispiel, bei dem interaktiv nur ein Teil
des Gesamtfeedbacks eingeblendet wurde.
5 Zusammenfassung und Ausblick
Die Grappa-Middleware und das Moodle-Plugin hat mit den beschriebenen Neuerungen
nun einen Stand erreicht, der es ermöglichte, dessen bisherige Bereitstellung auf einem
Moodle, Grappa, aSQLg, Graja – Neues zur Grading-Software der Hochschule Hannover 9
Moodle-Testsystem für nur einen begrenzten Teilnehmerkreis von Lehrenden dahinge-
hend zu erweitern, das Plugin und damit die Grader aSQLg und Graja auch im Moodle-
Produktivbetrieb der HsH interessierten Nutzern anzubieten. Dennoch sind weitere Ent-
wicklungen erforderlich. Zwar bietet die Bereitstellung von Moodle-Programmieraufga-
ben die Möglichkeit, insbesondere im Kontext formativen Assessments auch komplexere
Aufgaben zur automatisierten Bewertung anzubieten. Um aber auch bei summativen
Assessments, z. B. bei einer E-Klausur, Programmieraufgaben integriert in einen
Moodle-Test bestehend aus mehreren Aufgaben auch anderen Typs (z. B. Lückentext
oder MC-Frage) anbieten zu können, ist die Entwicklung eines eigenen „Fragetyps“ für
Programmieraufgaben erforderlich. Erstellung und Bearbeitung einer derartigen
„Programmierfrage“ sind ähnlich zur Programmieraufgabe, allerdings werden Feedback
und Bepunktung anders gehandhabt. Die entsprechende Weiterentwicklung ist für das
zweite Halbjahr 2017 geplant. Weitere erforderliche Erweiterungen betreffen die Ent-
wicklung zusätzlicher Backend-Plugins für Grader wie Jack [SZG15] oder Praktomat
[Gi16], sowie die vollständige Unterstützung des ProFormA-Austauschformates.
Literaturverzeichnis
[Fr15] Fricke, P. et al.: Grading mit Grappa - Ein Werkstattbericht. In: Automatische
Bewertung von Programmieraufgaben, Wolfenbüttel, CEUR-WS.org, 2015.
[GHW15] Garmann, R.; Heine, F.; Werner, P.: Grappa – Die Spinne im Netz der Autobewerter
und Lernmanagementsysteme. In: DeLFI 2015, München, Bd. 247, LNI, GI, 169-181.
[Gi16] Giffhorn D. u. a.: Praktomat, http://pp.info.uni-karlsruhe.de/projects/praktomat
/praktomat.php, Stand: 16.06.2017.
[St15] Strickroth, S. et al.: ProFormA: An XML-based exchange format for programming
tasks. eleed e-learning & education, 11(1), 2015.
[SZG15] Striewe, M.; Zurmaar, B.; Goedicke, M.: Evolution of the E-Assessment Framework
JACK. In: Software Engineering Workshops 2015, Dresden, CEUR-WS.org, 2015.