Child pages
  • Divekit

Divekit - Toolkit for Individual Exercises

Divekit (Toolkit for Individual Exercises) ist ein Tool, das für die digitale Lehre in programmiernahen Veranstaltungen (wie etwa Softwaretechnik, Algorithmik, Algorithmen und Programmierung im Informatik Bachelor, oder Coding Essential 1/2 in Code & Context) entwickelt wird. Es ist als Open Source System konzipiert, das möglichst umfassend einsetzbar sein soll. 

Überblick

Divekit hat das Ziel, digitale Lehre im Bereich Programmierung vielfältig zu gestalten - also insbesondere über das Niveau von Multiple-Choice-Tests hinaus, die nur Stufe 2 der Bloom'schen Taxonomie abdecken. Mit Divekit erreicht man mindestens Stufe 3. Heißt: Die Studierenden geben echte Modellier- und Programmieraufgaben ab, mit den Tools, die auch im professionen Alltag eingesetzt werden. Formatives Feedback wird möglichst automatisiert gegeben - was gleich mehrere Vorteile hat: 

  • Das Feedback ist bei einer Automatisierung sofort da, nicht erst eine Woche später. 
  • Betreuer*innen haben mehr Zeit für individuelle Beratung, anstatt 50 ähnliche Lösungen manuell durchzusehen. 

Des Weiteren bietet Divekit die Möglichkeit, Praktikumsaufgaben so zu individualisieren, dass Studierende die Lösungen nicht mehr leicht untereinander austauschen können. Selbst wenn sie in der Lage sind, Ähnlichkeiten zu erkennen, sind sie doch gezwungen, sich mit der Aufgabenstellung auseinanderzusetzen. Daher kann man sie ermutigen, sich in Gruppen untereinander auszutauschen, und dann - wie gefordert - individuelle Lösungen abzugeben. 



Das obige Schaubild zeigt die verschiedenen "Phasen" einer Übungsaufgabe, die wir anhand von Beispielen näher betrachten werden, um die Arbeitsweise von Divekit näher zu erklären.

  1. Der oder die Lehrende konzipiert eine Aufgabe mitsamt einer Musterlösung für die Betreuer*innen, die diese in Beratung und Korrektur (falls manuelle Korrektur nötig ist) einsetzen können. 
  2. Die - "generisch" verfasste - Aufgabenstellung wird für die einzelnen Studierenden individualisiert und dann in Form eines individuellen Gitlab-Repository an die Studierenden verteilt
  3. Die Studierenden bearbeiten die Aufgabe. Jede*r hat eine individuelle Aufgabenstellung. Durch Kombination verschiedener Individualisierungsmerkmale gibt es in in einer normalen Kohortengröße keine zwei gleichen Aufgabenstellungen. Die Studierenden reichen ihre Lösungen durch ein git commit / git push ein. 
  4. Über eine personalisierte Webseite erhalten die Studierenden Feedback. Im Fall von komplett automatisierten Tests erfolgt das Feedback unmittelbar.
  5. Bei manueller Korrektur gibt es Tools für die Betreuer*innen, um die Warteschlange der eingereichten Lösungen zu sehen und die jeweils "älteste" Lösung zu korrigieren. Auch in diesem Fall ist das Feedback auf der individuellen Testseite sichtbar. 

Beginnen wir mit einem Beispiel bei der Studierendenperspektive in Phase 3. 

(3) Bearbeiten einer Praktikumsaufgabe (Studierenden-Perspektive)

Versetzen wir uns in die Perspektive einer Studierenden im 3. Semester Informatik an der TH Köln, die gerade das Praktikum in Softwaretechnik 1 absolviert.

Beispiel: Fachliches Glossar

Eine typische Aufgabe sieht dabei (etwas verkürzt) so aus: 

Betrachten Sie den folgenden Ausgangstext und erstellen Sie daraus das fachliche Glossar und das entsprechende fachliche Datenmodell. 

