Danke, Enno, für die freundlichen und wohlwollenden Worte.

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.

R. Baumann

Michael, schick mir bitte über E-Mail an

baumann-garbsen@t-online.de

deine Postadresse.

Kaufen kannst du es, wenn es (beim LOG-IN-Verlag) erschienen ist. Das dauert aber noch eine Weile.

Gruß Rü

Hallo Rüdiger,

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

Ü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. Da ich selber keine Lehrer bin, habe ich LOG-IN nicht im Abo. Aber wenn Du derjenige aus diesen Verweisen bist, hätte ich den Wunsch an deinen damaligen Texten.

Viele Grüße aus Ettlingen bei Karlsruhe Rolf

Am 28.02.2011 21:53, schrieb R. Baumann:

Danke, Enno, für die freundlichen und wohlwollenden Worte.

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.

R. Baumann

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

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

Markus Schlager schrieb:

"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."

Einverstanden - ich bin inzwischen auch zu Etoys übergegangen. Squeak ist in vieler Hinsicht stehen geblieben, Etoys ist inzwischen viel weiter.

Markus weiter:

"Das erste, was mich gestört hat, waren dann diese [wenig?] aussagekräftigen Parameternamen der Form 't1', das zweite die eingeschränkten Editormöglichkeiten der Skriptfenster."

Die (auch in Etoys 4.1 vorhandenen) wenig aussagekräftigen Parameternamen kann man sofort durch die Schüler (als übung) durch aussagekräftige ersetzen lassen.

Markus:

"Die eigentliche Einschränkung, die ich beim Kachelprogrammieren empfinde, ist das Fehlen von Methoden mit mehreren Parametern."

Stimmt - dann muss man eben Variablen verwenden.

Noch vielen Dank für die eingehenden Bemerkungen zu den Verbindern; vielleicht werde ich ihren Sinn durchschauen und dann entsprechend verwenden.

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.

Gruß Rü

-- View this message in context: http://forum.world.st/Neues-Squeak-Buch-und-Aktualisierung-Vereinsseite-tp33... Sent from the Deutsch (German) mailing list archive at Nabble.com.