Neben der Vermittlung wichtiger mathematischer Grundlagen spielt auch die Programmierausbildung im Bachelorstudiengang Geodäsie und Geoinformatik eine Schlüsselrolle. Im Rahmen der Veranstaltung „GIS I / Geländemodellierung“ erfolgt die Programmierausbildung mittels der Programmiersprache Java. Der Fokus liegt, nach einer allgemeinen Einführung, auf der Modellierung und Umsetzung von Datenstrukturen für Geodaten sowie darauf basierenden Algorithmen. Aufgrund der stetig wachsenden Bedeutung von Programmierfähigkeiten wurde beschlossen die Programmierausbildung zu intensivieren, ohne jedoch den Lehrund Betreuungsaufwand signifikant zu steigern. Eine Lösung stellt ein System zur automatischen Bewertung von Programmieraufgaben dar, da ein solches System einen nahezu konstanten Aufwand unabhängig von der Anzahl der Studierenden aufweist. Dieses Paper gibt einen Überblick über das eigens für diesen Zweck entwickelte System, welches zurzeit in der Programmierausbildung des Institutes eingesetzt wird.
Die Entscheidung, welche Art von System um- und eingesetzt wird, wurde anhand folgender Anforderungen getroffen: • • • • • •
Das einzusetzende System muss frei Verfügbar und Erweiterbar sein Zugriff über ein Web-Frontend Leichte Erweiterbarkeit für weitere o Programmiersprachen o Lehrmodule
Das entworfene System besteht aus drei Hauptkomponenten. Das Web-Frontend stellt dabei die eigentliche Website mit allen Interaktionsmöglichkeiten dar, wohingegen das Backend die Verwaltung der angebotenen Inhalte, als auch die Überprüfung der Programmieraufgaben übernimmt. Die dritte und letzte Komponente stellt das Stud.IP als externer Anbieter von Kurs- und Teilnehmerinformationen dar, welches darüber hinaus als Authentifizierungsanbieter dient. Abbildung 1 zeigt die beschriebenen Systemkomponenten, sowie deren Kommunikationsschnittstellen.
Client (Web-Frontend) • Login • Übersicht • Vorlesungen • Fortschritt • Quelltext-Editor • Feedback Anzeige • Erstellung von Aufgaben
GWT RPC • login • checkProgrammingExercise • getCoursesForUser • getSubmissions • createNewExercise • …
Server (J2EE-Backend) • Login-Authentifizierung via Stud.IP • Sitzungsverwaltung • Codeüberprüfung • Ergebnisverwaltung
SOAP/WSDL • check_credentials • find_user_by_user_name • get_participants • get_lecturers_for_seminar • get_lecturers_for_institute
Stud.IP (Extern) • Login-Authentifizierung • Kursinformationen • Nutzerstatus (Student/Lehrender)
Als Basis für das gesamte System dient das Google Web Toolkit „GWT“ Framework. GWT
ermöglicht die Entwicklung von Web-basierten Client-Server Anwendungen. Dabei werden der
Server-seitige, als auch der Client-seitige Code komplett in Java erstellt. Der Client-seitige Code wird
dann vom GWT-Compiler von Java nach JavaScript übersetzt. Über selbstdefinierte Remote
Procedure Calls (RPC) können die Client- und Server-Instanzen miteinander kommunizieren.
Weiterführende Informationen finden sich unter [
Das Web-Frontend stellt wie bereits beschrieben die Interaktion mit dem Nutzer her. Nach der Authentifizierung des Nutzers (vgl. Abschnitt Authentifizierung) stehen dem Nutzer in Abhängigkeit seines Status unterschiedliche Optionen zur Verfügung. Nutzer haben grundsätzlich die Möglichkeit alle öffentlichen Inhalte abzurufen. Handelt es sich beim angemeldeten Nutzer um ein Stud.IP Konto können ebenfalls Inhalte zur Veranstaltungen abgerufen werden bei denen sich der Nutzer vorher über das Stud.IP als Teilnehmer eingetragen hat. Ist der Nutzer darüber hinaus noch Dozent des Instituts hat dieser entsprechende Editiermöglichkeiten, wie das Hinzufügen neuer Programmieraufgaben. Desweiteren erhalten Dozenten die Möglichkeit die Fortschritte der Kursteilnehmer zu überwachen, als auch die getätigten Quelltextabgaben ansehen.
Abbildung 2 zeigt Beispielhaft die Fortschritte der einzelnen Teilnehmer. Die Veranstaltungsansicht (links) gibt einen Überblick über alle gestellten Aufgaben und welche Aufgabe von welchem Teilnehmer bereits absolviert wurde. Die Aufgabenansicht gibt detaillierte Informationen über die getätigte Quelltextabgabe. Angezeigt werden Bearbeitungsbeginn (Spalte ‚Started‘) und –ende (Spalte ‚Submission‘) der Aufgabe, sowie Anzahl der benötigten Quelltextüberprüfungen (Spalte ‚Runs‘). Über die Schaltfläche „Show“ können die Quelltextabgaben betrachtet werden. Die durchnummerierten Spalten „0“, „1“, usw. entsprechen den der Programmieraufgabe zugrundeliegenden Quelltextdateien. Im gezeigten Beispiel gab es demnach zwei zu Implementierende Klassen. Der jeweilige Eintrag der Spalten ist eine Analyse der jeweiligen Quelltextabgaben zu allen anderen und spiegelt die „Ähnlichkeit“ von Abgaben wieder. Dabei symbolisiert die erste Zahl eine Gruppe von ähnlichen Abgaben und die zweite die Größe der jeweiligen Gruppe. Die Abgabe „1“ von Teilnehmer drei wurde somit von fünf weiteren, also insgesamt sechs Teilnehmern abgegeben. Um die Ähnlichkeit von Quelltextabgaben zu beurteilen wurde die Editierdistanz bzw. Levenshtein-Distanz jeder Abgabe mit allen anderen Abgaben ermittelt. Liegt die ermittelte Distanz unter einem festgelegtem Schwellwert werden die Abgaben einer Gruppe zugeordnet.
Die Server-Komponente ist wie bereits beschrieben für die Datenhaltung als auch die Überprüfung der Programmieraufgaben zuständig. Die Datenhaltung ist über eine lokale Datenbank realisiert. Um ein einfaches Deploying (Verteilung) des Systems zu gewährleisten wurde für die Datenbank auf ein eingebettetes Datenbanksystem in Form von HSQLBD zurückgegriffen. Die Datenbank ist komplett in das Systemeingebettet und somit nach außen nicht sichtbar.
Neben der eigenen Datenhaltung kommuniziert die Server-Komponente noch mit dem Stud.IP Service
um Vorlesungs- und Teilnehmerinformationen abzurufen. Die Kommunikation ist über die vom
Stud.IP bereitgestellte SOAP Schnittstelle, welche in [
Für die Nutzerauthentifizierung wurden zwei Varianten implementiert. Die bevorzugte Methode ist die Stud.IP Authentifizierung. Die SOAP Schnittstelle stellt dafür die Funktion check_credentials bereit, mit der Nutzername und Passwort auf ihre Gültig überprüft werden.
Neben dem Stud.IP Webservice ist auch eine Authentifizierung via OpenID umgesetzt. OpenID ist dabei ein dezentrales Authentifizierungssystem, welches einem Benutzer erlaubt sich mit einem OpenID-Konto bei beliebigen das System unterstützenden Websites anzumelden. Fast alle großen Webportale haben den Standard umgesetzt und fungieren somit als OpenID-Anbieter. Um Inhalte für externe Teilnehmer zu Verfügung zu stellen integriert das System den beschriebenen OpenID Standard und unterstützt bisher Google als Anbieter. Weitere Anbieter, wie z.B. Microsoft, Facebook oder Twitter können bei Bedarf mit minimalem Aufwand hinzugefügt werden.
Nach der Eingabe des Quelltextes in die zugehörige Frontend Maske wird dieser per RPC an die Server-Instanz zur Überprüfung geschickt. Dafür muss der Quelltext in Abhängigkeit der verwendeten Programmiersprache zunächst kompiliert werden. Etwaige Compiler-Fehler werden dabei als Feedback im Frontend angezeigt. Anschließend wird die Korrektheit mittels bereitgestellter Unit-Tests überprüft. Zurzeit wird lediglich zwischen Korrekt und nicht Korrekt unterschieden, eine feinere Bewertung kann daher nicht angebracht werden. Jedoch ist es vorgesehen, das der Student ein detailliertes Feedback erhält, welcher Testfall nicht erfüllt wurde und warum er nicht erfüllt wurde. Somit hat der Student Gelegenheit seine Lösung zu korrigieren und erneut zu übermitteln. Die jeweils aktuellste Fassung des übermittelten Quelltextes wird neben weiteren Statistiken in der lokalen Datenbank hinterlegt.
Je nach Aufgabentyp hat sich dabei die Aufteilung in Modell Tests und Logik Tests bewährt. Modell Tests sind dabei über Java Reflections realisiert, wohingegen auf das JUnit Framework im Falle der Logik Tests zurückgegriffen wird.
Das Java Reflection-Modell (häufig als Introspektion bezeichnet) ermöglicht die Analyse und auch Modifikation von Klassen und Objekten, die sich zur Laufzeit im Speicher der Java Virtual Machine JVM befinden. Das Reflection-Modell erlaubt es Felder, Methoden und Konstruktoren von Klassen abzufragen, was sich dazu nutzen lässt die korrekte Umsetzung eines geforderten Modells zu überprüfen. Der häufigste Aufgabentyp im Rahmen der Programmierausbildung ist die Implementierung eines vorgegebenen Modells, welches i.d.R. als UML Klassendiagramm dargestellt oder als reiner Text beschrieben ist.
Die Überprüfung ob der eingereichte Code dem vorgegebenen Modell genügt soll am folgenden Beispiel gezeigt werden. Angenommen es soll folgendes Datenmodell umgesetzt werden: • • • •
Straßen und Schienenbahnen sind Verkehrswege Jeder Verkehrsweg besitzt einen Namen Eine Straße hat eine bestimmte Breite
Schienenbahnen sind „icetauglich“ oder nicht Um das implementierte Modell auf Korrektheit zu überprüfen, sind folgende Tests notwendig: 1. Es existiert eine Klasse Schienenbahn, Straße als auch Verkehrsweg 2. Die Klassen Schienenbahn und Straße erben von Verkehrsweg 3. Die Klasse Verkehrsweg besitzt ein Feld mit dem Bezeichner name vom Typ String 4. Die Klasse Straße besitzt ein Feld mit dem Bezeichner breite vom Type double oder float 5. Die Klasse Schienenbahn besitzt ein Feld mit dem Bezeichner icetauglich vom Typ boolean Überprüfung (1) ist hinfällig, da alle Klassen immer als Code-Stub vorgegeben werden müssen. Um die Vererbungsbedingung (2) zu überprüfen muss zunächst auf die generische Reflections Klasse Class<?> zugegriffen werden, dies wird über einen statischen Zugriff auf das Feld class der entsprechende Klasse realisiert. Anschließend kann über die Methode getSuperclass die Elternklasse und damit die geforderte Vererbung überprüft werden. Listing 1 zeigt die zugehörige Implementierung. Neben der Vererbungshierarchie können alle relevanten Modellparameter auf diese Weise überprüft werden. Beispielsweise lässt sich mit getDeclaredField auf die Felder einer Klasse über dessen Name zugreifen. Existiert kein Feld mit dem gegebenen Namen wird eine entsprechende Exception geworfen. Abschließend lässt sich der Typ des gefundenen Feldes ebenfalls mit getType überprüfen. Listing 2 zeigt dies am Beispiel der Bedingung (3), wobei Bedingungen (4) und (5) analog zu überprüfen sind.
boolean ex = false; Class<Verkehrsweg> cl = Verkehrsweg.class; try {
Field f = cl.getDeclaredField("name"); assertTrue("Das Feld Verkehrsweg.name muss vom Typ String sein!",
f.getType().equals(String.class)); } catch (NoSuchFieldException e) {
ex = true; } assertFalse("Die Klasse Verkehrsweg muss ein Feld \"name\" besitzen!", ex);
Da das gezeigte System eine Authentifizierung voraussetzt, gilt es die Übertragung der eingegebenen Zugangsdaten entsprechend zu sichern. Grundsätzlich sollte hier auf eine SSL Verschlüsselung via HTTPS zurückgegriffen werden. Ist dies aus technischen Gründen nicht möglich, unterstützt das System auch eine eigene Verschlüsselung der Nutzerdaten. Diese basiert jedoch lediglich auf dem symmetrischen Verschlüsselungsverfahren „Triple-DES“. Da symmetrische Verfahren als leicht Angreifbar gelten sollte diese Variante nur im Ausnahmefall genutzt werden.
Da die Bewertung der Programmierübung darauf beruht den studentischen Quelltext serverseitig zu kompilieren, als auch auszuführen ist eine Sicherung des Servers vor böswilligem oder schlicht falschem Code unerlässlich. Je nach Programmiersprache kommen hier unterschiedliche Konzepte zum Einsatz. Grundsätzlich gilt zunächst, dass eine Codeüberprüfung nur als gültiger Benutzer möglich ist.
Allgemein stellt ein Sandbox-Ansatz, wie er auch in vielen existierenden Systemen wie [
Als weiteres Merkmal lässt sich die maximale Ausführungsdauer des Testcodes limitieren. So werden versehentliche oder absichtliche Endlosschleifen verhindert. Darüber hinaus führt jede Exception im Testablauf zu einem Automatischem Abbruch des Tests und einem entsprechenden Feedback an den einreichenden Nutzer.
Im Falle der ebenfalls vom System unterstützten Programmiersprache Python kann der beschriebene
Sandbox-Ansatz nur beschränkt verwendet werden. Hierbei wird der übermittelte Quelltext auf
potentiell Gefährliche Fragmente hin überprüft und entsprechend bereinigt. Konkret werden dabei
sämtliche Import Anweisungen verworfen und nur die für die Lösung der Aufgabe relevanten Imports
wieder hinzugefügt. Darüber hinaus werden sämtliche Anweisungen, die einen Dateisystem- oder
Socketzugriff realisieren herausgefiltert. Die Analyse des Python-Quelltextes basiert dabei auf
Regulären Ausdrücken, ähnlich wie in [
Es wurde ein System zur automatischen Überprüfung von Programmieraufgaben vorgestellt. Realisiert wurde es als Web-basierte Client-Server-Anwendung mit dem Framework Google Web Toolkit. Das System ist über eine SOAP Schnittstelle an den Stud.IP Service angebunden und nutz dessen Nutzerverwaltung, sowie die Kurs- und Teilnehmerinformationen. Darüber hinaus wurde auf die Modellüberprüfung mittels Java Reflections eingegangen. Abschließend wurden genutzte Sicherheitsmechanismen wie Sandboxing, Quelltextanalyse via Regulären Ausdrücken und Verschlüsselung beschrieben.
Das gezeigte System wird bereits im Lehrbetrieb eingesetzt, nichtsdestotrotz unterliegt es einer konstanten Weiterentwicklung. Geplant sind beispielsweise die Integration weiterer OpenID Anbieter zur Nutzerauthentifizierung. Darüber hinaus wird zurzeit untersucht inwiefern das System oder Teile davon auf Cloudservices wie Googles AppEngine oder Amazons AWS migriert werden kann um eine bessere Skalierbarkeit zu gewährleisten. Die Einführung einer Bewertungsskala über richtig und falsch hinaus wird ebenfalls geprüft. [Online].