The Intro Programming Course

Workshop in Dagstuhl vom 5.-9.4.2009

Wiki der Veranstaltung

Im Folgenden handelt es sich um meinen persönlichen Mitschrieb. (minimal ergänzt von mir - uschroeder)

Vorträge

Börstler: Objektorientiertes Programmieren - Machen wir irgendwas falsch?

positive Indikatoren für Lernerfolg
- mind. 2 Programmierkurse in der Oberstufe
- Einführung von CRC/RPD (role play diagrams)
Wir brauchen systematischere Untersuchungen
- Action Research?
McCracken et al. (2001)
- Hauptproblem: Übersetzung Aufgabenbeschreibung -> Programmier-Problem
Lister et al. (2004)
- Problem: Verfolgen von Code
Dehnadi/Bornat (2006); Ma et al (2007)
- Frühes Verstehen der Semantik der Zuweisung korreliert mit Erfolg
Objektorientierung
- modelliert nicht einfach die Realität
Wir schaden zwei Zielgruppen
- denjenigen, die mit Kenntnissen kommen (böses Erwachen in der Klausur)
- denjenigen, die ohne Kenntnisse kommen (hängen ab)

Felleisen: Systematic Program Design (for Freshmen)

In einem Einführungskurs muss man folgende Sachen machen
- Programming: how do I create programs?
- Computing: how do programs compute?
- Systematic design (problem solving)
- Functional programming (middle-school algebra)
Pair programming
- Artikulation des eigenen Denken notwendig; Fehler werden relativ schnell aufgespürt
Structural design
- Studenten müssen folgende Schritte zwangsläufig abarbeiten: data def, purpose, examples, template, erst jetzt code, dann test
  - erinnert mich an "Teaching Thinking"
Wichtige Elemente
- Design Principles
- Series of Programming Languages (Anfängersprache mit Fehlermeldungen für Anfänger)
- Ped. IDEs

Spannagel: Didaktisch-methodische Designentscheidungen auf dem Prüfstand

Wiki zu meinem eigenen Vortrag

Konsensrunde

Erste Sammlung von Ideen:

konsensfähig

Betreutes Programmieren ist wichtig.
1. Jahr verdient die höchste Investition (Wunschdenken).
Jeder weiß wie's besser geht.
Die Inf-1-Lehre ist eine intellektuelle Herausforderung ("der schwierigste Kurs im Curriculum").
Es gibt keine einheitlichen Lehrziele
Erstes Jahr soll Studenten eine Auswahlhilfe sein, ob sie Informatik weiterstudieren wollen oder nicht.
Studierende müssen selbst "Interpreter" spielen können (Code ohne Computer interpretieren können).
Designprozess für Programmierung.

nicht ganz konsensfähig

Die Mehrheit der Kollegen empfindet aber Info 1 leider als lästige Pflicht.
Im 1. Jahr mindestens 2 Programmiersprachen.
Rekursion und induktive Datenstrukturen gehören Anfängervorlesungen.

Workshop-Themen

Priorisiert

Was ist Objektorientierung?
Prüfen
Sammlung und Erfahrungen zu bestimmten didaktischen Methoden
Wie sieht der Designprozess für Programmierung

Zurück gestellt

Austausch von Best Practice in der Community
Wie sieht das "Rechenmodell" für Programmierung aus?
Reduktion: Breite vs. Tiefe
Welche Inhalte/Curriculum für 2-stündige LV (V2+Ü2)

Brainstorming-Punkte für Methoden-Sitzung

"Risiken und Sammlung Effekte didaktischer Methoden"
pair programming
- Wie kann man verhindern, dass einer die Arbeit macht und der andere zusieht?
gute Betreuung bei Präsenzübungen
Sammlung von Best Practices / Schlaglichtern
Frontalunterricht und Programmieren lehren
Wie wird aktive Mitarbeit der Studierenden gefördert?
Umgehen mit Abschreiben
Systematic pedagogic interventions
Sinn/Unsinn "Vorprogrammieren"
Rolle "Beob. Stud." bei Problemlösung
pedagogical design patterns

