Lieber Rüdeger, ich interessiere mich sehr für Squeak und Fragen zur Didaktik der Lehre des Programmierens und hätte gerne eine solche Vorabkopie. Ich würde aber auch ein Exemplar des Buches kaufen. Viele Grüße Michael

"R. Baumann" baumann-garbsen@t-online.de writes:

Hallo Rüdeger,

Das Buch ist eigentlich nur als Versuch gedacht, um zur Diskussion zu stellen und zu erproben, was man mit Squeak in der Schule eventuell machen kann. Es sollte damit das Urteil der Expert(inn)en eingeholt werden. Squeakern und Squeakerinnen, die bereit sind, kritische Anmerkungen zu machen und einige Hinweise zu geben, kann ich gerne ein Vorabdrucks-Exemplar (kostenlos) übersenden.

Was mich mal interessieren würde ... Für welche Klassen/Altersstufe ist das Buch gedacht? Meine Schulzeit liegt gut 20 Jahre zurück. Die meisten Themen sind mir zwar irgendwo mal über den Weg gelaufen, aber ob das schon in der Schulzeit war, kann ich nicht mehr sagen. Andererseits war der Informatikunterricht zu dieser Zeit auch gerade erst im Aufbau.

Zum Schluss noch eine kritische Bemerkung von mir. :) Ich vermisse einen Index! Kann man den noch ergänzen?

Und wenn du noch ein paar Anekdoten über Mathematiker unterbringen kannst, wäre das auch toll. Wenn man Mozart als Rockstar verkaufen kann, dann auch Euklid :)

ciao Enno

ich würde liebend gern einen Blick auf den Vorabdruck werfen (gern auch digital).

Anbei die pdf-Datei.

Übrigens habe ich vor einigen Monaten vom "Amt für Lehrerbildung" (Hessen) Informatik mit Prolog von Gerhard Röhner bestellt. In dem Heft war im Zusammenhang mit Prolog dein Name gefallen, ich nehme an das Du derjenige bist.

Stimmt. Röhners Skript ist das beste, was es auf diesem Gebiet gibt.

Aber wenn Du derjenige aus diesen Verweisen bist, hätte ich den ...

Ich hatte mal ein kleines Prolog-Buch im Klett-Verlag geschrieben und einige Aufsätze in LOG IN.

Sag, was du brauchst.

Gruß Rü

Nachdem ich mir nicht sicher bin, ob das mit den Anhängen auf der Liste klappt, vorsichtshalber die mail noch einmal. Die erwähnten Anhänge sind auch hier im Netz zu finden:

- http://www.lsh-marquartstein.de/schule/unterricht/faecher/informatik/unterri... - https://www.lsh-marquartstein.de/schule/unterricht/faecher/informatik/unterr...

Markus

On Thu, 24 Mar 2011, Markus Schlager wrote:

Lieber Rüdeger Baumann,

On Mon, 28 Feb 2011, R. Baumann wrote:

Das Buch ist eigentlich nur als Versuch gedacht, um zur Diskussion zu stellen und zu erproben, was man mit Squeak in der Schule eventuell machen kann.

So nach und nach schmökere ich in dem Vordruckexemplar herum. Schöne Ideen! Sehr erfreulich ist aus meiner Warte vor allem auch, daß das Buch tatsächlich auf den Schulbetrieb abzielt und dort viele typische Inhalte abdeckt. So tauchen auch typische Beispiele zur Datenflussmodellierung und Zustandsübergangsdiagrammen auf. Schade, daß hierbei eine in meinen Augen ganz große Stärke der Etoys nicht zum Zuge kommt: die Verbinder.

Zur Zustandsmodellierung habe ich mir heute das Beispielprojekt für den Unterrichtseinsatz in der 10. Jahrgangsstufe im Anhang gebastelt. Was mich an den üblichen Umsetzungen bei diesem Thema stört, ist die Trennung von Modell und Implementierung:

Einerseits malt man irgendwo den endlichen Automaten, andererseits programmiert man dann anderswo irgendetwas, das das Denken in Zuständen implementieren soll. (Leider scheint noch keinem süddeutschen Didaktiker aufgegangen zu sein, daß hier UnitTests genau das passende wären - wie das in Squeak ganz elegant geht, sieht man wunderbar im LaserGame-Tutorial.) Alternativ gibt es dann noch so Spezialprogramme wie Charon zur formalen Spracherkennung oder Kara, um ähnlich eingeschränkte Probleme zu lösen wie mit Robot Karol.

