Auflistung nach:
Auflistung LOG IN 33(1) - 2013 nach Erscheinungsdatum
1 - 10 von 15
Treffer pro Seite
Sortieroptionen
- ZeitschriftenartikelInfo-Markt(LOG IN: Vol. 33, No. 1, 2013) Peters, Ingo-Rüdiger
- ZeitschriftenartikelHardware & Software: ArduBlock – Visuelle Entwicklungsumgebung für die Arduino-Plattform(LOG IN: Vol. 33, No. 1, 2013) Baumann, Rüdeger
- ZeitschriftenartikelAm Rande bemerkt …(LOG IN: Vol. 33, No. 1, 2013) Koerber, Bernhard
- ZeitschriftenartikelEditorial(LOG IN: Vol. 33, No. 1, 2013) Koerber, Bernhard
- ZeitschriftenartikelVeranstaltungskalender(LOG IN: Vol. 33, No. 1, 2013) Koerber, Bernhard; Wilke, Thomas
- ZeitschriftenartikelMyoelektrische Armprothesen und digitale Elektronik – Ein altes Thema neu entdeckt und für den Unterricht aufbereitet(LOG IN: Vol. 33, No. 1, 2013) Strecker, Kerstin
- ZeitschriftenartikelModellieren und Implementieren für Android-Smartphones(LOG IN: Vol. 33, No. 1, 2013) Wehrheim, Ottovon Otto Wehrheim Smartphones sind vollwertige Informatiksysteme, die den Alltag der Lernenden prägen. Im Unterricht entwickelte 'Apps' können von Schülerinnen und Schülern jederzeit ortsunabhängig benutzt und mit einem gewissen Stolz auf die eigene Leistung auch anderen präsentiert werden; das in dieser neuen pädagogischen Dimension des Informatikunterrichts liegende Motivationspotenzial sollte unterrichtlich genutzt werden. Realitätsnahe und motivierende Anwendungsbeispiele gibt es viele, u. a. mit Animationen und Klängen, sowie grafische Darstellungen mit Auswertung von Sensordaten. Am Beispiel des bekannten Memory-Spiels (siehe Bild 1) wird im Folgenden die objektorientierte Modellierung und Implementierung mit JAVA für AndroidSmartphones erläutert. Das Memory-Spiel ist als Unterrichtsprojekt in der Qualifikationsphase gut geeignet, um einen Einblick in professionelle Software-Architekturen und Entwicklungsumgebungen zu vermitteln. Dies ist in der Oberstufe im wissenschaftspropädeutischen Sinne unerlässlich. Beispielsweise werden in Hessen in der Oberstufe noch keine 'Blöcke gestapelt' und dies mag auch noch lange Zeit so bleiben. Das heißt: Man pflegt nach wie vor textuelles Programmieren im Gegensatz zum visuellen (oder grafischen) Programmieren, wie es neuerdings auch in dieser Zeitschrift mehrfach dargestellt und propagiert worden ist. Grundlegende Techniken wie die Speicherung der Struktur und der Attribute von Benutzungsoberflächen sowie von (landessprachen-spezifischen) Textkonstanten in XML-Dateien, aber auch Konzepte der ereignisgesteuerten Programmierung und die Begriffe der objektorientierten Modellierung (u. a. Assoziation, Aggregation und Vererbung) können an diesem Beispiel erarbeitet werden. Dabei empfehlen sich eine projektartige, produktorientierte Vorgehensweise und eine sorgfältige methodische Planung. Manches muss vorgegeben, vieles kann aber auch von den Lernenden selbstständig erkundet und erarbeitet werden. Insbesondere können die dazu notwendigen instrumentellen Fertigkeiten wie z. B. der Umgang mit der Entwicklungsumgebung und das Anlegen eines neuen Projekts im Sinne des 'Umgekehrten Klassenzimmers' (siehe Kasten, nächste Seite) am besten mit selbsterstellten Video-Tutorien vermittelt werden. Die unterrichtlichen Voraussetzungen sind in Hessen am Ende der Einführungsphase in der Oberstufe i. d. R. gegeben, wenn man mit JAVA in das Programmieren einführt und HTML (mit Stylesheets zur Trennung von Layout und Inhalten) verwendet hat. Es lohnt sich daher, bereits in der Einführungsphase mit Eclipse zu arbeiten und einfache Benutzungsoberflächen mit dem WindowBuilder zu implementieren (vgl. Ullenboom, 2007, und Wehrheim, 2010). Eclipse unterstützt die Entwicklung von Android-Projekten in hervorragender Weise: Die meisten Fehler werden schon beim Ent-
- ZeitschriftenartikelLOG OUT(LOG IN: Vol. 33, No. 1, 2013) Koerber, Bernhard
- ZeitschriftenartikelLeserbriefe(LOG IN: Vol. 33, No. 1, 2013) Koerber, Bernhard; Schlager, MarkusBetr.: LOG IN Nr. 172/173, S. 101113 Von SCRATCH über BYOB nach JAVA Ein Unterrichtsbeispiel für Klassenstufe 10 Vielen Dank an die Autoren für diesen Artikel. Ich kann sie in dem Vorgehen nur bestärken, das objektorientierte Modellieren von der zusätzlichen Hürde des textbasierten Programmierens zu entlasten, die Modellierung durch eine visuelle Programmierumgebung zu unterstützen und damit zugleich den Einstieg in den Umgang mit klassischen Programmiersprachen zu erleichtern. Seit mehreren Jahren unterrichte ich selbst am Gymnasium in Bayern nach dem gleichen Konzept, allerdings mit wechselnden Programmiersprachen mehrfach PYTHON und SMALLTALK, im vergangenen Schuljahr auch einmal JAVA. Für die visuelle Programmierung setze ich sowohl SCRATCH als auch ETOYS ein und möchte von daher ein paar Dinge anmerken. Die Situation ist in Bayern insofern anders, als alle Schülerinnen und Schüler verpflichtend in Jahrgangsstufe 6 einen Einblick in das Konzept von Klassen und Objekten und in Jahrgangsstufe 7 die Grundzüge der Ablaufmodellierung vermittelt bekommen, ehe sich für sie in der 10. Klasse mit der objektorientierten Programmierung ein Kreis schließt. Wenn man sich nach den eingeführten Schulbüchern orientiert, sind die üblichen Werkzeuge Robot Karol für die Ablaufmodellierung in der 7. Klasse und JAVA mit BLUEJ in Klasse 10. Da Robot Karol weder die objektorientierten Konzepte aus Jahrgangsstufe 6 aufgreift noch projektorientiertes Arbeiten wie im Lehrplan vorgesehen oder offene Aufgabenstellungen und damit einhergehende Binnendifferenzierung ermöglicht, setze ich stattdessen seit jeher mit großer Zufriedenheit SCRATCH ein. Der Vorteil gegenüber ETOYS besteht an dieser Stelle in meinen Augen vor allem darin, dass die Oberfläche intuitiver zu bedienen ist, weil sämtliche Werkzeuge zu sehen sind, und die stärkere Beschränkung weniger unvorhergesehene Fehler zulässt. Der Nachteil, keine eigenen Operationen schreiben zu können bzw. sich hier mit Broadcast-Nachrichten behelfen zu müssen (was die Bausteine sende an alle und wenn ich empfange leisten), wird mit der kommenden Version 2.0 (http://beta.scratch .mit.edu/) entfallen, die das Erstellen eigener Blöcke wie in BYOB erlaubt. Bei der objektorientierten Modellierung in Jahrgangsstufe 10 ist SCRATCH meiner Meinung nach allerdings an wenigstens zwei zentralen Punkten eindeutig überfordert, die ETOYS aber bietet: Objektorientierung setzt auf der einen Seite auf Kapselung, auf der anderen Seite auf Beziehungen und damit auf Kommunikation zwischen Objekten: Nachrichten bzw. Methodenaufrufe werden versandt. Anders als in ETOYS sind in SCRATCH aber nur Broadcast-Nachrichten möglich; kein Objekt kann gezielt ein anderes individuell ansprechen. Auch lassen sich in SCRATCH keine Beziehungen zwischen Objekten umsetzen, weil SCRATCH keine objektwertigen Variablen oder Parameter kennt. Diese benötigt man aber z. B. schon bei einer einfachen Aggregation. ETOYS leistet das mit Variablen vom Typ Darsteller. Ein weiterer Vorzug von ETOYS besteht im Geschwister-Konzept, das eine Brücke vom prototypenbasierten Ansatz, dem SCRATCH und ETOYS an sich folgen, zum klassenbasierten Programmieren bildet, wie es die Schüler in der Folge lernen. Mit der Möglichkeit, in Skripten Klone von Figuren zu erzeugen, zieht SCRATCH in der Version 2.0 hier einen Schritt weit nach. Wenn man sich davon frei macht, die Schülerinnen und Schüler als erste Programmiersprache ausgerechnet mit JAVA zu konfrontieren, bietet ETOYS anders als SCRATCH zudem die Möglichkeit, auch das beiden zugrunde liegende SMALLTALK sichtbar zu machen und auch zu nutzen, was sich gerade bei komplexeren Projekten, wie sie sich in einer 10. Jahrgangsstufe entwickeln können, ganz organisch ergibt, weil sich manchmal Fragen anhand der sichtbaren Programmierblöcke (bzw. -kacheln, wie sie in ETOYS heißen) nicht eindeutig entscheiden lassen. Für das anschließende Programmieren in SMALLTALK wechselt man aber besser zu SQUEAK oder PHARO. Markus Schlager Gottsdorf
- Zeitschriftenartikel