Projektseite: OOPM

Thomas Mandl

Materialien zur Ars Docendi Einreichung 2026

Kurzzusammenfassung Appindex übungsaufgaben beispielhaftes code-review beurteilung

Kurzzusammenfassung

Die Einreichung präsentiert ein innovatives Lehrkonzept für eine Programmier-Einführungslehrveranstaltung, das die Leistungsüberprüfung im Zeitalter generativer KI überdenkt. Angesichts hoher Durchfallquoten und der Problematik asynchroner Abgaben wurde die Lehrveranstaltung von einer rein produktorientierten Bewertung auf eine prozessbegleitende, diskursive Beurteilung umgestellt.

Kern des Konzepts ist die Ableitung von kleinteiligen, sogenannten Micro-Lernergebnissen und deren Überprüfung in synchronen Code-Reviews: Studierende präsentieren vorbereitete Lösungen (bei deren Erstellung KI-Tools explizit erlaubt sind), müssen diese jedoch live adaptieren und erweitern, um so ihre Umsetzungskompetenz zu demonstrieren. Ausschließlich die im Code-Review nachgewiesene Transferleistung wird bewertet.

Dieser Ansatz gewährleistet die Authentizität der Eigenleistung, da Kompetenzen unmittelbar verifiziert werden. Zugleich fördert das Modell durch „Must-Have“-Kriterien und individuelle „Score Cards“ ein kontinuierliches Lernen sowie die studentische Eigenverantwortung. Der Austausch im Rahmen der Code-Reviews ermöglicht zudem ein präzises Feedforward für individuelle Lernpfade. Das Konzept von kleinteiligen Lernergebnissen, die in synchronen fachlichen Dialogen überprüft werden, kann ein taugliches Format sein, um in Zeiten generativer KI ein kontinuierliches Lernen entlang individueller Lernpfade mit mehr Eigenverantwortung für den Lernprozess zu fördern.

Appendix

Micro-Lernergebnisse

In einem ersten Schritt wurden aus den Lernergebnissen (LEOs) der Lehrveranstaltung 60 kleinere Micro-Lernergebnisse (MLEOs) abgeleitet.

Eine detaillierte Tabelle mit Modulcodes, Beschreibungen, Beziehungen zu anderen Modulen und der Angabe, ob sie mehrfach vergeben werden, mit Zeilen und Spalten, die mit Text, Kontrollkästchen und hervorgehobenen Überschriften gefüllt sind.

Abb. 1: Tabellarische Darstellung aller Micro-Lernergebnisse (MLEO) inkl. Beschreibung und Zuordnung zu den Lernergebnissen (LEO). “Must-Have” MLEOs sind mit einem Diamanten (◇) markiert. Dieses Dokument steht den Studierenden zur Vorbereitung zur Verfügung.

Ein lilafarbenes, abgerundetes Rechteck mit der Beschriftung 00_02 STRING_REPRESENTATION und der Text erzeugen eine String-Darstellung eines Objekts mit einer Methode.

Abb. 2: Graphische Darstellung eines einzelnen MLEOs mit Identifikation (hier: 00_02), Kurzname (hier: STRING_REPRESENTATION) und Beschreibung (hier: “create a String representation of an object with a method”). Die starke Umrandung zeigt an, dass es sich um ein “Must-Have” handelt. Die Zahl 1 (ohne Klammern) gibt die zugehörige Kurswoche bzw. Lektion an. Der Wert in eckigen Klammern gibt Auskunft über Abhängigkeiten (Erläuterung siehe nächste Abbildung).

Flussdiagramm der Konstruktoren in der Programmierung: DEEP_COPY führt zu SHALLOW_COPY und CONSTRUCTOR_CALL; CONSTRUCTOR_CALL führt zu CUSTOM_CONSTRUCTOR und STANDARD_CONSTRUCTOR. Zwei blaue Felder: CONVERSION_CONSTRUCTOR und SUPERCONSTRUCTOR.

Abb. 3: Ausschnitt der MLEO-Landkarte. Die Knoten (Rechtecke) repräsentieren MLEOs, die Farbe kodiert die Zuordnung zu LEOs. Die gerichteten Kanten (Pfeile) stellen die Abhängigkeitsbeziehung dar. In Pfeilrichtung wird die Relation zwischen zwei MLEOs als “benötigt” oder “umschließt” gelesen, also z.B. “MLEO CUSTOM_CONSTRUCTOR umschließt MLEO STANDARD_CONSTRUCTOR”. Praktisch bedeutet dies: wenn das MLEO CUSTOM_CONSTRUCTOR im Rahmen eines Code-Reviews mit zumindest “partially reached” bewertet wurde, wird das umschlossene MLEO STANDARD_CONSTRUCTOR ebenfalls mit “partially reached” bewertet. Die Relation ist transitiv, das bedeutet, dass sie auf weitere MLEOs übertragen wird. Wird beispielsweise das MLEO DEEP_COPY mit zumindest “partially reached” bewertet werden alle durch Pfeile erreichbare, also umschlossene MLEOS (SHALLOW_COPY, CONSTRUCTOR_CALL, CUSTOM_CONSTRUCTOR, STANDARD_CONSTRUCTOR) mit “partially reached” bewertet. Die Zahl in eckigen Klammern in der rechten oberen Ecke der Rechtecke gibt an wie viele MLEOs mit Erreichen dieses MLEOs insgesamt bewertet werden. Ein Asterisk (*) kennzeichnet Must-Haves, die nicht über Abhängigkeiten erreicht werden können. Dies ist für Studierende als Hilfestellung für die Vorbereitung auf Code-Reviews gedacht.

