Lehr- Lernprozesse im Informatik-Anfangsunterricht

Interpretation der Ergebnisse
keit von Story-Pattern aus einem Aktivitätsdiagramm in ein anderes hätte hier sehr hilfreich
sein können.
Abbildung 95 Aktivitätsdiagramm der Methode auswerten aus dem Memoryprojekt einer Schülergruppe.
Hier wird geprüft, wie viele Karten ausgewählt sind, bei zweien wird auf Gleichheit geprüft, es wird der
Punktestand und der aktive Spieler gesetzt, geprüft ob noch Karten vorhanden sind, ggf. das Spiel beendet und
jeweils die grafische Oberfläche verändert und aktualisiert.
In diesem Zusammenhang ist eine von Reinsch (2003) wiedergegebene Kritik an den Aktivitätsdiagrammen
bemerkenswert: Diese würden das Programmieren unstrukturierter Sprünge
erlauben und so das Ziel des Informatikunterrichts 'strukturiertes Denken' zu vermitteln, konterkarieren.
Diese Kritik deutet meiner Meinung auf zwei Dinge hin: Einerseits braucht man
ggf. ähnlich wie in textuellen Programmiersprachen Style Guides für die Struktur von Aktivitätsdiagrammen.
Andererseits ist vermutlich die Idee dynamischer Objektstrukturen wenig im
Bewusstsein der Lehrenden verankert; jedenfalls deutet der Vorschlag, Aktivitätsdiagramme
durch Struktogramme zu ersetzen, auf eine imperative Sichtweise hin, in der die Idee der Beschreibung
und Veränderung von Objektstrukturen gerade keine zentrale Rolle spielt, obwohl
sie nach den Ergebnissen dieser Studie vermutlich eine der wesentlichen Bedingungen für den
Lernerfolg darstellt.
Interessanterweise gibt es in Bezug auf Flussdiagramme eine Reihe negativer empirischer Befunde
über deren höhere Lernwirksamkeit gegenüber textuellen Darstellungen;
Aktivitätsdiagramme können als eine Art von Flussdiagrammen gelten. So berichten Shneiderman
u. a. (1977) über eine Serie einzelner Studien mit Studierenden, zum Teil in
Anfängerkursen:
„Although our original intention was to ascertain under which conditions detailed flowcharts were
most helpful, our repeated negative results have led us to a more skeptical opinion of the utility of
detailed flowcharts under modern programming conditions. We repeatedly selected problems and
tried to create test conditions which would favor the flowchart groups, but found no statistically
significant differences between the flowchart and nonflowchart groups. In some cases the mean
scores for the nonflowchart groups even surpassed the means for the flowchart groups. We conjecture
that detailed flowcharts are merely a redundant presentation of the information contained
in the programming language statements. The flowcharts may even be at a disadvantage because
they are not as complete (omitting declarations, statement labels, and input/output formats) and re-
182