Etoys bietet beides: Da läßt sich der Klassiker Verkehrsampel eben wirklich direkt mit einem daneben gezeichneten Zustandsübergangsdiagramm steuern! Auch läßt sich dieses Diagramm ganz nach Wunsch durch andere Ereignisse aller Art beeinflussen. Es läßt sich ein Getränkeautomat mit Knöpfen malen, bei dem die Knöpfe, wenn man sie anklickt, einen Übergang im Zustandsübergangsdiagramm auslösen, der dann eine Veränderung am Getränkeautomaten zur Folge hat - oder eine Drehorgel mit einer Zeichenkette als 'Lochstreifen' steuern. Damit macht der Rechner genau das, was die Schüler vom Denken her lernen und begreifen sollen. Einfach wird das dadurch, daß die Verbinder Quelle und Ziel kennen.

Ähnlich sieht es mit Datenflussdiagrammen aus. Wenn man Verbinder verwendet, können die ganz elegant Datenflüsse ausführen - egal welcher Art. Man kann klassisch rechnen, Strings verarbeiten oder auch Männchen Eimer voll Sand schaufeln lassen. Damit das dann leicht bedienbar wird und sich Teilergebnisse an beliebiger Stelle im Datenfluss mit nur einer Aktion (z.B. ein einziger Mausklick) abgreifen/erzeugen lassen, benötigt man nur die Fähigkeit 'sage allen Vorgängern', die sich bei verbundenen Objekten im Betrachter in der Kategorie 'Verbindungen zu mir findet'. So wie die Beispiele im Buchvordruck stehen, muß der Benutzer aber alle Teilschritte selbst in der richtigen Reihenfolge ausführen. Das erscheint mir eher ungünstig. Ich hänge auch dazu mein Projekt an, das ich in der 9. Jahrgangsstufe im Einsatz habe.

In München sollte meines Wissens die Entwicklung einer Software für solche Datenflußdiagramme schon einmal Thema einer fachdidaktischen Doktorarbeit sein. Ich weiß nicht, ob es je ein Ergebnis gab. Mit den Etoys läßt sich das recht einfach basteln.

Schöne Grüße

Markus

Lieber Rüdeger Baumann,

On Fri, 25 Mar 2011, R. Baumann wrote:

Markus schrieb: "Schade, daß hierbei eine in meinen Augen ganz große Stärke der Etoys nicht zum Zuge kommt: die Verbinder."

Den Vorteil der Verbinder habe ich immer noch nicht begriffen - außer dem rein geometrischen Effekt, dass die verbundenen Teile auch bei Verschieben aneinanderhängen.

Die Datenübertragung muss man doch nach wie vor explizit programmieren - oder ist das nicht nötig?

Jein - Datenübertragung ja, Nachrichtenübermittlung nein. Verbinder kennen Quelle und Ziel, mit denen sie verbunden sind, als Variablen; diese Variablen kann man auch in Skripten per Zuordnungskachel verändern, sodaß der Verbinder von Objekt zu Objekt springen kann. Objekte, die mit Verbindern verbunden sind, haben Kacheln, um den anhaftenden Verbindern bzw. den Objekten am anderen Ende des Verbinders Nachrichten zu schicken.

Die Text-Ellipsen und Text-Rechtecke sind m. E. umständlich zu handhaben. Einfacher geht's, glaube ich, mit gewöhnlichen Ellipsen und Text mit Rand.

Weiß ich nicht - Text-Ellipsen und Text-Rechtecke sind eben Ellipsen oder Rechtecke, in die sich einfach Text hineinschreiben läßt. Sie sind aber wohl nicht dazu gedacht, diesen Text per Skriptprogrammierung zu verändern. Da bettet man dann doch besser selber einen Textmorph in eine Form ein.

Aus der Paketdokumentation der Connectors (zu finden z.B. in Squeak im SqueakMap Package Loader - für squeak 4.2 scheint es eine überarbeitete Version zu geben):

---8X-------------------------- Description: Connectors is an application for making structured/connected drawings in Morphic. It adds a new kind of Morph (NCConnectorMorph) that can connect other Morphs together (and stay connected). There are also a number of other shapes, flaps, and tools for making your own drawings.

It comes with some sample shapes in flaps for making UML class diagram and state diagrams.

It's also a framework for making your own structured drawing editors. There is an easy to use API for querying drawing structure, constructing drawings, and more.

Categories: Applications - Applications written in Squeak intended for regular nonprogramming users ---X8--------------------------

Bezeichnend finde ich hier 'nonprogramming'.

