Blockly Für Den Schulunterricht Entwurf Und Implementierung Einer Graﬁschen Programmierumgebung Als Teil Einer Lernplattform

Blockly für den Schulunterricht Entwurf und Implementierung einer graﬁschen Programmierumgebung als Teil einer Lernplattform

Bachelorarbeit 27. März 2013

Michael Cyruk ([email protected])

Christian-Albrechts-Universität zu Kiel

Institut für Informatik

Arbeitsgruppe Theoretische Informatik

Betreut durch: Prof. Dr. Thomas Wilke I

Selbstständigkeitserklärung

Hiermit versichere ich an Eides statt, dass ich die vorliegende Arbeit selbständig ver- fasst, keine anderen als die angegebenen Quellen und Hilfsmittel benutzt und in keinem anderen Prüfungsverfahren eingereicht habe.

Kiel, den 27. März 2013 ...... Michael Cyruk INHALTSVERZEICHNIS II

Inhaltsverzeichnis

1 Einleitung 1 1.1 Motivation und Ziele ...... 1 1.2 Aufbau der Arbeit ...... 2

2 Grundlagen und genutzte Konzepte 3 2.1 Graﬁsche Programmierung ...... 3 2.2 Kara – eine Mini-Umgebung ...... 5 2.2.1 Motivation ...... 6 2.2.2 Der Aktor in seiner künstlichen Welt ...... 7 2.2.3 Verschiedene Versionen für verschiedene Ansprüche ...... 9 2.2.4 WarumKara?...... 10

3 Graﬁktechnologien für die Mini-Umgebung 11 3.1 Anforderungen an ein graﬁsches Spielfeld ...... 11 3.2 CanvasoderSVG? ...... 13 3.2.1 Canvas...... 13 3.2.2 SVG - Scalable Vector Graphics ...... 15 3.2.3 Auswertung ...... 18 3.3 Raphaël.js ...... 19

4 lili - Implementierung eines ersten Prototyps 21 4.1 Weitere Technologien ...... 21 4.2 Einführung in die Mini-Umgebung ...... 22 4.2.1 Funktionalität des Spielfeldes ...... 22 4.2.2 Verfügbare Blöcke im Editor ...... 24 4.3 Einordnung in das Gesamtprojekt ...... 27 4.4 Aufbau des Front-Ends ...... 29 4.5 Vom Benutzerprogramm zur Animation: Wie läuft die Simulation ab? . 31

5 Evaluation der Implementierung 35 5.1 Mögliche Verbesserungen der bestehenden Implementierung ...... 35 5.2 Welche Funktionalitäten fehlen noch? ...... 37

6 Fazit und Ausblick 39

A Literaturverzeichnis i

B Materialverzeichnis iv

C Anhang vii 1 EINLEITUNG 1

1 Einleitung

1.1 Motivation und Ziele

Unser Leben ist in der heutigen Zeit mehr von Computern geprägt als jemals zuvor. Egal, ob wir mit PCs, Laptops, Smartphones oder Tablets interagieren: In all diesen Geräten kommen Betriebssysteme und Programme zum Einsatz, die auf den Konzepten der Informatik beruhen. Die Anwenderinnen und Anwender können aber nur sehen, was in der meist grafischen Oberfläche der von ihnen genutzten Maschinen geschieht, die inneren Abläufe bleiben verborgen. Warum aber ein tieferes Verständnis dieser inneren Abläufe und somit der Informatik Teil einer guten Allgemeinbildung sein sollte, wird anhand der Lehrpläne für Schleswig- Holstein [A.20, S. 3][A.21, S. 26] deutlich, die Informatikunterricht in Schulen vorsehen: Schülerinnen und Schüler nutzen zwar Informationstechnik zur Unterhaltung, um In- formationen zu erhalten, oder um mit anderen zu kommunizieren, sie sind sich aber nicht über das Ausmaß der Möglichkeiten bewusst, die ihnen diese Geräte bieten. Eben- so wenig kennen sie die genauen Grenzen und Risiken dieser Systeme. Außerdem hat Informatik neben einem persönlichen und gesellschaftlichen Nutzen auch eine Bedeu- tung für die Berufswelt. Heute entwickeln Schülerinnen und Schüler schon in jungen Jahren die Fähigkeit Computer zu bedienen und für ihre Zwecke zu nutzen. Anders als viele Erwachsene haben sie einen lockeren Bezug zu Computersystemen und können so unbefangen und spielerisch die Funktion ebendieser erforschen. Ein Teilbereich der Informatik ist die Algorithmik und somit auch das Programmieren. Doch wie werden diese Themen am besten vermittelt? Der Schulunterricht bietet nur wenig Zeit dafür, aber die meisten Programmiersprachen sind komplex, so dass eine gewisse Einarbeitungszeit notwendig ist. Es gibt zwar einige Programmierumgebungen die speziell für Kinder und den Einsatz an Schulen entwickelt worden sind, aber diese werden meist lokal ausgeführt und müssen auf allen Computern installiert werden. Lehrer haben allerdings wenig Zeit Software zu installieren und zu warten. Außerdem ist die Computerausstattung an Schulen nicht homogen, es kommen verschiedene Systeme mit unterschiedlich guter Leistung zum Einsatz. Einen immer stärker wachsender Teil der Informationstechnik bilden aber Netzwerke und besonders das Internet, welches auch im Leben von Kindern Einzug gefunden hat. In dieser Bachelorarbeit möchten wir daher eine auf Schülerinnen und Schüler zuge- schnittene Programmierumgebung vorstellen, die webbasiert ist, und so auch diesem Aspekt des multimedialen Alltags gerecht wird. Solch ein Ansatz bietet einige Vorteile: Zum einen stellt sich nicht mehr die Frage, welche Systeme die Software aufgrund der heterogenen Computerausstattung an Schulen unterstützen muss, da die einzigen Voraussetzungen ein Netzwerkzugang und ein Browser sind, in welchem JavaScript ak- tiviert ist. Außerdem muss die Programmierumgebung nicht auf allen Rechnern installiert werden, es genügt ein Server in der Schule oder aber auch gar kein eigener Rechner im Hintergrund, da die Software als externe Dienstleistung Schulen zur Verfügung gestellt werden kann. Ein weiterer Vorteil besteht darin, dass die Programmierumgebung weiter zu einer Plattform ausgebaut werden kann, die Lehrerinnen und Lehrern die Möglichkeit bietet, ihre Kurse direkt zu verwalten, an denen ihre Schülerinnen und Schüler teilnehmen. So könnten im System neue Aufgaben erstellt und gestellt, Lö- sungen eingereicht, Aufgaben korrigiert und der aktuelle Fortschritt sowie die Erfolge mitverfolgt werden. Im Idealfall haben die Nutzerinnen und Nutzer auch von zu Hause 1 EINLEITUNG 2 aus Zugri auf die Software und nicht nur in der Schule vor Ort. Im Kern waren die beiden Hauptziele folglich, eine Programmierumgebung für den Unterricht für den Browser mit Hilfe von HTML und JavaScript zu entwickeln und zusätzlich eine Lernplattform um diese Umgebung herum zu schaen, eine Art virtuelles Klassenzimmer. Diese Arbeit ist letztendlich eine Machbarkeitsstudie, sie soll zeigen, wie die Imple- mentierung einer solchen Programmierumgebung für das Netz technisch verwirklicht werden kann. Die entstandene Software mit dem Namen lili hat daher zum Zeitpunkt des Verfassens dieser Arbeit noch prototypischen Charakter. Für die zentrale Pro- grammierumgebung sollten der grafische Code-Editor Blockly und die Konzepte der Programmierumgebung Kara miteinander verbunden werden. Warum dies sinnvoll ist, wird in Abschnitt 2 behandelt.

1.2 Aufbau der Arbeit

Diese Bachelorthesis ist im Rahmen eines Bachelorprojektes unter dem Titel Blockly für den Schulunterricht entstanden, an welchem im Wintersemester 2012/2013 zwei Studenten mitgewirkt haben. Diese Arbeit ergibt daher nur in Verbindung mit Gre- gor Große-Böltings Arbeit Blockly für den Schulunterricht. Konzeptionierung und serverseitige Implementierung einer Lernplattform [B.1] einen vollen Überblick über die Konzepte, die Implementierung und die Funktionalität des entwickelten Softwarepro- totyps. Im Laufe des Semesters hat sich auf organische Weise eine Arbeitsaufteilung zwischen uns ergeben, so dass ich eher im Front-End, also clientseitig an der eigentlichen Programmierumgebung gearbeitet habe, während Gregor Große-Bölting serverseitig eine Lernplattform um diese Programmierumgebung konzipiert und implementiert hat. Wie diese digitaler Übungsraum getaufte Plattform entstanden ist, kann in seiner Ar- beit nachvollzogen werden. Außerdem findet sich dort eine technische Einführung in Googles Blockly [B.3]. An einigen Stellen in dieser Arbeit, werde ich daher auf die andere Bachelorthesis verweisen. Trotz der Arbeitsaufteilung befanden wir uns aber im ständigen Austausch und haben uns gegenseitig bei der Erarbeitung der im Folgenden vorgestellten Konzepte unterstützt. Eine vollkommen saubere Trennung ist daher nicht möglich, in dieser Arbeit werden zum Teil gemeinsame Ideen präsentiert. Zusammen mit der Einleitung ist diese Arbeit in sechs Abschnitte unterteilt. Zunächst wird in Abschnitt 2 auf die Grundlagen und Konzepte eingegangen, die wir für unsere Bildungssoftware genutzt haben, und wichtige Begrie werden definiert. Daraufhin gibt es in Abschnitt 3 einen Exkurs in Grafiktechnologien, die im Web eingesetzt werden können, welcher in die Begründung der Wahl einer dieser Technologien für unser Projekt mündet. Erläuterungen meines Anteils an der entstandenen Software lili und deren Implementierung finden sich im Abschnitt 4 danach und anschließend eine Evaluation des aktuellen Standes in Abschnitt 5. Der Hauptteil endet mit einem Fazit in Abschnitt 6. Neben einem Literaturverzeichnis gibt es in dieser Arbeit auch noch ein Material- verzeichnis. Das Literaturverzeichnis listet die benutzten Quellen dieser Arbeit auf, während das annotierte Materialverzeichnis jeweils mit einer kurzen Erklärung auf weiterführendes Material verweist. Aufgrund dieses Vorgehens finden sich im Fließtext zwei verschiedene Arten von Verweisen mit eigener Nummerierung. Weitere Materialien sind hinten im Anhang beigefügt. 2 GRUNDLAGEN UND GENUTZTE KONZEPTE 3

