FANDOM


DancePads

Jahrgangsstufe

12/13

informatischer Inhalt

siehe unten

Baukasten

Tinkerforge

Materialkosten

~120 €

EIn Physical Computing Projekt für die Sekundarstufe II

ProjektbeschreibungBearbeiten

Das Ziel des Projektes ist für alle Schüler verbindlich. Jedoch kann der Weg bis zu diesem Ziel sehr unterschiedlich ausfallen. Um zu verhindern, das eine Projektumsetzung komplett „aus dem Ruder“ läuft, wird der Lehrkraft bei der praktischen Umsetzung empfohlen, stets ein Auge auf die Entwicklung der einzelnen Projekte zu haben. In der Schule existiert die Vorgabe, Leistungen der Schüler mit Noten zu bewerten. Auch wenn diese Tatsache der Bewertung für den Lernprozess hinderlich ist, muss man in der Realität Abstriche von der Vorstellung der idealen Lernumgebung machen. Um mögliche Probleme oder kritische Stellen während der Umsetzungsphase beurteilen zu können, wird dem Lehrer empfohlen, das Projekt mindestens einmal selbst vollständig durchgeführt zu haben. Nur so kann die Lehrkraft in angemessenem Rahmen jede Gruppe individuell bei auftretenden Problemen unterstützen. Auch kennt nur die Lehrperson die eigenen Schüler und deren Fähigkeiten am besten, sodass bei jeder Aufgabe notwendige Anpassungen an die Leistungsstärke der Schüler durchgeführt werden können.

Da nicht jede Klasse und jeder Schüler gleich sind, liegt es in der Verantwortung des Lehrers dafür Sorge zu tragen, dass die Schüler durch das Projekt weder überfordert noch unterfordert werden. Erleichterungen in den Aufgaben zu diesem Projekt können bspw. darin bestehen, mehr Code oder Hinweise für die Schüler vorzugeben. Die Aufgaben des Projektes orientieren sich an einer durchschnittlichen Klasse der Sekundarstufe II. Es wird davon ausgegangen, dass die Inhalte, wie sie im Rahmenlehrplan Brandenburg für die Sek. II festgeschrieben sind, bereits im Unterricht thematisiert wurden. Abweichungen von diesen Voraussetzungen sind durch die Anpassung der Aufgaben seitens der Lehrkraft zu kompensieren. In Zukunft können Schüler, wenn sie in der Sek. II sind, bereits Erfahrungen mit Physical Computing Projekten haben. Denn im aktuellen Entwurf für den Lehrplan Informatik der Sek. I ist Physical Computing als mögliches Wahlthema enthalten.

Um einen Kontrast zum normalen Informatikunterricht zu schaffen, eignen sich Physical Computing Projekte grundsätzlich für fächerübergreifenden Unterricht. Das bedeutet, es werden nicht nur Wissen und Fähigkeiten aus dem Fach Informatik benötigt, sondern auch Kompetenzen aus anderen Schulfächern. So wird den Schülern eine Abwechslung vom normalen Schulalltag geboten. Weiterhin sind Projekte mit Bezug zu unterschiedlichen Schulfächern anwendungsrelevant und authentisch, da in der Praxis häufig Wissen aus verschiedenen Bereichen benötigt wird, um Aufgaben zu erfüllen. Diese Vorteile von Projekten und fächerübergreifendem Unterricht sind im brandenburgischen Rahmenlehrplan beschrieben. (Ministerium für Bildung, Jugend und Sport - Land Brandenburg, 2008, S. 7) Um auch weniger an Informatik und Technik interessierte Schüler für das Physical Computing Projekt begeistern zu können, werden in diesem Projekt keine komplexen Schaltungen vorkommen. Weiterhin sind kein Löten oder das Umsetzen von komplexen Elektronikschaltungen notwendig. Ein sorgsamer Umgang mit den Bauteilen und Werkzeugen ist aber selbstverständlich eine Voraussetzung für die Durchführung von Projekten dieser Art. Grundlegende Fähigkeiten im Umgang mit Werkzeugen wie Schere, Schraubenzieher, Säge und Kleber werden in der Sek. II erwartet. Weiterhin soll die handwerkliche Bastelarbeit die schulische Routine durchbrechen. In der Regel ist der Schulunterricht in der Sekundarstufe I bzw. II ausschließlich auf kognitive Arbeit ausgerichtet, den Sportunterricht ausgenommen. (Schwill & Schubert, 2011, S. 306)

Inhaltlich ist dieses Projekt nicht darauf ausgelegt, während der Durchführung den Schülern neue Inhalte zu vermitteln, sondern bereits Erlerntes und vorhandene Kompetenzen zu nutzen. Das DancePads Projekt eignet sich z. B. für die Durchführung in einer Arbeitsgemeinschaft, als Projekt in einer Projektwoche oder als Abschlussprojekt in der Sek. II, wie es in vielen Schulen bereits gefordert wird. Bereits behandelte Unterrichtsinhalte können in dem Projekt in neuen authentischen Kontexten kombiniert und angewendet werden.


Das Projekt DancePads ist von dem kommerziellen Spiel Simon inspiriert. Dieses Spiel existiert seit den 1970er Jahren in verschiedenen Ausführungen und unter verschiedenen Namen. Über die Jahre weitestgehend gleichgeblieben ist das Spielprinzip. Das kommerzielle Produkt besitzt 4 Farbflächen. Diese Flächen werden in einer vom Computer vorgegebenen Reihenfolge dargestellt. Der Spieler muss sich diese Reihenfolge einprägen und im Anschluss selbstständig durch Betätigen der Farbfelder diese Reihenfolge wiederholen. Mit zunehmender Spieldauer steigt auch die Anzahl der vorgegebenen Felder. Macht der Spieler während der Eingabe einen Fehler, so ist der Durchlauf beendet.

Das Auslösen eines Feldes wird durch das Aufleuchten der Fläche und durch einen Sound begleitet. Das Ziel des DancePads Projektes ist es, dieses Spielprinzip aufzunehmen und auf ein möglichst einfach selbst zu bauendes Spielgerät zu übertragen. Für die Umsetzung des Projektes muss also die Spiellogik in der Software umgesetzt werden und die erforderliche Hardware konstruiert werden. Das Ziel des DancePads Projektes ist es nicht, ein kommerzielles Produkt exakt nachzubauen. Die Schüler sollen bei dem Projekt mehr über die Softwarelogik und Hardwareschnittstellen lernen und das Prinzip des Spiels selbstständig umsetzen.