Methodische Überlegungen: Unser Brainstorming

Bild: Grobstruktur

Ziele

Handlungskompetenz
- Problemlösekompetenz mit informatischen Mitteln
- Fachwissen kennen und anwenden können
- realistische Selbsteinschätzung
- Selbstkonzept fördern (Lernende sollen Zutrauen gewinnen)
- Kooperieren
  - Sozialkompetenz
  - Teamfähigkeit?
- Kommunizieren: Fachsprache anwenden
- Präsentieren / Erklären / Erläutern von Lösungen
- Selbstreflexion
- Inhaltliche Ziele (wird nicht hier diskutiert)
Lernen aus Fehlern
- Lauffähige Programme erzeugen

Grundsätzliches / didaktische Entscheidungen

Reduzierter Sprachumfang
- Echte Programmiersprache?
- Lauffähige Programmiersprache, aber reduziert?
- Pseudocode?
Lern-IDE verwenden? (Hamster?)
Programmieren: Systematisches Vorgehen oder kreativer Prozess?
Eine oder mehrere Sprachen aus verschiedenen Paradigmen?
virtuelle Begleitumgebungen
Nutzung externer Quellen?
Umgang mit Heterogenität / Differenzierung

Vorlesung: Methoden

Vorprogrammieren
- Cognitive Apprenticeship Model
Laptops verbieten oder nicht?
Folien oder Tafelanschrieb?
Welches Material stellt man zur Verfügung?
Wann sollte man vollständigen Code zeigen, wann Code-Schnipsel?
Programmieren lernen durch Frontalunterricht?
- Alternativen für die Vorlesung

Programmierübungen: Methoden

Pair Programming
Kooperative Gruppenarbeit
- Rollen oder nicht?
- Gruppenzusammensetzung
  - Wechsel der Gruppenzusammensetzung
Projekt
Präsenzübung ("Arbeiten in der Übungsstunde") / betreutes Programmieren vs. "Vorrechnen"
Abgabeform und Korrektur
- Plagiatvermeidung
Feedback und Hilfe
- Fehler zulassen oder vorbeugen?
  - "Fehler als Lernchance begreifen"
- Wie gibt man Feedback und Hilfe?
- Wann Hilfe?
Imitieren / Manipulieren von Code?
- Umgang mit fremdem Code?
Korrektur des Codes durch Peer Review?
Musterlösungen ja oder nein?
Tutorenschulungen
Bonus-/Sternchenaufgaben

Verbindung Vorlesung und Übungen

...

Pattern

Name: Pair Programming
Beschreibung
Ziele: Studenten sollen...
Beispiel/Umsetzung
Risiken, Indikatoren und Problemlösungen
Weitere Stellschrauben
Theoretischer Hintergrund
Vorwissen der Studierenden
Rahmenbedingungen
Alternativen / verwandte Methoden

Pattern: Pair Programming für Anfängerübungen

Ergebnis als Bild

Name: Pair Programming
Beschreibung
- Zwei Studierende arbeiten an einem Rechner und erstellen Programme
- Einer tut, einer berät
- Ständiger Rollenwechsel
Ziele: Studenten sollen...
- aktiv gemeinsam Probleme lösen
- (fachlich) kommunizieren
- verschiedene Lösungsansätze/Herangehensweisen kennen und diskutieren lernen
- argumentieren und begründen
- "Interpreter" spielen können (insb. Berater)
- Außerdem: Studenten bekommen Kontakt zu Kommilitonen
Beispiel/Umsetzung
Risiken und Probleme
- Risiken und Problemlösungen / Stellschrauben
  - Einer tippt, der andere schläft
  - Berater-Dominanz
  - Die beiden Personen "passen" nicht zusammen
    - Wechsel der Paare?
  - beide haben "keine Ahnung"
    - Heterogene Paare?