2 Grundlagen und genutzte Konzepte

Programmierumgebungen für Schülerinnen und Schüler sind keine neue Idee, sondern haben eine lange Tradition. Außerdem konzentrierte sich das Bachelorprojekt, aus welchem diese Arbeit entsprungen ist, auf die technische Implementierung einer Lernplatt- form und nicht auf die Entwicklung eines didaktischen Konzeptes. Daher wurde das Ziel verfolgt, bewährte Ansätze zu vereinen. Die verwirklichten Konzepte entstammen also nicht dem luftleeren Raum, weshalb in diesem Abschnitt dargelegt wird, welche Grundlagen genutzt werden. Die zentralen Begrie sind hierbei graﬁsche Programmie- rung und Mini-Umgebung, deren Bedeutung für unser Projekt wir an dieser Stelle klären.

2.1 Graﬁsche Programmierung

Die meisten Programmiersprachen, die genutzt werden um kleine bis komplexe An- wendungen zu entwickeln, sind textbasiert, das heißt sie erfordern die Eingabe von Zeichenketten über die Tastatur eines Computers. Anweisungen, Funktionsdefinitio- nen, Prozeduraufrufe und Kontrollstrukturen, werden anhand einer künstlichen Syn- tax zueinander in Beziehung gestellt. Diese drückt die komplexen Zusammenhänge, die ein Programm zu beschreiben versucht, in einer eindeutigen und strukturierten Wei- se aus. Je nach Programmiersprache geschieht dies anhand von runden, eckigen oder geschweiften Klammern, Trennzeichen wie Punkt, Doppelpunkt oder Semikolon oder aber auch über Einrückung durch Leerzeichen und Tabulatoren. Diese Art der Programmierung hat den großen Nachtteil, dass Syntaxfehler sehr wahr- scheinlich sind, da schnell ein Semikolon oder eine Klammer vergessen werden. Für Programmieranfänger ist dies besonders schwierig, da das Erlernen von strukturier- tem Denken und der Vertiefung des Verständnisses für Programmlogik oft durch solche Flüchtigkeitsfehler unterbrochen und so gestört werden kann. Grafische Programmierung, oder auch visuelle Programmierung, ist ein Ansatz, der dieses Problem löst. Die Erstellung von Programmen erfolgt hierbei über grafisch re- präsentierte Elemente und nicht nur über Zeichenketten. Programme werden primär mit der Maus erstellt und nicht der Tastatur. Auf diese Weise sollen Syntaxfehler ausgeschlossen werden. Es gibt verschiedene Ansätze für derartige Programmiersprachen, im Folgenden soll der Begri aber nur diejenigen Sprachen bezeichnen, die imperative Programmierung auf grafische Art und Weise nach einem bausteinähnlichem Prinzip ermöglichen. Der bekannteste Vertreter dieser Art von Sprachen ist Scratch, eine visuelle Pro- grammierumgebung, mit der interaktive, multimediale Projekte erstellt werden können [A.19, S. 16:1]. Zielgruppe sind Kinder und Jugendliche von acht bis sechzehn Jahren. Es werden zweidimensionale Objekte, sogenannte Sprites, vor einem Hintergrund, der Bühne, mit Hilfe eines Programmes animiert. Dieser Vorgang erfolgt bei Scratch grafisch: Es werden Blöcke zusammengezogen, welche Anweisungen, Ausdrücke, Kontroll- strukturen und ähnliches darstellen [A.19, S. 16:2][A.26, S. 63]. Die Form der Blöcke suggeriert dabei ähnlich einem Puzzleteil, wie diese kombiniert werden können. Man kann daher mit der Maus nur solche Blöcke zusammenziehen, die auch zusammen passen, Syntaxfehler werden ausgeschlossen und Programmieren kann spielerisch durch Probieren erlernt werden. Dieser Mechanismus, der den Nutzerinnen und Nutzern so- 2 GRUNDLAGEN UND GENUTZTE KONZEPTE 4 fort eine visuelle Rückmeldung, über die korrekte Struktur ihrer Programme gibt, erfüllt somit die Rolle, die sonst in textuellen Sprachen durch die Syntax übernommen wird [A.19, S. 16:7][A.26, S. 63]. Ursprünglich ist Scratch eine Desktopanwendung, allerdings befindet sich eine auf Flash basierende Version in der Betaphase und kann unter [B.22] ausprobiert werden. Abbildung 1 zeigt diese Version in Aktion. Eine Reimplementie- rung von Scratch namens snap! (früher BYOB, englisch für „Build Your Own Blocks“) stellt eine Erweiterung dar, die an weiterführenden Schulen und sogar an Universitäten Anwendung finden soll. Unter anderem werden hier Datenstrukturen wie Listen einge- führt und es ist möglich Prozeduren zu definieren. Neben einer Desktopversion gibt es snap! in JavaScript umgesetzt im Netz unter [B.24].

Abbildung 1: Scratch 2.0: Mit Hilfe des aus Blöcken bestehenden Programms (rechts) wird eine Katze animiert, die endlos zwischen den Kanten der Bühne hin- und herläuft (links).

Scratch diente als Vorbild für den App Inventor [B.20], der es ermöglicht mit Hilfe von Blöcken Programme für das mobile Betriebssystem Android herzustellen. Dieser wiederum hat Googles neue, quelloene grafische Programmiersprache Blockly [B.3] stark beeinflusst. Eigentlich handelt es sich bei Blockly nicht um eine reine grafische Pro- grammiersprache, sondern vielmehr um einen in JavaScript implementierten Editor, denn mit Blockly erstellter Code kann beispielsweise als JavaScript oder in Python umgewandelt exportiert werden. Das Grundkonzept von Scratch, die an Puzzleteile erinnernden Blöcke, bleibt bestehen, wie Abbildung 2 zeigt. Blöcke werden durch Kli- cken und Ziehen mit der Maus miteinander verbunden, die Tastatur muss nicht benutzt werden. Blockly befindet sich noch in einem frühen Entwicklungsstadium, es gibt noch keine finale Version [A.13]. Außerdem stellt Blockly keine fertige Bildungssoftware dar, kann aber als Komponente für ein solches Vorhaben genutzt werden [A.11]. Blockly bringt eine Reihe vorgefertigter Komponenten mit, unter anderem Blöcke für Kon- trollstrukturen, Logik und Prozeduren, welche modular, je nach Bedarf in den Editor 2 GRUNDLAGEN UND GENUTZTE KONZEPTE 5 geladen werden können. Ebenso können relativ einfach neue, benutzerdefinierte Blöcke angelegt werden.

Abbildung 2: Blockly: Die Demo Maze demonstriert die Nut- zung von Blockly in Verbindung mit einem graﬁschen Spiel- feld. Ziel ist es die gelbe Spielﬁgur ins Ziel zu führen.

Zusammenfassend stellen graﬁsche Programmiersprachen also eine erhebliche Erleich- terung für den Programmieranfänger dar. Aus diesem Grund möchten wir für unsere Lernsoftware diesen Ansatz nutzen. Wegen der einfachen Erweiterbarkeit bietet uns Blockly eine gute Grundlage, um diese zu verwirklichen. Einen technischen Einblick in Blockly gewährt Gregor Große-Bölting in [B.1]. Die für unsere Implementierung relevanten Blöcke werden dagegen in dieser Arbeit in Ab- schnitt 4.2 genauer erläutert.

2.2 Kara – eine Mini-Umgebung

Wie bereits erwähnt, stellt die Einführung in das Programmieren über eine konventionelle Programmiersprache und professionelle Programmierumgebungen für Anfänger oft eine große Hürde dar. Das Beherrschen der korrekten Syntax einer Sprache und das Verstehen von Fehlermeldungen, die durch einen Übersetzer ausgegeben werden, haben großes Frustpotenzial. Wenig anschauliche, abstrakte Aufgaben können zusätzliche Probleme bereiten und demotivieren. Für einen spielerischen Einstieg in das Programmieren ist es daher nötig, dieses Maß an Komplexität zu reduzieren. Sogenannte Mini-Umgebungen sollen dieser Aufgabe gerecht werden. Diese zeichnen sich für Reichert et. al. [A.25, S. 10–11][A.24, S. 309] 2 GRUNDLAGEN UND GENUTZTE KONZEPTE 6 im Gegensatz zu regulären Entwicklungsumgebungen unter anderem durch folgende Eigenschaften aus: ansprechende Spielwelt Die Haupteigenschaft der Mini-Umgebung ist die Existenz einer künstlichen Welt, welche mit Hilfe eines Programmes manipuliert werden kann. Dies geschieht allerdings nicht direkt, denn im Zentrum dieser Welt steht eine Spielﬁgur, auch Aktor genannt, welche durch ein Programm gesteuert werden kann. Auf diese Weise wird der Schülerin und dem Schüler die Möglichkeit geboten, sich direkt in die Figur hineinzuversetzen und aus ihrer Sicht den Pro- grammablauf mitzuverfolgen. visuelle Darstellung des Programmablaufs Die Aktionen, die ein Programm be- wirkt, werden visuell dargestellt und geben der Nutzerin oder dem Nutzer eine direkte Rückmeldung über die Struktur und Semantik des erstellten Programms. einfacher Sprachkern Es wird entweder eine Programmiersprache eingesetzt, die von vornherein nur einen geringen Sprachumfang besitzt und schnell erlernt werden kann, oder eine konventionelle Sprache, aus der nur die nötigsten Konstrukte übernommen werden, die gerade ausreichen, um einen Aufgabensatz sinnvoll bearbeiten zu können. kurze Einarbeitungszeit Bereits nach kurzer Zeit sollen erste Programmiererfolge sichtbar werden. So werden Berührungsängste abgebaut und Frust vermieden. konkrete Aufgaben Die Problemstellung muss einfach und klar formuliert werden können. Schwierig zu deﬁnierende, abstrakte Aufgaben sind kaum zu verstehen. Konkrete, alltagsnahe und anschauliche Aufgabenstellungen sind daher daher zu bevorzugen. Eine Mini-Umgebung soll es ermöglichen solche Aufgaben zu stellen.

