4. beispiele - ulb halle: online-publikationen · 433 z. b. ic 74194 wollen wir mit der schaltung...

4.1 Beispiel 1: Zur Präfiguration der Zustands-Idee 86

4. Beispiele 4.1 Beispiel 1: Zur Präfiguration der Zustands-Idee Sollen fundamentale Ideen präfiguriert werden, dann muss das früh geschehen. Ent-sprechende Einschübe sollten immer dann erfolgen, wenn sie sich ohne Zwang in die üblichen Unterrichtsgänge integrieren lassen. Als Beispiel dafür sollen die Ideen des Zustands und des Zustandsübergangs schon im Anfangsunterricht vorbereitend eingeführt werden. Geeignet dafür ist z. B. eine Unterrichtseinheit über kryptografi-sche Verfahren, die innerhalb des Themas „Bezahlen im Internet“ oder „Geschichte der Datenverarbeitung“423 auftauchen kann. Je jünger die Teilnehmerinnen und Teilneh-mer sind, desto mehr interessieren sie sich für dieses Thema. Deshalb, und weil die Verfahren einfach sind, gehört es in den Informatikunterricht der Klassen 9/10, not-falls in den Anfangsunterricht der Sek. II. Wenn Texte verschlüsselt werden, dann geschieht das oft zeichenweise, indem die Zeichenkette mithilfe von Zählschleifen durchlaufen wird. Das Thema macht also mit typischen Elementen des Anfangsunterrichts vertraut und enthält eine Fülle von Ver-änderungsmöglichkeiten, die auf sehr unterschiedlichem Niveau behandelt werden können. Es eignet sich damit sehr gut für Einzelarbeit bzw. projektartige Phasen. In diesem Beispiel soll experimentierend auf verschiedene elementare Datentypen ein-gegangen werden, auch die binäre Darstellung von Zahlen und Zeichen wird thema-tisiert. Als Sprache wählen wir Java und als Ziel ein Applet, weil Schülerinnen und Schüler der anvisierten Altersstufe gerne ihre Ergebnisse ins Netz stellen. Java-Pro-grammiereinheiten lassen sich so gut in Kurse über Informationsgewinnung und -darstellung integrieren.

423 Zahlreiche Beispiele finden sich z. B. in [Kip98], Unterrichtsgänge in [Mod96a]


Ein mögliches Codierungsverfahren läuft so:

Das Verschlüsselungsverfahren verschlüsselt also nicht alle Zeichen auf die gleiche Art, sondern es hängt von seinem Zustand ab, welches Ergebnis produziert wird. Ausgehend von einem Anfangszustand wird das System in Folgezustände über-führt, die sich aus der zu verschlüsselnden Zeichenfolge ergeben. (Ob das Verfah-ren besonders intelligent ist, wird sich in weiteren Tests ergeben.) Solch ein kompliziertes Verfahren will erst einmal gut verstanden sein. Hilfreich ist deshalb ein Zustandsgraph, der die Wechsel zwischen den Zuständen überschau-bar darstellt. Vor allem aber kann dieser Graph im Gespräch an der Tafel kon-struiert werden, wobei Unklarheiten und Fehlinterpretationen deutlich werden kön-nen und zu beseitigen sind. Da das Verfahren wiederholt angewandt werden muss, kann die Konstruktion des Graphen so weit getrieben werden, bis die Arbeitsweise von allen verstanden wurde. Ausgabe- und Überführungsfunktion sollten klar ge-trennt werden. Beschreiben wir den Zustand einfach durch das „aktuelle“ Zeichen, dann können wir z. B. das nächste Zeichen des Klartextes mit diesem xor-verschlüsseln. (Auch das will geübt sein! Im Programm werden die Zeichencodes deshalb so verschoben, dass das ‚A’ der Zahl ‚0’ zugeordnet wird usw. Dadurch wird das Nachvollziehen der XOR-Verschlüsselung „per Hand“ erleichtert.) Der Folgezustand ergibt sich im ein-fachsten Fall aus dem gerade verschlüsselten Zeichen. Ein Ausschnitt424 des entste-henden Graphen könnte dann wie folgt aussehen (der beliebig gewählte Anfangszu-stand ist farblich hervorgehoben):

424 Beschränkt man sich zuerst auf nur wenige Eingabezeichen, dann kann der Graph auch vollständig aufge-zeichnet werden. Vor allem aber werden die Zeichencodes kurz, so dass die XOR-Verschlüsselung einfach ist.

z ein frei gewähltes Startzeichen

mit allen Zeichen der zu verschlüsselnden Zeichenfolge tue

ergebnis ““

v das nächste Zeichen, verschlüsselt mithilfe von z

z das zuletzt verschlüsselte Zeichen

ergebnis ergebnis + v

B, B xor B

A, A xor A

D, D xor D

B

C

D

E A, A xor C

B, B xor A

D, D xor A

E, E xor A A

C, C xor A B, B xor C

usw.

E, E xor C

D, D xor C


Das Verfahren sollte, je nach Kenntnisstand der Lernenden, entweder teilweise oder vollständig, gemeinsam oder in Partnerarbeit in der gewählten Sprache programmiert werden. Danach gibt es sehr viel für die Lernenden selbstständig zu tun:

• Arbeitet die Codierung in allen Fällen korrekt? Gibt es Sonderfälle, z. B. dass bestimmte Zeichenfolgen gar nicht (kaum, zu einfach, ...) verschlüsselt wer-den?

• Ist die Codierung umkehrbar? Das Entschlüsselungsverfahren sollte dann auch realisiert werden. Wettbewerbe im Ver-/Entschlüsseln zwischen ver-schiedenen Gruppen sind möglich. (Das Verfahren ist einfach genug, um schnell zu Entschlüsseln.)

• Die Überführungsfunktion kann verändert werde. Der Folgezustand könnte vom alten Zustand und dem nächsten Zeichen abhängen, oder nur vom alten Zustand, indem eine Zeichenfolge zirkulär durchlaufen wird425, oder sonstwie.

• Die Ausgabefunktion kann verändert werden, indem andere Verschlüsse-lungsmethoden angewandt werden, die auf zwei Zeichen beruhen, auf Ver-schiebungen, ...

• Es können mehrstufige Verfahren realisiert werden.