Zum Einsatz kommen sollen nur freiverfügbare Hard- und Softwarekomponenten. Idealerweise wird das Nutzen von Opensource Komponenten angestrebt. Der Vorteil der Verwendung von populären Opensourcekomponenten ist die große Community. Sollten bei der Umsetzung Schwierigkeiten oder Probleme auftreten, so ist es für Lehrer und Schüler in der Regel schnell möglich, Lösungen dafür zu finden. Im Allgemeinen existieren gute Dokumentationen zu den verwendeten Komponenten. Weiterhin ermöglichen Foren das zeitnahe Klären von Problemen und Fragen. Eine Anpassung an die eigenen Bedürfnisse ist aufgrund der Offenheit von den verwendeten Komponenten kein Problem.

Die benötigten Baumaterialen sind, bis auf die Mikrocontroller und Sensoren, alles Baumarktartikel. So ist die Beschaffung von neuen Materialien bei auftretenden Fehlern während der Bearbeitung kein Hindernis. Durchgeführt werden sollte das Projekt als Gruppenarbeit, wobei die Gruppengröße 2 bis 3 Personen nicht überschreiten sollte. Auch in der Praxis werden Informatikprojekte in der Regel in Teams bearbeitet, so dass die Schüler bereits jetzt mit der Aufteilung von Aufgaben und der Verantwortung für ihren Teil des Projektes wichtige Erfahrungen sammeln können, wie es bspw. auch im neuen RLP gefordert wird. (Ministerium für Bildung, Jugend und Sport - Land Brandenburg, 2014, S. 20) Auch ist das Projekt bzgl. der Komplexität nicht begrenzt. Es können viele Erweiterungen von den Schülern in das Projekt eingebracht werden. Jedoch sollte von Beginn an klar sein, was das Ziel des Projektes ist. Das Ziel ist nicht, dass einzelne Gruppen immer mehr Ideen haben und Erweiterungen in das Projekt einbauen und es somit nie zu einem Ende bringen. Das Endprodukt jeder Gruppe soll am Ende funktionstüchtig sein und eine grundlegende Spiellogik bieten. Die einzelnen Projekte können so aktiv zum Spielen bspw. beim Tag der offenen Tür genutzt werden. Weiterhin haben Schüler so die Möglichkeit, anderen Personen ihre Leistung zu präsentieren, so dass diese gewürdigt werden kann. (Schwill & Schubert, 2011, S. 306,307)

Tinkerforge HardwareBearbeiten

Mittlerweile existieren sehr viele Baukästen mit Elektronikbauteilen, welche speziell für Kinder und Jugendliche entwickelt wurden, um ihnen das Programmieren bzw. die Grundlagen der Elektronik näher zu bringen. Die verschiedenen Kästen decken ein weites Komplexitätsspektrum ab. So können leicht einfache Sensoren und Aktoren angesteuert werden oder ganze Roboter programmiert werden. Während z. B. bei Arduino-Kits LEDs zum leuchten gebracht und Buttons ausgelesen werden können, so werden mit dem LEGO Mindstorms-Baukasten leicht ganze Roboter gebaut. Eine Eigenschaft vieler dieser Kits ist es, dass sie auf die Grundlagen und den Einstieg in das Gebiet Physical Computing ausgelegt sind. Werden die Projekte dann umfangreicher, wird es ebenso schwieriger und aufwendiger, die nötigen Sensoren und Aktoren miteinander zu verbinden und zu programmieren. Weiterhin sind viele Baukästen auf „Spielanwendungen“ begrenzt. Das heißt, sie sind nicht dafür gedacht, industriellen Anforderungen zu genügen. Jedoch kann es für Schüler von Vorteil sein, mit Bauteilen zu arbeiten, welche auch in der Industrie ihren Einsatz finden. So können die Schüler früh erkennen, dass sich mit den ihnen bereits vertrauten Bauteilen auch Anwendungsnaheprojekte in der Wirtschaft und Industrie realisieren lassen. Dieses Wissen kann den Schülern helfen, später in ähnlichen Berufsfeldern tätig zu werden.

Um also Schüler mit Physical Computing Bauteilen vertraut zu machen, welche auch in der Industrie Verwendung finden, bietet das Tinkerforgesystem einen guten Ausgangspunkt. Das Tinkerforgesystem basiert auf einem Baukastenprinzip. Es werden verschiedene Module angeboten, welche ein breites Anwendungsspektrum abdecken. Die einzelnen Module sind nicht größer als (5 x 8) cm, in der Regel sogar kleiner.

Die Module gliedern sich in in 2 Gruppen. Eine Gruppe besteht aus den sogenannten Bricks und die andere Gruppe aus Bricklets. Die Bricklets sind Module, welche verschiedene Sensoren bzw. Schnittstellen für Aktoren bereitstellen. Die Bricks stellen verschiedene Wege der Kommunikation bereit bzw. dienen als Hauptplattform, um die Bricklets anzuschließen. So existieren z. B. verschieden Bricklets für die Messung von Druck und Helligkeit, sowie für die Ansteuerung von Motoren. Kommunizieren können die Module mit dem Computer bspw. über USB, Ethernet oder WLAN.Programme können in vielen populären Programmiersprachen wie Python, Java, C, Pascal und anderen geschrieben werden. Ist die gewünschte Sprache nicht dabei, können Module auch direkt über TCP/IP angesprochen werden. (Tinkerforge GmbH)

Die API Bindings sowie die Hardwarespezifikationen sind Opensource. Falls gewünscht, können alle Komponenten an die eigenen Bedürfnisse angepasst werden. Es wurden auch fertig zusammengestellte Tinkerforge-Kits herrausgebracht. So existieren zusammengestellte Kits unter anderem für den Bau einer Wetterstation oder für die Überwachung von Serverräumen. Aufgrund des großen Anwendungsspektrums und der Abstraktion von der Elektronik eignen sich Tinkerforgekomponenten ideal für die Lehre. Mit Tinkerforgekomponenten können bspw. Spannungen von über 300 Volt geschaltet und Elektromotoren mit Leistungen im Kilowatt Bereich betrieben werden. Damit eignet sich Tinkerforge auch für fortgeschrittene Bastlerprojekte sowie für die Prototypenentwicklung in der Industrie.