Das Konzept der Mini-Umgebung ist nicht neu. Die bekanntesten, frühen Vertreter sind Turtle Geometry und Karel the Robot. In Turtle Geometry wird mit Hilfe der Programmiersprache Logo eine Schildkröte gesteuert, die sich frei in einer leeren, zwei- dimensionalen Welt bewegen kann und dabei eine Spur nachzeichnet oder nicht. Dieser einfache Ansatz ermöglicht Kindern das Zeichnen von komplexen Formen und somit einen spielerischen Einstieg in die Geometrie [A.25, S. 11, 134–135]. Karel the Robot hat diesen Ansatz erweitert: Der Protagonist dieser Mini-Umgebung ist ein Roboter, der sich nicht frei, sondern auf einer in einzelne, diskrete Felder unterteilten Welt von Feld zu Feld bewegen kann. Anders als die Schildkröte in Turtle Geometry ist der Roboter nicht blind, sondern kann Objekte in seiner Welt erkennen, wie zum Beispiel Wände [A.25, S. 12, 135–136]. Im Folgenden möchten wir aber nur näher auf die jüngere Mini-Umgebung Kara eingehen, die in gewissem Sinne eine Erweiterung von Karel ist, da wir letztendlich deren Konzepte in unserer webbasierten Lernsoftware realisiert haben.

2.2.1 Motivation

Kara ist eine Umgebung zum Erlernen des Programmierens, die an der ETH Zürich entstanden ist. An der Erarbeitung des Konzeptes und der Implementierung arbeiteten unter anderem Jürg Nievergelt, Werner Hartmann, Raimond Reichert, Markus Bränd- le und Tobias Schlatter [A.30]. Die Motivation für die Entwicklung Karas beschreiben 2 GRUNDLAGEN UND GENUTZTE KONZEPTE 7

Reichert. et. al. in einer Monografie [A.25] und einigen Artikeln [A.3, A.15, A.24]. Diese liegt darin begründet, dass unsere heutige Informationsgesellschaft die Beherrschung von Informations- und Kommunikationstechnologien erfordert und Schulen diesem Be- darf gerecht werden müssen. Doch wie gewährt man Schülerinnen und Schülern einen spannenden und einsteigerfreundlichen Einblick in die Programmierung? Denn aufgrund der Schnelligkeit des technologischen Wandels sollen langlebige Konzepte der Informatik und Algorithmik im Vordergrund stehen und nicht die Anwendung von Software, welche schnell obsolet werden kann [A.3, S. 201][A.24, S. 209]. Konventionelle Programmiersprachen erschienen den Entwicklern ungeeignet, da diese zu komplex seien. Der Schulunterricht biete kaum Zeit für die erforderliche, lange Einarbeitungszeit. Außerdem genüge es nicht mehr Schülerinnen und Schüler ein rein textbasiertes “Hallo Welt!”-Programm schreiben zu lassen, da dieses nicht mit ihrer Alltagserfahrung mit elektronischen Geräten übereinstimme. Kinder wüchsen mit multimedialen Inhalten auf und würden entsprechende Entwicklungsumgebungen erwarten. Intuitive, grafische Entwicklungsumgebungen könnten Schülerinnen und Schüler zudem beim Lernen unterstützen [A.3, S.201–202][A.24, S.309]. Weiterhin wurde die Annahme getroen, dass man einen Programmieransatz wählen sollte, der auf grundlegenden Theorien der Informatik beruht. Die Entwickler entschie- den sich für Automaten, die ein fundamentales Konzept der Informatik darstellen. Automaten können nicht nur leicht anhand von Alltagsgeräten erklärt, sondern auch komplett grafisch mit der Maus konstruiert werden. Syntaxfehler textbasierter Pro- grammiersprachen sind daher ausgeschlossen. Des Weiteren können während der Aus- führung aktuelle Zustände und Zustandsübergänge farblich hervorgehoben werden, so dass der Programmablauf visuell nachverfolgt werden kann. Die Umsetzung des Auto- matenkonzeptes ist auf der linken Seite von Abbildung 3 zu erkennen.

2.2.2 Der Aktor in seiner künstlichen Welt

Auf der rechten Seite der Abbildung 3 wird Karas Welt dargestellt. Reichert et. al. [A.25, S. 28–29][A.3, S. 203][A.15, S. 137][A.24, S. 311–312] liefern eine genauere Be- schreibung: Als Aktor dient Kara, ein Marienkäfer, der in einer ﬂachen Welt lebt, die die Form eines Torus hat, aber rechteckig dargestellt wird. Verläßt der Käfer auf der einen Seite also das Spielfeld, kommt er an der entgegengesetzten Seite wieder heraus. Die Welt ist zudem in diskrete Quadrate unterteilt, die durch Gitterlinien getrennt sind. Neben Kara gibt es nur drei weitere Gegenstände, die auf einem Feld vorkommen können:

Baumstümpfe Ein Baum stellt ein nicht überwindbares Hindernis dar. Kein anderer Gegenstand kann auf einem Feld liegen, auf dem sich bereits ein Baumstumpf beﬁndet. Kleeblätter Ein Feld, das mit einem Kleeblatt versehen ist, verhält sich für den Kä- fer wie ein leeres Feld, das heißt er kann es betreten. Kleeblätter können dafür im Gegensatz zu Baumstümpfen aufgesammelt und auf leeren Feldern abgelegt werden. Pilze Fliegenpilze lassen sich anders als Bäume durch den Käfer verschieben, wenn hinter dem Pilz ein leeres oder ein mit einem Kleeblatt versehenes Feld ist. Pilze 2 GRUNDLAGEN UND GENUTZTE KONZEPTE 8

Abbildung 3: Die Mini-Umgebung Kara (verfügbar unter [A.30]): visueller Editor zum Programmieren mit Automaten (links) und die Welt des Marienkäfers (rechts) mit Lösung der Aufgabe “Wand entlang” aus [A.25, S. 36–38].

können jedoch nicht über einen Baumstumpf geschoben werden. Auch zwei Pilze in einer Reihe zu verschieben ist unmöglich.

Das einzige Objekt, welches in der Welt direkt manipuliert wird, ist der Marienkäfer Kara, der über lediglich fünf Aktionen verfügt, über die er gesteuert werden kann:

Kara kann einen Schritt in seine Blickrichtung tun, solange kein Hindernis den • Weg blockiert.

Der Wechsel der Blickrichtung erfolgt durch eine Drehung um 90¶. Kara kann • sich links- oder rechtsherum auf der Stelle drehen.

Schließlich kann Kara Kleeblätter auch noch aufsammeln und diese auf leeren • Feldern auch wieder platzieren. Kara verfügt von Anfang an über einen unbe- grenzten Vorrat an Kleeblättern.

Der Käfer kann nicht genau bestimmen, auf welchem Feld er steht oder in welche Himmelsrichtung er schaut, allerdings besitzt er fünf Sensoren, mit deren Hilfe er sich orientieren kann:

Kara kann erkennen, ob sich vor, links oder rechts von ihm ein Baum beﬁndet. • Pilze kann der Käfer nur sehen, wenn sie direkt vor ihm liegen. • Außerdem kann Kara spüren, ob ein Kleeblatt unter ihm liegt. • 2 GRUNDLAGEN UND GENUTZTE KONZEPTE 9

Trotz all dieser Einschränkungen lassen sich mit der Mini-Umgebung Kara bereits schwierige Aufgaben lösen. Da der Käfer sowohl die Welt wahrnehmen als auch manipulieren kann, bietet die Welt sogar die Möglichkeit diese als externen Speicher zu nutzen.

2.2.3 Verschiedene Versionen für verschiedene Ansprüche

Letztendlich bietet die ursprüngliche Kara-Variante aber doch nur einen einfachen Ein- stieg in die Informatik. Für die Vermittlung spezieller Themen und einen Übergang zu echten Programmiersprachen wurden weitere Versionen entwickelt. Zu diesen zählen unter anderem:

MultiKara Zur Einführung in die Denkweise der nebenläuﬁgen Programmierung, die einige Tücken aufweist, wird Kara auf vier Marienkäfer erweitert, die sich eine Welt teilen und jeweils über einen eigenen Automaten verfügen. Verschiedene Konzepte wie Nichtdeterminismus, Scheduling und Synchronisation sollen hier anschaulich vermittelt werden [A.3, S. 203][A.25, S. 95].

TuringKara Universelle Berechnungsmodelle helfen zu zeigen, welche Probleme bere- chenbar sind und welche nicht. Erstaunlich für viele Schülerinnen und Schüler ist, dass diese mit sehr einfachen Operationen auskommen, solange unbegrenzte Zeit und Speicher vorausgesetzt werden können. TuringKara soll unter anderem dies vermitteln. Anders als in Kara wird kein Käfer sondern ein Lese- und Schreibkopf programmiert, der auf einer Turingmaschine arbeitet, die als zweidimensionales Band dargestellt wird [A.3, S. 206][A.25, S. 83].