- Indikatoren und Problemlösungen / Stellschrauben
  - Indikatoren +:
  - Indikatoren -:
    - Kein Fortschritt
    - Streit
    - Inaktivität während der Übungsstunde (der gute macht's dann zu Hause fertig)
      - Wann müssen die Arbeiten abgegeben werden?
    - Berater greift ein
    - nur einer redet oder keiner redet (weil der Programmierer alles macht)
      - Tutor stellt einer Person gezielt eine Frage, und diese Person muss antworten (der andere darf nicht)
- Weitere Stellschrauben:
  - Nach welcher Zeit wird gewechselt?
  - Gebe ich überhaupt eine Zeitspanne vor?
  - Stabile oder wechselnde Paare? Über welchen Zeitraum bleiben sie stabil?
Theoretischer Hintergrund
- Extreme Programming
  - Unterschied zu hier: In XP arbeiten keine Anfänger zusammen, sondern Experten
- Es findet automatisch immer ein Code-Review statt
- learning through teaching
Vorwissen der Studierenden
- Einführung und Begründung der Methode notwendig
Alternativen / verwandte Methoden
- Einzelarbeit
- Gruppenarbeit
- Vorrechnen

Anregungen

Rahmenbedingungen / organisatorische Bedingungen aufnehmen
Prüfungen/Assessment mit aufnehmen
- Andere Meinung: Das ist eine andere Ebene (liegt quer), weil mit verschiedenen Methoden dieselben Ziele verfolgt werden können
Überschneidungen mit anderen AGs klären
Referenzbeispiele fehlen noch: Es sollten Personen "Farbe bekennen" und Berichte und Beobachtungen zu bestimmten didaktischen Vorgehensweisen beschreiben ("Man kann mich fragen").

Best Practices / Worst Practices von Teilnehmern

Kontinuierliche Prüfung (z.B. durch Quizzes)
"social culture" in der Vorlesung
"Test Fest" / competitive testing; Studierende entwickeln Tests für einander und testen jeweils die Programme der anderen; mit Punkten und Punktabzug
Wettbewerbe
CRC-Karten und Rollenspiele
- Achtung: Gefahr der Verwechslung von Klassen und Objekten; CRC-Karten nur für Klassen nehmen! Objekte als Post-Its o.ä.
eTests und korrigierte Hausaufgaben, gezieltes informatives Feedback

AG Object Orientation

ACM/IEEE CS Curriculum (v2008) als Grundlage
- Kritikpunkte:
  - Punkte auf unterschiedlichem Abstraktionsniveau
  - Object-oriented design nicht definiert
  - Rekursion nicht erwähnt - unwichtig?
  - Typ wichtiger als Klasse
  - OO ungleich Java ("overloading vs overriding")
  - High-level Konzept / low-level Erklärung
OO Konzepte
- Abstrakter Datentyp
- Subtyppolymorphie (Interface)
- Kollaborationsgedanke (von Objekten)
  - Protokoll statt Algorithmus
- Vererbung (Klassenhierarchie)
Probleme / Fragen / Aspekte
- Gute Beispiel für OO?
- OO muss nicht an einer PS festgemacht werden
- Natürlich Modellierung durch Objekte?
  - aber nicht in der Natur
  - eher: künstliche virtuelle Entitäten
- Vorgehensweise: Top-Down oder Bottom-up?

AG Prüfungen

Übungen / eTests
- eher als Self-Assessment, um Lernen in den Mittelpunkt zu stellen und Plagiate zu verhindern?
Prüfungen müssen selbst auch evaluiert werden.
- Sind sie zweckmäßig? fair?
- Verschränkung Bloomsche Lernzieltaxonomie / Inhalte

AG Designprozess

Design Rezepte:
- Vorteil, weil Studierende wissen, wie sie an ein Problem herangehen
- Nachteil für Studierende, die kreativ eigene Programme entwickeln wollen
- "Erst durch die Hölle gehen"
Das Lehren eines Designprozesses benötigt eine einfache Sprache
- wirklich so?
Was ist wichtiger: Datenstrukturen oder Algorithmen?
- Meinung der AG: Datenstrukturen

Vorgestellte Programmierumgebungen

Lern-IDEs sind Lernumgebungen, keine professionellen Programmierumgebungen. Wenn die Lern-IDE ihren Nutzen erfüllt hat, dann kann man zu einer Programmierumgebung (z.B. Eclipse) übergehen.

Session: Design Process

OO mit CRC-Karten

Methode zur objektorientierten Analyse
- ist kein Designprozess
Substantive im Aufgabentext unterstreichen (potenzielle Klassen)
Class - Responsibilities - Collaboration
Problem: Verwirrung Klasse/Objekt; besser nur für Klassen verwenden

How to design classes

Prozess, der zu einem "deterministischen" Ergebnis führt
In der ersten Phase wird ein Datenmodell erstellt, und zwar durch ständiges Hin- und Herübersetzen zwischen Welt und Datenstrukturen.

Einige aufgeschnappte und/oder gemeinsam entwickelte Ideen

Ablenkung in der Vorlesung durch Laptops: Man müsste als Dozent mal das Verhalten vorne spiegeln, also z.B. auch ständig per IM von einem Kollegen angechattet werden, dann auf einen interessanten Link klicken (und dafür die Vorlesung unterbrechen).
Programmierprojekt: Jemand "spielt" Kunde und kommt zwei Wochen später mit neuen Anforderungen.
Zugelassene Hilfsmittel in Prüfungen:
- Handbeschriebenes Blatt ("cheat sheet" / Spickzettel):
  - Black-Out-Gefahr größer
  - Prüfungsfragen beziehen sich doch oft auf Aspekte, die der eine glücklicherweise auf seinem Blatt stehen hat, der andere nicht
  - Aber: Auswahl von Inhalten ist schon didaktisch sinnvoll in der Vorbereitung (Studierende werden sich klar darüber, was sie können und was noch nicht so gut usw.)
- "open book"/"Kofferklausuren":
  - Deutlicher, dass sich die Prüfungsfragen ändern müssen; zwingt einen dazu, Aufgaben auf "höheren" Ebenen der Bloomschen Taxonomie zu stellen
Bei Nebenfächler, die nur ein Semester studieren, sollte man keine teaching language verwenden, da sie nach diesem Semester auch in der Praxis eine Sprache verwenden können sollten. Wenn man mehr Zeit hat (mehrere Semester), ist zu überlegen, eine teaching language zu verwenden.
In den Anfangszeiten waren die Studenten besser, weil die Vorlesungen nicht perfekt waren.
- Wir müssen versuchen, Unsicherheiten zu erzeugen, damit diese Unsicherheiten gemeinsam gelöst werden können.
ACM/IEEE-Curricula werden von den Top-200-Forschungsuniversitäten nicht unterstützt/umgesetzt.
"The Camel has to humps"-Phänomen
- Probleme
  - zusammengesetzte Textaufgaben verstehen
  - nie das Lernen gelernt haben
  - niedrige Lernmotivation
  - Paper: Unskilled and unaware of it

Feedback-Phase am Ende des Workshops

Einige Anmerkungen:

Methodisches, systematisches Vorgehen ist wichtig
Effekte der eigenen Arbeit müssen noch mehr messbar gemacht werden

Meine eigenen Reflexionen:

Einsichten: Sehr viel gelernt über verschiedene Methoden in der Informatik-Hochschullehre (Pair Programming, Unterschiede in einzelnen Lehrveranstaltungen, ...) - sehr lehrreich; auch in der Vorbereitung auf meinen Vortrag hab ich viel gelernt (zuvor noch nicht so reflektiert damit auseinandergesetzt)
Konsequenzen: in Zukunft werde ich mich stärker damit auseinandersetzen
Wünsche: Kontuinierliche, gemeinsame Weiterarbeit; Es wäre schade, wenn das Wiki leer bleiben würde
Welche Vorschläge: wieder ein Workshop im nächsten Jahr