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