Der Primärfokus lag also wohl darauf, ein Werkzeug zu haben, um Diagramme (etwa UML, endliche Automaten, Datenflüss) zu zeichnen. Beispiele dafür findet man in Etoys, wenn man in den Einstellungen (zu erreichen über das Menü - Alt+, - unter Hilfe) die Einstellung eToyFrienly deaktiviert und dann bei deutscher Lokalisierung im Objektkatalog alphabetisch 'k' auswählt. Da gibt es dann Klappen und Knopfleisten für UML und FSM. In Squeak gibt es nach Laden des Connector-Paketes (es fehlt dort standardmäßig) im Objektkatalog eine eigene Kategorie 'UML'.

In diesem Sinne lassen sich Verbinder ganz naiv als Linien nutzen, die kleben bleiben, aber auch Objekte in eine geordnete Reihenfolge bringen. Mein erster Kontakt mit Verbindern war hier auf der Liste, als irgendjemand über ein Projekt seines Sohnes, glaube ich, berichtete, der im Prinzip einen Morph einen Parcour abfahren lassen wollte und dies letztlich mit Verbindern löste.

Andererseits sind die Etoys aber keine Programmierumgebung, sondern eine Ideenverarbeitungs und -visualisierungswelt - Zielgruppe Kinder, aber nicht nur. Auch als Erwachsener und Informatiklehrer darf ich die Etoys genau dazu benutzen. In dieser Rolle muß ich meinen Schülern Ideen und abstrakte Konzepte nahebringen. Eine zentrale Idee sind hier Beziehungen/Assoziationen/Pointer/Zeiger/Links.