LegoKara Diese Variante überträgt das Weltprinzip aus Kara auf die reale Welt in Form von Lego Mindstorms Robotern. Diese werden wiederum mit Hilfe der bekannten Automaten programmiert. Auch ein Roboter kann sich wie Kara nur in Schritten von 90¶ um sich selbst drehen und bringt weitere Einschränkungen mit. So kann er keine Objekte aufheben oder ablegen. Mit Hilfe von Sensoren kann er aber Wände erkennen und einen dunklen von einem hellen Untergrund un- terscheiden. LegoKara soll nicht nur einen praktisch spielerischen Ansatz bieten, sondern auch Probleme aufzeigen, die bei der Übertragung von Modellen auf die reale Welt auftreten können, da die Sensoren nicht immer so akkurat reagieren wie in der künstlichen Welt [A.15, S. 140][A.24, S. 312–313].

JavaKara Da Mini-Umgebungen nicht immer einen sanften Übergang zu echten Pro- grammiersprachen bieten, wurde JavaKara entwickelt, um diese Kluft zu schlie- ßen. In JavaKara wird dieselbe Welt manipuliert wie in Kara, allerdings mit der objektorientierten Sprache Java. Durch die gewohnte Kara-Umgebung kön- nen sich Schülerinnen und Schüler zunächst anhand einfacher Beispiele an die Syntax der Sprache und die Fehlermeldungen des Compilers gewöhnen, bevor sie das Programmieren im Kleinen in einer imperativen Sprache erlernen [A.3, S. 123–124][A.3, S. 208][A.15, S. 139][A.24, S. 313].

Dies ist nur eine kleine Auswahl der Kara-Varianten. Eine in Hinblick auf diese Arbeit ebenfalls relevante Version ist ScratchKara, welche einen ähnlichen Ansatz verfolgt wie unser Prototyp, allerdings nicht webbasiert ist, sondern lokal auf einem Computer mit einem Java Runtime Environment ausgeführt wird [A.29]. Abbildung 4 vermittelt einen 2 GRUNDLAGEN UND GENUTZTE KONZEPTE 10

Eindruck der grafischen Oberfläche. Weitere Versionen und Informationen zu Kara sind unter [A.30] zu finden. .

Abbildung 4: ScratchKara (verfügbar unter [A.29])

2.2.4 Warum Kara?

Kara hat sich als Lernsoftware im Unterricht bewährt, mit Kara wurden gute Erfah- rungen gesammelt und die Software wird an vielen Schulen eingesetzt. Nach wenigen Stunden Einarbeitungszeit sollen die Nutzerinnen und Nutzer bereits nicht-triviale Pro- bleme lösen können. Der einfache Einstieg und die interaktive, visuelle Repräsentation helfen zudem Berührungsängste abzubauen [A.3, S. 209][A.15, S. 139][A.24, S. 312]. Wegen dieser guten Rückmeldungen haben wir für unsere webbasierte Lernplattform beschlossen, das Weltkonzept aus Kara zu übernehmen. Mit Hilfe von Blockly werden wir außerdem der Anforderung nach einer ansprechenden visuellen Darstellung von Programmen gerecht, die keine Möglichkeit für frustrierende Syntaxfehler bietet, genau so wie die Automaten in Kara. Anders als bei Kara setzen wir dagegen von Anfang auf das imperative Programmierparadigma. Weitere Abweichungen, die einige Details der Welt betreen, werden in Abschnitt 4.2 geklärt. Vor der eigentlichen Implementierung waren aber noch einige technologische Entscheidungen zu treen, die das Front-End betreen. Diese werden im folgenden Abschnitt genauer beleuchtet. 3 GRAFIKTECHNOLOGIEN FÜR DIE MINI-UMGEBUNG 11

3 Graﬁktechnologien für die Mini-Umgebung

In Abschnitt 2.2 haben wir mit Kara bereits eine Mini-Umgebung vorgestellt, an der wir uns für unsere Implementierung orientieren möchten. Diese besteht aus zwei Teilen, dem Programmeditor, für den wir die grafische Programmiersprache Blockly benutzen, welche Gregor Große-Bölting in seiner Bachelorarbeit [B.1] vorstellt, und dem Spielfeld, auf dem mit Hilfe der in Blockly erstellten Programme wie in Kara die Aktionen eines Käfers simuliert werden. Außerdem dient das Feld den Schülerinnen und Schülern zur Kontrolle ihrer selbst erstellten Algorithmen. Da es nicht nur eine Möglichkeit gibt, solch ein Spielfeld auf einer Webseite zu verwirklichen, ist es nötig verschiedene Technologien gegeneinander abzuwägen. Im Folgenden werden wir zunächst auf die Anforderungen an die grafische Implementierung eines Spielfeldes eingehen, daraufhin mit Canvas [B.12] und Scalable Vector Graphics [B.25] den Einsatz von zwei heute verfügbaren browserbasierten, animierbaren Grafiklösungen mit Hilfe dieser Anforderungen gegeneinander abwägen, und schließlich mit Raphaël.js [B.2] eine Grafikbibliothek vorstellen, die das Zeichnen von Vektorgrafiken im Browser erleichtert.

3.1 Anforderungen an ein graﬁsches Spielfeld

Die Anforderungen an die Grafikimplementierung ergeben sich vor allem durch den Anspruch auf Benutzerfreundlichkeit und Oenheit der Software, die Einschränkungen, die die Wahl des Webbrowsers als Plattform mit sich bringt, und das zugrunde liegende Modell der Spielwelt. Der Ansatz für das Spielfeld ist hierbei sehr stark an den von Kara angelehnt. Wie bei Reichert et. al. beschrieben [A.25, S. 28–29] kann eine Spielfigur, ein Käfer, programmiert werden, der mit Objekten wie Pilzen und Kleeblättern in seiner Umwelt interagiert. Diese wird wiederum als Rechteck dargestellt, welches in einzelne quadra- tische Felder unterteilt ist. Die in Abbildung 5 gezeigte Oberfläche für die Spielwelt bietet zahlreiche Optionen für die Nutzerin und den Nutzer zur Manipulation des Spiel- feldes und zur Navigation in diesem. Unter anderem kann es vergrößert und verkleinert werden. Auch seine Dimensionen lassen sich anpassen. Objekte können durch einfaches Klicken und Ziehen auf dem Spielfeld bewegt, gelöscht oder neu erstellt werden. Die Spielfigur kann manuell über Knöpfe bewegt werden. Ebenso kann der Programmab- lauf gesteuert werden bis hin zu einer Einstellmöglichkeit für die Geschwindigkeit der Animation. Um eine Grafiklösung mit ähnlichem Funktionsumfang im Webbrowser anbieten zu können, ist es vor der Implementierung notwendig einen Ansatz zu wählen, der es ermöglicht zumindest einen Teil dieser Möglichkeiten dort umzusetzen. Hieraus ergeben sich nun einige Anforderungen:

Browserkompatibilität Die Graﬁklösung sollte möglichst viele Webbrowser unter- stützen, zumindest aber diejenigen, die auch Blockly unterstützt.

Performanz Da das Projekt browserbasiert ist, ist es auf vielen verschiedenen Platt- formen lauähig, die zum Teil mit sehr unterschiedlicher Hardware ausgestattet sind. Die Software sollte auch in Hinblick auf die Ausstattung der Schulen, die 3 GRAFIKTECHNOLOGIEN FÜR DIE MINI-UMGEBUNG 12

Abbildung 5: Karas Spielfeld: Elemente können jederzeit einfach durch Klicken und Ziehen verschoben werden.

diese einsetzen möchten, auf Computern mit geringerer Leistung auszuführen sein. Skalierbarkeit Das Spielfeld soll mit der Fenstergröße des Browsers skaliert werden können. Außerdem soll es der Nutzerin und dem Nutzer der entwickelten Soft- ware über die Lernumgebung möglich sein, eigene Aufgaben zu erstellen. Um diese Option möglichst oen zu halten, wird die Spielfeldgröße nicht beschränkt. Dies erfordert bei großen Spielfeldern die Möglichkeit Abschnitte des Spielfeldes vergrößern zu können, um Details zu erkennen. Animation Die Bewegung der Spielfigur und weiterer Elemente auf dem Spielfeld soll möglichst flüssig und nicht abgehackt verlaufen, um ansprechend zu wirken. Animationen können der Nutzerin und dem Nutzer auch Rückmeldung über den Ablauf seines Programms geben, die über die bloße Position der Objekte auf dem Spielfeld hinausgeht. So kann zum Beispiel animiert werden, dass die Spielfigur gegen ein nicht passierbares Objekt zu laufen versucht. Allerdings sollte Animati- on mit Bedacht eingesetzt werden, um nicht zu sehr abzulenken sondern vor allem den Programmablauf zu verdeutlichen. In der beschriebenen Welt beschränkt sich Animation daher auf die Spielfigur und diejenigen Objekte, welche sie in ihrer unmittelbaren Umgebung manipuliert. Manipulierbarkeit Das Spielfeld soll während der Lösung einer Aufgabe manipuliert werden können, das heißt sowohl die Größe des Spielfeldes als auch die sich darauf befindenden Objekte sollen verändert werden können. Der Nutzer soll Objekte hinzufügen und entfernen, aber auch bestehende Objekte durch Ziehen mit der Maus verschieben können. Erweiterbarkeit Die Grafikimplementierung sollte so konzipiert werden, dass sie mög- 3 GRAFIKTECHNOLOGIEN FÜR DIE MINI-UMGEBUNG 13

lichst oen ist. So sollte es zum Beispiel möglich sein, externe Nutzergraﬁken einzubinden, um sie als neue Objekte in der Spielwelt einzusetzen.

Nicht alle diese Kriterien sind für eine prototypische Software zwingend zu erfüllen. Es genügt für diese Arbeit zunächst die Unterstützung mindestens eines Desktopbrowsers. Außerdem kann die Performanz zunächst vernachlässigt werden. Die weiteren Gesichts- punkte beziehen sich dagegen direkt auf die angestrebte Funktionalität der Software und sind daher auf jeden Fall zu berücksichtigen.

