Lehr- Lernprozesse im Informatik-Anfangsunterricht

Fachdidaktische Ausgestaltung des Unterrichtskonzepts
ses eingesetzt (vgl. Jacobson, Booch und Rumbaugh 1999). Die grafische Notation erlaubt die
Betrachtung des objektorientierten Systems auf einer abstrakteren Ebene als dies in einer Programmiersprache
möglich wäre. Die UML ist eine grafische Sprache: „not only to
communicate with others but to provide a setting in which individual developers can think
and analyze. [...] Basically, the UML enables the developers to visualize their work products
in standardized blueprints or diagrams“ (Jacobson, Booch und Rumbaugh, 1999, S. 421). Visualisierung,
so die hier implizite Annahme, ist verständnisfördernd und hilft deshalb
Entwürfe zu kommunizieren – auch mit eher fachfremden Personen bzw. Anfängern. Dabei
reduziert Visualisierung die Fülle von Details und erlaubt einen schnelleren 'Überblick'.
Im Unterricht könnte die Visualisierung der UML ebenso die Kommunikation von Designideen,
aber etwa auch die Darstellung des Programms zur Laufzeit ermöglichen. Code generierende
Werkzeuge, die auf der UML aufbauen, können die Transformation der CRC-Karten
in die Implementation unterstützen.
CRC-Karte UML-Klassendiagramm
Name Klassenname
Verantwortlichkeiten, Responsibilities:
'Wissen' und
'Können'
Attribute
Methoden
Beteiligte, Collaborators Assoziation
Tabelle 13 Übergang vom CRC-Modell zum Klassendiagramm: In der linken Seite die Angaben auf einer CRC-
Karte, auf der rechten Seite die Angaben im Klassendiagramm.
Die beiden Notationen CRC und UML helfen, die Entwicklungsphasen zu unterscheiden:
CRC-Karten werden mit der Analysephase identifiziert, UML-Klassendiagramme mit der Designphase.
Anhand der Klassendiagramme soll dann die Modellierung, zumindest zum Zwecke ihrer
Überprüfung implementiert werden können. Welche Inhalte dazu nötig sind, hängt auch davon
ab, welche fachlichen Aspekte zum Verstehen einer Implementation notwendig
erscheinen. Diese Aspekte sollen nun geprüft werden. Dabei soll die Implementierung durch
die Verwendung eines Codegenerators teilweise automatisiert werden, sodass die Implementation
für die Schülerinnen und Schüler direkt als eine Formalisierung der Modellierung
verstehbar wird.
Broy und Siedersleben machen in diesem Zusammenhang auf folgendes Problem aufmerksam:
„Leider ist es außerordentlich schwierig, das beobachtbare Verhalten von Klassen und Objekten
zu beschreiben. Der Grund dafür sind die komplexen Interaktionen von Objekten über Methodenaufrufe,
die nichts anderes sind als normale Funktionsaufrufe, ergänzt um den Mechanismus der
späten Bindung. [..] Daher müssen Methodenaufrufe in objektorientierten Programmen als in einem
riesigen Zustandsraum – dem globalen Programmzustand – operierend angesehen werden.“
(Broy und Siedersleben 2002, S. 5)
Das Problem wird verschärft durch den Zugriff auf Objekte mittels Referenzen und mögliche
Seiteneffekte, wenn ein Objekt mehrfach referenziert wird (Broy und Siedersleben 2002, S.
6). Hinzu kommt die immer wieder anzutreffende Vermischung von Implementations- und
Ausführungsebene, beispielsweise auch im obigen Zitat („das beobachtbare Verhalten von
Klassen und Objekten“), die ein Verständnis für die Funktionsweise eines objektorientierten
Programms erschwert. Das didaktische Problem für den Anfangsunterricht besteht darin, dass
der Einblick in das Laufzeitverhalten objektorientierter Software durch Programmieren und
50