Flussdiagramm mit mehreren farbcodierten Kästchen und Pfeilen, die die Schritte zur Behandlung von Typ-2-Diabetes beschreiben. Enthält Entscheidungen zu Medikamenten, Blutzuckerzielen, Begleiterkrankungen und Behandlungsanpassungen für eine individuelle Betreuung.

Abb. 4: Vollständige MLEO-Landkarte. Dieses Dokument gibt einen Überblick über Inhalte und inhaltliche Struktur der LV und kann zur Ermittlung eines individuellen Lernpfades sowie zur Vorbereitung auf Code-Reviews dienen. Es steht den Studierenden zur Verfügung.

Übungsaufgben

Die Übungsaufgaben sind aufbauend und in Phasen (jeweils eine Woche) und Levels unterteilt. In jeder Phase gibt es drei Level. In Level 1 ist die Angabe detailliert spezifiziert. So werden Schnittstelle, Verhalten, Fehlerbehandlung meist auf Methodenebene vollständig beschrieben und vorgegeben. Dadurch werden Programmier-Techniken geübt.
In Levels 2 und 3 werden die Angaben immer offener formuliert. Dadurch sollen die Studierenden die erworbenen Programmiertechniken auf neue Problemstellungen eigenständig anwenden.

Die Angaben werden als Text über ein git-Repository zur Verfügung gestellt:

Screenshot eines VS-Code-Dateiexplorers, der die Projektstruktur von OOPMLAssignments zeigt, mit verschachtelten Ordnern für guides, james_app und workout, die jeweils mehrere Unterordner für Phasen und Ebenen enthalten.

Abb. 5: Die Abbildung illustriert die Strukturierung des Beispiels “Workout” in Phasen und Level.

Screenshot der Java-Klassendokumentation für Person mit Abschnitten für Felder, Konstruktoren und Methoden. Die Felder umfassen Name, Gewicht und Größe. Methoden ermöglichen das Abrufen/Einstellen dieser Werte und die Berechnung des BMI.

Screenshot der Dokumentation für die Java-Methode setWeight. Sie setzt das Gewicht einer Person in Kilogramm, verlangt, dass der Wert größer als 0 ist, und gibt andernfalls einen Fehler aus. Der Parameter weight wird beschrieben.

Abb. 6: Ausschnitt einer detaillierten Level-1 Angabe als Javadoc. Das Klassendesign ist vorgegeben (oben), in der Spezifikation auf Methodenebene (unten) wird deutlich beschrieben, wie eine Aufgabe gelöst werden soll.

Ein UML-Klassendiagramm für StrengtheningExercise, das dessen Attribute, Methoden, Vererbung von Exercise und Komposition mit ExerciseVolume zeigt. Die Klassen Exercise und ExerciseVolume mit ihren eigenen Feldern und Methoden werden ebenfalls detailliert dargestellt.

Screenshot der Dokumentationsabschnitte, in denen der Erstellungs- und Kopiervorgang für die Klassen StrengtheningExercise und AerobicExercise beschrieben wird, mit Angabe der Eingabewerte, Konstruktoren und resultierenden Objekteigenschaften.

Abb. 7: Ausschnitt einer Level-2 Angabe. In Form eines Klassendiagramms (oben) werden nur mehr bestimmte Teile der Lösung vorgegeben. Die zusätzliche textuelle Beschreibung (unten) erläutert nur noch, was die einzelnen Code-Teile tun sollen, nicht mehr wie.

Ein Screenshot der Softwareanforderungen für ein System zur Verfolgung von Übungen, mit detaillierten Angaben zu den Funktionen zum Festlegen von Übungsnamen, Dauer und Entfernung, zum Anzeigen von Übungsdetails und zur Erwähnung eines Klassendiagramms für AerobicExercise und Person.

Abb. 8: Ausschnitt einer Level-3 Angabe. Es werden lediglich Anforderungen genannt, die beschreiben, was die Lösung leisten soll. Die Art der Umsetzung ist frei.

Beispielhaftes Code-Review