Diese Art von Aufgabenstellung verlangt eine Hauptwortanalyse eines Ausgangstexts, der Anforderungen an ein Softwaresystem beschreibt. Dabei müssen die Studierenden Synonyme identifizieren und streichen. Die übriggebliebenen Begriffe sind Kandidaten für das fachliche Glossar, aus dem man dann ein erstes Datenmodell gewinnen kann. 

Zwei Studierende könnten diesen Text erhalten: 

Der linke und der rechte Text stammen aus derselben Ausgangs-Aufgabenstellung und wurden durch Divekit automatisch individualisiert. Farbig markiert sind einige der Hauptwörter für das fachliche Glossar. Gleiche Farben links und rechts bedeuten Variationen desselben Basisbegriffs. Gleiche Farben innerhalb eines Texts sind bewusst eingebaute Synonyme. 

Beispiel: Überführung des fachlichen ins logische Datenmodell

Eine weitere typische Aufgabenstellung ist die Überführung eines fachlichen (FDM) in ein logisches Datenmodell (LDM). Ersteres ist (wie der Name sagt) sehr fachlich geprägt und nahe an den Anforderungen (das Ausgangsprodukt des obigen Beispiels). Das logische Datenmodell ist programmiernah - bestimmte Klassen (Entities) müssen ergänzt werden, andere weggelassen, und Beziehungen bekommen eine Richtung. Daraus lässt sich dann wieder unmittelbar Code schreiben. Die Aufgabenstellung könnte etwa wie folgt lauten: 

Überführen Sie das fachliche ins logische Datenmodell und implementieren Sie die Entities mittels JPA.

Um Folgefehler zu vermeiden (der oder die Studierende hat schwere Fehler in das FDM eingebaut und damit keine Chance, ein korrektes LDM und damit passenden Code zu erstellen ...), ist es sinnvoll, das Ausgangs-FDM hier vorzugeben. Divekit unterstützt hier nicht nur bei der Individualisierung von Texten, sondern auch von Diagrammen. Nachfolgend sind zwei Aufgabenstellung für zwei verschiedene Studierende gezeigt, die beide wiederum aus derselben "generischen" Aufgabenstellung erzeugt wurden: 

Wie im ersten Beispiel bedeuten gleiche Farben oben und unten wiederum Variationen desselben Basisbegriffs. Man beachte, dass mit Divekit auch das Diagramm-Layout variiert werden kann, was die direkte Austauschbarkeit von Lösungen zwischen Studierenden zumindest erschwert. 

(4) Feedback (Studierenden-Perspektive)

Jede*r Studierende bekommt über Divekit eine individuelle Testseite, die ein formatives Feedback beinhaltet. Jede Übungsaufgabe ist entweder "grün" oder "rot".

Feedback kommt einerseits aus automatischen Tests

Dieses Feedback kommt zum Einen aus automatischen Tests. Hier gibt es in Divekit zurzeit zwei Arten von Tests: 

  • Eine (stetig wachsende) JUnit-Testbibliothek, die bestimmte Standard-Tests aus der Softwaretechnik abdeckt. Aus dieser Bibliothek kann man sich als Lehrende*r bedienen, wenn man eigene Übungsaufgaben konzipieren will. 
  • Eine Bibliothek von Tests für Markdown-Tabellen, mit denen man z.B. formalisierte Texte wie etwa ein Glossar automatisiert auf Richtigkeit prüfen kann. 

Feedback aus manuellen Korrekturen

Neben den automatischen Tests kann auch manuelles Feedback an den / die Studierende*n übermittelt werden, z.B. für Modellierungen, die zurzeit noch nicht automatisiert überprüft werden können. 

(1) Konzipieren (Lehrenden-Perspektive)

Als Lehrende*r erstellt man die Aufgabenstellung mit Hilfe einer Meta-Notation, wie unten dargestellt. Der Platzhalter $mgmt__Betreiber$ kann darin zu "Mischkonzern", aber auch zu "Wohnungsbaugesellschaft" expandiert werden.