• ... Die Einführung des Zustandsbegriffs und einiger Formalien akzentuiert die Arbeit etwas – aber nur leicht – anders als üblich. Sie schafft dabei durch die klare Unter-scheidung der einzelnen Aktionen Eingriffsmöglichkeiten und so Ansatzpunkte für eigene Veränderungen, deren Schwierigkeitsgrad dem Anfangsunterricht angemes-sen ist. Sie schafft Freiräume in einem einheitlichen Begriffsfeld und erleichtert so die Kommunikation zwischen den Gruppen, die klar benennen können, an welchen „Schrauben sie gedreht“ haben. Haben wir als Lerngruppe z. B. eine 11. Klasse, üblicherweise mit sehr unterschiedli-chen Vorkenntnissen und Interessen bei den Unterrichteten, die sich zur Einführung einige Wochen mit Problemen der Computergrafik beschäftigt haben426, wobei ele-mentare Datentypen (ganze Zahlen, boolesche Größen, ggf. Zeichen) und die algo-rithmischen Grundstrukturen Sequenz, Verzweigung und ggf. Iteration427 benötigt wurden, dann kann man sich danach z. B. mit Sicherheitsfragen im Internet beschäf-tigen („elektronisches Geld“, „Softwarepiraterie“, …), wobei das „Verschlüsseln“ als Teilthema auftaucht. Da Komponenten (Buttons, Editierfelder, …) mit ihren Event-handlern von Anfang an benutzt werden sollten, kann man sich jetzt völlig auf die Zeichenkettenverarbeitung konzentrieren, wobei anfangs die Strings den benutzten Komponenten entnommen und ihnen zum Schluss wieder übergeben werden. Weil die Ereignisbehandlungsmethoden als Prozeduren realisiert sind, kann auch die Zei-chenkettenverarbeitung in Unterprogramme verlagert werden428. Ziel des Unterrichts ist es neben der Einführung einiger fachlicher Grundlagen, die Schülerinnen und Schüler, ausgehend von einem gelösten Problem, langsam an selbstständiges Arbeiten zu gewöhnen.

425 Das wäre dann das übliche Verfahren mit „Schlüsselwort“. 426 Das Thema lässt sehr gut Binnendifferenzierung zu. 427 Statt Schleifen hat man aber wahrscheinlich Timer-Komponenten eingesetzt. 428 Damit unterscheiden sich die Lösungen der jetzt hinzukommenden Teilaufgaben der Zeichenkettenmanipula-tion kaum noch von denen, die z. B. vor 20 Jahren benutzt wurden.


Unter diesen Voraussetzungen benötigen wir eine Unterrichtsstunde, um anhand eines sehr einfachen Verfahrens gemeinsam das Grundgerüst eines Verschlüsse-lungsprogramms zu entwerfen. Die nächsten vier Stunden stehen für Gruppenarbei-ten bereit, in denen die Schülerinnen und Schüler das Gerüst verändern und erwei-tern bzw. durch bessere Verfahren ersetzen. Das ist auf sehr unterschiedlichem Ni-veau möglich (s. o.), so dass auf die unterschiedlichen Vorkenntnisse eingegangen werden kann. Die Unterrichtenden sollten in diesen Stunden anhand von Transiti-onsgraphen unterschiedliche Verschlüsselungsverfahren mit den Kleingruppen ent-werfen und diese diskutieren lassen. Mit diesen – relativ knappen – Informationen lässt sich die Unterrichtseinheit ent-sprechend den Vorschlägen in Kapitel 2.5 klassifizieren: Thema: Kodierungsverfahren

Zeitbedarf: ab 5 WStd.

Voraussetzungen: elementare Datentypen, Zeichenketten, Ein- und Ausgabe über Komponenten in Applets, Methoden, ggf. XOR-Verschlüsselung

Die Einheit dient der Verdeutlichung der kulturellen Bedeutung des Themas zu 5 %. gesellschaftlicher Auswirkungen des Themas zu 15 %. rein fachlicher Aspekte zu 80 %. Die folgenden Unterrichtsmethoden erfordern an Unterrichtszeit ca. Lehrervortrag: Unterrichtsgespräch: 20 %. Partnerarbeit: 40 %. Einzelarbeit: 40 %. Projektarbeit: Das Thema verdeutlicht die folgenden fundamentalen Ideen:

1. Algorithmisierung 1.1 Entwurfsparadigmen (Branch and Bound, Backtracking, …) 1.2 Programmierkonzepte (Alternative, Iteration, Rekursion, ...) zu 60 % 1.3 Ablauf (Prozess, Nebenläufigkeit, ...): 1.4 Evaluation (Verifikation, Komplexität, ...): 2. strukturierte Zerlegung 2.1 Modularisierung (Methoden, Hilfsmittel, ...) zu 20 % 2.2 Hierarchisierung (Darstellung, Realisierung, ...) 2.3 Orthogonalisierung (Emulation, ...) 3. Formalisierung 3.1 formale Sprache (Syntax, Semantik, ...) 3.2 Automat (Zustand, Übergang, Vernetzung, ...) zu 20% 3.3 Berechenbarkeit (Grenzen, Durchführbarkeit, ...)

Der Java-Quelltext findet sich bei den Materialien am Ende der Arbeit.

4.2 Beispiel 2: Rechnermodelle 90

4.2 Beispiel 2: Rechnermodelle Fasst man „Programmiertwerden“ als eine Form von „Maschinenlernen“ auf, dann müssen Maschinen über die Fähigkeit verfügen, auf unterschiedliche Situationen unterschiedlich zu reagieren, also Entscheidungen zwischen Alternativen zu fällen. Da es Aufgabe von Unterrichtseinheiten über technische Informatik in ihrer Gesamt-heit ist, ein gültiges Maschinenmodell bei den Lernenden entstehen zu lassen, gehört m. E. der Übergang von den elementaren Grundschaltungen zu eben dieser Fähig-keit zu den wichtigen Elementen eines Technikkurses. Darauf aufbauend kann eines der üblichen Rechenwerke, das über mindestens zwei unterschiedliche Zustände verfügt (z. B: Addieren und Subtrahieren) gesteuert werden. Die Belegung der Steu-erleitungen bildet dann einen Elementarbefehl. Fügt man mehrere Elementarbefehle zu einer Sequenz zusammen und speichert sie geeignet, dann hat man schon die rudimentäre Form eines Programms gefunden. Kann der Wert des erforderlichen Programmschrittzählers mithilfe der „Entscheidungsschaltung“ beeinflusst werden, dann können wir Alternativen und Sprünge und somit Iterationen programmieren. Das genügt als Maschinenmodell für ein Grundverständnis programmierbarer Auto-maten. Wenn man die Baugruppen der Schaltung zu funktionalen Einheiten wie Re-chenwerk, Steuerwerk, Speicher, … zusammenfasst, dann hat man ein schönes Bei-spiel für Modularisierung und Hierarchisierung gefunden. Aber auch Erfahrungen mit der zunehmenden Integration der TTL-ICs dienen demselben Zweck. Die ange-gebenen fundamentalen Ideen treten hier in einem ganz anderen Gewand auf als in den anderen Kursen. Sie verdeutlichen damit deren übergreifenden Charakter. Schülerinnen und Schüler der Sekundarstufe I mögen den Umgang mit echter Hard-ware (TTL-ICs, …) – meist nach anfänglichem Sträuben429 – sehr. Sie stellen der Schulgemeinschaft mit großem Stolz die entwickelten „Rechenwerke“ z. B. in Schau-kästen vor. Da die Entwicklung von Schaltungen und die Komposition von einfachen Schaltwerken aus vorhandenen ICs auch vom Anspruch her in diese Altergruppe gehört, sollten zumindest die Anfänge der technischen Informatik in diesen Bereich verlegt werden. Nicht zu unterschätzen sind die Erfahrungen mit echter Technik, die sonst in der Schule kaum vorkommen. Beginnen wir mit den Alternativen. Da sich TTL-ICs in einem Buch schlecht unter-bringen lassen, benutze ich stattdessen ein frei verfügbares Simulationspro-gramm430. Reduzieren wir die Fragestellung so weit wie nur möglich, dann lautet die Aufgabe: „Gesucht ist eine Schaltung, die entscheiden kann, ob eine 1-Bit-Zahl kleiner als eine andere ist.“ Das Problem kann leicht über eine Schaltwerttabelle gelöst werden. Wir erhalten z. B. die folgende Schaltung und ihre Gatterdarstellung:

