Garnicht mal so schlecht, Guido Stepken, nur weiter so :)
Cheers Klaus
On Thu, 22 Nov 2007 22:14:52 +0100, stepken wrote:
Markus Schlager schrieb:
Also ich wäre in der Tat ausgesprochen an diesen Tutorien interessiert, stehe ich doch konkret vor dem Problem, einen guten Weg zu finden, meinen Schülern Dinge beizubringen, die ich selbst nicht kann. Da ist es immer gut, allein schon zu sehen, auf welche Ideen andere für vergleichbare Zwecke kommen, die offensichtlich mehr Ahnung von der Materie haben.
Ich frage mich hier ernsthaft, wieviel Ahnung einige Smalltalk Hacker wirklich von Didaktik und den wirklichen Problemen mit Squeak im Schulunterricht haben.
- 'Mein Ding' besteht im Moment darin, Wege zu finden, mit Squeak im Unterrichtseinsatz am Gymnasium vernünftige Dinge zu tun, die sich mit dem Lehrplan vertragen. Zielgruppe sind die Jahrgangsstufen
6,7,9,10. Die Lehrpläne sind im Internet veröffentlicht.
Wo genau? Das würde mich auch noch interessieren, damit ich meine Tutorials direkt schon ordnen kann.
Was ich z.B. ausgesprochen gut brauchen könnte, wären
- Datenflussdiagramme, die etwas tun (z.B. rechnen, Strings verarbeiten, Skripte starten... -- rechnen können meine Diagramme schon)
Ist Dir schon einmal aufgefallen, diese frappierende Ähnlichkeit zwischen den ETOYS / Scratch Programmierkacheln und Nassi/Shneidermann Diagrammen?
http://de.wikipedia.org/wiki/Nassi-Shneiderman-Diagramm
Und da steht auch drin, dass sich diese Diagramme nicht für Objektorientierung eigenen, wofür dann UML 2.0 entwickelt wurde. Schluss: ETOYS ist zwar objektorientiert geschrieben, selber aber kann man damit keine objektorientierte Programmierung lernen.
Und tatsächlich ist es so, dass Du mit Scratch/ETOYS halt nur an ganz wenigen Stellen was von OO (Polymorphie) merkst.
Viel interessanter ist es, Petri-Netze der Programmstrukturen zuvor zu malen, z.B. mit WoPeD. Da kann man dann auch noch die Prozesslogiken austesten. Die Zukunft geht genau dort hin. Wenn ich Programmcode sehe, bin ich geneigt, daraus erst einmal die Entscheidungslogiken zu extrahieren (das geht z.B. mit Python Smalltalk oder Ruby sehr gut, daraus dann XML zu extrahieren und nach PNML zu konvertieren, damit man die Programmflusslogiken, also den Möglichkeitsraum der Zustände, die ein Programm annehmen kann, analysieren und Fehler nachweisen kann, z.B. mit WoPeD
Es gibt da eine Reihe von Tools für verschiedene Programmiersprachen, wo es um die Sicherstellung der logischen Fehlerfreiheit von Programmen und ihren impliziten Ablaufslogiken geht. Ich habe z.B. mal so etwas analysiert, als es um mögliche Deadlocks beim Multiprocessing ging. Die Anregung war das "Philosophenproblem", welches mit Petrinetzen simuliert werden kann.
- Visualisierungen von Smalltalk-Code in Form von UML-Diagrammen, idealiter auch so, daß die UML-Diagramme der Ausgangspunkt sind und entsprechenden Smalltalk-Code generieren. BlueJ ist hier die Standardkonkurrenz.
Ochja. Rational Rose, nun IBM, Plugin in Eclipse ist ja auch ladbar aus dem Internet. Nur - die Einarbeitungszeit beträgt mind. 1 Jahr für ausgebildete Informatiker. Muss wirklich mit UML Kanonen auf Kinder geschossen werden? Ich denke nicht. Nassi-Shneidermann genügt vollauf.
- Ideen für schlaue Projekte, die sich etwa mit einer 10. Klasse bei zweistündigem Informatikunterricht sinnvoll realisieren lassen.
Recht wenig. Ich weiss aus Berichten aus Schulen, dass viele Lehrer mit BlueJ und Java arbeiten. Und auch da treten unglaublich viele Probleme auf, z.B. fängt es damit an, dass Kinder kein Windows, sondern Mac OS X zuhause haben, und nicht wissen wie sie die Library vom Lehrer in den Classpath einbinden sollen. Lehrer weiss es auch nicht. Ich rate: Weniger ist mehr. Lieber anspruchsvollere Aufgaben in Scratch und dann ETOYS, als mit UML anfangen. Nassi genügt vollauf, um Denkstrukturen zu trainieren. Man kann mal auch mal das eine oder andere Flussdiagramm in UML übertragen. Aber nicht den Unterricht damit gestalten!
Datenbanken .... tsss. Die müssen erst einmal Mengenlehre nochmal wiederholen, bevor man die an SQL ransetzt. Und dann kommt noch dazu, das SQL eben OO untypisch ist, siehe "impedance missmatch": http://www.google.de/search?q=%22impedance+mismatch%22+stepken&hl=de&...
Gru/3, Guido Stepken