In meinen Augen schrecklichstes Beispiel, das ich in der 11. Klasse umsetzen muß: Implementiere eine verlinkte Liste gemäßt dem Compound-Pattern. Da soll also von den Schülern eine Datenstruktur implementiert werden, die es in zahlreichen Programmiersprachen ohnehin schon fix und fertig gibt. Schön, aber begreifen die Schüler deren Funktionalität dann wirklich? Bekommen sie eine *Vorstellung* davon, was beim Löschen/Einfügen tatsächlich passiert? *Sehen* sie das? Noch habe ich keine 11. Klasse unterrichtet, aber diese Implementierung werde ich ziemlich sicher mit Etoys machen - nicht in einer klassischen Programmiersprache. Dann sind die Listenelemente eben Ellipsen oder Textfelder mit irgendwelchen Werten (Beschriftung/Farbe/sonstetwas - als Lehrer kann ich auch ohne großen Aufwand ein Projekt vorbereiten, in dem es in einem Objektlager (liefert Kopien) oder auf einem MakerButton (Morph-Knopf, liefert Geschwister - wie die Kopie-Kachel) etwa Ellipsen mit einer Variablen 'wert' von irgendeinem Typ gibt (bei den Datenflussdiagrammen oder endlichen Automaten mache ich das auch so - ohne selbst Programmierer zu sein). Für die Werte könnte man Musterobjekte erzeugen, die dann bei Bedarf z.B. mit der Kopie-Kachel vermehrt werden.

Und was paßt als Visualisierung der Zeiger/Pointer/Links? Die Verbinder! Und zwar genau. In einer Liste haben die Elemente keine Namen oder Nummern. Diese Information steckt allein in den Zeigern, die wissen, von wo nach wo sie zeigen. Verbinder wissen das auch, kennen Quelle und Ziel - Namen sind unerheblich. Objekte, die mit Verbindern verbunden sind, können ein- und ausgehenden Verbindern und ihren Vorgängern oder Nachfolgern Nachrichten schicken. Verbinder können diese Nachrichten ausführen. So lassen sich etwa per Kachelskript 'Zeiger' umhängen.

Ebenso bei Datenflussdiagrammen oder endlichen Automaten - die Funktionalität der Verbinder paßt genau:

1. Verbundene Objekte können ihren Nachfolger/Vorgänger ansprechen.

Beim funktionalen Modellieren in Datenflußdiagrammen braucht es den Vorgänger. Dann kann jede (Teil-)Funktion den gesamten Teilgraphen ihrer vorausgehenden Teilfunktionen rekursiv aufrufen. Als Lehrer brauche ich also nur einen Prototypen für einen Teilprozeß zu Basteln: einen Darsteller, der ein einziges Skript 'führeDeineFunktionAus' sowie eine Variable für das Ergebnis seiner Funktion kennt. 'führeDeineFunktionAus' muss als erstes allen Vorgängern eben diese Nachricht schicken - und dafür gibt es bei verbundenen Objekten eine eigene Kachel. In meinem Beispiel habe ich in diesen Prototypen gleich noch einen Knopf für das Skript und einen Beobachter für den Variablenwert eingebettet - Luxus, den man sich auch sparen kann. Wenn man für die Prototypen Textrechtecke oder Textellipsen verwendet, kann der Schüler für sein Diagramm einfach eine Kopie aus einem Objektlager holen, sie nach Belieben beschriften und das führeDeineFunktionAus-Skript programmieren. Dabei darf er nur die abschließende Wertzuweisung in die Variable nicht vergessen.

2. Verbinder können Skripte ausführen und kennen ihre Quelle und ihr Ziel.

Das paßt z.B. genau für Zustandsübergänge in endlichen Automaten. Da braucht es einen Prototypen für einen Zustand, also einen Morph mit einer Variablen 'istAktiv'. Wenn man will, kann man auch noch Variablen für 'istStartzustand' und 'istEndzustand' spendieren sowie ein Skript, das die Aktivität visualisiert - etwa durch einen Farbwechsel. Dafür sind die Textellipsen sehr schön. Der Schüler holt sich vom MakerButton eine solche angepaßte Ellipse und beschriftet sie mit der Bezeichnung, die er gerne für den Zustand hätte.

Bleibt der Verbinder. Da ist auch nicht viel Vorarbeit seitens des Lehrers nötig. Der Verbinder muß

- eine Variable 'auslöser' besitzen, die etwas enthält, was das auslösende Ereignis repräsentiert - z.B. einen string.

- ein Skript 'führeÜbergangAus' kennen und darin

- auf Ereignisse warten, die Übergänge auslösen, also laufen; als Ereignis bietet sich der Wert einer globalen Variablen an, z.B. 'Welts>letzteEingabe' - überprüfen, ob die Quelle aktiv ist - evtl. Übergangsbedingungen überprüfen - Übergangsaktionen auslösen - ein Skript 'löseAktionAus' kennen, das die ausgelösten Aktionen enthält.

Das genügt auch schon, wenn man den Verbinder in einem Objektlager zur Verfügung stellt, weil die Verbinder dann Kopien des Prototyps sind und sich daher ihre 'führeÜbergangAus'-Skripte unterscheiden dürfen. Der Schüler holt sich einen Verbinder aus dem Objektlager, legt den Wert für den Auslöser fest und programmiert das Skript für die ausgelösten Aktionen.

In meinem Beispiel bin ich beim letzten Schritt anders vorgegangen, weil der bequemste Weg zu Verbindern über einen Verbinder-Knopf geht. Die erzeugten Verbinder sind dann aber Geschwister, teilen also ihre Skripte und können sich nur in ihren Variablenwerten unterscheiden. Daher haben die Verbinder bei mir eine Variable 'zuSteuerndesObjekt' und eine Variable 'auszulösendesSkript'. Diese beiden Variablenwerte muß der Schüler setzen. An sich die schlechtere, da unflexiblere Lösung - nur *ein* Skript *eines* Objektes kann aufgerufen werden. Vielleicht baue ich das auch noch um, aber mir hat der Morph-Knopf so gefallen.

Wer es weniger informatisch-abstrakt mag: Bei Physik-Simulationen könnten Verbinder einfach zu bedienende Repräsentanten für Kräfte sein. Sie kennen ihre eigene Geometrie sowie mit Quelle und Ziel die beiden Reaktionspartner. Abhängig von der Art der zu simulierenden Kraft würde der Verbinder aus Attributen von Quelle und Ziel (z.B. deren Massen und Positionen) und ggf. seiner eigenen Geometrie oder eigenen Attributen (etwa seiner Federhärte) die Kraft (die ja auf Quelle und Ziel wirkt) berechnen und sich die Körper dann nur noch um ihre eigenen Eigenschaften wie die Beschleunigung kümmern. Zum Experimentieren könnte man so einen Verbinder dann einfach mit der Maus (wie Federn) zwischen verschiedene Massenobjekte hängen und könnte das unterschiedliche Verhalten der Objekte beobachten. Weil Verbinder Quelle und Ziel kennen, sind die Namen der Objekte unerheblich. Der Schüler muß nichts umprogrammieren/Kacheln austauschen, sondern einfach nur den Verbinder umhängen.

Markus

Lieber Rüdeger Baumann,

Den Übergang zur Smalltalk-Programmierung mit dem Fehlen der Wiederholungskachel in Squeak zu motivieren, halte ich für wenig zwingend. Die naheliegende Reaktion aus meiner Sicht wäre die, dann eben Etoys zu benutzen, wie generell eher Konsens sein dürfte, daß man zum Kachelprogrammieren besser ein Etoys-Image benutzt.

Ich habe auch einmal mit Etoys (damals noch Squeak) begonnen, weil mir der Wechsel zur Textansicht bei den Skripten gefallen hat und ich an einen ähnlichen Weg dachte, wie der im Buch beschrieben wird. Aber das erste, was mich daran gestört hat, waren dann diese aussagekräfitgen Parameternamen der Form 't1', das zweite die eingeschränkten Editormöglichkeiten der Skriptfenster.

Die eigentliche Einschränkung, die ich beim Kachelprogrammieren empfinde, ist das Fehlen von Methoden mit mehreren Parametern. Das kann man zwar auch schaffen, wenn man einen Parameter vom Typ 'player', also Darsteller benutzt und dessen Attribute im Skript auswertet, aber das ist eher trickreich als naheliegend.

In meinen 10. Klassen taucht der Smalltalk-Quelltext aber meist aus ganz anderen Gründen auf: Schüler programmieren etwas, bei dem sie sich (und manchmal auch erst einmal ich mich) wundern, warum das nicht (immer) klappt. Mit den Kacheln sieht man das nämlich nicht immer.

Konkretes Szenario: Die Schüler programmieren bei mir ein Tausammler-Spiel, in dem ein Käfer Tautropfen einsammeln muß. Entscheidend ist hier, daß es mehrere Tautropfen gibt, die alle Geschwister sind.

Lösung 1: Die Tropfen warten auf den Käfer.

Lösung 2: Der Käfer sucht die Tropfen.

Anschließend läuft der Tropfen dem Käfer hinterher oder der Käfer transportiert ihn - das ist egal, wie herum.

Die Schüler programmieren das zuerst für einen Tropfen und erweitern es anschließend auf mehrere Tropfen. Was üblicherweise passiert, ist folgendes:

Die Schüler mit Lösung 1 haben keine Probleme. Zumindest ein Teil der Schüler mit Lösung 2 beklagt sich irgendwann, dass der Käfer immer denselben Tropfen mitnimmt, egal welchen er gerade überlappt.

Die Kachelskripte sehen praktisch gleich aus:

"Käfer überlappt Tropfen" oder umgekehrt. Wer bei den Kacheln wen überlappt ist egal. Einziger Unterschied: Bei Lösung 1 ist das ein Skript des Tropfens, bei Lösung 2 ein Skript des Käfers.

Verschieden werden die beiden Skripte aber, sobald man in die Textversion blickt: Da steht als einmal "self überlappt Käfer" und einmal "self überlappt TropfenSoundSo". Und daran läßt sich auch erklären, warum Lösung 2 ein Problem hat und wie man das mit "überlappt irgendein" noch lösen kann. Zugleich sehen die Schüler hier eine Stelle, an der die Kacheln einen echten Schwachpunkt haben, weil sie etwas verbergen - es gibt kein 'self'.

Anschließend wechsle ich aber direkt zum Programmieren mit Workspace und Browser, weil die Syntaxvervollständigung einfach angenehm ist, und ich ohnehin dorthin will/muß.

Markus

On Sat, 26 Mar 2011, R. Baumann wrote:

Die beiden Beispiele (Automat und Datenflüsse) scheinen mir überprogrammiert; es handelt sich um fertige Software, die die Schüler (nur) verwenden sollen. Meines Erachtens müssten die Schüler die entsprechenden Projekte selbst entwickeln (können), auch wenn sie nicht so perfekt sind.

Kommt darauf an, wozu man sie verwenden will. Die beiden Projekte sind als fertige Software gedacht. Zugleich sind sie aber auch Beispiele dafür, was man mit Etoys so alles umsetzen kann, ohne groß Klassenbibliotheken einer Programmiersprache kennen zu müssen.

Das Datenflussprojekt benutzen bei mir Schüler der 9. Klasse, weil sie etwas über Datenflüsse lernen sollen. Ihre eigenen Programmierkenntnisse beschränken sich zu dem Zeitpunkt auf etwas Scratch aus der 7. Klasse.

Den Automat verwende ich in der 10. Klasse, um den Schülern die Konzepte zustandsorientierte Modellierung und Zustandsübergangsdiagramm zu vermitteln. An diesem Punkt geht es mir nicht um Programmierfähigkeiten der Schüler, sondern darum, hier, vom Automaten her gedacht, etwas nettere/vielfältigere Beispiele umsetzen zu können und dabei die Schüler nicht unbedingt ein komplett neues Werkzeug lernen lassen zu müssen.

Markus