baba ^=<

429 Das Thema könnte ja etwas mit Physik zu tun haben, und die ist leider sehr unbeliebt. 430 Den Digitalsimulator 4.0 von A. Herz


Betrachten wir jetzt eine Sequenz von Befehlen, die durchnummeriert sind, dann kann nach einem Vergleich dessen Ergebnis zum nächsten Programmschritt addiert werden. Schlägt der Vergleich fehl, dann wird der nächste Befehl ausgeführt, sonst der übernächste.431 Folgen auf einen Vergleichsbefehl zwei Sprungbefehle, dann stellen die angesprungenen Befehlssequenzen die gesuchten Alternativen dar.432 Wir benötigen als Ausgangspunkt ein Rechenwerk, das wenigstens zwei Funktionen ausführen kann. Ich wähle einen umschaltbaren 3-Bit-Addierer/Subtrahierer.

In diesem ersetzen wir eine Schalterreihe durch ein Register433, das Zahlen spei-chern und Zwischenergebnisse aufnehmen kann - dann haben wir schon mal einen Akkumulator. Da das hier benutzte Simulationsprogramm leider in der derzeitigen Version kein Register enthält, missbrauche ich einfach das 16k x 8Bit-RAM dafür. Das ist zwar nicht schön, vereinfacht aber die Schaltung drastisch. Weiterhin führen wir einen Takt(-Schalter) ein, da der Speicher einen solchen benötigt, und einen Re-set-Schalter, um den Akkumulator bei Bedarf zu löschen. Damit haben wir zwei Steuerleitungen (und den Takt), um die Funktionalität der Schaltung zu beeinflussen.

431 So arbeiteten z. B. die ersten programmierbaren Taschenrechner von HP. 432 Mit diesem einfachen Verfahren können wir schon alle algorithmischen Verfahren realisieren – wenn auch nicht besonders elegant. 433 z. B. IC 74194


Wollen wir mit der Schaltung eine Rechenaufgabe lösen (deren Ergebnisse aller-dings im 3-Bit-Rechenbereich bleiben müssen), dann können wir diese durch eine Folge von Steuerleitungsbelegungen und die erforderlichen „Daten“ (Zahlen) „pro-grammieren“. Wählen wir z. B.

3 + 4 – 5 + 1 = dann brauchen wir das folgende Programm:

Reset S Eingabe Kommentar 0 bel. bel. Akku löschen

1 0 011 3 laden

1 0 100 4 addieren

1 1 101 5 subtrahieren

1 0 001 1 addieren Wir können die Bitfolge 00000 als „Maschinenprogramm“ 10011 auffassen . Zwischen den 10100 Befehlen folgen „Takte“. 11101 10001


Bis zu dieser Ebene ist auch in der Sek. I mühelos vorzudringen. Die Schülerinnen und Schüler können mit der Schaltung experimentieren, lernen vergleichend mit Si-mulationsprogrammen und echter Hardware umzugehen, können die Schaltung ab-wandeln

• durch andere Bauteile (hier: „richtige“ Register benutzen, Anzeigen, …),

• durch andere Steuerleitungen (z. B. um den Akkumulators zu laden),

• durch weitere Register (z. B. als Speicher für Zwischenergebnisse)

• oder durch Erweiterung des Zahlenbereichs. Kurz: Sie machen sowohl auf einer relativ abstrakten wie auf einer konkreten Ebene Erfahrungen im Umgang mit echter Technik, lernen abzuschätzen, ob ihnen diese Art des Vorgehens liegt.


Betrachten wir das oben abgebildete Rechenwerk als ein Modul, in das drei Daten-leitungen, zwei Steuerleitungen und eine Taktleitung hereinführen, dann können wir dieses von außen steuern, indem wir die erforderlichen Befehle in einem Speicher ablegen. Dieser selbst muss natürlich auch geordnet arbeiten, also „gesteuert“ wer-den. Dazu benötigen wir einen Binärzähler als Program-Counter, der den aktuellen Befehl angibt, und eine Möglichkeit, die Programminhalte einzugeben. Ich realisiere das hier über geeignete Schalter im unteren Teil des Bildes.

Leider kann unser Binärzähler (im Gegensatz zu vielen „echten“434) keine Werte la-den. Deshalb ist in dieser Schaltung nur ein „Sprung zur Adresse 0“ möglich – über Reset. (Ich habe hier stattdessen einfach die Taktleitung zum Rechenwerk unterbro-chen, um einen Stopp zu realisieren.) Trotzdem tauchen schon die ersten Elemente eines echten Prozessors auf. Das System ist – bei einem geeigneten Zähler – leicht zu erweitern. Es können von den Schülerinnen und Schülern Maschinen erfunden werden, die natürlich nur immer einige Ausschnitte eines richtigen Befehlssatzes „verstehen“, trotzdem aber z. B. in der Lage sind, rekursive Programme auszuführen. Die programmierbaren Schaltwerke erfordern einiges an analytischem Denken und sorgfältige Abstimmung der Schaltungsmodule. Sie sind von der Komplexität her in der Sek. II anzusiedeln, können da aber durchaus auch im Grundkurs entwickelt werden. Sie liefern ein stark reduziertes, aber im Prinzip richtiges Hardwaremodell des Von-Neumann-Computers, das für das Verständnis der Abläufe bei Unterpro-grammaufrufen und deren Parameterübergabe, Rekursionen und Referenzen m. E. unerlässlich ist. Und sie liefern auch in dieser Altersstufe Erfahrungen in technik-ori-entierter Arbeit. Haben wir als Lerngruppe z. B. einen Grundkurs der Stufe 13, dann sollte dieser ei-nerseits solide Kenntnisse über Entwurfstechniken und Programmierung besitzen, andererseits an Gruppen- und selbstständige Einzelarbeit gewohnt sein. Weil die Simulation von TTL-Bauteilen in der Schule eines der besten Beispiele für den Ein-satz von OOP-Techniken ist, kann kursbegleitend ein eigener Hardwaresimulator als Hausarbeit entwickelt werden, wobei der im Unterricht neben der echten Hardware eingesetzte Simulator als Vorlage dient. Die dabei auftauchenden Probleme lassen sich sowohl auf einem elementaren Niveau als auch außerordentlich anspruchsvoll lösen: Es bietet sich ein weites Feld für Binnendifferenzierung. Ziel des Unterrichts ist es neben der Anwendung fachlicher Grundlagen, bei den Schülerinnen und Schülern ein valides Rechnermodell entstehen zu lassen. Unter diesen Voraussetzungen wird der Entwurf eines Rechnermodells im zweiten Kursteil liegen, weil anfangs die logischen Grundschaltungen, Rechenschaltungen, Speicher und Rechenwerke kennen gelernt werden müssen435. Zusammen mit Teil-problemen der Hardwaresimulation (Anwendung von Listen, OOP-Techniken, …) braucht das seine Zeit. Wählen wir jetzt den oben skizzierten Weg, über stufenweise Erweiterungen von einem umschaltbaren Rechenwerk zu einem programmierbaren System zu kommen, dann erfordern die einzelnen Schritte von Stufe zu Stufe nur relativ wenig Zeit für gemeinsame Unterrichtsgespräche, die bei Bedarf eingestreut werden können. Der überwiegende Teil der Unterrichtszeit wird für Einzel- und Grup-penarbeit sowie intensive Einzelgespräche benötigt, in denen auftauchende Proble-me geklärt werden - insbesondere, wenn mit echter Hardware gearbeitet wird.

