material/Examensarbeit Spittank/source/chapters/060-Gestaltung/060-main.tex

\chapter{Gestaltung mobiler Informatiksysteme für die Nutzung im Unterricht}\label{chpGestaltung}

Dieses Kapitel muss noch einmal mit der schon in der Einleitung angedeuteten Klarstellung beginnen. Der Autor wurde von interessierten Personen mehrfach auf das Thema der Arbeit angesprochen und bei den Diskussionen traten zwei wesentliche Missverständnisse auf. Erstens geht es hier nicht um die Gestaltung des konkreten Unterrichts mit mobilen Informatiksystemen. Hierzu liegen bereits entsprechende Entwürfe aus der Diplomarbeit von Matthias Heming \citep{Heming2009} und aus den Pilotkursen an der Willy-Brandt-Gesamtschule Bergkamen vor. Das hier zu behandelnde Problem ist leider viel grundlegender. Nach dem Wegfall der bisher genutzten Plattform \textit{Symbian S60}  stehen die Vertreter der Idee, Informatikunterricht mit mobilen Informatiksystemen zu betreiben, wieder fast am Anfang. Es muss also zunächst eine neue Basis in Form einer Lernumgebung geschaffen werden. 

Zweitens geht es auch nicht um die Gestaltung von Informatiksystemen für den Unterricht im Hinblick auf den Entwurf und die Produktion spezifischer Unterrichtssysteme, wie dies etwa im Rahmen des Projekts \gls{OLPC}\vgln{OLPC} ge\-schieht. Dies wäre zwar grundsätzlich denkbar, läuft jedoch dem Ziel des Alltagsbezugs zuwider. Es besteht die Gefahr, dass dadurch reine \enquote{Unterrichtsgeräte} entstehen würden, die den gewünschten Effekt konterkarieren würde.

\section{Lernumgebung}
	Nach der Auswahl einer grundsätzlich geeignet erscheinenden Plattform stehen weitere Entscheidungen an, wie diese sinnvoll im Unterricht verwendet werden soll. Primär geht es um die Gestaltung einer didaktisch sinnvollen Lernumgebung. Diese ist als Gesamtheit der verwendeten \textit{Programmiersprache}, \textit{Werkzeuge} und \textit{Bibliotheken} anzusehen. Dass das Ziel die Programmierung mit den Geräten ist, sollte inzwischen hinreichend deutlich geworden sein.
	
	Da auf einer Plattform meist mehrere \textit{Programmiersprachen} zur Verfügung stehen, ist eine passende auszuwählen. Hierfür wurden bereits beim Kriterium der Programmierbarkeit\vglr{secKritProg} die Auswahlkriterien nach Linkweiler als Grundlage benannt. Bei Verfügbarkeit erscheint es demnach sinnvoll, mit Python zu arbeiten.
	
	Die notwendigen \textit{Werkzeuge} richten sich zum Teil nach den Erfordernissen der jeweiligen Plattform. Auf jeden Fall werden aber ein \textit{Interpreter} oder \textit{Compiler} und ein \textit{Editor} benötigt. Dabei ist, wie in \referenz{secKritWerk} erläutert, ein einfacher Editor vollkommen ausreichend. Es muss zudem sichergestellt werden, dass auch Sonderzeichen einfach eingegeben werden können, entweder über eine passende \textit{\gls{OSTastatur}} oder mit einer Erweiterung des zu verwendenden Editors.
	
	Zusätzlich ist eine \textit{Klassenbibliothek} erforderlich, die einerseits die objektorientierte Programmierung auf der Plattform ermöglicht und andererseits eine sinnvolle didaktische Reduktion der vorhandenen Möglichkeiten ist.	