3.2 Canvas oder SVG?

Mit Canvas und SVG gibt es heute zwei Lösungen, um Graﬁken auf einer Webseite dynamisch zu erstellen und zu animieren, die nicht auf proprietäre Browsererweiterun- gen zurückgreifen müssen. Beide werden hier kurz vorgestellt und deren Eignung zur Entwicklung des Spielfeldes eingeschätzt, beginnend mit dem jüngeren HTML-Canvas- Element.

3.2.1 Canvas

Das Element

Inwiefern das Canvas-Element für die Umsetzung des graﬁschen Spielfeldes im Stil von 3 GRAFIKTECHNOLOGIEN FÜR DIE MINI-UMGEBUNG 14

1 2 3 4 7 21 22

Abbildung 6: Einfaches Canvas-Beispiel (vgl. [A.10, S. 108–109])

Abbildung 7: Drei mit Hilfe des Canvas-Elementes gezeichnete Rechtecke

Kara geeignet ist, bestimmen wir anhand der in Abschnitt 3.1 gestellten Anforderun- gen.

Browserkompatibilität Nach Pilgrim [A.23, S. 59] bieten folgende Browser eine ele- mentare Unterstützung für Canvas: Internet Explorer ab Version 7.0 (da noch nicht nativ, aber mit externen Erweiterungen), Firefox ab Version 3.0, Safari ab Version 3.0, Opera ab Version 10.0, iPhone ab Version 1.0 und Android ab Version 1.0.

Performanz In den in heutigen Browsern eingesetzten JavaScript-Interpretern ist das Canvas-Element performant. Dies liegt neben der in einigen Browsern eingesetzten Hardwarebeschleunigung vor allem daran, dass das Canvas-Element keine weitere innere DOM-Struktur (Document Object Model [B.9]) aufweist, auf welche im JavaScript-Code zurückgegrien werden muss [A.18, S. 152]. Beim Erstel- len von Animationen oder Spielen oder bei der Entwicklung für mobile Plattfor- men müssen womöglich einige Optimierungen selbst vorgenommen werden [A.14, S. 18].

Skalierbarkeit Da der 2D-Kontext eine Rastergraﬁk zum Zeichnen bereitstellt, lassen 3 GRAFIKTECHNOLOGIEN FÜR DIE MINI-UMGEBUNG 15

sich mit Canvas nur Rastergraﬁken realisieren. Jede Skalierungsoperation erfordert ein Neuzeichnen auf dem Canvas. Dementsprechend werden auch importierte Bilder gerastert. Animation Canvas fehlt eine explizite Unterstützung für Animationen. Soll ein Be- reich auf dem Canvas-Element verändert werden, so muss dieser erst einmal ge- leert und wieder neu gezeichnet werden. Das heißt man benötigt eine Funktion zum Löschen und Zeichnen, die in regelmäßigen Intervallen aufgerufen wird [A.14, S. 339–340][A.18, S. 146][A.10, S. 166]. Manipulierbarkeit Da Canvas kein DOM hat, kann auf gezeichnete Elemente nicht wieder zurückgegrien werden. Wird eine Repräsentation für Objekte benötigt, muss daher die Verwaltung dafür selbst geschrieben werden (vgl. [A.18, S. 152]).

Erweiterbarkeit Der 2D-Kontext bietet mit der Methode drawImage() die Mög- lichkeit Bilder in Form von einem HTMLImageElement, HTMLCanvasElement oder HTMLVideoElement aus einem HTML-Dokument zu laden [A.4][A.10, S. 135–136].

3.2.2 SVG - Scalable Vector Graphics

Der Ursprung von Scalable Vector Graphics, kurz SVG genannt, reicht noch weiter zurück als die des Canvas-Elements. Im Jahr 1998 bildete das W3C eine Arbeitsgrup- pe, die eine Repräsentation für skalierbare Vektorgrafiken auf XML-Basis (Extensible Markup Language) erarbeiten sollte [A.8, S. 6]. Viele große Firmen der Computer- industrie waren an der Ausarbeitung des Standards beteiligt, unter anderem Adobe, Apple, Canon, IBM und Microsoft, so dass am 4. September 2001 mit SVG 1.0 eine erste ozielle Empfehlung rausgegeben werden konnte [A.9, S. 80]. Die aktuelle Version zum Zeitpunkt des Verfassens dieser Arbeit ist die Version 1.1. Das W3C [A.7] beschreibt SVG als eine Sprache um zweidimensionale Grafiken in XML zu beschreiben, welche mit Formen, Bildern und Text drei verschieden Grafikobjekte unterstützt. Einige mögliche Formen sollen hier kurz vorgestellt werden:

beschreibt ein Geradensegment über die Koordinaten seiner beiden End- punkte [A.8, S. 27]. beschreibt ein Rechteck über die Koordinaten des Eckpunktes mit kleinstem x- und y-Wert und seine Höhe und Breite [A.8, S. 32] beschreibt einen Kreis über die Koordinaten des Mittelpunktes und seinen Radius [A.8, S. 35]. beschreibt Vielecke über eine Reihe von Punkten, wobei automatisch eine Linie zwischen dem letzten und dem ersten Punkt gezogen wird, sodass eine geschlossene Kontur entsteht [A.8, S. 36]. ist das mächtigste Element, auf welches sich alle anderen Formen zurück- führen lassen. Ein Pfad beschreibt eine Reihe von Punkten, die durch gerade Linien, Bögen oder Kurven miteinander verbunden werden. Anders als bei Poly- gonen werden über beschriebene Formen nicht automatisch geschlossen. Außerden muss ein Pfad nicht zusammenhängend sein, sondern kann Lücken auf- weisen [A.8, S. 74–76]. 3 GRAFIKTECHNOLOGIEN FÜR DIE MINI-UMGEBUNG 16

Diese inneren Elemente innerhalb eines SVG-Elements können außerdem weitere Attri- bute besitzen, die Eigenschaften wie Füll- und Linienfarbe deﬁnieren, oder zusätzliche Transformationen wie Translationen, Rotationen und Scherungen auf den Elementen anwenden. Abbildung 8 zeigt, wie die Rechtecke aus Abbildung 7 deklarativ in einfacher Weise als SVG beschrieben werden können, ohne dass ein Skript eingesetzt wird. Es genügt das SVG als DOM-Element in ein HTML-Dokument einzubetten. Das äußerste Element der Vektorgraﬁk ist hierbei

1 2 3 4 12 13

Abbildung 8: Beispiel einer in HTML eingebetteten SVG-Graﬁk

Da die Kindelemente des SVG-Elements im HTML-Dokument sichtbar sind, können diese mit Hilfe von JavaScript manipuliert werden. Diese Möglichkeit kann für die Animation der Kindelemente des SVG-Elementes genutzt werden. Abbildung 9 zeigt ein Beispiel für ein Skript, welches das in Abbildung 8 definierte rote Rechteck um 360¶ im Uhrzeigersinn und mit konstanter Geschwindigkeit dreht, sobald es angeklickt wird: Das rote Rechteck besitzt ein Attribut id, hier mit dem Wert "animation_example", anhand dessen es identifiziert werden kann. Dieses wird in Zeile 2 genutzt, um eine Referenz auf das Rechteck zu erzeugen. Die Zeilen 5 bis 28 definieren eine Funktion für die Rotation im Uhrzeigersinn, welche einen Anfangs- und einen Endwinkel in Grad, Koordinaten für einen Punkt, um den gedreht werden soll, und die Dauer der Animation in Millisekunden als Argumente entgegennimmt. Die schrittweise Animation wird dabei über den wiederholten Aufruf von window.requestAnimationFrame verwirklicht, mit der ein Einzelbild zum Zeichnen vom Browser eingefordert werden kann [A.27]. Anhand der Zeit, die seit dem Start der Animation vergangen ist, wird bestimmt um welchen Winkel das Quadrat sich für ein bestimmtes Einzelbild schon gedreht haben muss. Wird der endgültige Winkel erreicht oder überschritten, so wird kein neues Einzelbild eingefordert, sondern der Winkel des Rechtecks auf den Endwinkel gesetzt. Dafür wird das Attribut transform des Rechtecks entsprechend gesetzt, welches das Rechteck 3 GRAFIKTECHNOLOGIEN FÜR DIE MINI-UMGEBUNG 17

1 //Referenz auf das Rechteck durch Angabe seiner ID 2 var rect = document.getElementById("animation_example"); 3 4 //Animationsfunktion 5 rect.animate = function(startAngle , endAngle , centerX , centerY , millis) { 6 var angle = startAngle; 7 var angleStep = (endAngle - startAngle) / millis; 8 var startTime = Date.now(); 9 var that = this; 10 //Fordere ein Einzelbild zum Zeichnen an. 11 window.requestAnimationFrame(function drawRotation() { 12 //Bestimme anhand der vergangenen Zeit, um welchen Winkel das Element 13 //sich schon gedreht haben muss. 14 angle = startAngle + angleStep * (Date.now() - startTime); 15 //Setze das SVG-Attribut "transform" entsprechend. 16 that.setAttribute(’transform’, ’rotate(’ + angle + ’,’ + centerX 17 +’,’+centerY+’)’); 18 if (angle < endAngle) { 19 //Solange der endgültige Winkel nicht erreicht ist, fordere neuw 20 //Einzelbilder an. 21 window.requestAnimationFrame(drawRotation); 22 }else{ 23 //setze andernfalls den endültigen Winkel und beende Animation. 24 that.setAttribute(’transform’, ’rotate(’ + endAngle + ’,’ + centerX 25 +’,’+centerY+’)’); 26 } 27 }); 28 } 29 30 //Füge dem Rechteck einen Ereignisbehandler für Mausklicks hinzu 31 rect.setAttribute(’onclick ’, ’this.animate(0, 360, 100, 75, 3000)’);

Abbildung 9: Beispiel der Animation einer Rechtsdrehung um 360¶

