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

> 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