434 z. B. IC 74191 435 Auf entsprechende Vorkenntnisse aus der Sek. I wird man (noch) kaum zurückgreifen können.


Mit diesen Informationen lässt sich die Unterrichtseinheit entsprechend den Vor-schlägen in Kapitel 2.5 klassifizieren: Thema: Rechnermodelle

Zeitbedarf: ab 10 WStd. (je nach Ziel)

Voraussetzungen: logische Grundschaltungen, einfache Rechenschaltungen, einfache Schaltwerke (Zähler, Speicher, …)

Die Einheit dient der Verdeutlichung der kulturellen Bedeutung des Themas zu 10 % gesellschaftlicher Auswirkungen des Themas zu 20 % rein fachlicher Aspekte zu 70 % Die folgenden Unterrichtsmethoden erfordern an Unterrichtszeit ca. Lehrervortrag: Unterrichtsgespräch: 20 % Partnerarbeit: 40 % Einzelarbeit: Projektarbeit: 40 % Das Thema verdeutlicht die folgenden fundamentalen Ideen:

1. Algorithmisierung 1.1 Entwurfsparadigmen (Branch and Bound, Backtracking, …) 1.2 Programmierkonzepte (Alternative, Iteration, Rekursion, ...) zu 20 % 1.3 Ablauf (Prozess, Nebenläufigkeit, ...): 1.4 Evaluation (Verifikation, Komplexität, ...): 2. strukturierte Zerlegung 2.1 Modularisierung (Methoden, Hilfsmittel, ...) zu 20 % 2.2 Hierarchisierung (Darstellung, Realisierung, ...) zu 20 % 2.3 Orthogonalisierung (Emulation, ...) 3. Formalisierung 3.1 formale Sprache (Syntax, Semantik, ...) 3.2 Automat (Zustand, Übergang, Vernetzung, ...) zu 20% 3.3 Berechenbarkeit (Grenzen, Durchführbarkeit, ...) zu 20 %

4.3 Beispiel 3: Gekoppelte Automaten 96

4.3 Beispiel 3: Gekoppelte Automaten Das überraschende Verhalten gekoppelter Systeme kann mit zellulären Automaten sehr gut demonstriert werden436. Einerseits nutzt man hier ziemlich einfache endliche Automaten, so dass die Benutzung der entsprechenden Beschreibungsmittel geübt werden kann, andererseits sind die Resultate so vielfältig, dass die Arbeit trotz dieser Einfachheit alles andere als langweilig ist. Man kann leicht Systeme modellieren, deren Verhalten sich kaum aus dem Simulationsprogramm selbst erschließen lässt. Die Anordnung der Elementarautomaten in Gittern liefert ein exzellentes Beispiel für den Umgang mit zweidimensionalen Feldern. Verteilt man die Funktionalität auf ge-eignete Objektklassen, dann kann die Darstellung der Ergebnisse standardisiert wer-den, so dass Experimente an den Automaten ohne großen Programmieraufwand zu realisieren sind. Die Unterrichtseinheit ist je nach der Fortschrittlichkeit der einge-setzten Programmiertechniken im Unterricht der Sek. II anzusetzen. Der erforderliche Zeitbedarf wird wesentlich dadurch bestimmt, ob – und wenn, welche – Teile des Simulationsprogramms vorgegeben werden. In diesem Beispiel benutze ich Delphi, weil ich diese Sprache im Unterricht für bestens geeignet halte. Wir wollen einen zellulären Automaten bauen, der auf dem Gefangenendilemma auf-baut, aber etwas abgewandelt auf den Handel im Internet. Das Verhalten der Han-delspartner wird durch endliche Automaten simuliert, die auf einem in beiden Dimen-sionen abgeschlossenen Gitter sitzen und innerhalb einer Moore-Nachbarschaft Handel mit den Partnern treiben. Sie tauschen – wie im Internet üblich – Waren ge-gen Geld437. Dabei gibt es unterschiedliche Arten von Geschäftpartnern:

• Naive kooperieren immer, liefern also den korrekten Gegenwert.

• Betrüger kooperieren nie.

• Gewitzte kooperieren anfangs und reagieren danach so, wie der Partner beim letzten Mal.

Auch hier ist die Idee des Zustands und seiner Wechsel zentral. Des Weiteren spielt aber auch die Idee der Berechenbarkeit in ihrem prognostischen Aspekt eine Rolle, da sich die Frage stellt, ob Voraussagen über das Verhalten des Systems möglich sind, ohne es vollständig zu realisieren, also wirklich „laufen zu lassen“. Die Imple-mentierung über Objekte liefert Beispiele für strukturierte Zerlegungen und einfa-che Programmierkonzepte. Wir können dieses Verhalten der Handelspartner leicht durch Zustandsdiagramme beschreiben: K: „kooperieren“ B: „betrügen“ Ordnen wir solche Automaten in einem Gitter an, verteilen sie zufällig und färben sie entsprechend ihrem Zustand (grün als „Naiver“, rot als „Betrüger“ oder gelb als „Ge-witzter“) ein, dann erhalten wir ein Bild ähnlich dem folgenden:

436 Zahlreiche gut umsetzbare Beispiele finden sich z. B. in [Ger95] 437 Man kann sich das wie in einer Auktionsbörse organisiert vorstellen, z. B. in ebay.

K,K v B,K

K

Der „Naive“

K,B v B,B

B

Der „Betrüger“

B,K

K,K

K

Der „Gewitzte“ K,B

B,B

B


Der weitere Ablauf ist einfach:

• Zuerst handeln alle Partner einmal mit ihren Nachbarn aus der Moore-Nachbarschaft. Dabei ist einiges an Orientierung im Gitter (als Array) vonnö-ten: es wechselt die „Blickrichtung“ (Stellung in der Nachbarschaft), und an den Rändern muss man auch überlegen.

• Danach bewerten alle Partner den Erfolg ihrer Nachbarn.

• Als Opportunisten übernehmen sie daraufhin den Zustand des erfolgreichsten Nachbarn oder behalten ihren Zustand bei, wenn sie selbst besser waren.

Im Beispiel (s. Materialien) wird eine Automatenklasse in einer eigenen Unit verein-bart und darauf aufbauend eine „Welt“ (auch in einer Unit), die mit einem Gitter aus Automaten hantiert. Beides wird von der Programmoberfläche des zellulären Auto-maten gesteuert. Die Abläufe zwischen diesen Klassen sind zwar nicht ganz trivial (besonders bei der grafischen Darstellung in der Windows-Welt), dafür aber nur ein-mal zu lösen. Danach können die Automaten in ihrer Unit bzw. die „Welt“ in der an-