Abbildung 10: Einige Einzelbilder der Animation, aufgenom- men im Abstand von 375 ms. Das rote Rechteck erscheint auf den ersten drei Bildern um 0¶, 45¶ und 90¶ im Uhrzeigersinn gedreht. transformiert. rotate(angle, centerX, centerY) steht dabei für eine Drehung um angle in Grad im Uhrzeigersinn um den Punkt (centerX, centerY ) [A.8, S. 69]. In Zeile 31 wird schließlich die beschriebene Animationsfunktion dem Rechteck als Attribut onclick, einem Ereignisbehandler für Mausklicks, zugewiesen. Im Falle eines Klicks wird dann die Funktion ausgeführt, hier handelt es sich um eine Drehung von 0¶, auf 360¶ um den Mittelpunkt des Rechtecks innerhalb von 3 Sekunden. Abbildung 10 zeigt die ersten Zwischenschritte dieser Animation. Nach diesem kleinen Beispiel möchten wir auch hier darlegen, inwieweit SVG die An- forderungen aus Abschnitt 3.1 erfüllt:

Browserkompatibilität Nach Förster [A.10, S. 183] unterstützen zehn Jahre nach Einführung des Standards mit der Veröentlichung von Internet Explorer Versi- on 9 alle Browser SVG nativ. Da die andere Komponente der Programmierum- 3 GRAFIKTECHNOLOGIEN FÜR DIE MINI-UMGEBUNG 18

gebung, Blockly, selbst auf SVG basiert, würde ein mit Hilfe von Vektorgraﬁken gezeichnetes Spielfeld keine weiteren Nachteile in Hinsicht auf Browserverträg- lichkeit nach sich ziehen.

Performanz Im Gegensatz zum Canvas-Element hat SVG ein inneres DOM mit ge- schachtelter Baumstruktur, welche durchlaufen werden muss, um einzelne Ele- mente manipulieren zu können. Die Zugriszeiten auf die DOM-Knoten wirken sich negativ auf die Geschwindigkeit aus.

Skalierbarkeit SVGs können vergrößert und verkleinert werden, ohne dass Qualitäts- verluste eintreten. SVG beschreibt zunächst nur Punkte, die erst unter Nutzung von Funktionen in Linien, Kurven oder Kreise übersetzt werden. Die Punkte selbst können nach Belieben skaliert, rotiert oder auf eine andere Weise transformiert werden. Eine Vergrößerung oder Verkleinerung der Graﬁk verändert die Qualität des Bildes daher nicht [A.8, S. 4][A.9, S. 65].

Animation Es gibt zwei Möglichkeiten SVGs zu animieren, entweder deklarativ durch Nutzung spezieller Animationselemente innerhalb eines SVGs, welche auf dem SMIL-Standard (Synchronized Multimedia Integration Language [B.23]) basieren, oder mit Hilfe einer Skriptsprache wie JavaScript, mit der Attribute des SVG-Elementes und seiner Kinder verändert werden können [A.7][A.8, S. 183- 184]. Die zweite Möglichkeit wird in Abbildung 9 demonstriert.

Manipulierbarkeit SVG bietet ein DOM, und somit Zugri auf alle seine Elemente, Attribute und Eigenschaften, die durch andere Sprachen wie JavaScript genutzt werden können. Des Weiteren können einem SVG-Element Ereignisbehandler wie onmouseover oder onclick zugewiesen werden [A.7][A.5, S. 11].

Erweiterbarkeit SVG erlaubt auch weitere SVGs als Kindelemente. Außerdem wird im Standard das Element beschrieben, in dem externe Rastergraﬁken per Referenz eingebunden werden können. Auch auf andere, externe SVG-Dateien kann auf diese Weise verwiesen werden [A.7][A.9, S. 105].

3.2.3 Auswertung

Nachdem wir beide Technologien kurz vorgestellt haben, legen wir fest, welche wir weiter verfolgen werden. Das Canvas-Element hat den Geschwindigkeitsvorteil gegenüber Scalable Vector Graphics, dafür sind SVGs beliebig skalierbar und bieten Möglichkei- ten der Animation, was Canvas nicht so einfach leistet. Außerdem kann auf die inneren Elemente eines SVGs zugegrien werden, um diese zu manipulieren, Canvas bietet nur eine Rastergrafik ohne innere Struktur. Beide Lösungen sind durch externe Grafiken erweiterbar und werden durch gängige Browser unterstützt. Die Auflösungsunabhängigkeit sowie die Animier- und Manipulierbarkeit, die SVG bietet, geben letztendlich den Ausschlag zu Lasten der Performanz. Spielfelder beliebiger Größe können in beliebig großen Browserfenstern gezeichnet werden. Für Elemente auf dem Spielfeld wird jeweils nur eine SVG-Datei als Vorlage benötigt, die beliebig skalierbar ist. Jedes Element auf dem Spielfeld hat eine Repräsentation, auf die zugegrien werden kann, um diese zu manipulieren. Diese Eigenschaften bietet Canvas nicht ohne Weiteres. 3 GRAFIKTECHNOLOGIEN FÜR DIE MINI-UMGEBUNG 19

Um den Umgang mit Vektorgraﬁken zu erleichtern, arbeiten wir nicht direkt mit SVG, sondern nutzen eine JavaScript-Bibliothek, die auf SVG aufbaut. Auf diese gehen wir als nächstes ein.

3.3 Raphaël.js

Raphaël.js ist eine JavaScript-Bibliothek von Dmitry Baranovskiy, einem Programmie- rer aus Sydney, der inzwischen bei Adobe beschäftigt ist. Sie verfolgt das Ziel, die Arbeit mit Vektorgraﬁken im Web zu vereinfachen. Als Basis dient in den heutigen Browsern die SVG-Empfehlung des W3C, nur in älteren Versionen des Internet Explorers ohne SVG-Unterstützung wird Microsofts VML (Vector Markup Language [B.19]) verwen- det, wenn dies möglich ist. Die Benutzung der Bibliothek soll anhand eines Beispiels deutlich werden. Für die folgende Erläuterung des Programmcodes wurde die Referenz von Raphaël.js [A.1] zurate gezogen, die alle Schnittstellen dokumentiert, welche die Bibliothek bietet. Dieses Beispiel soll an dieser Stelle nur einen groben Einblick in die Funktionalität geben.

1 //Erzeuge SVG-Element 2 var paper = Raphael(document.getElementById(’container’), 300, 200); 3 4 //Erstelle Rechtecke 5 var blueRect = paper.rect(0, 0, 300, 200); 6 var redRect = paper.rect(0, 0, 200, 150); 7 var yellowRect = paper.rect(100, 50, 200, 150); 8 9 //Färbe Rechtecke ein, zeichne Kanten nicht nach 10 blueRect.attr({ 11 fill : ’#bbbbff’, 12 stroke : ’none’ 13 }); 14 redRect.attr({ 15 fill : ’red’, 16 stroke : ’none’ 17 }); 18 yellowRect.attr({ 19 fill : ’rgba(255,255,0,0.5)’, 20 stroke : ’none’ 21 }); 22 23 //Gib dem roten Rechteck einen Ereignisbehandler für Mausklicks 24 redRect.click(function() { 25 this.transform(""); 26 this.animate({ 27 transform : "R360" 28 }, 3000, ’linear ’); 29 });

Abbildung 11: Drei gefärbte Rechtecke mit Raphaël.js

Der Programmcode in Abbildung 11 zeigt, wie abermals die drei Rechtecke aus Abbil- dung 7 gezeichnet werden können, dieses Mal mit Hilfe von Rapahaël.js: Zunächst wird mit dem Konstruktor Raphael(parent, width, height) ein neues SVG-Element als Kindelement von parent mit der Breite width und der Breite height erzeugt. In diesem Beispiel gibt es in dem HTML-Dokument, in welchem das Skript eingebunden wurde einen DOM-Knoten mit der id "container", in den das SVG- Element eingefügt wird. Dies ist die einzige Stelle, an der ein Knoten aus dem HTML- 3 GRAFIKTECHNOLOGIEN FÜR DIE MINI-UMGEBUNG 20

Dokument direkt referenziert wird, denn die weitere Manipulation des SVG-Elements wird über JavaScript-Objekte abstrahiert. Der Konstruktor liefert ein Objekt, welches alle Methoden bereitstellt, um neue Objekte in das SVG-Element einzufügen. In diesem Beispiel wird die Methode rect(x, y, width, height) genutzt, um Rechtecke zu zeichnen. Diese haben ebenfalls Objektmethoden wie attr, mit welcher die aus der SVG-Speziﬁkation bekannten Attribute gesetzt werden können. Transformationen haben in Raphaël.js eine etwas verkürzte Syntax, so wird eine Ro- tation eines Elements im Uhrzeigersinn um sein eigenes Zentrum mit Endwinkel 360¶ schlicht mit der Zeichenkette "R360" beschrieben. Die größte Vereinfachung, die die Bibliothek aber anbietet, betrit die Animation von Elementen. In dem gegeben Beispiel wird dem roten Rechteck mit click ein Ereignis- behandler für Mausklicks hinzugefügt, der eine Animation auslöst. Die Funktionalität der Methode animate aus Abbildung 9 wird durch Nutzung der allgemeineren Funk- tion animate(params, ms, easing) verwirklicht. Das Objekt params beschreibt die Attribute, die das Element nach Ende der Animation haben soll, ms die Dauer in Mil- lisekunden und easing die Art der Animation. Diese kann linear verlaufen oder aber beispielsweise auch mit zu- oder abnehmender Geschwindigkeit. Die Zwischenwerte, die die Attribute im Animationsverlauf von ihren Anfangs- bis zu ihren Endzuständen annehmen, berechnet hier die Bibliothek, das heißt anders als in Abbildung 9 werden hier die Winkel zwischen 0¶ und 360¶ nicht explizit durch die Programmiererin oder den Programmierer bestimmt. Die hier beschriebene Animation hat aber denselben Eekt. Das rote Rechteck dreht sich innerhalb von 3 Sekunden gleichmäßig im Uhrzeigersinn um 360¶. 4 LILI - IMPLEMENTIERUNG EINES ERSTEN PROTOTYPS 21