Zunächst präsentieren die Studierenden ihre Level-1 Lösung. Darauf aufbauend werden zusätzliche Aufgaben gestellt:

Aufgabe: Customer sollen verwaltet werden. Customer müssen beim Registrieren, Namen, Adresse und Telefonnummer angeben. Wähle passende Datentypen.

Im Gespräch: Wieso hast du diese Datentypen gewählt? Weshalb hast du diese Zugriffrechte gewählt? Welche Fehlerfälle hast du berücksichtigt? Wie würdest du testen? Skizziere Tester-Code!

Aufgabe: Customer werden beim Registrieren mit einer ID versehen, diese ist aufsteigend und einzigartig.

Im Gespräch: Was bedeutet static? Wie kann die ID unveränderbar erstellt werden? Welche Code-Teile haben Zugriff? Was passiert nach Programmneustart?

Aufgabe: Führe eine neue Klasse ein, um die Klassen Trainer und Customer zu vereinfachen.

Im Gespräch: Was bedeutet abstract? Wieso bietet es sich in diesem Beispiel an? Was sind die Vor- und Nachteile? Auf welche Teile der Basisklasse haben die abgeleiteten Klassen Zugriff? Wie kann im Code auf Elemente der Basisklasse zugegriffen werden?

Aufgabe: Trainer können viele Todos haben und ein Todo kann mehreren Trainern zugeordnet sein, bilde diese Logik im Klassendiagramm und im Code ab.

Im Gespräch: Wie nennt sich diese Verbindung? Was muss man hier insbesondere beachten? Mit welchen Datenstrukturen hast du das umgesetzt?

Eine zweiseitige Scorecard mit Tabellen, die verschiedene Kodierungskonzepte auflisten, jeweils mit Spalten für ID, MLO, Nutzen und Status. Auf beiden Seiten befinden sich neben jedem Thema leere Felder für Notizen oder Bewertungen.

Abb. 9: Score Card für Code-Reviews. Studierende können ihren Lernfortschritt MLEO darstellen und eintragen, welche MLEOs sie im kommenden Code-Review unter Beweis stellen können. Wenn gewünscht, können Lektor:innen MLEOs zusätzlich auf der Score Card bestätigen.

Beurteilung

Die Bewertung pro MLEO erfolgt auf der 3-teiligen Skala
(not reached | partially reached | reached ). Diese wird im Kurs definiert:

Screenshot der Bewertungsskala für MLEOs mit drei Stufen: nicht erreicht, teilweise erreicht und erreicht, die jeweils die Fähigkeit beschreiben, Aufgaben mit unterschiedlicher Qualität und Effizienz durchzuführen und zu erklären.

Die Beurteilungskriterien für die Hauptartefakte (Code, Diagramme) werden ebenso definiert:

Eine Liste mit dem Titel Bewertungskriterien enthält Punkte wie die Fähigkeit, Lösungen zu erklären und zu erweitern, die Korrektheit und Vollständigkeit von Diagrammen, die Kompilierbarkeit, die Erfüllung von Anforderungen, die Korrektheit von Rand- und Eckfällen und den Codestil.

Die Berechnung der Gesamtnote auf der 5-teiligen Schulnotenskala:

Screenshot einer Benotungstabelle, die zeigt, wie die Punkte den Noten entsprechen. Die Punkte 0-60 entsprechen der Note 5, 61-79 entsprechen der Note 4, 81-90 entsprechen der Note 3 und 91-100 entsprechen der Note 1. Der Text erklärt die Anforderungen an die Codeüberprüfung und die Aufgabenstellung.

“Current assignment” bezieht sich in der Praxis auf das vorbereitete MLEO.

Beurteilungsansicht Studierende

Im Moodle-Kurs sehen Studierende den aktuellen Beurteilungsstand nach LEOs gruppiert auf MLEO-Ebene:

Ein Dashboard, das den Fortschritt in objektorientierten Programmierthemen anzeigt, mit erweiterbaren Abschnitten für Klassen, Vererbung und Schnittstellen. Statusindikatoren zeigen Aufgaben als nicht erreicht, teilweise erreicht oder erreicht an, mit numerischen Punktzahlen und Symbolen.

Abb. 10: In obiger Abbildung fehlt in LEO_02 ein “Must-Have” MLEO (EXTEND_CLASSES), weswegen das übergeordnete LEO_02 mit 0% bewertet wird.

Eine Fortschrittstabelle für 'LEO_00_BASIC_CLASSES' zeigt Aufgaben mit dem Status teilweise erreicht oder nicht erreicht. Für jede Aufgabe wird eine Punktzahl angegeben, mit einer Gesamtpunktzahl von 5,5/10. Die Überschriften sind auf Deutsch.

Abb. 11: In diesem Beispiel sind alle MLEOs zumindest mit “partially reached” bewertet.