\section{Klassenbibliothek}
		
		Die Entwicklung einer eigenen Klassenbibliothek für den Informatikunterricht ermöglicht die didaktische Reduktion der jeweiligen \glspl{API}. Zusätzlich sorgt die weitere Abstraktionsebene für eine geringere Abhängigkeit von der Plattform. Bei einem Plattformwechsel muss im Idealfall nur die Klassenbibliothek übertragen werden. Das Unterrichtsmaterial kann unangetastet weiterverwendet werden, zumindest unter der Voraussetzung, dass auch die entsprechende Programmiersprache zur Verfügung steht.

	\subsection{Stifte und Mäuse}
		Bei den bisherigen Ansätzen kam die Portierung der im schulischen Kontext beliebten Klassenbibliothek \gls{SuM} \citep[vgl.][]{Schriek} zum Einsatz. Der Autor hält es jedoch für unabdingbar, beim neuen Ansatz davon abzurücken. Dies liegt vor allem daran, dass das SuM-Konzept eigentlich nicht zu den Zielen passt, die mit dem Einsatz mobiler Informatiksysteme verbunden sind. Dies wird bereits am Namen des Konzepts und an der Zusammenstellung der grundlegenden Klassen von \gls{SuM} deutlich. Es gibt hier die Klassen \textit{Bildschirm}, \textit{Maus}, \textit{Tastatur}, \textit{Stift} und Buntstift. Maus und Tastatur haben bei modernen Smartphones in der Regel überhaupt keine realweltlichen Repräsentanten mehr. Der Bildschirm, der bei \gls{SuM} eher eine Zeichenfläche ist\footnote{Ansonsten wäre das Zeichnen mit Stiften auf den Bildschirm auch eher eine seltsame Assoziation.}, findet zumindest bei einigen Plattformen ebenfalls keine Entsprechung. Bei den wenigsten ist es zudem möglich, im Vollbildmodus den gesamten Bildschirm zu verwenden. Somit wäre jegliche Entsprechung der Klasse Bildschirm immer nur ein Teil des realen Bildschirms, ein Bildschirmausschnitt also. An den Stiften sieht man zudem die deutliche Ausrichtung des Konzepts auf die Erzeugung grafischer Darstellungen. Der Autor ist überzeugt, dass diese Sichtweise dazu verleitet, im Unterricht ein \enquote{Malen nach Objekten} zu etablieren und darüber die notwendige Alltagsanbindung zu vergessen. Dass diese Gefahr besteht, wird mehr als deutlich, wenn man sich den tatsächlichen Un\-ter\-richts\-ein\-satz von \gls{SuM} an den meisten Schulen ansieht. \cite{SuMKritik} kritisiert hier zu Recht, dass die verbreitete Praxis zu einem seltsamen Verständnis von Objektorientierung führt:
		
		\zitatblock[.]{In der zunächst kleinen Welt von SuM findet man Autos, Züge, die über den Bildschirm fahren. Das ist alles ordentlich programmiert, aber es ist eine blasse Welt von Häusern ohne Dach und Fenster, Mäusen ohne Schwanz und Ohren, Lokomotiven ohne Räder, Kessel und Schornstein usw. [\dots] Wenn in den Unterklassen lediglich nur eine Methode auftaucht, die per Stift ein anderes Bild fertigt, aber ansonsten keine Merkmale von Vererbung zeigt, darf man sich schon fragen, was hier eigentlich modelliert wird. Sicher nicht Anwendungsaspekte und Ausschnitte der Realwelt. [\dots] Damit wird die Forderung nach sauberer Modellierung konterkariert und den Schülern vom ersten Tage an ein falsches Bild von den Entwurfsaufgaben der Informatik und den Möglichkeiten der OOP vermittelt. }{SuMKritik}{1}
		
		Ein weiteres Problem ist der Wildwuchs an verfügbaren Erweiterungen, die oft ohne didaktische Bewertung unkritisch verwendet werden. Da diese sich oft genug nicht an die von \gls{SuM} vorgegebene Notation halten, ensteht in der Praxis ein buntes Gemisch verschiedener Programmierstile, die von den \SuSn zu berücksichtigen sind. Von der notwendigen Orthogonalität bleibt keine Spur.
		
		Nun ist es keinefalls so, dass das SuM-Konzept von Grund auf schlecht wäre, es passt jedoch nicht mehr zum zeitgemäßen Informatikunterricht. Eine zu entwickelnde Alternative muss den Fokus vom Zeichnen grafischer Objekte wegführen. Dabei können und sollten durchaus erprobte und gut funktionierende Erweiterungen von \gls{SuM}, etwa \textit{sumStrukturen}, \textit{sumNetz}, \textit{sumSQL}, \textit{sumWerkzeuge}\vgln{SuMS60} und \textit{PyObjVG}\vgl{HemingINFOS2009}{13~ff.}, weiterverwendet werden\footnote{Über die Weiterverwendung der grafiklastigen Teile kann diskutiert werden. Zumindest die Klasse Bildschirm muss dann aber umbenannt werden.}. Die grundsätzlich vernünftige Notation muss daher ebenfalls beibehalten werden. 

	\subsection{Grundsätzliche Überlegungen}

		Für den Entwurf einer neuen Klassenbibliothek sind also zunächst einige Kriterien zu benennen. Diese sollten sich an den bereits erarbeiteten Kriterien orientieren. Besonders bedeutend ist das Kriterium der Programmierbarkeit\vglr{secKritProg}. Daraus folgt, dass auch die Kriterien nach Linkweiler, die zur Auswahl der Programmiersprache gebraucht werden, zu berücksichtigen sind. Es gilt also zunächst, dass das Konzept\dots
		\vspace{1em}
		\begin{compactitem}
			\item \dots \textit{orthogonal} sein muss.
			\item \dots \textit{kompakt und lesbar} sein muss.
			\item \dots einfach \textit{verständlich} und leicht \textit{erlernbar} sein muss.
			\item \dots strikt \textit{objektorientiert} sein muss.
			\item \dots \textit{modularisiert} und wiederverwendbar gestaltet sein muss.
			\item \dots \textit{portabel} sein sollte.
			\item \dots gut \textit{dokumentiert} sein sollte.
		\end{compactitem}
		\vspace{1em}
		
		Die Kompaktheit und die Modularisierung sind aufgrund der Einschränkungen der mobilen Informatiksysteme besonders bedeutend. Im Hinblick darauf sollte bei der Objektorientierung darauf geachtet werden, dass keine zu komplexen Zusammenhänge zwischen den Klassen notwendig werden. Dies trägt auch zur Wiederverwendbarkeit bei und unterstützt andere Zugänge bei der Modellierung, etwa den Einsatz von Objektspielen.
		
		Zur Verständlichkeit und Erlernbarkeit muss durch ein klares Bekenntnis zur Orthogonalität beigetragen werden. Hier sollte zudem durch die konsequente Verwendung objekorientiert implementierter Datenstrukturen, wie sie etwa durch sumStrukturen bereitgestellt werden, zumindest im Anfangsunterricht eine klare und eindeutige Linie verfolgt werden. Später können auch Spracheigenheiten, wie die äußerst angenehm zu verwendenden Listen und Dictionaries in Python, verwendet werden.
		
	\subsection{Entwurf einer geeigneten Klassenbibliothek}
		Da nun die wichtigsten Kriterien für die Gestaltung einer neuen Klassenbibliothek benannt sind, soll jetzt ein Vorschlag für eine solche gemacht werden. Es ist wichtig, eine starke Modularisierung beizubehalten, daher sollen funktionale Gruppen bestimmter Klassen in Paketen zusammengefasst werden, die (möglichst) unabhängig voneinander eingebunden und verwendet werden können. Hier lassen sich verschiedene SuM-Erweiterungen integrieren. So etwa die besonders wichtige Erweiterung sumStrukturen. Allerdings sollten diese Erweiterungen noch an eine Besonderheit der aktuellen mobilen Informatiksysteme angepasst werden: Zusätzlich zu den bereits vorhandenen Ausgabefunktionen müssen Rückgabefunktionen für Zeichenketten -- \texttt{gibZeichenkette()} -- implementiert werden. Denn aufgrund der meist fehlenden oder fehlerhaften Konsolen kommt man mit einer normalen Ausgabe von Text nicht weit. Jede dieser SuM-Erweiterungen sollte in der neuen Klassenbibliothek ein Paket darstellen.
		
		Zusätzlich zu den Übernahmen aus \gls{SuM} bedarf es einiger weiterer Pakete. Neben einem neuen Ansatz für die grafische Benutzeroberfläche und einiger multimedialer Erweiterungen wären hier Pakete für die spezifischen Funktionen mobiler Informatiksysteme notwendig. Etwa Pakete für \textit{Nachrichten} (SMS, E-Mail, Chat), \textit{Kontakte}, \textit{Kalender}, \textit{Sensoren}, \textit{Positionsdaten}, \textit{Bluetooth} und \textit{Telefonie} (auch Internettelefonie). Die multimedialen Pakete sollten eine einheitliche Möglichkeit bieten, Medien (Audioaufnahmen, Videos, Fotos) aufzunehmen und wiederzugeben. Außerdem können die, auf den meisten Geräten vorhandenen, Funktionen zur Spracherkennung und Sprachausgabe in ein weiteres Paket verpackt werden. Eine einheitliche Basis für die Sensoren gestaltet sich hingegen, aufgrund der Vielzahl verschiedener Arten von Sensoren, die berücksichtigt werden müssen, schwierig. Hier wäre darüber nachzudenken, ob eine Normierung sinnvoll möglich ist (etwa auf eine Skala zwischen 0 und 100 bzw. -100 und 100). So könnten verschiedene Sensoren über eine einheitliche Schnittstelle abgefragt und gegebenenfalls gegeneinander ausgetauscht werden. Da aktuelle mobile Informatiksysteme für die Bestimmung der Position zumindest vier verschiedene Wege (via Satellit, IP-Adresse, empfangenen \glspl{SSID} von \glspl{WLAN} und Mobilfunkzellen-ID) anbieten, erscheint es sinnvoll, hier ebenfalls eine entsprechende Vererbungshierarchie zu erstellen.
		
		Für die grafische Oberfläche sind deutlich mehr Faktoren zu bedenken. Da hier auf unterschiedlichen Plattformen verschiedene Ansätze verfolgt werden müssen, empfiehlt sich eine Reduktion auf die wesentlichen Komponenten, etwa \textit{Ansichten}, \textit{Tastern}, \textit{Schaltern}, \textit{Bildern} (evtl. auch \textit{Zeichenflächen}, so dies von der Plattform unterstützt wird) und \textit{Textfeldern} (sowohl statischen als auch Eingabefeldern). Die Ansichten ersezten dabei die bisher eher gebräuchliche Fenstermetapher, denn die meisten mobilen Informatiksysteme bieten keine Fenster an, sondern zeigen immer nur eine Ansicht gleichzeitig. Die Platzierung von Komponenten sollte wegen der Kompatiblität zu verschiedenen Systemen keinesfalls absolut erfolgen. Die äußerst unterschiedlichen Displaygrößen würden hier zu Darstellungsproblemen führen. Weil die verschiedenen Layout-Konzepte auf den verschiedenen Plattformen als deutlich zu komplex für den Unterricht erscheinen, wird hier eine zusätzliche Klasse \textit{Container} vorgeschlagen, die verschiedene Komponenten (auch  andere Container) aufnehmen und entweder vertikal oder horizontal nebeneinander darstellen kann. Die Komponenten sollten dabei in der jeweiligen Richtung gleichmäßig skaliert werden, während sie in der anderen Richtung die gesamte Containergröße beanspruchen sollten. Dies beschränkt natürlich die Gestaltungsmöglichkeiten massiv, bietet jedoch die größtmögliche Kompatiblität und ist in der Anwendung besonders einfach. Für fortgeschrittenere Anwendung wären entsprechende Ergänzungen etwa in Form einer tabellarischen Darstellung denkbar.
		
		Die bisherigen Überlegungen zur grafischen Oberfläche berücksichtigen allerdings nicht, dass es Ansätze gibt, die keine freie Gestaltung der grafischen Benutzungsschnittstelle zulassen. Für diese sollte in Form vorgefertigter Dialoge eine entsprechende Alternative angeboten werden. Die einfachste Form eines Dialogs wäre die einfache Darstellung von Text, ebenfalls notwendig wäre ein Dialogtyp zur Eingabe von Texten. Weitere Formen etwa zur Auswahl zwischen Alternativen wären denkbar, sind jedoch nicht zwingend erforderlich.
		
		Die bisher beschriebenen Überlegungen wurden vom Autor in einen entsprechenden Entwurf umgesetzt, der sich in Diagrammform auf der beiliegenden CD findet. Für einen ersten Überblick wurden einzelne Diagramme im Anhang abgedruckt\vglr{secKlass}.