4 lili - Implementierung eines ersten Prototyps

Ziel des Bachelorprojektes Blockly im Schulunterricht war es, wie in der Einleitung beschrieben, einen Softwareprototypen zu entwickeln, der Blockly und Kara in einer Mini-Umgebung vereint und in eine Online-Plattform einbindet, an der Schülerinnen und Schüler, aber auch Lehrkräfte partizipieren können. Im Folgenden wird die Im- plementierung der clientseitigen Mini-Umgebung beschrieben. Die serverlastige Imple- mentierung der Lernumgebung wird von Gregor Große-Bölting in seiner Arbeit [B.1] genauer beleuchtet. Da neben Raphaël.js noch weitere Technologien eingesetzt wurden, wird zunächst auf diese kurz eingegangen. Danach erfolgt ein Überblick über die Welt und den Program- meditor der Mini-Umgebung. Der Aufbau der Software wird im Anschluss erklärt, so dass der Ablauf der Simulation abschließend anschaulicher erläutert werden kann.

4.1 Weitere Technologien

Der Softwareprototyp wurde clientseitig mit Hilfe von HTML und JavaScript realisiert. Neben Raphaël.js wurden einige andere Bibliotheken und Frameworks eingesetzt, um die Entwicklung zu vereinfachen: Bootstrap [B.4] ist ein Framework, welches die Gestaltung von ansprechenden Web- seiten vereinfacht. Es bietet ein vorgefertigtes Grundgerüst für HTML-Dokumente und ein leicht anzupassendes Gitterlayout. Außerdem gibt Bootstrap eine Reihe von Stylesheets vor, welche unter anderem die Typographie, Tabellen, Formulare und Knöpfe anpassen und so einer Seite ein modern wirkendes Äußeres verleihen. Des Weiteren gibt es vorgefertigte Komponenten, die genutzt werden können, wie zum Beispiel Navigationsleisten, Tooltips und modale Dialoge. Einige der inter- aktiven Komponenten erfordern JavaScript-Plug-ins, welche Bootstrap mitliefert. jQuery [B.15] ist eine JavaScript-Bibliothek, welche das Navigieren und Manipulieren von DOM-Objekten in HTML-Dokumenten vereinfacht. Unter anderem soll sie bei der Ereignisbehandlung und der Animation helfen. In der Mini-Umgebung des Softwareprototyps wird jQuery zum Zeitpunkt des Verfassens dieser Arbeit nur an wenigen Stellen eingesetzt. jQuery UI Bootstrap [B.17] liefert noch einige zusätzliche Komponenten, die sich optisch am Aussehen von Bootstrap orientieren. Sie basieren auf jQuery UI [B.16], einer Erweiterung von jQuery, welche sich auf die Gestaltung von Nutzerschnitt- stellen im Browser spezialisiert. Jasmine [B.14] ist ein Entwicklungswerkzeug für das automatische Testen von in Ja- vaScript geschriebenem Code, welches selbst auf JavaScript basiert. Mit ihm lassen sich vor der eigentlichen Implementierung Testfälle deﬁnieren, um zu prüfen, ob selbst geschriebener JavaScript-Code sich wirklich so verhält wie erwartet. Bei der Entwicklung von lili wurde die Simulation der Spielwelt auf diese Weise getestet. YUIdoc [B.29] ermöglicht es aus Kommentaren, die einer Javadoc-ähnlichen Syntax folgen, automatisch eine API-Dokumentation auf HMTL-Basis zu erzeugen. Die Dokumentation im Anhang dieser Arbeit wurde so erstellt. 4 LILI - IMPLEMENTIERUNG EINES ERSTEN PROTOTYPS 22

4.2 Einführung in die Mini-Umgebung

Mit Hilfe der gewählten Technologien ist es bis zum Ende des Bachelorprojektes gelun- gen einen funktionierenden Prototypen zu entwickeln. In Abbildung 12 ist die Mini- Umgebung der entstanden Software für eine Beispielaufgabe inklusive Lösung dargestellt. Ziel in diesem Beispiel ist es, ein Programm zu schreiben, das den Käfer eine Blattspur bis zum Ende verfolgen lässt. Die Aufgabe entstammt einem Aufgabenkata- log, der an der Christian-Albrechts-Universität zu Kiel im Rahmen des Schnupperstu- diums Informatik zum Einsatz kommt. Die bisher fertiggestellten Funktionen möchten wir nun kurz vorstellen.

Abbildung 12: Die Mini-Umgebung von lili : Aufgabentext (oben), Programmeditor (links) und Spielfeld (rechts). Über und unter dem Spielfeld sind Bedienelemente zur Steuerung der Programmausführung und zur Anpassung des Spielfeldes.

4.2.1 Funktionalität des Spielfeldes

Das Spielfeld auf der rechten Seite von Abbildung 12 lehnt sich sehr an die Welt von Kara aus Abschnitt 2.2 an. Noch immer ist die Welt ein Torus, so dass Objekte auf dem Spielfeld immer auf der entgegengesetzten Seite wieder herauskommen, wenn sie 4 LILI - IMPLEMENTIERUNG EINES ERSTEN PROTOTYPS 23 das Feld verlassen. Der Käfer in lili bewegt sich in seiner Welt genauso wie Kara. Einige Elemente auf dem Spielfeld haben sich allerdings leicht verändert und neue sind hinzugekommen:

Baumstümpfe Ein Baumstumpf stellt weiterhin ein unüberwindbares Hindernis dar. Wenn der Käfer gegen einen Baumstumpf stößt, dann wird ein laufendes Nutzer- programm nicht abgebrochen. Der Käfer schüttelt sich stattdessen und gibt so eine visuelle Rückmeldung über mögliche Fehler im Programm.

Vögel Da Bäume keine Bedrohung mehr darstellen, wurden Vögel als neues Element eingeführt. Der Käfer kann ein Feld, auf dem sich ein Vogel beﬁndet zwar betreten, allerdings wird er dann gefressen. Programme werden gestoppt und das Spielfeld zurückgesetzt.

Blätter Die Funktion der Kleeblätter aus Kara wird durch gewöhnliche Blätter über- nommen

Pilze Anders als in Kara können Blätter nicht über Felder geschoben werden, auf denen sich bereits andere Elemente wie zum Beispiel Blätter beﬁnden. Alle anderen Eigenschaften bleiben erhalten.

Blumen In der Welt des Käfers kommen auch Blumen vor. Diese kann der Käfer wie Blätter einsammeln aber nicht wieder ablegen.

Eier Der Käfer kann seine Welt nicht nur mit Blättern markieren, er kann auch gelbe Eier legen, die er allerdings nicht wieder aufsammeln kann.

Um die eigentlich Welt herum sind einige Steuerelemente verteilt, mit denen der Pro- grammablauf gesteuert, der Käfer manuell bewegt und die Welt editiert werden kann. Das Anwendungsfalldiagramm in Abbildung 13 verdeutlicht die Interaktionsmöglich- keiten, die im Prototypen bereits verwirklicht sind. Diese können in drei Kategorien unterteilt werden:

Simulation Die Nutzerinnen und Nutzer sollen ihre in Blockly erstellten Programme ausführen können. Dafür gibt es Bedienelemente, um die Programmausführung zu starten und zu stoppen und die Möglichkeit vor oder während des Program- mablaufs die Geschwindigkeit der Simulation anzupassen. Wird eine Simulation gestoppt, so wird das Spielfeld nicht automatisch zurückgesetzt. Stattdessen gibt es Bedienelemente, die Welt entweder auf den Zustand vor der letzten Program- mausführung oder aber auf den Ausgangszustand zurücksetzen. Jede Aufgabe besitzt eine Beispielwelt, die beim Aufruf einer Aufgabe vom Server geladen wird. Sie stellt das ursprüngliche Spielfeld dar. manuelle Steuerung Neben der programmatischen Manipulation des Spielfeldes ist es aber auch möglich, einfach durch spielerisches Probieren ein Gefühl für die Welt zu bekommen. Dafür kann der Käfer über Knöpfe manuell gesteuert werden. Alle Aktionen stehen den Nutzerinnen und Nutzern dabei zur Verfügung, das heißt der Käfer kann einen Schritt in seine Blickrichtung gehen, sich um 90¶ nach links oder rechts drehen, Blätter und Blumen aufsammeln und Blätter und Eier ablegen.

Editor Das Spielfeld, welches mit dem Aufruf einer Aufgabe geladen wird, stellt nur 4 LILI - IMPLEMENTIERUNG EINES ERSTEN PROTOTYPS 24

Abbildung 13: Funktionalitäten der Mini-Umgebung

ein Beispiel dar, anhand dessen Programme getestet werden können. Um zu veri- fizieren, dass sich ein Programm auch in allen in der Problemstellung geforderten Situationen korrekt verhält, bedarf es aber mehrerer Beispiele. Eine Editorkompo- nente ermöglicht es, das Spielfeld den eigenen Bedürfnissen anzupassen. Bisher ist es möglich, die Spielfeldgröße anzupassen und zusätzliche Spielfeldelemen- te hinzuzufügen. Ungewollte Spielfeldelemente können auch wieder entfernt und schlecht platzierte mit der Maus auf andere Felder verschoben werden. Auch die Spielfigur kann auf diese Weise verschoben werden. In dieser Version gibt es aber nur eine steuerbare Spielfigur, daher lassen sich keine weiteren Käfer hinzufügen oder entfernen.

All diese Funktionalitäten sollen es leichter machen, selbst erstellte Programme in einer ansprechenden, multimedialen Umgebung auszuführen und zu testen. Die Spielwelt ist daher ohne Programmeditor unvollständig, weshalb nun näher auf Blockly im linken Bereich von Abbildung 12 eingegangen werden soll.