deren getrennt und ohne direkte Beeinflussung manipuliert werden. Man kann also „schön einfach“ experimentieren. In den ersten Generationen setzen sich meist „die Bösen“ durch. Doch danach bilden sich Cluster aus „Guten“ bzw. „Gewitzten“, und dann beginnt eine wilde „Schlacht“.

Zwar werden die „Guten“ hart von den „Betrügern“ bedrängt. Sie halten sich aber ganz gut in Gruppen. Die „Gewitzten“ setzen sich gegenüber den „Betrügern“ – je nach Konfiguration – meist durch und kooperieren mit den „Guten“.

Am Ende siegen meist die „Gewitzten“ – aber eben nicht immer. Das Beispiel ist als Vorbereitung auf die Automatentheorie eher schlicht. Es bietet aber eine extreme Bandbreite von sowohl programmiertechnischen wie inhaltlichen Variationen und legt sozialwissenschaftliche bzw. naturwissenschaftliche Interpreta-tionen nahe. In dieser Beziehung wird der Modellcharakter besonders deutlich. Bleiben wir zuerst bei den Variationen:


• Das Verhalten der „Partner“ kann leicht durch veränderte Strategien ergänzt werden. „Wettbewerbe“ zwischen verschiedenen Strategien werden möglich, wobei Statistiken geführt werden müssen, da der Einzelfall nicht viel über das Gesamtverhalten aussagt. Schon hier ist systematisches Arbeiten gefragt.

• Die „Welt“ kann verändert werden durch veränderte Nachbarschaften (von-Neumann-Nachbarschaft, andere Reichweiten, …), andere Abläufe, ... Statt des zweidimensionalen Gitters kann die zeitliche Entwicklung linearer Auto-maten in der üblichen Weise dargestellt werden, wobei chaotische Vorgänge auftreten438. Bei beidem können sowohl die Art der Automaten wie das Steu-erprogramm völlig ignoriert werden.

• Die Gewichtungsfaktoren, die den Gewinn bei unterschiedlichen Vorgängen bestimmen, sind veränderbar.439 Auch hier sind die anderen Größen irrele-vant.

• Das Steuerprogramm kann verbessert werden, z. B. um während des Pro-grammlaufs die unterschiedlichen Faktoren zu verändern.440 Dafür sind „Ober-flächenprogrammierer“ gefragt.

• Die Eigenschaften der Gitterautomaten sollten auch per Mausklick gesetzt werden können (einige „Gewitzte“ in einer Welt aus „Bösen“, …), um das Ver-halten bestimmter Konfigurationen gezielt untersuchen zu können.

Es kann aber auch versucht werden, die beobachteten Vorgänge systematisch zu bewerten:

• Zur Bewertung der Systeme sind globale Größen geeignet („Bruttosozialpro-dukt“ als Summe aller „Handelspunkte“, …). Der Einfluss der Parameter auf das Erreichen und die Art des ggf. erreichten Endzustands kann abgeschätzt werden. Lineare Automaten lassen sich entsprechend klassifizieren.441

• Es können Beschränkungen eingeführt werden („Anzahl der handelbaren Gü-ter“, „Geldmenge“, …), und die Verteilung der Größen auf die Gruppen sowie deren zeitliche Entwicklung ist darstellbar.

Die Beobachtung der manchmal überraschenden Abläufe liefert Ansatzpunkte zur Diskussion ethischer Fragen. Auch wenn das Beispiel natürlich nicht direkt auf ge-sellschaftliche Systeme übertragbar ist, so haben wir doch ein für die meisten neuar-tiges Argument für kooperatives, soziales Verhalten gefunden, das nicht aus trans-zendenten oder philosophischen Überlegungen gewonnen wird, sondern aus Effi-zienzbetrachtungen. Es steht darin in klarem Gegensatz zur Egozentrik des Primitiv-darwinismus, der oft die öffentliche Diskussion in dieser Hinsicht beherrscht. Unter-richtseinheiten dieser Art steuern damit einem die „Ellenbogengesellschaft“ fördern-den und fordernden Biologismus entgegen. Unsere zellulären Automaten sollten den Handel im Internet simulieren. Was erhal-tene Modell ist aber auch ganz anders interpretierbar: Betrachten wir den „Handel“ als Energieaustausch benachbarter Teilchen, dann kommen wir recht schnell zum Ising-Modell für Spingitter442. Die globalen Größen „Temperatur“ und „Magnetisie-rung“ liefern Bewertungsmaßstäbe zur Beurteilung des Systems. Relativ kleine Än- 438 [Schr91] ab S. 388, [Man91] S. 436 439 Im vorgestellten Programm wurde dafür etwas „Zufall“ eingebaut. 440 Das ist auch bitter nötig, da die Instantiierung so vieler Objekte einige Zeit dauert. 441 z. B. [Ger95] S. 59 nach Stephen Wolfram 442 [Arg94] S. 405 ff.


derungen führen auf Strukturbildungsprozesse und/oder Modelle für biologische und chemische Systeme443. Die Interpretation desselben Modells in unterschiedlichem Kontext, die (teilweise) Unvorhersagbarkeit der Ergebnisse, das dynamische Verhalten und sein Bezug zu nichtlinearen Systemen liefert Erfahrungen mit Modellen, Simulationen, deren Mäch-tigkeit und deren Grenzen – und das fast ohne Mathematik. Die Visualisierungsmög-lichkeiten der Computer machen so einerseits der Schule völlig neue Gebiete zu-gänglich und verdeutlichen andererseits den von der Mathematik unterschiedenen Charakter der Informatik als „Prognosesystem“. Nebenbei ist das Thema eine uner-schöpfliche Quelle von „Facharbeiten“ der Schülerinnen und Schüler. Haben wir als Lerngruppe z. B. den ersten Leistungskurs der Stufe 12 etwa zur Mitte des Semesters, dann sollte dieser eigentlich einen soliden Anfangsunterricht in der Klasse 11 durchlaufen haben. Leider ist derzeit aber zumindest bei schulübergrei-fenden Kursen davon auszugehen, dass die Vorkenntnisse kaum vergleichbar sind. Die Lernenden werden deshalb in diesem ersten Kurs die komprimierte „Nach-lieferung“ fehlender Inhalte444 noch kaum „verdaut“ haben. Sie sollten aber mit der elementaren Algorithmik, primitiven Datentypen und einfacher Computergrafik inzwi-schen halbwegs vertraut sein. Beginnen wir danach eine Unterrichtseinheit über „Vi-sualisierung großer Datenmengen“, dann steht uns einerseits das weite Feld der Falschfarbendarstellungen von astronomischen445, geografischen446 oder medizini-schen447 Daten mit ihren Interpretationsmöglichkeiten offen, andererseits bilden Git-terautomaten ein interessantes Arbeitsgebiet, das hier betrachtet wird. Repräsentieren wir die Teilautomaten durch Objekte, dann können die entsprechen-den Klassen aus grafischen Komponenten der GUI abgeleitet werden448. Wir haben damit neben einem elementaren Zugang zu endlichen Automaten auch einen einfa-chen Einstieg in OOP-Methoden gefunden. In der angegebenen Form erfordert die Nutzung der Transitionsgraphen kaum Zeit: Bei einer Diskussion unterschiedlicher Strategien, z. B. der des „Langmütigen“, wird diese Notationsform nebenbei einge-führt und gefestigt. Erheblich mehr Zeit benötigt eine eingehende Analyse der Ab-läufe, die daraus folgende Verteilung der Informationen und ihre Repräsentation. Wird hier nicht sorgfältig gearbeitet, dann kann es später erhebliche Probleme ge-ben. Sind die Alternativen und deren Konsequenzen betrachtet und die wesentlichen Entscheidungen getroffen, dann werden die Teilprobleme einzeln angegangen:

