Benutzer:Cspannagel/forschungsprofil/dagstuhl2009

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

• DrScheme
• BlueJ
• Java-Hamster-Modell

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