Für das DancePads Projekt eignet sich der Tinkerforge Baukasten wegen des einfachen Stecksystems und der intuitiven API. Die Schüler müssen so keine elektrischen Verbindungen löten oder sich mit Low-Level Elektronik beschäftigen. Des Weiteren ist die API sehr intuitiv gestaltet und einfach gehalten. Die Dokumentation zu den Komponenten und der API ist in deutscher Sprache vorhanden. Aus dem Tinkerforge Baukasten wurden für den Prototyp des DancePads Projektes ein Masterbrick, ein Multitouchbricklet und 2 Dualrelais- Bricklets benötigt.

Informatische InhalteBearbeiten

Da das DancePads Projekt am Ende der schulischen Laufbahn von Schülern durchgeführt werden soll, werden keine neuen informatischen Inhalte vermittelt. Wissen und Kompetenzen aus verschiedenen im Laufe der Schullaufbahn behandelten Bereichen werden im Projekt zusammengebracht. Die SuS müssen vorhandenes Wissen anwenden und miteinender in Bezug setzen können. Gegebenenfalls sind Wissenlücken durch selbstständige Recherchen zu schließen. Das Projekt dient als praxisorientiertes Element, indem die Schüler selbst feststellen können, in wieweit sie informatische Konzepte und Kompetenzen beherrschen. Die Schüler bekommen ein Endziel vorgegeben und sollen möglichst selbstständig dieses Ziel erreichen. Dies bereitet sie auf Berufe im informatischen Umfeld vor, denn auch dort bekommen sie nur einen Auftrag für ein Produkt und müssen dann Konzepte und mögliche Prototypen selbstständig im Team entwickeln. Aus diesem Grund soll die Verantwortung für die verschiedenen Schritte bei den Schülern liegen. Der Lehrer soll lediglich als Berater während des Projektes agieren und den Schülern möglichst viel Freiraum lassen. Um den Schülern zu zeigen, welche Überlegungen wichtig sind, erhalten sie zwei Arbeitsblätter mit Aufgaben. Im Rahmen der Aufgaben sollen sich die jeweiligen Gruppen grundlegende Gedanken zu ihrem Projekt machen. Weiß eine Gruppe nicht, wie sie eine Aufgabe lösen soll, so liegen für einige Aufgaben Hilfekarten bereit. In der folgenden Auflistung werden die im Rahmen des Projektes vorkommenden informatischen Inhalte aufgezählt.

  • Objektorientierte Programmierung (Voraussetzung): Die Objektorientierung ist ein Programmierparadigma. Das Ziel der Objektorientierten Programmierung ist es, Eigenschaften eines realen Objektes auf ein programmiersprachliches Konstrukt abzubilden. Übertragen werden dabei nur die für das aktuelle Projekt relevanten Eigenschaften und Methoden. Die Objektorientierte Programmierung ist eines der wichtigsten Prinzipien in der heutigen Softwareentwicklung und deswegen auch für den Informatikunterricht und die Programmierung in der Schule relevant. So ist die Objektorientierte Modellierung dem Gebiet des informatischen Modellierens zugeordnet. Das objektorientierte Modellieren ist im Rahmenlehrplan Brandeburg als eine Eingangsvoraussetzung für die Qualifikationsphase aufgeführt. (Ministerium für Bildung, Jugend und Sport - Land Brandenburg, 2008, S.12) Die SuS sollen also in der Lage sein, relevante Eigenschaften und Methoden realer Objekte zu erkennen und zu abstrahieren. Im Abitur sollen sie dann in die Lage versetzt werden, diese Abstraktion in einer Programmiersprache zu formulieren. Die Objektorientierte Programmierung ist auch im Bereich der Softwareentwicklung im Rahmenlehrplan aufgeführt. Für das DancePads Projekt ist die Objektorientierte Programmierung relevant, weil sich die Spielfläche ideal eignet, um als Objekt in Python modelliert zu werden. Weiterhin wird die Umsetzung einer Spiellogik in einem anwendungsnahen Programmierparadigma geübt. Die SuS können somit selbstständig Wissenslücken im Bereich der Programmierung erkennen und an ihnen arbeiten.
  • Datenbanken/SQL (Voraussetzung): Wir leben in einem Informationszeitalter. Die Menschheit generiert immer mehr Daten und Informationen. Eine Herausforderung der heutigen Zeit ist es, diese Daten strukturiert zu speichern, um mit ihnen arbeiten zu können. Eines der populärsten und effizientesten Datenbanksysteme ist eine relationale Datenbank. In diesen Datenbanken werden Daten als mathematische Relation abgelegt. Datenbanken treten überall im Internet auf, ohne dass sich die meisten Menschen darüber bewusst sind. Um einen Einblick in die Welt der großen Datenmengen und der Datenbanken zu bekommen, ist die Behandlung im Schulunterricht wichtig. Relationale Datenbanken und die Verwendung einer Abfragesprache wie SQL sind deswegen auch im Rahmenlehrplan festgeschrieben. (Ministerium für Bildung, Jugend und Sport - Land Brandenburg, 2008, S. 14) Für das DancePads Projekt wird grundlegendes Wissen zum Umgang mit Datenbanken vorausgesetzt. Im Rahmen des Projektes werden einfache Abfragen aus Python herraus für die Realisierung einer Highscoreliste umgesetzt.
  • Grafische Oberflächen: Grafische Oberflächen erlauben dem Benutzer, Computerprogramme einfach zu steuern und relevante Informationen schnell zu erfassen. Ein Teil des DancePads Projektes ist die Umsetzung einer einfachen grafischen Oberfläche per Drag and Drop und das Reagieren auf Events im Code. Die Oberfläche wird mithilfe des Qt Frameworks realisiert. Die SuS werden im Qt Designer die Oberfläche anlegen und im Programmcode das Signal-Slot Konzept verwenden. Die Codesnippets für die Einrichtung der Signale und Slots können von den Schülern selbst entwickelt oder von der jeweiligen Hilfekarten genommen werden. Auch bei der Benutzung der Hilfekarte ist eine Anpassung des Codes an das eigene Projekt seitens der Schüler erforderlich. Je nach Aufgabe und Vorwissen der Schüler kann die Nutzung der Dokumentation trotz Hilfekarte erforderlich sein.
  • Zufallszahlen: Höchstwahrscheinlich haben die SuS noch nie vertiefend über den Zufall als Phänomen nachgedacht. Möglicherweise wurden Aspekte der Kryptografie und damit auch die Notwendigkeit guter Zufallszahlen bereits im Informatikunterricht thematisiert. Denn nur mithilfe möglichst guter Zufallszahlen kann eine akzeptable Verschlüsselung erreicht werden. Doch der Zufall ist bei genauerer Betrachtung eine sehr komplexe Sache. In der Informatik existiert auch Software, welche Zufallszahlen erzeugen kann. Jedoch handelt es sich bei diesen Zahlen nur um Pseudozufallszahlen, welche mithilfe mathematischer Vorschriften erzeugt werden. Echte Zufallszahlen können nur mithilfe quantenmechanischer Prozesse generiert werden. Für das DancePads Projekt ist es nötig, zufällige Zahlenfolgen zu erzeugen, welche die entsprechende Padreihenfolge repräsentieren. Dazu wird eine Pythonfunktion aus dem Paket random genutzt, welche eine Periode von 219937-1 hat. Die Schüler sollen sich in diesem Zusammenhang anschauen, welche Quellen von Zufallszahlen es gibt und wo der Unterschied zwischen echten Zufallszahlen und Pseudozufallszahlen liegt.
  • Dokumentaionen: Hat man als Programmierer mit fremdem Quellcode, Modulen und Bibliotheken zutun, ist es sehr häufig erforderlich, sich Codekommentare oder Dokumentationen durchzulesen. Aus diesem Grund sind verständliche Dokumentationen mit einfachen Codebeispielen wichtig und hilfreich. Während der Arbeit mit Python und den Tinkerforgekomponenten werden die Schüler wahrscheinlich mehrmals die Dokumentationen entsprechender Hard- und Softwarekomponenten zurate ziehen müssen. Dadurch lernen die Schüler den Umgang und das Zurechtfinden mit verschiedenen Dokumentationen. Weiterhin können sie so ihre Sprachkenntnisse ausbauen, da die meisten Dokumentationen ausschließlich in englischer Sprache vorhanden sind. Auch den Nutzen von Codekommentaren sollen die Schüler erkennen, da ab einer gewissen Komplexität das Verstehen des Programms nicht nur durch das bloße Lesen des Codes möglich ist.
  • Zahlensysteme und Bitoperatoren (Voraussetzung): Verschiedene Zahlensysteme spielen in der Informatik eine wichtige Rolle. Die Berechnungen von Computern basieren auf dem Binärsystem, welches physikalisch durch einzuhaltende Spannungsgrenzen realisiert wird. Für die Adressierung von Speicherzellen verwendet man häufig das Hexadezimalsystem. Der Mensch hingegen ist aus dem täglichen Leben und der Schule an das Dezimalsystem gewöhnt. Beim Umgang mit dem Multitouchbricklet des Tinkerforgesystems spielt das Binärsystem eine wichtige Rolle. Der Pinstatus des Bricklets wird als Bitstring repräsentiert. Um in Abhängigkeit des Status die entsprechenden Aktionen auszulösen, muss der Pinstatus abgefragt werden. Eine effiziente Möglichkeit einen Status abzufragen, lässt sich unter Zuhilfenahme von Bitoperatoren realisieren. So können in Abhängigkeit von der gebrauchten Information bspw. einzelne Bits geshiftet werden. Die SuS verstehen so, dass eine Umrechnung vom Binärsystem in bspw. das Dezimalsystem nur für den Menschen hilfreich ist. Der Computer hingegen kann mit dem Bitstring effizient weiter arbeiten. Verschiedene Zahlensysteme und logische Operatoren werden auch im RLP als Inhalte zum Thema „Rechner und Netze“ vorgeschlagen. (Ministerium für Bildung, Jugend und Sport - Land Brandenburg, 2008, S. 19)
  • Cheaten: Cheaten bedeutet so viel wie betrügen. In einem Computerspiel verschafft sich der Spieler auf einem nicht vom Programmierer/Hersteller vorgesehenen Weg einen Vorteil. Die Arten des Cheatens reichen von der Eingabemanipulation bei Maus und Tastatur, bis zum Ausnutzen von Programmfehlern, sog. Bugs. Beim Ausnutzen von Bugs kann sich ein Spieler Vorteile verschaffen, welche im Spiel nicht eingeplant sind. Wie jede Computersoftware können auch Spiele Fehler enthalten. Viele Schüler kennen wahrscheinlich Spiele, bei denen man cheaten kann bzw. sie haben selbst schon einmal gecheatet. Warum das Ausnutzen von Fehlern im Spiel möglich ist, kann mit den Schülern diskutiert werden. Nach dem Satz von Rice kann nämlich nicht überprüft werden, ob ein Programm ausschließlich das geplante Verhalten zeigt und nichts anderes leistet. Der Satz von Rice kommt aus der Theoretischen Informatik und gilt für Spiele genauso wie für jede andere Software. Ein Spiel kann also allgemein nicht auf einen Bug hin getestet werden. Dieser Punkt kann mit den Schülern besprochen werden, nachdem der Lehrer das fertige Projekt der Gruppe getestet hat. Dabei kann er gezielt einen Fehler ausnutzen. Auf diese Weise kann man im Spiel ein beliebiges Level erreichen, ohne dabei Zeit zu verbrauchen. Eine Aufgabe jeder Gruppe ist es, das eigene Spiel auf Cheatmöglichkeiten hin zu überprüfen und festzustellen, warum sie diesen Fehler nicht von Beginn an vermieden haben.

