Zeitschriftenartikel
Leserbriefe
Vorschaubild nicht verfügbar
Volltext URI
Dokumententyp
Text/Journal Article
Zusatzinformation
Datum
2013
Autor:innen
Zeitschriftentitel
ISSN der Zeitschrift
Bandtitel
Quelle
Verlag
LOG IN Verlag GmbH
Zusammenfassung
Betr.: LOG IN Nr. 172/173, S. 101113 Von SCRATCH über BYOB nach JAVA Ein Unterrichtsbeispiel für Klassenstufe 10 Vielen Dank an die Autoren für diesen Artikel. Ich kann sie in dem Vorgehen nur bestärken, das objektorientierte Modellieren von der zusätzlichen Hürde des textbasierten Programmierens zu entlasten, die Modellierung durch eine visuelle Programmierumgebung zu unterstützen und damit zugleich den Einstieg in den Umgang mit klassischen Programmiersprachen zu erleichtern. Seit mehreren Jahren unterrichte ich selbst am Gymnasium in Bayern nach dem gleichen Konzept, allerdings mit wechselnden Programmiersprachen mehrfach PYTHON und SMALLTALK, im vergangenen Schuljahr auch einmal JAVA. Für die visuelle Programmierung setze ich sowohl SCRATCH als auch ETOYS ein und möchte von daher ein paar Dinge anmerken. Die Situation ist in Bayern insofern anders, als alle Schülerinnen und Schüler verpflichtend in Jahrgangsstufe 6 einen Einblick in das Konzept von Klassen und Objekten und in Jahrgangsstufe 7 die Grundzüge der Ablaufmodellierung vermittelt bekommen, ehe sich für sie in der 10. Klasse mit der objektorientierten Programmierung ein Kreis schließt. Wenn man sich nach den eingeführten Schulbüchern orientiert, sind die üblichen Werkzeuge Robot Karol für die Ablaufmodellierung in der 7. Klasse und JAVA mit BLUEJ in Klasse 10. Da Robot Karol weder die objektorientierten Konzepte aus Jahrgangsstufe 6 aufgreift noch projektorientiertes Arbeiten wie im Lehrplan vorgesehen oder offene Aufgabenstellungen und damit einhergehende Binnendifferenzierung ermöglicht, setze ich stattdessen seit jeher mit großer Zufriedenheit SCRATCH ein. Der Vorteil gegenüber ETOYS besteht an dieser Stelle in meinen Augen vor allem darin, dass die Oberfläche intuitiver zu bedienen ist, weil sämtliche Werkzeuge zu sehen sind, und die stärkere Beschränkung weniger unvorhergesehene Fehler zulässt. Der Nachteil, keine eigenen Operationen schreiben zu können bzw. sich hier mit Broadcast-Nachrichten behelfen zu müssen (was die Bausteine sende an alle und wenn ich empfange leisten), wird mit der kommenden Version 2.0 (http://beta.scratch .mit.edu/) entfallen, die das Erstellen eigener Blöcke wie in BYOB erlaubt. Bei der objektorientierten Modellierung in Jahrgangsstufe 10 ist SCRATCH meiner Meinung nach allerdings an wenigstens zwei zentralen Punkten eindeutig überfordert, die ETOYS aber bietet: Objektorientierung setzt auf der einen Seite auf Kapselung, auf der anderen Seite auf Beziehungen und damit auf Kommunikation zwischen Objekten: Nachrichten bzw. Methodenaufrufe werden versandt. Anders als in ETOYS sind in SCRATCH aber nur Broadcast-Nachrichten möglich; kein Objekt kann gezielt ein anderes individuell ansprechen. Auch lassen sich in SCRATCH keine Beziehungen zwischen Objekten umsetzen, weil SCRATCH keine objektwertigen Variablen oder Parameter kennt. Diese benötigt man aber z. B. schon bei einer einfachen Aggregation. ETOYS leistet das mit Variablen vom Typ Darsteller. Ein weiterer Vorzug von ETOYS besteht im Geschwister-Konzept, das eine Brücke vom prototypenbasierten Ansatz, dem SCRATCH und ETOYS an sich folgen, zum klassenbasierten Programmieren bildet, wie es die Schüler in der Folge lernen. Mit der Möglichkeit, in Skripten Klone von Figuren zu erzeugen, zieht SCRATCH in der Version 2.0 hier einen Schritt weit nach. Wenn man sich davon frei macht, die Schülerinnen und Schüler als erste Programmiersprache ausgerechnet mit JAVA zu konfrontieren, bietet ETOYS anders als SCRATCH zudem die Möglichkeit, auch das beiden zugrunde liegende SMALLTALK sichtbar zu machen und auch zu nutzen, was sich gerade bei komplexeren Projekten, wie sie sich in einer 10. Jahrgangsstufe entwickeln können, ganz organisch ergibt, weil sich manchmal Fragen anhand der sichtbaren Programmierblöcke (bzw. -kacheln, wie sie in ETOYS heißen) nicht eindeutig entscheiden lassen. Für das anschließende Programmieren in SMALLTALK wechselt man aber besser zu SQUEAK oder PHARO. Markus Schlager Gottsdorf