Neben der in Markdown verfassten Aufgabenstellung muss der oder die Lehrende zusätzlich einen Satz von JSON-Konfigurationsdaten pflegen, wie unten gezeigt. Für den Oberbegriff mgmt_ wurden hier die Variationen "Wohnhaus", "Produktionsstandort", "Werkshalle", "Autowaschanlage" etc. definiert (unten, linkes Teilbild). Für jede Variation muss dann jeweils ein passender Satz von weiteren Attributen definiert werden (unten, rechtes Teilbild), damit der Gesamttext in sich schlüssig bleibt. 

Um das Konzipieren von Aufgabenstellungen und Variationen bequemer zu machen, wird momentan im Rahmen eines Praxisprojekts ein IntelliJ-Plugin auf Basis des Language Server Protocols erarbeitet. 

(2) Individualisieren und Verteilen (Lehrenden-Perspektive)

Wenn die obigen Dateien zur Definition der Aufgabenstellung fertig sind, dann übernimmt Divekit das zufällige Individualisieren und Verteilen der Aufgaben. Dies geschieht dadurch, dass das Gitlab-Repo mit der Aufgabenstellung für alle Studierenden per Command-Line-Befehl kopiert wird.  Dabei geschieht folgendes:

  • Das Repo wird mit einer persönlichen UUID versehen, um es von den anderen Repos zu unterscheiden. Das Ergebnis sieht man unten - in einer Gitlab-Group liegen dann so viele Repos wie es Studierende gibt. 
  • Divekit setzt dabei automatisch die passenden Zugriffsrechte, so dass der Studierende nur ihr oder sein eigenes Repo sieht. Das hat - neben Daten- und Kopierschutz - den Vorteil, dass man den Studierenden nur die allgemein gültige, nicht individualisierte URL der Gitlab Group geben muss, was die Verteilung ungemein vereinfacht. 
  • In dem individuellen Repo wird dann, wie im vorigen Abschnitt dargestellt, eine zufällige Variation der Aufgabenstellung erzeugt. Durch die Vielfalt der kombinatorischen Möglichkeiten gibt es keine zwei gleichen Repos. 
  • Die Variationen werden von Divekit natürlich auch auf die Tests angewandt, so dass diese auf die passend benannten Tabellen, Klassen und Variablen abgestimmt sind.


Zusätzlich zum für die Studierenden sichtbaren Repo, in dem die Aufgabenstellung liegt und in dem sie ihre Lösung verfassen, gibt es für jeden Studierenden noch ein zweites "Hidden Test" Repo. Dies enthält diejenigen Tests, die für die Studierenden nicht einsehbar sein sollen. Wenn die Aufgabenstellung beispielsweise lautet: 

Implementieren Sie die genannten Klassen als Entities oder Value Objects. Entscheiden Sie nach dem Anforderungstext, ob es sich um ein Entity oder ein Value Object handelt.

dann sollte der Test, ob die richtigen Klassen als Entities oder als Value Objects implementiert wurden, nicht einsehbar sein - sonst wäre die Lösung ja schon klar. Solche Tests liegen dann im Hidden-Test-Repo. Ergebnisse der Hidden Tests werden ebenfalls auf der persönlichen Feedbackseite (s.o.) angezeigt. 

Testen einer Aufgabenstellung

Für das Testen einer Aufgabenstellung, während der Erarbeitung, kann man Divekit auch im "local mode" arbeiten lassen. Dann werden Test-Repos mit Individualisierungen nur lokal erzeugt, und man kann sie auf korrekte Verwendung der Variationsvariablen prüfen. 

Die Anzahl der erzeugten Variationen kann man dabei frei wählen. So sind auch Abschlusstests möglich, bei denen man z.B. 10-20 Repos erzeugt und prüft, ob alle Kombinationen auch tatsächlich wie intendiert aussehen und in sich konsistent sind.

(5) Korrigieren und Auswerten (Betreuer*innen-Perspektive)

Für das (manuelle) Korrigieren und Auswerten von Aufgaben, bei denen eine automatisierte Prüfung noch nicht möglich ist, bietet Divekit einige Command-Line-Befehle, um die nächsten zu korrigierenden Lösungen zu bestimmen. 

Hier wird im Rahmen eines Praxisprojekts gerade ein einfaches graphisches UI erarbeitet, das diese Aufgaben bündelt und vereinfacht.