4.2.2 Verfügbare Blöcke im Editor

Um das Spielfeld nicht nur manuell beeinﬂussen zu können, bedarf es eines Editors, um Programme zu erstellen. Wie bereits in Abschnitt 2.1 beschrieben, nutzen wir dafür Blockly. Um die Konzepte von Kara und Blockly zusammenzuführen, benötigen wir zuerst Aktionen und Sensoren. Diese sind in Abbildung 14 zu erkennen. 4 LILI - IMPLEMENTIERUNG EINES ERSTEN PROTOTYPS 25

Abbildung 14: Die in lili zur Verfügung stehenden Aktionen (links) und Sensoren (rechts). Die Blöcke können mit Hilfe von Dropdown-Menüs angepasst werden.

Die dem Käfer zur Verfügung stehenden Aktionen sind mehr oder weniger aus Ka- ra übernommen worden. Nur aufgrund der zusätzlichen Gegenstände auf dem Feld ergeben sich beim Aufheben und Ablegen Unterschiede:

Der Käfer kann wie in Kara einen Schritt nach vorne gehen, sofern kein Hindernis • ihn behindert.

Zudem kann er sich nach links und nach rechts drehen. Die Richtung kann einfach • anhand eines Dropdown-Menüs verändert werden, welches erscheint, wenn der entsprechende Block angeklickt wird.

Schließlich kann er nicht nur Blätter aufheben, sondern auch Blumen. Ablegen • kann er diese aber nicht mehr. Stattdessen kann er Eier legen und weiterhin Blätter auf freien Feldern platzieren. Auch hier dient ein Menü zur Auswahl der Elemente.

Im Vergleich zu Kara haben sich die Sensoren etwas stärker verändert als die Aktio- nen. Sie orientieren sich nun eher an einer auf der Sprache Erlang basierenden Variante Karas, die im Schnupperstudium am Institut für Informatik der Christian-Albrechts- Universität zu Kiel eingesetzt wird. Huch [A.17] geht näher auf diese Version ein. Der Käfer kann für jedes Element, das auf dem Spielfeld auftreten kann, beantworten, ob es vor ihm liegt. Das heißt er kann erkennen, ob sich ein Baum, ein Pilz, ein Vogel, ein Blatt, ein Ei, eine Blume oder auch nichts vor ihm befindet. Das gleiche gilt für Gegenstände links und rechts neben dem Käfer. Anders als in Kara kann der Käfer daher jedes Element auf dem Spielfeld gleich gut erkennen. Die zu prüfenden Elemente werden aber weiterhin explizit angegeben. Dazu werden sie wie bei den Aktionsblöcken aus einem Dropdown-Menü ausgewählt. Diese Verallgemeinerung auf drei Sensorblöcke ermöglicht es allerdings nicht mehr, nachzuprüfen, ob ein Blatt unter dem Käfer liegt. Bisherige, mit Kara lösbare Aufgaben sollten aber auch in lili gut zu lösen sein. Einige Aufgabentypen, wie zum Beispiel diejenigen, die das Verfolgen einer Blattspur bein- halten, können sogar einfacher gelöst werden, wenn der Käfer direkt erkennen kann, ob vor ihm ein Blatt liegt. Ohne diese Möglichkeit muss der Käfer einen Schritt nach 4 LILI - IMPLEMENTIERUNG EINES ERSTEN PROTOTYPS 26 vorne gehen, um ein Blatt erkennen zu können, und im negativen Fall umständlich zurückbewegt werden. Die Form der Aktions- und Sensorblöcke deutet bereits an, wie diese zu nutzen sind: Die Einkerbungen an den oberen und unteren Kanten der Aktionsblöcke zeigen, dass diese vertikal untereinander gesteckt werden können. Es handelt es sich um Anweisungen, die sequenziell ausgeführt werden. Die Sensoren haben dagegen keine Einkerbungen. Stattdessen besitzen sie links eine Ausstülpung, so dass ein Sensorblock einem Puzz- leteil ähnelt. Die Ausstülpung deutet an, dass die Blöcke einen Rückgabewert haben, in diesem Fall wahr oder falsch, je nachdem, ob die spezifizierte Bedingung erfüllt ist oder nicht. Die Sensorblöcke können allein in Verbindung mit den Aktionen nicht sinnvoll eingesetzt werden. Blockly aber bietet einige vorgefertigte Blöcke an, die dies ändern. Diese sind in Kategorien eingeteilt, welche je nach Bedarf hinzugefügt werden können, unter anderem Blöcke zur Steuerung des Kontrollflusses, Prozedurblöcke, Blöcke für logische Ausdrücke, Variablen, Text, Farben und mathematische Operationen. Abbildung 15 zeigt einige Beispiele aus Kategorien, die sich bereits gut in lili einsetzen lassen:

Abbildung 15: Einige vorgefertigte Blöcke aus Blockly lassen sich bereits gut mit den Aktionen und Sensoren kombinie- ren: Kontrollstrukturen (links), Prozeduren (Mitte)und logische Blöcke (rechts).

Kontrollstrukturen Dies sind Blöcke, die Verzweigungen, While- und For-Schleifen nachbilden. Anweisungen, die innerhalb einer dieser Blöcke platziert werden, werden unter bestimmten Umständen ausgeführt. Die Blöcke können beliebig viele Anweisungen aufnehmen. Die Aussparungen der Blöcke falls und wiederhole solange passen zu den Sensoren, sie können hier als Bedingung für die (wiederholte) Ausführung eingesetzt werden.

Prozeduren Im Blockly-Editor können Prozeduren ohne Rückgabewert und Funktio- nen mit Rückgabewert deﬁniert werden. Diese können frei benannt werden. Mit der Deﬁnition einer Prozedur wird automatisch ein Block generiert, der denselben 4 LILI - IMPLEMENTIERUNG EINES ERSTEN PROTOTYPS 27

Namen trägt wie die Deﬁnition der Prozedur selbst, um diese ausführen zu kön- nen. Auf diese Weise kann wiederverwendbarer Code in Blockly erzeugt werden. Außerdem ermöglichen Prozeduren Rekursion. Logik Mit Hilfe der Logikblöcke können Sensoren kombiniert und negiert werden. Die logischen Konstanten wahr und falsch sind ebenfalls gegeben. Blöcke, die mit einem Pluszeichen versehen sind, lassen sich außerdem über so genannte Mutatoren dynamisch erweitern [A.12]. Abbildung 16 zeigt den Dialog, der sich önet, sobald auf das Pluszeichen geklickt wurde. Nach demselben Prinzip wie in Blocklys Hauptansicht kann man in der Dialogblase weitere Blöcke mit dem dort dargestellten falls-Block verbinden, die dem falls-Block in der Hauptansicht neue Verzweigungen hinzufügen. Entfernt man die Blöcke im Dialog, so werden auch die Verzweigungen aus der Hauptansicht wieder entfernt.

Abbildung 16: Mit Hilfe von Mutatoren lassen sich einige Blö- cke erweitern. Der Block falls erlaubt beispielsweise das dy- namische Hinzufügen von Verzweigungen.

Mit der Kombination aus den selbst deﬁnierten Sensoren und Aktionen mit den Kon- strukten, die Blockly bereitstellt, ist es also möglich den Käfer in seiner Welt zu programmieren. Um zu vermitteln, wie genau aus dem visuellen Programm letztendlich eine graﬁsche Simulation der Spielwelt resultiert, ist es zunächst nötig den Aufbau der Software zu beschreiben.

4.3 Einordnung in das Gesamtprojekt

Wie bereits erwähnt ist die hier vorgestellte Mini-Umgebung Teil einer Lernplattform. Gregor Große-Bölting beschreibt in seiner Arbeit [B.1] mehrere Funktionen , die diese bereitstellt. Unter anderem ist es möglich sich anzumelden, Aufgaben zu erstellen und diese zu Übungseinheiten zusammenzustellen. Diese Übungen können zu einer persönlichen Übersichtsseite hinzugefügt werden, so dass die Nutzerinnen und Nutzer ihre Aufgaben leicht wiederﬁnden können, um diese zu bearbeiten. Diese verschiedenen Funktionalitäten werden in unterschiedlichen HTML-Vorlagen präsentiert, die Gre- gor Große-Bölting mit Hilfe des Webframeworks Django [B.8] generiert. Abbildung 17 4 LILI - IMPLEMENTIERUNG EINES ERSTEN PROTOTYPS 28

Abbildung 17: Grober Überblick über das Gesamtprojekt: Die Mini-Umgebung wird in detail.hmtl eingebunden (grün), deren Hauptkomponenten im Verzeichnis mini_environment verweilen. Einige eingesetzte Komponenten wie Blockly in blockly-read-only waren bereits vorgegeben. Andere mussten für die Realisierung der Mini-Umgebung eigenständig konzipiert und implementiert werden (gelb und orange hervorgehoben).

gibt einen groben Einblick in die Verzeichnisstruktur des gesamten Projektes mit Be- tonung auf der clientseitigen Programmierung der Mini-Umgebung. Die serverseitige Programmierung erfolgt vor allem unter blockade und blockade_static. Die Vorlage für die Ansicht zur Aufgabenbearbeitung wird dabei in detail.html deﬁniert. Genau hier liegt die Schnittstelle zwischen meiner Arbeit und der von Gregor Große-Bölting. Ser- verseitig wird mit Hilfe von Django die gewünschte Aufgabe geladen. Das Modell des Spielfeldes wird dabei über AJAX (Asynchronous JavaScript and XML) und JSON (JavaScript Object Notation [B.7]) vom Server geholt. Mit Hilfe einer AJAX- und 4 LILI - IMPLEMENTIERUNG EINES ERSTEN PROTOTYPS 29

XML-Schnittstelle hat Gregor Große-Bölting außerdem das automatische Laden und Sichern von in Blockly erstellten Programmen implementiert. Die clientseitig laufende Mini-Umgebung dagegen, für welche ich zuständig war, wird einfach über