• Eine Automatenklasse mit den erforderlichen Methoden wird vereinbart, imple-mentiert und an einzelnen Objekten getestet.

• Ein Gitter solcher Automaten wird als Array definiert.

• Die Aktionen im Gitter werden realisiert. Ziel des Unterrichts ist es, bei der Implementierung eines relativ einfachen Modells elementare informatische Techniken kennen zu lernen, sowie sich mit Simulationen zu beschäftigen, deren Ergebnisse kaum prognostizierbar sind und die zu Diskussio-nen anregen.

443 [Cra88] 444 die man ganz gut mit einer Einheit über Programmverifikation „anreichern“ kann, damit nicht in Vergessen-heit gerät, dass es sich um einen Leistungskurs handelt. 445 z. B. aus dem Projekt „Hands-On Universe“ 446 z. B. Satellitenbilder 447 z. B. mit NMR-Daten aus der Tomografie 448 Das ist zwar nicht effizient, aber sehr lehrreich.


Unter diesen Voraussetzungen wird eine anfängliche eingehende Diskussion der Problematik im Unterrichtsgespräch unbedingt erforderlich sein. Aus dieser sollten sich dann die zu lösenden Teilprobleme ergeben, und aus diesen folgen die erforder-lichen Programmiertechniken. Die Vereinbarung einer Tochterklasse z. B. von GUI-Panels, die mit Automateneigenschaften ausgestattet wird, sollte ebenfalls gemein-sam durchgeführt werden, wobei der Neuigkeitswert nicht bei den in Methoden auf-tretenden Algorithmen, sondern in den Zugriffstechniken liegt. So etwas lässt sich schnell abhandeln, die notwendigen Erfahrungen werden bei der Anwendung ge-wonnen. Sind zweidimensionale Felder schon bekannt, dann können die Lernenden das Zusammenspiel der Automaten selbst realisieren. Die dabei möglichen Fehler sollten erkannt und korrigiert werden. Als Hilfe wird ggf. das zufällige Erzeugen einer Anfangsbelegung des Feldes vorgegeben. Danach wird das Modell wie beschrieben variiert und erprobt. Mit diesen Informationen lässt sich die Unterrichtseinheit klassifizieren: Thema: zelluläre Automaten

Zeitbedarf: ab 10 WStd. (je nach Ziel)

Voraussetzungen: Arrays, elementare OOP, einfache grafische Darstellungen

Die Einheit dient der Verdeutlichung der kulturellen Bedeutung des Themas zu 10 % gesellschaftlicher Auswirkungen des Themas zu 50 % rein fachlicher Aspekte zu 40 % Die folgenden Unterrichtsmethoden erfordern an Unterrichtszeit ca. Lehrervortrag: 10 % Unterrichtsgespräch: 30 % Partnerarbeit: Einzelarbeit: Projektarbeit: 60 % Das Thema verdeutlicht die folgenden fundamentalen Ideen:

1. Algorithmisierung 1.1 Entwurfsparadigmen (Branch and Bound, Backtracking, …) 1.2 Programmierkonzepte (Alternative, Iteration, Rekursion, ...) zu 10 % 1.3 Ablauf (Prozess, Nebenläufigkeit, ...): 1.4 Evaluation (Verifikation, Komplexität, ...): 2. strukturierte Zerlegung 2.1 Modularisierung (Methoden, Hilfsmittel, ...) zu 20 % 2.2 Hierarchisierung (Darstellung, Realisierung, ...) zu 20 % 2.3 Orthogonalisierung (Emulation, ...) 3. Formalisierung 3.1 formale Sprache (Syntax, Semantik, ...) 3.2 Automat (Zustand, Übergang, Vernetzung, ...) zu 40% 3.3 Berechenbarkeit (Grenzen, Durchführbarkeit, ...) zu 10 % Der Delphi-Quelltext findet sich bei den Materialien am Ende der Arbeit.

4.4 Beispiel 3: Eine Sprache für LEGO-Roboter 102

4.4 Beispiel 4: Eine Sprache für LEGO-Roboter LEGO-Mindstorms-Roboter sind für Unterrichtszwecke in jeder Altersstufe hervorra-gend geeignet. Sie betonen als „Spielzeuge“ die spielerischen Elemente des Unter-richts, können entweder über eine ActiveX-Komponente in Windows-basierte Pro-grammiersprachen oder mithilfe besonderer Sprachen449, die im Internet frei verfüg-bar sind, eingebunden und direkt gesteuert werden oder als Geräte mit eingebauter eigener Programmiersprache als Ziel von Kompilierungsprozessen dienen. Steuert man die Roboter direkt450, dann kann man ih-nen über eine geeignete Programmoberfläche einzelne Befehle oder Befehlsfolgen schicken und die Ergebnis-se direkt beobachten. Die Sensoren des Geräts können abgefragt, ausgewertet und wiederum zur Steuerung benutzt werden. Wohlgemerkt: nicht nur in den grafi-schen LEGO-Programmsystemen, sondern genauso unter Java, C++, C# oder Delphi. In diesem Kontext veranschaulichen die Geräte die Idee des Automaten besonders gut. Verfügt der Roboter z. B. über einen Stift, der angehoben und gesenkt werden kann, dann ist auch sein Zustand direkt beobachtbar. Valentin Brai-tenberg hat in seinem interessanten und sehr witzigen Buch451 eine Fülle von „kybernetischen Wesen“ be-schrieben, deren erste Versionen sich direkt als Roboter nachbauen lassen. In diesem Beispiel452 sollen die Roboter als Ziel von Übersetzungsprozessen einer formalen Sprache dienen, die definiert, geparst und in die „Robotersprache“ über-setzt wird. Das Beispiel ist deshalb als Projektphase in einem Kurs über theoretische Informatik anzusiedeln und erfordert einige Vorkenntnisse und – je nach Komplexität der definierten Sprache – auch einiges an Zeit. Ziel ist es also, eine erweiterbare Turtlegrafik für LEGO-Mindstorms-Roboter453 zu schreiben, die

• die spielerischen Elemente der Roboter für den Unterricht nutzt,

• die Grundelemente einer Computersprache am konkreten Beispiel einführt: Editor, Parser und (rekursiver) Interpreter werden „gebaut“,

• die Möglichkeiten der OOP ausnutzt und

• Testmöglichkeiten am Bildschirm vorsieht. Unter einer Turtle versteht man ein computergesteuer-tes Modell, das ähnlich wie eine Schildkröte aussieht, einen Stift trägt und sich bewegen kann. Je nach Aus-bau „versteht“ das Modell unterschiedliche Befehls-sätze, die seine Bewegungen steuern. Bei seinen Be-wegungen hinterlässt die Turtle bedingt durch den Stift eine „Spur“, die eine Zeichnung erzeugt.