DurchführungBearbeiten

In Abhängigkeit von dem Rahmen, in welchem das Projekt durchgeführt wird, fällt auch die Vorbereitung für den Lehrer unterschiedlich aus. Zum Bau des Projektes werden überwiegend Materialien aus dem Baumarkt benötigt. Wurden in der Vergangenheit bereits ähnliche Projekte durchgeführt, so sollte bereits eine Auswahl an Materialien in der Schule vorhanden sein. Ansonsten sind je nach gewünschter Organisationsform die Materialien vorher vom Lehrer zu besorgen, oder erst nachdem die Gruppen ihre Materialliste vorgelegt haben. Mögliche verwendbare Materialien sind z. B. Spanplatten, Plexiglas, Polystyrol, LED-Streifen, Verbindungsklemmen (Wago/Lüsterklemme), Drähte, Schrauben/Muttern, Säge und Aluminiumklebeband. Abweichungen bei den von den Gruppen benötigten Materialien sind natürlich möglich und vom Lehrer entsprechend zu berücksichtigen. Je nach handwerklichem Geschick der einzelnen Schüler sind vom Lehrer Hinweise bzw. Hilfestellungen bei der Bearbeitung der Materialien zu geben. Während der Durchführung des Projektes sind von den Gruppen 2 Arbeitsblätter zu bearbeiten. Erst nach Bearbeitung des 1. Blattes und der Präsentation der Ergebnisse beginnen die Gruppen mit dem Bau ihres Projektes. Das erste Arbeitsblatt widmet sich der Hardware und das zweite Arbeitsblatt der Software. Die Arbeitsblätter stellen keine Schritt-für-Schritt Anleitung für das Projekt dar. Die einzelnen Aufgaben bilden ein Gerüst von Punkten, welche bei der Projektdurchführung von den Schülern durchlaufen werden sollen. Jede Aufgabe thematisiert einen Sachverhalt, mit dem sich die Gruppen während des Projektes auseinandersetzen müssen. Die Lösung der Aufgaben kann variieren, da die Auswahl der Materialien und Tinkerforgekomponenten in die Verantwortung der jeweiligen Gruppe fällt. Auch die konkrete Entwicklung des Programmcodes kann stark variieren. Diese Freiheiten sollen ein gewisses Maß an Eigenverantwortung und Kreativität der Gruppen sicherstellen. Durch diese Freiheiten ist es aber nötig, dass der Lehrer sich mit dem Projekt gut auskennt und so jeder Gruppe, wenn nötig, angemessen helfen kann. Auch die individuelle Umsetzung, der Umgang mit Problemen und die Kreativität der Gruppen sind bei der Bewertung vom Lehrer entsprechend zu berücksichtigen. Für die Gruppen werden auch Hilfekarten bereit gestellt. Einige Karten hängen direkt mit Aufgaben vom zweiten Arbeitsblatt zusammen. Die anderen Karten bieten den Gruppen Hilfe bei verschiedenen Problemen hinsichtlich der Programmierung. Die Hilfekarten können vom Lehrer in entsprechend beschriftete Briefumschläge gesteckt und auf dem Lehrertisch bereit gelegt werden. Die Karten enthalten Hinweise und Codesnippets für Aufgaben, bei denen die Schüler selbst nicht weiter kommen. Die Gruppen können einen Blick auf die Karte werfen, wenn sie z. B. eine Sounddatei zu einem bestimmten Zeitpunkt abspielen wollen. Vorgegebene Codesnippets dienen nur als Einstiegspunkt für die Gruppe und müssen an das eigene Projekt angepasst werden. Falls erforderlich, müssen die Gruppen selbst in der Dokumentation zur Software nachschlagen, um den Code zu verstehen und richtig anpassen zu können. Jede Gruppe baut ein eigenes DancePads Projekt. Die Bearbeitung der Aufgaben erfolgt innerhalb der Gruppe. Dadurch sollen die Diskussion und der Gedankenaustausch unter den Gruppenmitgliedern gefördert werden. Die Hilfekarten in den Umschlägen liegen auf dem Lehrertisch für alle Gruppen aus. Dies soll verhindern, dass die Gruppen zu schnell aufgeben und ohne Anstrengungen sich die fast fertige Lösung einer Aufgabe beschaffen. Ebenso soll die Anzahl der Hilfekartensätze möglichst klein gehalten werden. Benötigt eine Gruppe eine Hilfekarte, so wird der entsprechende Umschlag vom Lehrertisch geholt und anschließend wieder zurückgelegt. Kann eine Gruppe trotz lesen der Dokumentation und Benutzung der Hilfekarte ein Problem nicht lösen, so kann der Lehrer um Hilfe gebeten werden. Der Lehrer gibt der Gruppe Denkanstöße und Impulse, um ihr das selbstständige Weiterarbeiten zu ermöglichen. Beginnen soll das Projekt mit der Vorführung des kommerziellen Spiels „Simon“. Im Idealfall steht dem Lehrer dieses Spiel direkt zur Verfügung. So haben die Schüler die Möglichkeit, das Spiel unmittelbar auszuprobieren und genau kennenzulernen. Das Spiel ist im Internet noch immer erhältlich. Steht kein Spiel zur Verfügung, so kann ein Video vorgeführt werden, welches das Spielprinzip veranschaulicht. Verschiedene Videos, in denen das Spiel gespielt wird, stehen auf verschiedenen Videoplattformen zur Verfügung. In der ersten Aufgabe des Hardwarearbeitsblattes sollen die Gruppen den Spielablauf des Simon Spiels beschreiben. Die Schüler sollen die Spielregeln und den Ablauf in eigenen Worten aufschreiben. Dies ist notwendig, da sie beim Schreiben der eigenen Spiellogik mit dem Spielprinzip vertraut sein müssen. Bei der zweiten Aufgabe sollen die Schüler den Spielablauf bezüglich der Eingaben des Spielers und der Ausgaben des Spielgerätes beschreiben. Die Schüler kennen aus dem Informatikunterricht bereits das EVA-Prinzip. Mithilfe dieses Wissens können sie die Ein- und Ausgabemechanismen des Spiels beschreiben. Anhand dessen sollen sie dann selbstständig die für ihr Projekt benötigten Sensoren und Aktoren definieren. Für die Eingabe sowie für die Ausgabe kommen mehrere Sensoren und Aktoren in Frage. Die Schüler müssen nicht, wie beim Original, die Eingabe über buttonähnliche Elemente realisieren. Bei der Ausgabe gibt es jedoch die Vorgabe, mit Licht und Sound zu arbeiten. Die Gestaltung von Lichteffekten ist auch als Kontext im Entwurf des neuen Rahmenlehrplans beim Thema Physical Computing zu finden. (Ministerium für Bildung, Jugend und Sport - Land Brandenburg, 2014, S. 21) Je nachdem welche Ideen die Schüler für die Benutzerinteraktion haben, werden verschiedene Sensoren und Aktoren verwendet, welche in der dritten Aufgabe aufgezählt werden sollen. Weitere für den Bau benötigte Materialien sollen in Aufgabe 4 genannt werden. Die Auswahl kann in Abhängigkeit von bereits in der Schule vorhandenen Materialien erfolgen, oder aber völlig frei sein. Anschließend folgt auf dem Arbeitsblatt ein kurzer Einleitungstext zum Tinkerforgesystem. Die Schüler sollen dann auf der Tinkerforge Homepage die benötigten Bricklets herraussuchen, mit welchen sie die in Aufgabe 3 beschriebenen Sensoren und Aktoren umsetzen können. Für diese Aufgabe steht eine Hilfekarte zur Verfügung, auf welchem eine Auswahl an möglichen Bricklets zu finden ist. Prinzipiell eignet sich für die Eingabe das Multitouch Bricklet, um auf Berührungen oder Annäherungen durch Körperteile zu reagieren. Eine zweite Möglichkeit bietet das I/O Bricklet. Dieses kann so konfiguriert werden, dass es Ereignisse bei geöffneten oder geschlossenen Stromkreisen auslöst. So können z. B. einfache Button zur Eingabe genutzt und noch gestaltet werden. Die dritte Möglichkeit ist ein Voltage/Current Bricklet einzusetzen. An diesem können verschiedenen Sensoren wie bspw. Piezoelemente angeschlossen und als Eingabeschnittstelle genutzt werden. Der Einsatz von Piezoelementen ist prinzipiell möglich, aber die Realisierung ist deutlich aufwendiger für die Schüler. Die einfachste und interessanteste Art, die Eingabeschnittstelle zu realisieren, ist daher sicherlich das Multitouch Bricklet. Wird von einer Gruppe das Multitouch Bricklet verwendet, so soll in der Aufgabe das Funktionsprinzip des Bricklets mit dem Modell des Kondensators erklärt werden. Wird ein Piezoelement verwendet, so soll erklärt werden, wie dieses eine Spannungsänderung verursacht, welche mit dem Voltage/Current Bricklet gemessen werden kann. Auch der prinzipielle Aufbau und die Funktionsweise eines Relais sollen in dieser Aufgabe erklärt werden. Dies verhindert, dass die Schüler die Bricklets einfach „nur“ benutzen. Sensoren und Aktoren können auf komplexen Mechanismen beruhen, welche nach außen gut abstrahiert und nicht direkt sichtbar sind. Jedoch stellen viele derartige Elektronikkomponenten eine Black Box für Schüler dar. Ziel dieses Projektes soll es nicht sein, den genauen Aufbau eines Sensors zu verstehen, sondern das grundlegende Prinzip zu erkennen, welches allen diesen Bauteilen gemein ist. Diese Erklärung sollte für Schüler der 12. bzw. 13. Klasse kein Problem sein, denn Relais, Kondensatoren und andere elektrische Bauelemente wurden im Physikunterricht zu dieser Zeit bereits behandelt. Wissen aus dem Bereich der Elektrizitätslehre aus dem Physikunterricht ist auch für die Bearbeitung der 7. Aufgabe notwendig. In dieser Aufgabe soll jede Gruppe eine Skizze ihres geplanten Aufbaus machen und einen Schaltplan mit den geplanten Beleuchtungselementen entwerfen. Eine Darstellung der Sensoren für die Benutzereingabe ist nicht vorgesehen. Diese kann in Abhängigkeit vom Detailgrad sehr komplex werden. Zudem ist bei den Eingabesensoren überwiegend das Tinkerforgestecksystem einzusetzen und keine manuelle Verdrahtung nötig. Bei der Beleuchtung hingegen muss sich jede Gruppe selbstständig Gedanken um die Kabelführung und die richtige Polung machen. Die letzte Aufgabe des ersten Arbeitsblattes besteht darin, dass jede Gruppe ihre bisherige Planung vorstellt. Die Gruppen sollen in einer kurzen Präsentation ihren geplanten Aufbau und die ausgewählten Sensoren und Aktoren vorstellen. Getroffene Entscheidungen sollen begründet werden. Alle anderen Schüler sind dazu angehalten, Fragen zu stellen und ein Feedback zum geplanten Projekt zu geben. So können noch Unklarheiten oder Probleme rechtzeitig besprochen werden. Nach der vollständigen Bearbeitung des ersten Arbeitsblattes und der Präsentation aller Gruppen kann mit dem Bau der Projekte begonnen werden. Das zweite Arbeitsblatt widmet sich dann der Software und der Programmierung der Programmlogik. Es beinhaltet Aufgaben zu wichtigen Etappen der Programmentwicklung. Mit der Bearbeitung des zweiten Arbeitsblattes sollte jede Gruppe vor dem festen Einbau der Tinkerforgekomponenten beginnen. Auf dem zweiten Arbeitsblatt wird die Vorgabe gemacht, dass die Software einen Highscore erstellen und dauerhaft speichern soll. Im Gegensatz zum originalen Simon-Spiel wird das DancePads Projekt also eine grafische Oberfläche für die Highscoretabelle brauchen. Durch den Einsatz einer Datenbank können die Schüler ihr Wissen bzgl. SQL als Abfragesprache noch einmal anwendungsnah einsetzen. Bevor die Schüler mit der Entwicklung der Software beginnen, sollen sie in der 1. Aufgabe des zweiten Arbeitsblattes erst die Funktionsfähigkeit der Tinkerforgekomponenten und des Aufbaus testen. Diese Aufgabe dient dazu, defekte Komponenten rechtzeitig zu identifizieren und auszusortieren, bevor diese verbaut werden. Weiterhin sollen die Schüler sich mit den Tinkerforgekomponenten mehr auseinandersetzen und mit ihnen experimentieren. Dazu dient die Brickviewer-Software, welche von Tinkerforge bereit gestellt wird. Die Software bietet eine einfache grafische Oberfläche, um alle Bricks und Bricklets schnell testen zu können. Alle Funktionen sind in einer grafischen Oberfläche leicht zugänglich. Auch Sensorwerte von entsprechenden Bricklets werden in Echtzeit dargestellt. So können die Schüler, ohne eine Zeile Code selbst zu schreiben, die genaue Funktionsweise der Komponenten selbstständig entdecken. Anschließend machen sich die Gruppen in den folgenden Aufgaben des zweiten Arbeitsblattes mehr Gedanken zur konkreten Realisierung ihrer Software. In der zweiten Aufgabe entwirft jede Gruppe eine grafische Oberfläche für ihre Software und beschreibt die benötigten Elemente. Dabei soll auf gute Bedienbarkeit und selbsterklärende Beschriftungen Wert gelegt werden. Anschließend soll der Entwurf im Qt Designer umgesetzt werden. Die Qt Bibliothek bietet Klassen zum einfachen Entwurf von grafischen Oberflächen. Oberflächen können einfach im Qt Designer per Drag and Drop erstellt und abgespeichert werden. Um die *.ui Datei im eigenen Pythoncode verwenden zu können, wird das PyQt Paket benötigt. Qt selbst ist nur eine C++ Bibliothek. Die Einrichtung von PyQt auf den Computern sollte vor Beginn des Projektes vom Lehrer übernommen und hinsichtlich ihrer Funktionsfähigkeit überprüft werden. Um die Benutzung der grafischen Oberfläche nicht unnötig zu verkomplizieren, steht für die Einbindung in den Pythoncode auch eine Hinweiskarte zur Verfügung. Eine Vorgabe des Projektes ist es, einen Highscore anzulegen. Zu diesem Zweck muss sich jede Gruppe Kriterien für eine Rangfolge der einzelnen Spieler überlegen. Die einfachste Möglichkeit Spieler zu unterscheiden, ist die Eingabe eines Nicknames jedes Spielers. Die Notwendigkeit für die erforderlichen GUI Elemente muss von den einzelnen Gruppen dann erkannt werden. Die Kriterien für das Erstellen einer Rangfolge überlegt sich jede Gruppe in der 4. Aufgabe des zweiten Arbeitsblattes. Auch die Erhebung der notwendigen Informationen für die Rangfolge muss von den jeweiligen Gruppen selbstständig im Programmcode umgesetzt werden. Wenn Gruppen keine eigenen Ideen haben, sind in der Hinweiskarte zu dieser Aufgabe das erreichte Level und die dafür benötigte Zeit als Hinweise gegeben. Das Mitzählen des Levels und das Erfassen der Zeit müssen im Code umgesetzt werden. Um einen Eintrag mit den von der Gruppe ausgewählten Kriterien zu speichern, müssen diese in die Datenbank eingefügt werden. Die zum Einfügen und zum sortierten Wiederausgeben der Daten erforderlichen SQL Statements sollen in der Aufgabe 5 aufgeschrieben werden. Zur Speicherung der Highscoretabelle wird SQLite verwendet. Die Hinweiskarte zur Aufgabe 5 enthält die SQL Statements und den Pythoncode, um die Statements zum Einlesen und Auslesen auszuführen. Die Codesnippets müssen zur Verwendung erst von den Schülern an das eigene Projekt angepasst werden. Um den Code zu verstehen, können sie die Pythondokumentation herranziehen, welche auch ein Kapitel zu SQLite beinhaltet. Bei noch offenen Fragen können sich die Schüler an den Lehrer wenden. Die 6. Aufgabe wird von den Gruppen nur bearbeitet, wenn sie das Tinkerforge Multitouch Bricklet benutzen. Dieses gibt den Status der Pins als Integer zurück, wobei die Zahl für einen Bitstring steht. Ist die entsprechende Stelle im Bitstring eine 1, so wird der Pin berührt, ansonsten ist er eine 0. Eine effiziente Abfrage des Pinstatus ist mit Bit-Operatoren möglich. Im Beispielcode der zur Aufgabe 6 gehörigen Hinweiskarte wird überprüft, ob der Bitstring verschieden von 0 ist. Anschließend werden mittels Shiften die ersten 4 Pins abgefragt. Als mögliche Erweiterung können weitere Pads zum Spiel hinzugefügt werden. Der Code muss dann entsprechend angepasst werden. In der folgenden Aufgabe 7 geht es um die Erzeugung der Padreihenfolge. Diese Reihenfolge soll zufällig erzeugt werden. Dafür bietet Python in der Standardbibliothek das random Paket. Dieses Paket bietet Funktionen zur Erzeugung von Pseudo-Zufallszahlen. Die Schüler sollen in der Pythondokumentation die Einschränkungen dieser Erzeugung von Zufallszahlen herraussuchen und im zweiten Teil den Unterschied zwischen Pseudo-Zufallszahlen und „echten“ Zufallszahlen beschreiben. Dazu können sie in Büchern oder dem Internet recherchieren. In der Aufgabe 7c) sollen die Schüler beschreiben, warum gute Zufallszahlen in der Informatik wichtig sind. Gute Zufallszahlen spielen heutzutage unter anderem in der Kryptografie eine wichtige Rolle. Denn nur mithilfe guter Zufallszahlen sind sichere Verschlüsselungen überhaupt realisierbar. Für die 8. Aufgabe suchen die Schüler z. B. im Internet nach verwendbaren Sounddatein für ihr Projekt. Dabei müssen sie auf die jeweils angegebene Lizenz achten. Alternativ können sie die Sounds bzw. Melodien auch selbst erstellen. Sie können Melodien oder Töne von verschiedenen Musikinstrumenten einspielen, welche sie selbst beherrschen. Spätestens zu diesem Zeitpunkt sollen die Gruppen dann mit dem Programmieren beginnen. Darauf werden sie in der Aufgabe 9 noch einmal hingewiesen. Für die weitere Programmierung der Software stehen zusätzliche Hinweiskarten zur Verfügung. Die Hinweiskarten 7 bis 11 enthalten überwiegend Codesnippets, die für wichtige Etappen während der Programmierung Hilfen anbieten. Die Codesnippets müssen individuell an das Projekt der Schüler angepasst werden. In der Praxis ist es eher die Regel als die Ausnahme, dass Informatiker sich mit verschiedenen Dokumentationen zu Soft- und Hardware auseinandersetzen müssen, um selbst ihre Projekte realisieren zu können. Nach dem das Spiel der Gruppen weitestgehend fertig ist und auch funktioniert, wird noch die 10. Aufgabe von allen bearbeitet. Hier soll jede Gruppe nun überprüfen, ob in ihrem Spiel Cheaten möglich ist. So können für das Cheaten Programmierfehler ausgenutzt oder das Programmverhalten in einer nicht von den Schülern beabsichtigten Weise beeinflusst werden. Nachdem die Gruppen versucht haben bei ihrem eigenen Spiel und vielleicht auch bei dem Spiel einer anderen Gruppe zu cheaten, sollen sie das daraus resultierende Verhalten des Spiels beschreiben. Anschließend nehmen sich die Gruppen die Aufgabenkarte, welche in mehrfacher Ausführung auf dem Lehrertisch ausliegt. Im ersten Teil sollen die Schüler dann begründen, warum Cheaten in ihrem Spiel möglich ist. In der Regel wird der Fehler bei der Verarbeitung der Eingabe im Quellcode passieren. Während der Padvorgabe seitens des Computers lauscht dieser immer noch an den Eingabesensoren. Beim Multitouch Bricklet beispielsweise werden durch Berührungen der Pads weiterhin Eingaben vom Programm entgegen genommen. Anschließend soll jede Gruppe andere Spiele beschreiben, bei denen ebenfalls Cheaten möglich ist. Diese Spiele können sie aus eigener Erfahrung oder aus Internetrecherchen kennen. Noch immer stellt Cheaten, besonders in Multiplayerspielen, ein großes Problem dar. In den letzten Jahren haben Spieleentwickler unterschiedliche Methoden entwickelt, um Cheater zu erkennen. Im letzen Teil der 10. Aufgabe soll erklärt werden, warum das Cheaten durch Ausnutzen von Programmierfehlern noch immer nicht verhindert werden kann. Zur Lösung dieser Aufgabe müssen die SuS auf Wissen aus dem Bereich der Theoretischen Informatik zurückgreifen. Im Unterricht haben sich die SuS bereits mit der Theoretischen Informatik beschäftigt. Sie kennen den Satz von Rice und müssen diesen zur Begründung ihrer Aussage herranziehen und erklären, warum der Satz von Rice auch für das Cheaten gilt. Der Satz von Rice besagt, dass jede nicht triviale Eigenschaft eines Programms nicht algorithmisch entschieden werden kann. Ein Computer kann also nicht überprüfen, ob ein Spiel ausschließlich das gewünschte Verhalten zeigt. So kann auch nicht getestet werden, ob ein Spiel Fehler enthält, welche das Cheaten ermöglichen. Am Schluss des Projektes stellt jede Gruppe ihr fertiges Endprodukt in einer Präsentation vor. Es sollen aufgetretene Probleme und Hürden beschrieben werden. Auch der Umgang mit den Problemen soll in der Klasse diskutiert werden. Möglicherweise sind andere Gruppen auf ähnliche Probleme gestoßen und haben diese auf anderem Wege gelöst. Auch vorgenommene Änderungen bzgl. der Hardware, welche seit der Bearbeitung von Arbeitsblatt 1 vorgenommen wurden, sollen erklärt werden. Insgesamt ist der Ablauf des Projektes möglichst frei gehalten. Diese Freiheit erfordert jedoch, dass die Lehrperson genaue Kenntnis von der Abfolge und den Möglichkeiten der Umsetzung im Rahmen dieses Projektes hat. Nur so kann die Lehrperson den Schülern beratend zur Seite stehen und bei Bedarf eingreifen. Am Ende des Projektes haben die SuS einen Einblick bekommen, wie schwierig es sein kann, ein Informatikprojekt umzusetzen. Zu Beginn erfolgte die Vorgabe eines Zieles, welches in eigener Verantwortung zu erreichen war. Auch das Lösen von Konflikten und die Gleichberechtigung der Teammitglieder stellen wichtige Erfahrungen für die Schüler dar. (Schwill & Schubert, 2011, S. 312-314) Die Schüler erhielten somit einen Einblick in die Praxis hinsichtlich Teamarbeit und Konfliktlösung. Alle Überlegungen und Schritte auf dem Weg zum Ziel müssen Informatiker selbstständig bewältigen. Auch die Koordination von Aufgaben innerhalb eines Teams muss gut geplant sein. Weiterhin konnten die Schüler in diesem Projekt ihr Wissen aus verschiedenen Bereichen des Informatikunterrichts auffrischen und anwenden. Somit können die SuS nun besser einschätzen, ob ihnen ein Beruf in der Informatik zusagt oder nicht. Auch können sie ihre Rolle während der Arbeit in einem Team besser beurteilen.

