[Squeak-ev] Re: Neues Squeak-Buch - Verbinder

[Markus Schlager]

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