449 z. B. mit NQC 450 Was etwas langsam und fehlerträchtig ist, aber den Schülerinnen und Schüler besonders dann viel Vergnügen macht, wenn sich mehrere Geräte im Raum befinden. 451 [Bra93] 452 Das Beispiel stammt aus einem N21-Projekt über Roboter und robotische Teleskope, das ich für diese nieder-sächsische Initiative entwickelt habe. 453 Grundlage dieses Beispiels sind [Mod92b], [Mod98] und [Mod00]


Eine funktionsfähige Turtle zu bauen ist mechanisch nicht gerade einfach.

• Entscheidend ist die Position des Stifts möglichst im Drehpunkt des Modells (was beim abgebildeten Primitivmodell nicht der Fall ist),

• eine funktionsfähige Einrichtung zum Heben und Senken des Stifts (fehlt beim Modell, wird aber durch „Kippen“ bei Vorwärtsbewegungen teilweise realisiert),

• eine genaue Winkelteilung, die stark von der Mechanik und dem Untergrund abhängt. Entsprechend muss das Modell oft „geeicht“ werden.

Um einen Eindruck von den Möglichkeiten des Systems zu erhalten folgt hier ein Screenshot454 von der ScreenTurtle, die zum Testen der Programme dient:

Das entsprechende Programm lautet:

W 20 ( W 36 ( W 4 ( V 100 R 90 ) R 10 ) V 120 R17 ) $

454 Grundlage dieses Beispiels sind [Mod92b], [Mod98] und [Mod00]

Geschachtelte Schleifen.Innen wird ein Rechteck gezeichnet.


Zur Realisierung ist es erforderlich

• ein Menüsystem mit Delphi zusammenzustel-len, das eine einfache Dateiverwaltung für Texte realisiert (editieren, laden, speichern),

• die geschriebenen Programmtexte auf syntak-tische Korrektheit zu überprüfen und ggf. Feh-ler anzuzeigen und

• die „übersetzten“ Programme richtig zu inter-pretieren.

Der erste Punkt lässt sich leicht mithilfe vorhandener Delphi-Komponenten innerhalb eines Menü-Systems realisieren. Interessanter ist schon die Programmier-sprache. Wir müssen Programmtexte schreiben, übersetzen und ausführen können. Dazu benutzen wir das zweite Untermenü. Das dritte dient zur Um-schaltung zwischen der „echten“ LEGO-Turtle und dem Bildschirmmodell u. Ä. Um die Programmtexte übersetzen zu können, benötigen wir eine Sprachdefinition, die wir über Syntaxdiagramme geben:

Programm: „LEGO-Logo

für Arme“

Befehl: Zeichenbefehl

Kontrollbefehl

Zeichenbefehl: ZahlV

ZahlR

ZahlL

Kontrollbefehl:

Zahl:

0 1 2 8 9 ...

Vorwärts-, Rechts- und Links-Befehle

ZahlW Befehl ( )

Befehl $