PrototypBearbeiten

Im Rahmen dieser Arbeit wurde auch ein Prototyp des DancePads Projektes entwickelt. Der Prototyp hat eine Polystyrolplatte als Grundfläche. Auf dieser ist eine weitere Platte mit 4 Löchern befestigt. An den Rändern dieser Löcher ist jeweils ein LED-Streifen befestigt. Die oberste Platte ist eine durchsichtige Acrylglasplatte. In der Mitte jedes Loches ist ein Stück Aluminiumfolie aufgeklebt, welches mit einem Draht verbunden ist. Dieser Draht führt in einen Kasten, in welchem sich das Multitouch-Bricklet, 2 Relais Bricklets und ein Masterbricklet befinden. Weiterhin führen 1 USB Kabel für den Anschluss an einen Computer und ein Stromkabel nach außen. Das Stromkabel dient der Energieversorgung der LEDs. Beim Auslösen der Pads ertönen Sounds. Bei der Nutzung des Programms ist auf die erforderlichen Softwarepakete zu achten. Die Software wurde unter Linux entwickelt und getestet. Der Prototyp stellt eine Möglichkeit der Umsetzung des DancePads Projektes dar und ist voll funktionsfähig. Die in den Hilfekarten vorgegebenen Codesnippets entstammen dem Quellcode des Prototyps. Der gesamte Quellcode ist im Anhang zu finden.

DancePads-Protoyp

DancePads Protoyp

QuellenBearbeiten

AnhangBearbeiten