Da die Programme innerhalb der Schleifen geschachtelt werden können, ist ein Kel-lerautomat zur Analyse der Klammerstruktur erforderlich. Die restlichen syntaktischen Konstrukte können von einem einfachen endlichen Automaten analysiert werden, der ggf. Fehlermeldungen produziert. Der endliche Automat wird durch seinen Transiti-onsgraphen beschreiben. (Die etwas eigenwillig notierten Kellerbefehle sind fett her-vorgehoben.) Eingabealphabet: IE = {V,R,L,W,0,1,2,3,4,5,6,7,8,9,(,),$} Zustandsmenge: IS = {s0, s1, s2, s3, s4, s5, s6, s7, se, sf} Überführungsfunktion des Kellerautomaten: [(,s0,#] [s0,(#] [(,s0,(] [s0,((] [),s0,(] [s0, ] [ ,s0,#] [se, ]

Parser für „LEGO-Logo für Arme“:

V v R v L 0 v 1 v...v 9

V v R v L

( ^ Keller.push(“ (“ )

s0 S1 s7

0 v 1 v...v 9

se

s2

$

W W

s3

0 v 1 v...v 9

0 v 1 v...v 9

s4

( ^ Keller.pull=“)“Keller.erstes=“)"

( ^ Keller.pull=“)“Keller.erstes=“#"

W

S5 s6

V v R v L 0 v 1 v...v 9

0 v 1 v...v 9

V v R v L

W

$

sf alle nicht angege-benen Übergänge führen in den Fehlerzustand


Fehlermeldungen des entsprechenden Parsers sehen dann z. B. so aus: Für die Interpretation des Programms wählen wir eine „reduzierte“ Version des Quell-textes, in der überflüssige Zeichen (Leerzeichen, Zeilenwechsel, ...) weggelassen worden sind. Als Ziele der Befehle stehen eine Bildschirmturtle und eine LEGO-Turtle zur Verfügung, die über die gleichen Befehlssätze („Methoden“) verfügen. Mit diesen Methoden kann der Interpreter implementiert werden. Damit geschachtelte Schleifen abgearbeitet werden können, interpretiert der Interpreter (Befehls-)Zei-chenketten. Trifft er auf eine Schleife, dann sucht er sich den Schleifenkörper zu-sammen (der weitere Schleifen enthalten kann) und ruft sich selbst mit diesen Be-fehlen wieder auf. Der Interpreter arbeitet also rekursiv. Für den korrekten Ablauf des Programms benötigt man weitere Methoden, z. B. um den Inhalt von Memofeldern zu kopieren, Anfangswerte zu setzen und vor allem, um die LEGO-Turtle zu „eichen“. Die von der Turtle zurückgelegt Strecke wird über eine Wartezeit definiert. Sie hängt aber natürlich auch von der Bauart der Turtle und dem Untergrund ab. Bei Vorwärtsbewegungen ändert sich nur die Größe der Figuren durch diese Werte. Bei Drehungen hängt der Drehwinkel und damit die Form der Zeichnungen stark von ihnen ab. Ich lasse meistens ein Rechteck zeichnen und prü-fe, ob die Turtle danach in die gleiche Richtung zeigt. Damit kann man ganz gut die Zeit für eine volle Umdrehung korrigieren. Den entsprechenden Faktor für Vor-wärtsbewegungen sollte man so einstellen, dass die LEGO-Turtle-Figuren zur Schrittweite der Bildschirmturtle passen. Der Umgang mit verschiedenen Programmiersprachen gehört zumindest zur Infor-matik-Prüfungsfachkursfolge. Zu fragen ist dann natürlich, wie diese verschiedenen Sprachen „erfahren“ werden sollen. Eine der Möglichkeiten besteht m. E. darin, selbst eine solche – natürlich stark vereinfachte – Sprache zu schreiben455. Der Charme dieses Vorgehens liegt darin, dass in der bekannten Umgebung weiter ge-arbeitet werden kann und sich all die bekannten Teilprobleme des Theoriekurses der Schulinformatik zwanglos ergeben – aus der Anwendung. Es werden also zwei Flie-gen mit einer Klappe geschlagen. Damit gewinnt man Zeit – und die brauchen wir dringend für die Projektphasen. Sprachdefinitionen lassen sich auf sehr unterschiedlichem Niveau umsetzen. Sie dienen deshalb auch zur Binnendifferenzierung in den Kursen, ermöglichen gemein-sames Arbeiten am gleichen Thema bei sehr unterschiedlichem Zeiteinsatz. Das

455 Das funktioniert auch ganz gut mit reduzierten deklarativen Sprachen wie „Miniprolog“ oder „MiniSQL“.


Editieren und Ändern von Programmen, das Speichern und Laden u. Ä. lässt sich mit den integrierten grafischen Programmentwicklungssystemen durch wenige Maus-klicks und einige Programmzeilen umsetzen. Diese intellektuell nicht gerade her-ausfordernde Funktionalität hat also inzwischen den gebührenden – geringen – Stel-lenwert erhalten. In ähnlichen Zeiträumen können deshalb wesentlich an-spruchsvollere Projekte in Angriff genommen werden als früher, ohne auf eine Imp-lementierung der Ideen zu verzichten. Der Informatikunterricht hat deshalb m. E. mit den neuen Möglichkeiten an Wert gewonnen. Haben wir als Lerngruppe z. B. den Grundkurs der Stufe 13 im zweiten Halbjahr, dann stehen wir kurz vor dem Abitur, sollten also bei Gelegenheit bekannte Inhalte wiederholen, aber auf neue nicht verzichten. Folglich bietet sich eine längere Pro-jektphase an, weil bei etwas umfangreicheren Vorhaben unterschiedliche Techniken benutzt werden, wobei sich eine Wiederholung älterer Themen automatisch ergibt. Haben wir bei der technischen Informatik im vorhergehenden Kurs endliche Auto-maten benutzt, dann müssen in diesem Kurs noch die Themen erkennende Automa-ten, zusammen mit Sprachdefinitionen, Parsern, …sowie ggf. Kellerautomaten be-handelt werden, wobei z. B. die schon bekannten Stapel und Listen wieder auftau-chen. Danach kann unser LEGO-Projekt starten. Arbeiten wir zuerst mit einer Screen-Turtle (also auf dem Bildschirm), dann können wir uns ganz auf die Definition und das Parsen der entsprechenden Sprachkon-strukte konzentrieren. Die Implementierung der Turtle-Befehle sollte den Schülerin-nen und Schülern dieser Stufe keine Schwierigkeiten mehr bereiten. Nach Abschluss dieser Phase liegen die Sprache und die erforderlichen Turtle-Methoden fest. In ei-nem zweiten Schritt kann jetzt die LEGO-Turtle gebaut und über einfach zusammen-geklickte Oberflächen gesteuert und getestet werden (s. o.). Es bleibt allein das „handwerkliche“ Problem offen, die Screen-Turtle-Methoden auch für die LEGO-Turtle zu implementieren. Verzichten wir auf geschachtelte Schleifen, dann kann der Parser drastisch verein-facht werden. Berücksichtigen wir die Zustände der LEGO-Sensoren (Druckschalter, Lichtsensoren, …), dann können wir zusätzlich sinnvoll Alternativen oder weitere Schleifenarten in die Sprache einführen, z. B.: IF (Sensor1=0) (R180 V30 R210) Es bestehen also genügend Möglichkeiten, das Projekt sowohl einfacher (und damit kürzer) als auch umfangreicher zu halten oder es über unterschiedliche Teilgruppen-aufgaben anders zu strukturieren. Vor allem aber gibt es mehrere Zeitpunkte, an de-nen das Projekt ggf. auch sinnvoll, also ohne Frustrationen zu hinterlassen, abgebro-chen werden kann. Ziel des Unterrichts ist es, die beim Entwurf und der Implementierung von Program-miersprachen auftauchenden Probleme zu diskutieren und durch Anwendung von Methoden der theoretischen Informatik in einem einfachen Fall zu lösen. Die dabei benötigten Datenstrukturen erfordern nebenbei eine effiziente Wiederholung vorheri-ger Kursinhalte. Unter diesen Voraussetzungen wird zuerst eine eingehende Diskussion der Proble-matik im Unterrichtsgespräch erforderlich sein, wobei die Konsequenzen unter-schiedlicher Syntaxen gegeneinander abgewogen werden. Die Implementierung des Parsers sollte zu diesem Zeitpunkt kein ernstes Problem mehr sein. Schwieriger ist die Interpretation der Sprachkonstrukte, also die Übersetzung der selbst definierten Sprache in Sprachkonstrukte des Roboters. Wählen wir hierfür einen rekursiven In-


terpreter, dann reduziert sich das Problem weitgehend auf das Erkennen der richti-gen Klammerstruktur, und so etwas ist ggf. mit Hilfen gut machbar. Das Schreiben einer Turtlegrafik für den Bildschirm stellt keine besonderen Anforde-rungen und kann parallel z. B. von einer Teilgruppe erledigt werden – wenn so ein System nicht schon vorhanden ist. Der Bau des Roboters ist ein gesondertes Prob-lem. Man kann auf vorhandene Baupläne zurückgreifen, die Aufgabe ebenfalls einer Teilgruppe überlassen oder ein Minimalmodell wählen, wie es sich auf der Abbildung in diesem Kapitel findet. Die Übersetzung von Turtlebefehlen in die Sprache des Ro-boters erfordert dann wiederum Hilfen der oder des Unterrichtenden. Die Unterrichtseinheit wird wie folgt klassifiziert: Thema: Die LEGO-Turtle

Zeitbedarf: ab 15 WStd.

Voraussetzungen: zwei Informatikkurse incl. Datenstrukturen, erkennende endli-che Automaten, ggf. Kellerautomaten

Die Einheit dient der Verdeutlichung der kulturellen Bedeutung des Themas gesellschaftlicher Auswirkungen des Themas zu 10 % rein fachlicher Aspekte zu 90 % Die folgenden Unterrichtsmethoden erfordern an Unterrichtszeit ca. Lehrervortrag: 10 % Unterrichtsgespräch: 20 % Partnerarbeit: Einzelarbeit: Projektarbeit: 70 % Das Thema verdeutlicht die folgenden fundamentalen Ideen:

1. Algorithmisierung 1.1 Entwurfsparadigmen (Branch and Bound, Backtracking, …) 1.2 Programmierkonzepte (Alternative, Iteration, Rekursion, ...) zu 20 % 1.3 Ablauf (Prozess, Nebenläufigkeit, ...): 1.4 Evaluation (Verifikation, Komplexität, ...): 2. strukturierte Zerlegung 2.1 Modularisierung (Methoden, Hilfsmittel, ...) zu 10 % 2.2 Hierarchisierung (Darstellung, Realisierung, ...) zu 10 % 2.3 Orthogonalisierung (Emulation, ...) 3. Formalisierung 3.1 formale Sprache (Syntax, Semantik, ...) 3.2 Automat (Zustand, Übergang, Vernetzung, ...) zu 40% 3.3 Berechenbarkeit (Grenzen, Durchführbarkeit, ...) zu 20 %

Die Delphi-Quelltexte finden sich bei den Materialien am Ende der Arbeit.

4. beispiele - ulb halle: online-publikationen · 433 z. b. ic 74194 wollen wir mit der schaltung...

Documents