Beiträge hinzugefügt, Examensarbeit hinzugefügt, Diagramme hinzugefügt.

This commit is contained in:
Daniel Spittank 2017-02-21 22:27:13 +01:00
parent d28f0594c2
commit aa36f85702
216 changed files with 173743 additions and 0 deletions

Binary file not shown.

View file

@ -0,0 +1,50 @@
% Examensarbeit
% Autor: Daniel Spittank
% E-Mail: determina@daniel.spittank.net
\documentclass[print,11pt]{examensarbeit}
%\documentclass[11pt]{examensarbeit}
\includeonly{
500-glossar,
501-akronyme,
chapters/010-Einleitung/010-main,
chapters/020-Bedeutung/020-main,
chapters/030-Perspektiven/030-main,
chapters/040-Kriterien/040-main,
chapters/050-Auswahl/050-main,
chapters/060-Gestaltung/060-main,
chapters/070-Android/070-main,
chapters/080-Ausblick/080-main,
100-appendix
}
\input{config}
\include{500-glossar}
\include{501-akronyme}
\begin{document}
\include{chapters/010-Einleitung/010-main}
\include{chapters/020-Bedeutung/020-main}
\include{chapters/030-Perspektiven/030-main}
\include{chapters/040-Kriterien/040-main}
\include{chapters/050-Auswahl/050-main}
\include{chapters/060-Gestaltung/060-main}
\include{chapters/070-Android/070-main}
\include{chapters/080-Ausblick/080-main}
\include{100-appendix}
\examenAbschluss
\end{document}

View file

@ -0,0 +1,241 @@
\appendix
\chapter{Anhang}
\section{Erläuterungen}
\subsection{Zum verwendeten Zahlenmaterial}\label{secZahl}
Die Fragen nach der Bedeutung von Informatiksystemen insgesamt, mobilen Informatiksystemen im Speziellen sowie den gesellschaftlich üblichen Nutzungsgewohnheiten lassen sich nur sinnvoll beantworten, indem man auf empirische Daten zurückgreift. Nun ist es natürlich schwierig, hierzu konkrete Zahlen zu erheben. Am vielversprechendsten erscheinen hier noch die Veröffentlichungen des \gls{BITKOM} (etwa \citep{bitkom2011a} und \citep{bitkom2011b}), da sich diese -- zumindest zum Teil -- auf die realen Verkaufszahlen seiner Mitglieder beziehen. Natürlich umfassen diese Daten immer nur die in Deutschland neu verkauften Geräte und ignorieren somit sowohl gebrauchte bzw. noch im Gebrauch befindliche Altgeräte als auch Importe aus dem (europäischen) Ausland, die heute selbst für Privatpersonen einfach zu realisieren sind.
Unabhängig von grundlegenden Problemen einer genauen Erfassung ergibt sich ein weiteres wesentliches Problem. Denn viele relevante Erhebungen -- etwa zur Verbreitung von Smartphones -- werden nur von (in der Regel privatwirtschaftlich geführten) Meinungs- und Marktforschungsinstituten bzw. -unternehmen durchgeführt, die die vollständigen Ergebnisse ihrer Studien nur gegen erhebliche Gebühren zugänglich machen.
Die konkreten Messmethoden werden ebenfalls oft nicht veröffentlicht, sodass bestenfalls die Stichprobengröße und die untersuchte Personengruppe bekannt sind. Allein die Auswahl der untersuchten Personengruppen unterscheidet sich zwischen den verschiedenen verfügbaren Studien deutlich: In manchen Erhebungen werden nur Handy- oder Internetnutzer erfasst, in anderen wird die Gesamtbevölkerung als Basis gewählt. Ohne detaillierte Kenntnisse zu den verwendeten Methoden und der tatsächlichen Datenbasis verbieten sich also direkte Vergleiche. Daher müssen die jeweiligen Ergebnisse im Gesamtkontext aller herangezogenen Studien gesehen werden. Trotz offenbar sehr unterschiedlicher Datenbasen und verschiedener Methoden werden dabei oft tendenziell ähnliche Aussagen getroffen.
Zusätzlich sind die tatsächlich (fast) vollständig veröffentlichten Studien oft von direkt oder indirekt an der Herstellung oder dem Verkauf entsprechender Geräte beteiligten Akteuren in Auftrag gegeben worden. Allen voran ist hier das umfangreiche \enquote{\gls{OMP}} \citep{OMP} zu nennen, welches Google in Auftrag gegeben und veröffentlicht hat. Als Hersteller des Betriebssystems \gls{Android} und Eigentümer des Smartphone-Herstellers Motorola ist Google natürlich alles andere als eine neutrale Instanz. Auch unter diesem Gesichtspunkt sind die Zahlen der Studien natürlich kritisch zu sehen.
Im Rahmen dieser Arbeit war es somit nicht möglich, vollständig belastbare Zahlen zu Verbreitung und Nutzung mobiler Informatiksysteme, bezogen auf die Gesamtbevölkerung, zu erhalten. Trotzdem können die Zahlen wichtige Hinweise liefern. Es wurden daher nur Ergebnisse verwendet, die hinreichend plausibel waren, d.\,h. tendenziell von anderen Studien bestätigt wurden. So sind sie dann zu verstehen: Es kommt hier weniger auf die tatsächlichen Werte an, sondern auf Größenordnungen und Trends.
Glücklicherweise steht zumindest für die Gruppen der sechs- bis neunzehnjährigen Kinder, Jugendlichen und jungen Erwachsenen umfangreiches Zahlenmaterial zum Gerätebesitz und zur Mediennutzung bereit. Der \gls{MPFS}, ein Kooperationsprojekt von der Landesanstalt für Kommunikation Baden-Württemberg und der Landeszentrale für Medien und Kommunikation Rheinland-Pfalz, führt seit 1998 zusammen mit dem \gls{SWR} zwei Langzeitstudien zur Mediennutzung durch. Die \gls{KIM} deckt dabei die Altersgruppe von sechs bis dreizehn Jahren ab, die \gls{JIM} beschäftigt sich hingegen mit den Zwölf- bis Neunzehnjährigen.
Diese jährlich durchgeführten Studien sind die wichtigste Datenquelle für die folgenden Betrachtungen. Dabei spielt die JIM-Studie eine größere Rolle, da sich diese Arbeit auf den (Informatik-)Unterricht konzentriert, wie er an weiterführenden Schulen stattfindet.
\subsection{Gerätetypen}\label{secTyp}
\subsubsection{Handys}\label{secHandy}
In der Kategorie \glspl{Handy}, werden alle Mobiltelefone erfasst, die in erster Linie genau das sind. Obgleich durchaus weitere Funktionen wie Multimediafähigkeiten, Kameras oder erweiterbare Speicherkapazität vorhanden sein können.
Wichtigstes gemeinsames Merkmal ist die fehlende Erweiterbarkeit um zusätzliche Anwendungen. Auch fehlende Sensoren oder fehlende Zusatzfunktionen wie Ortungsdienste grenzen diese Gruppe von den anderen ab, diese sind jedoch zu uneindeutig für eine eindeutige Zuordnung. So gibt bzw. gab es durchaus einzelne Handys mit GPS-Empfängern. Außerdem zeichnen sie sich durch bestenfalls nur eingeschränkte Netzanbindung aus (zum Beispiel verfügen die wenigsten über WLAN, sondern bieten eher einen eingeschränkten Zugriff auf Internet-Dienste über das Mobilfunknetz, etwa nur WAP und E-Mail). Hochauflösende Displays oder gute Kameras sind hier ebenfalls eher selten zu finden.
Bei den Eingabemethoden verfügen diese Geräte in der Regel nicht über Touch\-screens oder Spracheingabefähigkeiten, sondern meist über klassische Hard\-ware-Tas\-ta\-tu\-ren (üblicherweise Handy-Tastaturen mit der bekannten alphanumerischen Belegung).
Handys sind inzwischen nur noch in bestimmten Nischen erhältlich. Dazu gehören Notfall- und einmalig nutzbare Geräte ebenso wie Großtastentelefone für Senioren.
\subsubsection{Java-Handys}\label{secJavaHandy}
Die Java-fähigen Mobiltelefone entsprechen eigentlich den Handys, bis hin zum üblicherweise mit den Handys übereinstimmenden Bedienkonzept. Obwohl sie für gewöhnlich als \gls{JavaHandy} bezeichnet werden, fallen sie aus der reinen Han\-dy-Ka\-te\-go\-rie heraus, da sie eine grundsätzliche Erweiterbarkeit um zusätzliche Anwendungen -- auf Basis der Java Micro Edition -- bieten. Die Java Micro Edition ist gegenüber der bekannteren Standard Edition stark reduziert, um die Funktionsfähigkeit auf Geräten mit beschränkten Ressourcen zu ermöglichen. Auch kann nicht auf alle nativen Funktionen der Handys zugegriffen werden.
Diese grundsätzliche Erweiterbarkeit unter Berücksichtigung der vorhandenen starken Ein\-schrän\-kungen gegenüber (Lesser) Smartphones rechtfertigt eine eigene Kategorie. Die Einsatzmöglichkeiten für den Unterricht wurden von \cite{Carrie2006} bereits beschrieben.
\subsubsection{Lesser Smartphones}\label{secLesserSP}
Geräte aus der Kategorie der \enquote{\glspl{LesserSP}}\footnote{Eigentlich ist der Begriff des \gls{LesserSP} eng mit Samsungs Betriebssystem Bada verknüpft. Hier wird er jedoch dem häufig analog verwendeten Begriff des \enquote{Feature Phones} vorgezogen, da jener noch weniger durch feste Eigenschaften von Smartphones unterschieden wird, sondern der zeitliche Aspekt eine wesentlich größere Rolle spielt. Genauer: Alles, was derzeit kein Smartphone ist, ist demnach ein \enquote{Feature Phone}.} verfügen über die Möglichkeit der Installation zusätzlicher Programme, häufig zusätzliche Sensoren und in der Regel eine nur wenig eingeschränkte Netzanbindung (vor allem eine umfangreiche, wenn auch oft langsame, Nutzung von Internet-Diensten). In Studien, Statistiken und im allgemeinen Sprachgebrauch werden sie in der Regel den Smartphones zugerechnet.
Allerdings sind hier noch sehr enge Grenzen (vor allem im Hinblick auf die knappen Ressourcen) vorhanden, die die jeweiligen Merkmale einschränken. Diese fallen jedoch bereits wesentlich weniger ins Gewicht als bei Java-Handys. So ist selbst bei neueren Geräten dieser Kategorie in vielen Fällen das Betrachten von umfangreichen, auf die Nutzung mit PC-Systemen optimierten Webseiten kaum möglich. Im Gegensatz zu Smartphones oder Java-Handys gibt es hier eher selten (als kleine Ausnahme wäre hier wiederum Samsungs Betriebssystem Bada zu nennen) \textit{gemeinsame \glspl{API}}, sodass es aufgrund des hohen Anpassungsaufwands nur wenige \glspl{App} externer Anbieter für diese Geräte gibt. Die fehlenden \glspl{API} sind der Hauptgrund für die eigene Kategorie im Rahmen dieser Arbeit. Durch die mangelnden Gemeinsamkeiten erscheint es unwahrscheinlich, dass eine sinnvolle Nutzung im Informatikunterricht möglich wird. Sollten sich hier aber Plattformen wie Bada weiter etablieren und sich eine entsprechende Verbreitung einheitlicher \glspl{API} einstellen, wird diese Gerätekategorie wohl in der der Smartphones aufgehen.
Das auffälligste Unterscheidungsmerkmal zu den Java-Handys ist die in der Regel vorhandene Touch-Bedienung, die den neueren Smartphones nachempfunden wurde und inzwischen sogar häufig zur Erkennung von einfachen Berührungsgesten fähig ist, wie sie bei Smartphones Verwendung finden.
\subsubsection{Smartphones}\label{secSmartphone}
\glspl{Smartphone} zeichnen sich durch einen hohen Grad an Universalität aus. Sie sind durchweg erweiterbar, sowohl auf der Software- als auch auf der Hardwareseite. Bei der Hardware werden oft proprietäre Schnittstellen verwendet, die herstellerspezifische Erweiterungen erlauben. Inzwischen finden sich aber viele Geräte mit universellen, standardisierten Schnittstellen, etwa Bluetooth\footnote{Die Nutzung von Bluetooth war bisher bei vielen Geräten auf einige wenige (zum Teil herstellerspezifische) Profile eingeschränkt, daher ist es in diesem Zusammenhang erwähnenswert, auch wenn es schon lange bluetoothfähige Mobiltelefone gibt.}, USB (im Gegensatz zu einfacheren Geräten auch im Host-Modus) und HDMI.
Software lässt sich (in der Regel online über \enquote{Appstores} der Hersteller, bei einigen Systemen aber auch auf anderen Wegen) nachinstallieren. Da sie über wesentlich mehr Rechenleistung und Ressourcen verfügen, bieten sie sehr viel mehr Möglichkeiten als Java-Handys und Lesser Smartphones.
Die Smartphones verfügen heute fast ausnahmslos über Touchscreens mit der Fähigkeit zur Erkennung von Berührungsgesten. Sie erkennen durchweg mehrere Berührungspunkte gleichzeitig, was komplexere Gesten erlaubt. Die in der Hochzeit von Symbian üblichen Geräte mit Handytastatur oder sogar umfangreicher alphanumerischer Tastatur sind hingegen kaum noch anzutreffen.
Zusätzlich verfügen Smartphones über diverse Sensoren, die sowohl für die Bedienung als auch für speziellere Anwendungszwecke eingesetzt werden können. Dazu zählen Lage-, Beschleunigungs-, Umgebungslicht-, Näherungs- und Temperatursensoren ebenso, wie ausgefeilte Software für die Nutzung der von Kameras und Mikrofonen gelieferten Daten. Fast alle aktuellen Smartphones haben mindestens eine Kamera eingebaut, die neben der Aufnahme von Videos und Fotos für verschiedene andere Zwecke genutzt werden kann, etwa zur die Gesichtserkennung oder zur Erfassung von Barcodes.
Zudem verfügen viele Smartphones über \glspl{Ortungsmodul} (bei anderen lassen sie sich als externe Hardware nachrüsten) und eigenen sich somit mittels entsprechender Software als Navigationssysteme.
Viele Geräte verfügen über weitere Merkmale, etwa Module für \gls{NFC}, welche zur Authentifizierung des Benutzers (\zb für Bezahlvorgänge), Datenübertragungen etc. genutzt werden können.
\subsubsection{Tablets}\label{secTablet}
Tabletcomputer waren lange Zeit Nischenprodukte, die als \glspl{Slate} oder \glspl{Convertible} angeboten wurden. Die Bedienung erfolgte entweder mittels Stifteingabe oder -- seltener -- mittels Touchscreen. Die extrem hohen Preise sorgten dafür, dass die Geräte in der Regel nur im kommerziellen Bereich eingesetzt wurden. Außerdem gab es noch die Kategorie der \glspl{PDA}, bei der bereits einige Konzepte der heutigen Tablets anzutreffen waren. Jedoch ist diese Kategorie inzwischen, nachdem sie bereits von Smartphones stark zurückgedrängt wurde, spätestens nach dem Erscheinen der ersten Tablets und Hybride vollkommen bedeutungslos geworden.
Die Einführung von Apples iPad änderte die Situation grundsätzlich. Heutige Tablets basieren meist auf derselben Technik wie Smartphones (meist ARM-Ar\-chi\-tek\-tur), die zwar weniger leistungsstark, dafür aber wesentlich günstiger und weniger energiehungrig ist. Mit dem iPad entwickelten sich die neuen Tablets von einem Nischen- zu einem Massenprodukt mit eher universellem Nutzungsprofil. Tabletcomputer wurden zuvor eher im kommerziellen Umfeld eingesetzt, während die neue Generation der Tablets ganz klar die private Nutzung in den Vordergrund rückt, die geschäftliche aber nicht ausschließt.
Tablets zeichnen sich vor allem durch ihre Größe aus. Sie sind noch klein und leicht genug, um weitgehend mobil zu sein, bieten mit ihren großen Touchscreens (im Allgemeinen zwischen 7 und 10 Zoll) aber mehr Bedienkomfort. Mit ihnen ist es möglich, längere Zeit ohne größere Einschränkungen zu arbeiten. Das Schreiben von Texten fällt aufgrund großer Onscreen-Tastaturen leichter\footnote{Teile dieser Arbeit wurden ebenfalls auf Tablets und Hybriden verschiedener Hersteller verfasst.}.
Für \glspl{Tablet} gibt es im Allgemeinen weniger proprietäre Schnittstellen und dazu passende Zusatzhardware als für Smartphones, dafür verfügen Tablets häufiger\footnote{Dies gilt, wenn man die Gesamtheit der verfügbaren Tablets betrachtet und nicht den Marktanteil. Denn hier dominiert das iPad von Apple, das nur über proprietäre Schnittstellen verfügt.} über Schnittstellen, die sie mit einiger PC-Hardware\footnote{Vor allem Anzeigegeräte, Massenspeicher, Eingabegeräte und UMTS-Modems sind hier relevant, aber auch speziellere Hardware ist teilweise kompatibel.} kompatibel machen, allen voran sind hier USB-Host-Anschlüsse zu nennen, die bei Tablets inzwischen häufig anzutreffen sind, während sie bei Smartphones noch eine geringe Rolle spielen. HDMI-, VGA- und Video-Ausgänge finden sich bei Tablets eher ohne die Notwendigkeit von Adaptern, wie sie bei Smartphones in der Regel nötig sind.
\subsubsection{Hybride}\label{secHybrid}
Als \glspl{Hybrid} werden hier Geräte beschrieben, die eine Mischung aus Smartphones und Tablets darstellen. Diese Kategorie ist weniger trennscharf als die übrigen, rechtfertigt sich aber derzeit noch, da diese Geräte eher große Smartphones als Tablets sind und meist mit Smartphone-Betriebs\-sys\-te\-men ausgeliefert werden, jedoch trotzdem viele Eigenschaften mit den Tablets teilen. Wesentliches Merkmal der Geräte dieser Kategorie sind ihre Telefonfunktionen und ihre Größe.
Auf den ersten Blick sind die Hybride mit kleinen Tablets zu verwechseln, teilweise gibt es sogar einige Modelle, die sowohl als Hybrid als auch als Tablet (also ohne Telefonfunktion) verkauft werden. Allerdings verfügen sie -- anders als diese -- über echte Telefonfunktionen. Aufgrund ihrer Größe sind sie kaum als wirkliche Mobiltelefone geeignet. Die Telefonfunktion wird in der Regel über zusätzliche Headsets oder über eine (eingebaute) Freisprecheinrichtung genutzt.
In Bezug auf die Rechenleistung und die Ausstattung entsprechen sie üblicherweise guten Smartphones. Einige verfügen über besondere Merkmale, wie \zb Stifteingabe, die eher an die inzwischen fast vergessene Kategorie der \glspl{PDA} erinnern.
Teilweise haben sich inzwischen (häufig geräte- oder herstellerspezifische) Bezeichnungen wie Smartlet, Phablet, Tabphone, Padphone oder Teletab etabliert.
\section{Exkurse}
\subsection[Konsumgeräte]{Über die generelle Nichteignung von Konsumgeräten für den Unterricht}\label{secKonsum}
\subsubsection{Gläsernes Gefängnis}
Die wesentlichen Vorteile der mobilen Informatiksysteme erschließen sich relativ schnell, wenn man damit arbeitet. Die hohe Mobilität, die immerwährende Verfügbarkeit, die angenehme und auf das Nötigste reduzierte Benutzungsschnittstelle und das große Angebot an (kostengünstiger) Software machen die Geräte zu einem geschätzten, alltäglichen Begleiter.
Für die Benutzerinnen und Benutzer erscheinen die Geräte allerdings zunächst wie eine Blackbox. Die informatisch-analytische Perspektive\vglr{secPersAna} kann hier grundsätzlich Abhilfe schaffen. Versucht der informatisch interessierte Mensch allerdings, die Funktionsweise der Geräte zu ergründen oder sogar ihre Funktionalität zu erweitern, kann er schnell an unsichtbare Wände stoßen. Denn einige der Geräte wurden von den Geräteherstellern als geschlossene Systeme konstruiert, die nur zulassen, was der Hersteller explizit genehmigt hat. Und das ist in aller Regel der Konsum digitaler Inhalte in Form von Videos, Musik, E-Books und Apps. Kreativ gestaltend tätig werden, können der Benutzer oder die Benutzerin nur im Rahmen der von Hersteller gesteckten Grenzen.
Zu diesen Konsumgeräten gehören derzeit vor allem die Geräte der Firma Apple sowie Amazons Kindle Tablets und E-Book-Reader, aber auch weitere mobile Informatiksysteme anderer Hersteller. Aus schulischer Sicht sind wegen Apples derzeitiger Aktivitäten zur Eroberung des Bildungsmarktes vor allem die iOS-Geräte interessant.
Für Informatiksysteme übliche Funktionen werden bei Konsumgeräten häufig unterbunden oder verborgen. So ist oftmals kein einfacher Austausch von Dateien möglich, weder zwischen Apps auf demselben System, noch zwischen verschiedenen Systemen. Die Installation neuer Software oder der Bezug neuer Inhalte obliegt dabei häufig nicht der Kontrolle der Benutzerinnen und Benutzer der Geräte, sondern ist an zentralistisch organisierte Bezugskanäle gebunden. Dabei obliegt es nicht nur dem Plattformanbieter, welche Apps überhaupt installiert werden können. Sogar bereits gekaufte Inhalte können jederzeit wieder vom Anbieter gelöscht, die Nutzungslizenzen entzogen werden, teilweise sogar aus der Ferne von den Systemen der Benutzer.
Zusätzlich ist bei den Benutzungsschnittstellen der mobilen Informatiksysteme ein Trend zu erkennen, der den Benutzerinnen und Benutzern der mobilen Geräte Entscheidungen abnimmt, von denen die Hersteller wohl annehmen, dass diese dazu nicht in der Lage sind. Das prominenteste Beispiel hierfür ist der Wegfall des manuellen Speicherns von Dateiänderungen. In der Regel wird jede Änderung unmittelbar gespeichert. Eine Rücknahme von Änderungen ist somit nur möglich, solange die jeweilige App noch läuft und die entsprechende Änderungshistorie hinter der \enquote{Rückgängig}-Schaltfläche noch im Speicher vorhanden ist.
Kurzum: Die Anwenderinnen und Anwender mobiler Informatiksysteme begeben sich in die Obhut des Herstellers, der als weiser Aufseher über ihre Taten wacht. Begründet wird dies offiziell mit den vielen Gefahren, die den Systemen drohen und durch zentrale Kontrollen verhindert werden könnten. Dass diese Sicherheit mitunter trügerisch ist, zeigen die auch für iOS immer wieder auftauchende Malware und die Aktivitäten von Apple geprüfter Apps\vglr{parGefDatMal}.
\subsubsection{Ein erfolgreiches Geschäftsmodell}
Aus Sicht der Plattformanbieter und der Inhaltsanbieter erscheint dieses Konzept natürlich folgerichtig und sinnvoll. Die Konsumenten können in den digitalen Geschäften einkaufen und die jeweiligen Artikel konsumieren. Im Gegensatz zu Software und Medien auf konventionellen Datenträgern können diese jedoch nicht verliehen oder weiterverkauft werden. Die intensive Nutzung von \gls{DRM} verhindert dabei die Weitergabe an andere Konsumenten.
Die Exklusivität der Distributionswege sichert den Plattformanbietern ferner einen festen finanziellen Anteil an den Verkäufen zu. Derzeit sind dies bei den meisten Plattformen rund 30\,\% des Umsatzes. Diese Exklusivität lässt sich etwa Apple von den Entwicklern vertraglich zusichern: Der Vertrieb von iOS-Apps außerhalb des Appstores ist unzulässig, auch im Quelltext, was den Store mit vielen Open-Source-Lizenzen inkompatibel macht. Dass Apps zudem keinen Code ausführen dürfen, sorgt dafür, dass es weder Compiler noch Interpreter für iOS gibt, die tatsächlich die Funktionalität unter Umgehung des Appstores der Geräte erweitern könnten.
Die Beschneidung der Möglichkeiten zum Austausch von Dateien zwischen den Systemen erschwert die Weiternutzung von, auf anderen Wegen erworbenen, Inhalten. Da die Nutzung der vorhandenen Content-Stores sehr viel einfacher möglich ist, dürfte dies den Umsatz mit digitalen Inhalten befördern. Zumal es den Anbietern möglich ist, alte Versionen aus den Stores\footnote{Hierfür gibt es viele Beispiele, das letzte besonders hervorstechende war die Entfernung von Mac OS X 10.7 nach der Veröffentlichung der Version 10.8 durch Apple \cite{AppleLionRevoke}.} und sogar von den Geräten zurückzuziehen\vgln{Amazon1984} und damit eine weitere Nutzung zu erschweren oder zu verhindern.
Die erworbenen Inhalte sind in der Regel an die jeweilige Plattform gebunden, sodass die Plattformanbieter die Benutzerinnen und Benutzer langfristig an das eigene kommerzielle System binden können. Denn wer will schon die Plattform wechseln, wenn damit alle bereits gekauften Inhalte verloren gehen?
Es erscheint also nur logisch, dass dieses Geschäftsmodell und die Einschränkungen der Benutzungsschnittstelle in die letzten Versionen der Betriebssysteme stationärer Informatiksysteme Einzug gehalten haben. Nicht nur Mac OS X seit Version 10.6 und Windows 8 verfügen über App- und Contentstores, sogar in einigen Linux-Distributionen (allen voran Ubuntu) sind diese bereits integriert. Die verschiedenen Umsetzungen sind unterschiedlich rigide und die Exklusivität der digitalen Distribution ist noch nicht so universell wie bei mobilen Informatiksystemen, jedoch ist der Trend eindeutig.
\subsubsection{Freiheit und Mündigkeit?}
Nicht nur durch die Antizipation dessen, was den Anwenderinnen und Anwendern bei der Bedienung der Geräte zuzutrauen ist, sondern auch durch die weitgehenden Vorgaben, was mit den Geräten gemacht werden darf, verlieren die Anwenderinnen und Anwender an Selbstbestimmtheit und Handlungsfreiheit. Durch die enge Verbindung von Onlinediensten und den mobilen Informatiksystemen ensteht eine digitale \enquote{Gated Community}, eine oberflächlich friedliche Umgebung voller beleuchteter Straßen, ganz ohne finstere Gestalten, die in den Schatten lauern. Dies wird allerdings von den Benutzerinnen und Benutzern durch einen gewaltigen Verlust an Mündigkeit und Freiheit erkauft. Letztlich liefern sie sich dem Plattformanbieter aus und müssen auf dessen wohlwollende Führung vertrauen. So kann der Plattformanbieter (insbesondere durch die Integration von Cloud-Diensten) umfassend Zugriff auf die persönlichen Daten ausüben, wie etwa Amazon, das nachträglich erworbene Bücher von den Geräten der Konsumenten entfernte. Ironischerweise handelte es sich dabei gerade um eine digitale Fassung des Buches \enquote{1984} von George Orwell.
\zitatblock[.]{Mit dieser Aktion hat Amazon den größten technologischen Vorzug seines Geräts in einen gravierenden Nachteil verwandelt: Von nun an wird jedem Nutzer eines Kindle klar sein, dass stets eine Thought Police seine digitale Bibliothek im Blick haben und mit ihr unbeobachtet nach Belieben schalten und walten kann. Dies sollte vor allem im Auge behalten, wer einen weiteren Vorzug des neuesten Kindle-Modells DX nutzen will: Dessen eingebaute pdf-Software \enquote{ermöglicht es Ihnen}, wie Amazon verspricht, \enquote{all Ihre persönlichen und beruflichen Dokumente unterwegs zu lesen}. Möglicherweise nicht nur Ihnen}{Amazon1984}{1}
Denn die Übertragung von Dokumenten auf die Kindle-E-Book-Reader kann ausschließlich über den Cloud-Dienst von Amazon erfolgen.
Diese Zenurmöglichkeit hat jedoch noch andere Auswirkungen, so hat Apple sehr rigide Vorstellungen davon, was über seine Plattform genutzt werden darf. Medien, die von Apple als anstößig angesehen werden, etwa nackte, weibliche Brüste finden über den regulären Distributionskanal keinen Weg auf die Geräte. Dies musste nicht nur die Bild-Zeitung mit ihrer App erfahren \citep{BildApple}.
Denen, die (wie wohl die Autoren der in \referenz{secAnsPad} genannten Broschüren für Eltern) auf rigidere Jugendschutzmaßnahmen und Kindersicherungen setzen, sei jedoch die Freude genommen: Nicht nur besteht die Möglichkeit, derartige Inhalte über den Webbrowser abzurufen, vielmehr sind aus Apples Perspektive Gewaltdarstellungen und \enquote{Killerspiele} in der Regel nicht anstößig und daher regulär zu beziehen.
Offensichtlich wurden die Möglichkeiten der Zensur allerdings durch die Entfernung des kritisch-satirischen Spiels \enquote{Phone Story}\vgln{ApplePhoneStory}. Dieses Spiel, das die sozialen Produktionsbedingungen in den Fertigungsanlagen von Apple kritisierte, wurde sehr schnell entfernt.
Dass all diese Beispiele jedoch trotz der vorhandenen Kontrollen zunächst ihren Weg auf die Geräte gefunden haben, zeigt deutlich, dass diese nicht lückenlos funktionieren. Bei tatsächlich schädlichen Apps ist dies fatal. Denn die Aufgabe der Mündigkeit durch die Benutzerinnen und Benutzer verbunden mit der von den Anbietern vermittelten Illusion absoluter Sicherheit in den digitalen Gated Communities führt zu unüberlegter und nicht vernunftgeleiteter Nutzung der Systeme.
\subsubsection{Konsequenzen für den schulischen Einsatz}
Es liegt klar auf der Hand, dass diese Voraussetzungen einen Einsatz der Geräte im Informatikunterricht ausschließen. Die Einnahme der kritisch-analytischen Perspektive\vglr{secPersAna} ist bei den verbarrikadierten Blackboxen, die die Konsumgeräte darstellen, nur erschwert möglich. Die Einnahme der konstruktiven Perspektive der Veränderung der Wirklichkeit ist sogar fast vollständig ausgeschlossen. Lediglich das Entwickeln von Webapps\vglr{secPersWebApp} und das Entwickeln für die Geräte \vglr{secPersFor} wären möglich. Letzeres allerdings nur kostenpflichtig und unter Anerkennung umfangreicher vertraglicher Auflagen. Die Möglichkeit, diese Beschränkungen durch Rooting zu umgehen, besteht zwar, ist jedoch für die Schule keine Option\vglr{secRoot}.
Besonders für den Informatikunterricht ist die Kritik des führenden Kopfes des \gls{OLPC} Projekts\vgln{OLPC} wegweisend:
\zitatblock{Tablets are indeed the future. OLPC announced its own eight months ago. However, caution is needed with regard to one aspect of tablets: learning is not media consumption. It is about making things.}{NegroponteIpad}{1}
Doch auch für den generellen Einsatz in der Schule erscheinen die Geräte als grundsätzlich ungeeignet. Betrachtet man das Ziel der \enquote{mündigen Gesellschaftsangehörigen} und die Vorbereitung auf eine freiheitlich-rechtsstaatliche, demokratische Gesellschaft, so erscheinen die Beschränkungen und Möglichkeiten zur Zensur als ausgesprochen negativ. Insbesondere in Verbindung mit Apples Ambition, den Markt für Schulbücher aufzumischen, ist dies außerordentlich fragwürdig.
\zitatblock[.]{Für mächtigen Ärger sorgen nun die neuen Lizenzbedingungen, die Apple an den Vertrieb aller eBooks in seinem iBookstore knüpft. Demnach dürfen eBooks, die mit der Apple-Software \enquote{iBooks Author} produziert wurden, ausschließlich nur in Apples iBookstore verkauft werden. Der kalifornische Konzern behält sich zudem die Entscheidung darüber vor, welche Bücher im iBookstore überhaupt erscheinen dürfen und welche nicht}{AppleMoloch}{1}
Das in diesem Zusammenhang überhaupt ernsthaft über die Nutzung dieses vergifteten Angebots an Schulen nachgedacht werden kann, erschließt sich dem Autor nicht. Eine privatwirtschaftliche Firma, die bereits gezeigt hat, dass sie bereit ist, in eigener Sache von Zensurmöglichkeiten Gebrauch zu machen, mit einer monopolistischen Oberaufsicht über das in öffentlichen Schulen verwendete Unterrichtsmaterial auszustatten, erscheint im Sinne demokratischer Prinzipien als vollkommen wahnwitzige Idee. Das Schulministerium von Sachsen-Anhalt hat bereits klar gemacht, \zitat[.]{dass eine Reglementierung/Zulassung des Einsatzes von Lernsoftware im Unterricht durch Dritte nicht akzeptabel ist}{GEWApple}{1} Dass damit nebenbei handfeste kommerzielle Interessen bedient würden, da eine exklusive Bindung an die Apple-Plattform bestünde und die Kinder und Jugendlichen bereits in der Schule an die Allgegenwart der Marke Apple gewöhnt würden, ist eine weitere Konsequenz, die eindeutig nicht mit dem Bildungsauftrag der allgemeinbildenden Schulen kompatibel ist.
Ganz davon abgesehen, dass die bisher von Apple angestrebte Lösung von Bildungsforschern scharf kritisiert wird und aus deren Sicht weit hinter dem Stand der Forschung zurückliegt:
\zitatblock{Der Schulbuch-Forscher Volkhard Nordmeier von der Freien Universität Berlin sieht den Vorstoß von Apple kritisch. Für ihn greift Apples Idee zu kurz, das \enquote{Schulbuch der Zukunft} einfach nur durch Multimedia-Elemente anzureichern. \enquote{Nur dadurch dass es irgendwie bunt ist und sich bewegt, geht das Lernen nicht anders oder leichter}, sagt Nordmeier.}{AppleMoloch}{1}
Kritik kommt auch von Seiten der \gls{GEW}:
\zitatblock[.]{Marianne Demmer, Leiterin des GEW-Vorstandsbereichs Schule, kritisiert den \enquote{Werbefeldzug zum Verkauf von iPads} und warnt vor einem \enquote{weiteren Kommerzialisierungsschub im Bildungsbereich}. Wahrscheinlich, so Demmer, sollten die Eltern das auch noch mitfinanzieren. \enquote{Zudem binden sich Schulen, die sich für Apple-Hard- und -Software entscheiden, an einen einzigen Wettbewerber und dessen inhaltliche Angebote.} Damit werde jegliche demokratische Kontrolle der angebotenen Materialien ausgehebelt}{GEWApple}{1}
Es erscheint daher dringend geboten, Konsumgeräten generell den Einsatz im Unterricht zu verweigern. Informatiklehrkräfte sind hier, nach Ansicht des Autors, aufgrund ihrer speziellen Rolle\vglr{secKritInfoLehr} besonders gefragt.
\subsection{Back to the roots -- Rooting als Ausweg?}\label{secRoot}
\subsubsection{Potentieller Nutzen}
Bisher wurden mehrfach künstliche Sperren und Barrieren beschrieben, die den Einsatz bestimmter Geräte in der Schule als nicht sinnvoll erscheinen lassen. Es soll jedoch nicht verschwiegen werden, dass es in den meisten Fällen Möglichkeiten gibt, diese Sperren zu umgehen. Dies ist natürlich seitens der Hersteller nicht gern gesehen, da die Sperren in der Regel angebracht werden, um das jeweilige Geschäftsmodell zu schützen.
Hat man Rootrechte auf einem mobilen Informatiksystem, so sieht die Nutzbarkeitsbewertung für den Informatikunterricht sehr schnell ganz anders aus. Freie Betriebssysteme ließen sich etwa vollständig an die schulischen Bedürfnisse anpassen. Mittels einer \textit{chroot}-Umgebung ist auf Android-Systemen etwa die Installation einer vollständigen Linux-Distribution möglich, sodass keine wesentlichen Einschränkungen gegenüber stationären Systemen mehr bestehen -- bei gleichzeitiger Beibehaltung aller Vorteile der mobilen Informatiksysteme.
\staticBox{Was ist Rooting?}{\label{boxRooting}Mit dem Begriff \textit{Rooting} bezeichnet man das Entsperren eines Informatiksystems. Hierzu verschafft man sich die Benutzerrechte des Superusers (root), davon leitet sich der Name \enquote{Rooting} ab. Dies kann entweder auf offiziellem Wege geschehen, so dies vom Hersteller vorgesehen ist, oder -- und dies ist der häufigere Fall -- inoffiziell über (in der Regel undokumentierte) Systemfunktionen oder bekannte Sicherheitslücken. Danach ist es möglich, die künstlichen Sperren des Herstellers aufzuheben oder zu umgehen.
Bei Apple-Systemen hat sich der Begriff \textit{Jailbreaking} -- auf deutsch: Gefängnisausbruch -- eingebürgert. Im Rahmen des Jailbreakings werden zwar ebenfalls meist Rootrechte erlangt, allerdings sind die verfügbaren Lösungen weitgehend automatisiert und die entsprechenden Tools heben zeitgleich einige Sperren auf (etwa durch die Installation eines alternativen Appstores), sodass der Jailbreaking-Prozess über das reine Rooting hinausgeht. Teilweise wird der Begriff des Jailbreaking jedoch so verwendet, dass jegliches Entsperren eines Gerätes -- auch das für das Rooting evtl. erforderliche -- als Jailbreak bezeichnet wird.}
Noch dramatischer ist die Situationen bei Geräten von Apple. Diese werden erst durch einen Jailbreak wirklich für den Informatikunterricht nutzbar. So besteht hier nicht nur Zugriff auf das Dateisystem und die Möglichkeit der Installation von Compilern und Interpretern, es existiert sogar die Möglichkeit auf die gesamte API zugreifen zu können. \cite{saurikAPI} hat hierzu für Python das notwendige Fundament gelegt. Damit fallen alle wesentlichen Kritikpunkte weg, die iOS als ungeeignet erscheinen lassen.
\subsubsection[Rechtliche Aspekte]{Rechtliche Aspekte\footnote{Da der Autor kein Jurist ist, stützen sich die getroffenen Einschätzungen ausschließlich auf die angegebenen Quellen. Eine tatsächliche rechtliche Bewertung und Absicherung wäre bei einem geplanten Einsatz gerooteter Geräte in der Schule absolut unumgänglich, sofern keine Genehmigung des Herstellers vorliegt.}}
Das Rooting bzw. ein Jailbreak führen in der Regel dazu, dass die Herstellergarantie verloren geht. Der Hersteller ist also bei einem Defekt berechtigt, die Garantieleistungen zu verweigern, wenn eine derartige Modifikation nachgewiesen wird. Welchen Einfluss dies auf die gesetzlich festgeschriebene Gewährleistung hat, ist bisher nicht gerichtlich geklärt worden. Es muss jedoch zumindest davon ausgegangen werden, dass die Gewährleistung erfolgreich verweigert werden kann.
Ein weiterer Aspekt wäre die Aussperrung entsprechend modifizierter Geräte von der offiziellen Infrastruktur, wie sie von Spielekonsolenherstellern praktiziert wird. Dafür gibt es derzeit keine Anzeichen, jedoch würde dies bedeuten, dass neue und bereits gekaufte Software und Inhalte aus den offiziellen Distributionskanälen auf diesen Geräten nur noch auf Umwegen oder gar nicht zu verwenden wären.
Während das Jailbreaking und Rooting seit Juli 2010, durch eine Entscheidung des Kongresses in den USA erlaubt ist\vgl{EFFJailbreak}{1}, sind weitere rechtliche Folgen von Jailbreaking und Rooting von mobilen Informatiksystemen in Deutschland bisher ungeklärt. Strafrechtliche Folgen für den rein privaten Gebrauch können wohl ausgeschlossen werden. So wurde im Zusammenhang mit der US-Entscheidung vielfach die Anwältin Eva Dzepina der Düsseldorfer Kanzlei Borgelt \& Partner mit folgender Äußerung zitiert: \enquote{Strafrechtlich ist ein Jailbreak nicht relevant, wenn dies ausschließlich zum eigenen privaten Gebrauch stattfindet. Das ergibt sich aus § 108b des Urheberrechtsgesetzes}. Zivilrechtliche Folgen können jedoch, mangels entsprechender gerichtlicher Entscheidungen nicht vollständig ausgeschlossen werden:
\zitatblock[.]{Verschiedentlich wird die Ansicht vertreten, dass die Entfernung eines SimLocks oder ein Jailbreak die Umgehung einer technischen Schutzmaßnahmen sei, die gemäß § 95a UrhG und damit verboten ist. [\dots] Ebenso ist Software gemäß § 69a UrhG urheberrechtlich geschützt [\dots] die Nutzung von Jailbreak Software könnte daher ohne Zustimmung des Rechteinhabers unzulässig sein [\dots] Ebenso sind Unterlassungsansprüche und Schadenersatz denkbar}{BorgeltJailbreak}{1}
Ein weiteres Problem ist, dass ein Jailbreak bzw. Rooting Möglichkeiten eröffnet, die als illegal zu werten sind. Etwa das Aufheben einer Einschränkung auf das Netz eines Mobilfunkproviders (Netlock) bzw. ein spezifisches \gls{SIM} (SIM-Lock). Hierzu gibt es bereits diverse Urteile\vgln{UrteilBGH,UrteilNurt,UrteilGott}, die recht deutlich machen, dass dies nicht nur zivilrechtlich problematisch ist, sondern nach § 303a StGB (Datenveränderung) und § 263a StGB (Computerbetrug) strafbar ist. Für schuleigene Geräte hat dies zunächst jedoch keine direkten Auswirkungen, da diese in der Regel nicht in Verbindung mit SIM-Karten beschafft werden und somit keiner Vertragsbindung unterliegen.
Des Weiteren besteht nach erfolgtem Jailbreak oder Rooting die Möglichkeit, illegal vervielfältigte Software zu installieren, was wiederum eine Urheberrechtsverletzung und somit grundsätzlich eine strafbare Handlung darstellt. Auch hier ist eher mit zivilrechtlichen als mit strafrechtlichen Konsequenzen zu rechnen, da Urheberrechtsverletzungen durch Privatpersonen ohne Gewinnabsichten nur selten strafrechtlich verfolgt werden. Wie dies bei einer großen Anzahl in der Schule eingesetzter Geräte gewertet werden würde, ist jedoch unklar. Ob hierbei im Zweifelsfall von einer Haftbarkeit (etwa Mittäterschaft oder Anstiftung) der Lehrkraft oder der Schule ausgegangen werden kann, wenn diese am Jailbreak mitgewirkt bzw. diesen vorausgesetzt haben, bleibt offen und kann hier auch nicht geklärt werden.
Bei Systemen mit einem freien Betriebssystem, speziell solchen, die der \gls{GPL} unterliegen, fehlt zwar ebenfalls eine entsprechende Entscheidung. Da es hier jedoch eindeutige Entscheidungen aus anderen Bereichen\footnote{Es gab hier diverse gerichtliche Klärungen, etwa zu Routern, zuletzt der FritzBox von AVM (vgl. \citep{WelteAVM}).} gibt, ist es wesentlich wahrscheinlicher, dass es keine rechtlichen Probleme gibt, diese Geräte zu rooten oder mit anderer Firmware auszustatten: \zitat{Anders wäre sicherlich der Fall der vollständigen Auswechselung der Software zu beurteilen, beispielsweise durch die denkbare Verwendung von \enquote{Open-Source} Software.}{BorgeltJailbreak}{1} Manipulationen an unfreien Bestandteilen (etwa Treibern), \zb zum Entfernen eines SIM-Locks, könnten jedoch wiederum zu den oben genannten Problemen führen. Der entscheidende Punkt hierbei ist, dass man mit dem Kauf eines mobilen Informatiksystems zwar die Hardware erwirbt, jedoch nur ein begrenztes Nutzungsrecht an der Software, welches in der Regel Veränderungen an der Software ausschließt. Bei freier Software gilt dies natürlich nicht.
Generell muss man sagen, dass es bisher keine Anzeichen dafür gibt, dass einzelne Nutzer für reines Jailbreaking oder Rooting abgemahnt würden. Bei intensiver Recherche stellt sich überdies heraus, dass nur in sehr wenigen Fällen Garantieleistungen verweigert werden und in den meisten Fällen nicht einmal überprüft wird, ob eine entsprechende Veränderung vorliegt. Das ist jedoch eine sehr unsichere Basis für wohlbegründete Entscheidungen.
\subsubsection{Technische Aspekte}
Viele Hersteller treiben sehr großen Aufwand, um das Rooting oder Jailbreaking zu verhindern oder zumindest zu erschweren. Kryptographisch signierte Bootloader und ein ständiges Katz- und Mausspiel mit den Entwicklern von Jailbreak-Software gehören inzwischen zum Alltag.
Das Katz- und Mausspiel ist dabei besonders problematisch, denn niemand kann garantieren, dass ein Jailbreak bei bestimmten Geräten dauerhaft, also auch bei künftigen Versionen, verfügbar sein wird. Man muss also unter Umständen auf Aktualisierungen des Betriebsystems und damit auf wichtige Sicherheitsupdates und Patches verzichten. Außerdem werden Software-Updates erschwert: Teilweise werden die Modifikationen durch ein Update entfernt, teilweise ist ein direktes Update nicht möglich und die Modifikationen müssen zuerst händisch entfernt werden.
Bei vielen mobilen Informatiksystemen lassen sich Rooting oder Jailbreaks relativ problemlos und meist spurlos wieder entfernen, sodass die rechtlichen Probleme hier oft als nicht relevant erscheinen mögen. Es gibt jedoch keine Garantie, dass eine Modifikation nicht vom Hersteller erkannt werden kann. Einige Hersteller betreiben diese Erkennung sogar sehr offen. So werden teilweise hardwareseitige Sicherungen oder signierte Speicherfelder genutzt, um einen Jailbreak dauerhaft nachweisbar zu machen. Ein Beispiel hierfür ist etwa der Hersteller Sony (bis vor kurzem SonyEricsson), der das Entsperren offiziell unterstützt, dies jedoch an eine Einwilligung zum Verzicht auf die Herstellergarantie bindet und somit rechtliche Zweifel in dieser Hinsicht ausräumt.
Zusätzlich zu technischen Maßnahmen der Hersteller zur Einschränkung von Garantieleistungen ergeben sich Probleme für die Datensicherheit auf den Geräten. Durch das Entsperren haben theoretisch alle Apps auf den Geräten Zugang zu Rootrechten. Damit werden also die Sicherheitskonzepte der Systeme untergraben und es wird grundsätzlich einfacher, Schadsoftware auf den Geräten unterzubringen. Außerdem haben Bedienungsfehler potentiell schlimmere Folgen.
\subsubsection{Sonderfälle}
Bei Herstellern von Geräten, die auf offenen Plattformen basieren, gibt es einige Sonderfälle zu beachten. Nicht nur dass hier, wie bereits beschrieben, weniger rechtliche Folgen drohen. Im Gegenteil gibt es hier sogar vereinzelt Hersteller, die entsprechende Modifikationen explizit erlauben.
Außerdem gibt es bei günstigen \enquote{NoName-Geräten} meist keine Herstellergarantie, sodass hier nur die Gewährleistung betroffen wäre, die jedoch wie oben angegeben, eher nicht durch die softwareseitigen Modifikationen eingeschränkt wird. NoName-Geräte nutzen darüber hinaus eigentlich immer freie Betriebssysteme, denn Eigenentwicklungen würden sich für die Hersteller nicht lohnen. Werden diese Geräte nicht bei einem Mobilfunkprovider erworben, bestehen auch keine Net- oder SIM-Locks. Tendenziell wäre hier also eine Entsperrung unproblematisch. Es bleiben jedoch die offenen Fragen des möglichen Missbrauchs und der Exposition gegenüber Schadsoftware.
\subsubsection{Fazit}
Die großen Unklarheiten sowie die zumindest möglichen und schwer kalkulierbaren rechtlichen Folgen lassen Rooting und Jailbreaking für in der Schule genutzte Geräte, trotz der erweiterten Nutzungsmöglichkeiten, als sehr unattraktiv erscheinen. Für Geräte, die den \SuSn gehören, muss man sie sogar als vollkommen inakzeptabel bewerten. Hier könnten sogar bei Beschädigung oder aus der Entsperrung resultierendem Missbrauch der privaten Geräte (etwa unzulässige Kopien von Apps) Schadenersatzansprüche auf die Schulen und Lehrkräfte zukommen.
Die alleinige Nutzung entsperrter, schuleigener Geräte ließe die gewünschte Anknüpfung an den Alltag vermissen, da auf den alltäglich genutzen Geräten eben nicht die Möglichkeiten bestünden, die auf den schulischen Geräten vorhanden wären. Eine einfache Anwendung des Gelernten im Alltag wäre nicht möglich.
Somit ist -- zumindest derzeit -- die Nutzung entsperrter Geräte keine ernsthafte Option. Es sollten eher Geräte genutzt werden, die die notwendigen Möglichkeiten offiziell bieten.
Empfehlenswert wäre natürlich der Einsatz von Systemen mit der Erlaubnis zu Modifikationen. Da es jedoch nur wenige Anbieter gibt, die derart weitgehende Freigaben erteilen und gleichzeitig die Garantie aufrecht erhalten, wäre die Geräteauswahl sehr stark eingeschränkt. Berücksichtigt man Hersteller, die ein Entsperren unter Verlust der Garantie erlauben, ist die Auswahl zwar größer, aber noch immer eingeschränkt. Da dies jedoch ohnehin nur Systeme betrifft, die freie Plattformen nutzen, welche die nötigen Voraussetzungen für den Unterrichtseinsatz ohnehin bieten, ist diese Einschränkung nicht notwendig.
\section{Klassendiagramme}\label{secKlass}
\begin{minipage}{0.9\textwidth}
\captionsetup{type=figure}
\centering
\includegraphics[scale=0.9]{imgs/wrapper/klassen/dialoge-1}
\captionof{figure}{Klassenbibliothek, Paket \enquote{Dialoge}}
\end{minipage}
\vspace{2em}
\begin{minipage}{0.9\textwidth}
\captionsetup{type=figure}
\centering
\includegraphics[scale=0.9]{imgs/wrapper/klassen/multimedia-1}
\captionof{figure}{Klassenbibliothek, Paket \enquote{Multimedia}}
\end{minipage}
\vspace{2em}
\begin{minipage}{0.9\textwidth}
\captionsetup{type=figure}
\centering
\includegraphics[scale=0.9]{imgs/wrapper/klassen/sprache-1}
\captionof{figure}{Klassenbibliothek, Paket \enquote{Sprache}}
\end{minipage}
\section{Quelltexte}\label{secQuell}
\subsection{Klassen aus dem Paket \enquote{Sprache}}
\lstinputlisting[language=Python,caption={Klasse \enquote{Sprachausgabe}}]{sources/Sprachausgabe.py}
\subsection{Klassen aus dem Paket \enquote{Dialoge}}
\lstinputlisting[language=Python,caption={Klasse \enquote{Dialog}}]{sources/Dialog.py}
\lstinputlisting[language=Python,caption={Klasse \enquote{EingabeDialog}}]{sources/EingabeDialog.py}
\subsection{Beispiel \enquote{Sprachtest}}
\lstinputlisting[language=Python,caption={Beispiel \enquote{Sprachtest}}]{sources/Sprachtest.py}

View file

@ -0,0 +1,115 @@
\newglossaryentry{InfSys}{
name=Informatiksystem,
description={Eine Kombination von Hardware, Software und Netzverbindungen zur Lösung von Anwendungsproblemen. Siehe \referenz{secInfSys}.},
plural=Informatiksysteme
}
\newglossaryentry{MobInfSys}{
name={Mobiles Informatiksystem},
description={Ein von Anfang an für den mobilen Einsatz entwickeltes \gls{InfSys}. Siehe \referenz{secMobInfSys}.},
plural={Mobile Informatiksysteme}
}
\newglossaryentry{MobTel}{
name=Mobiltelefon,
description={Ein \gls{MobInfSys}, das über eine Funktion zur Telefonie über Mobilfunknetze verfügt. Geräte, die nur zu reiner Online-Telefonie über Datendienste fähig sind, selbst wenn diese über Mobilfunknetze erfolgt, werden hier nicht als Mobiltelefone bezeichnet.},
plural=Mobiltelefone
}
\newglossaryentry{Handy}{
name=Handy,
description={Ein nicht erweiterbares \gls{MobTel}, das vornehmlich dem Telefonieren dient. Siehe \referenz{secHandy}.}
}
\newglossaryentry{JavaHandy}{
name=Java-Handy,
description={Ein mittels Java-Applikationen erweiterbares \gls{Handy}. Siehe \referenz{secJavaHandy}.},
plural=Java-Handys
}
\newglossaryentry{LesserSP}{
name={Lesser Smartphone},
description={Ein grundsätzlich durch Apps erweiterbares \gls{MobTel}, das häufig über einfache Touchbedienung gesteuert wird. Siehe \referenz{secLesserSP}.},
plural={Lesser Smartphones}
}
\newglossaryentry{Smartphone}{
name=Smartphone,
description={Ein \gls{MobTel}, das hardware- und softwareseitig vielfältig erweiterbar ist und sich durch -- für \glspl{MobInfSys} -- hohe Rechenleistung und heute in der Regel auch Touch-Bedienung auszeichnet. Siehe \referenz{secSmartphone}.}
}
\newglossaryentry{Tablet}{
name=Tablet,
description={Tablets sind \glspl{MobInfSys}, die über eine ähnliche Leistung und Ausstattung verfügen, wie Smartphones, aber nicht über echte Telefoniefunktionen verfügen und deutlich größer sind. Siehe \referenz{secTablet}.}
}
\newglossaryentry{Hybrid}{
name=Hybrid,
description={Hybride sind eine Mischung aus \glspl{Smartphone} und \glspl{Tablet}, die zwar prinzipiell echte Telefonfunktionen mitbringen, aber aufgrund ihrer Größe nur eingeschränkt zum Telefonieren geeignet sind. Siehe \referenz{secHybrid}.},
plural=Hybride
}
\newglossaryentry{AllInOnePC}{
name={All-In-One-PC},
description={All-In-One-PCs sind stationäre Computer, die zusätzlich zur üblichen Ausstattung eines PCs -- wie Notebooks -- wesentliche Peripherie, wie den Bildschirm, Kameras, Lautsprecher, Mikrofone etc., direkt eingebaut haben und damit deutlich kompakter sind. Üblicherweise sehen diese Geräte aus wie ein etwas tieferer Bildschirm. Viele Komponenten wurden eigentlich für Notebooks entwickelt und benötigen daher weniger Strom und geben weniger Hitze ab, was eine einfachere, oft lautlose Kühlung ermöglicht. Neuere Geräte bieten darüber hinaus Touchscreens, sodass sie eher stationären Tablets als stationären PCs ähneln. Das bekannteste Gerät dieser Gruppe ist der iMac von Apple.}
}
\newglossaryentry{iOS}{
name={iOS},
description={iOS ist ein von Apple entwickeltes Betriebssystem für \glspl{MobInfSys}, das sich ausschließlich auf Apple-Hardware findet. Die Basis dieses Systems bildet eine Variante von Darwin, Apples \gls{BSD}-Ableger, der auch das Fundament von Apples Desktop-Betriebssystem Mac OS X bildet. Ursprünglich entwickelt wurde es für das iPhone (und den diesem sehr ähnlichen Mediaplayer iPod Touch) unter dem Namen iPhoneOS und wurde dann mit Erscheinen des iPads auch an Tablets angepasst. Inzwischen läuft es auch auf Apples Settop-Box AppleTV.}
}
\newglossaryentry{Android}{
name={Android},
description={Android ist ein von Google entwickeltes Betriebssystem für \glspl{MobInfSys}. Die Basis dieses Systems bildet ein Linuxkernel, allerdings mit teilweise stark von üblichen Distributionen abweichenden Dienstprogrammen. Anwendungen werden grundsätzlich (mit wenigen Ausnahmen) in der \gls{Dalvik} ausgeführt.}
}
\newglossaryentry{Dalvik}{
name={Dalvik Virtual Machine},
description={Eine von Google für Android entwickelte Java Virtual Machine, die für den Einsatz auf \glspl{MobInfSys} und somit auf sparsame Ressourcennutzung und hohe Ausführungsgeschwindigkeit optimiert wurde. Sie ist nicht kompatibel zum Bytecode der üblichen JVMs. Dalvik ist Teil des Android-Sicherheitskonzepts, da für jede Anwendung eine separate VM gestartet wird.}
}
\newglossaryentry{Rooting}{
name={Rooting},
description={Prozess des Entsperrens eines (mobilen) Informatiksystems durch den Erwerb von Root-Rechten. Siehe \referenz{boxRooting}.}
}
\newglossaryentry{Jailbreaking}{
name={Jailbreaking},
description={Gängiger Begriff für das Entfernen künstlicher Sperren auf (mobilen) Informatiksystemen. Umfasst \gls{Rooting} und das (weitgehend) automatisierte Entfernen dieser Sperren. Siehe \referenz{boxRooting}.}
}
\newglossaryentry{App}{
name={App},
description={Gängiger Begriff für mobile Software. Abgeleitet vom englischen Begriff Application.}
}
\newglossaryentry{OSTastatur}{
name={On-Screen-Tastatur},
description={Auf mobilen Informatiksystemen standardmäßig verwendete Eingabemethode, auch Bild\-schirm\-tas\-ta\-tur (was nach Ansicht des Autors keine treffende Bezeichnung ist) oder einfach virtuelle Tastatur genannt. Dabei wird auf dem Touchscreen des Geräts eine virtuelle Tastatur eingeblendet, die zur Eingabe von Texten und Steuerbefehlen genutzt werden kann. Alternativ ist bei vielen Systemen die Nutzung einer externen Hardware-Tastatur möglich.},
plural={Onscreen-Tastaturen}
}
\newglossaryentry{KonsumG}{
name={Konsumgerät},
description={Als Konsumgeräte werden hier die (mobilen) Informatiksysteme bezeichnet, deren Hauptzweck der Konsum digitaler Inhalte ist. Dazu zählen etwa die Geräte von Apple, aber auch Amazons Kindle Tablets und E-Book-Reader sowie Spielekonsolen und vermutlich auch Tablets mit Windows RT. Siehe auch den Exkurs hierzu in \referenz{secKonsum}.},
plural={Konsumgeräte}
}
\newglossaryentry{SecBoot}{
name={Secure Boot},
description={Bei Secure Boot handelt es sich um eine, unter anderem von Microsoft vorangetriebene Erweiterung des \gls{UEFI}, also dem Basisbetriebssystem neuerer Informatiksysteme. Dabei sollen nur \enquote{vertrauenswürdige} Kernel und Treiber geladen werden dürfen. Dies wird durch eine Zertifizierung und Signierung der Komponenten erreicht. Kritiker sehen dies in erster Linie als Zugangsbarriere für alternative Betriebssysteme. Für x86-Syteme ist Secure Boot noch optional, während es für ARM-Hardware mit Windows RT vorgeschrieben und nicht deaktivierbar ist.}
}
\newglossaryentry{Convertible}{
name=Convertible,
description={Convertibles sind Notebooks mit einem Display, das umgedreht und auf die Tastatur geklappt werden kann, sodass sie sowohl als Notebook als auch als Tabletcomputer eingesetzt werden können.}
}
\newglossaryentry{Slate}{
name=Slate,
description={Die Slate-Bauweise entspricht der üblichen Bauweise heutiger Tablets. Diese Geräte verfügen lediglich über einen Touchscreen und besitzen weder Tastatur noch Maus.}
}
\newglossaryentry{Ortungsmodul}{
name={Ortungsmodul},
description={Als Ortungsmodul werden hier alle Hardwaremodule zur Positionsbestimmung und Navigation via Satellit bezeichnet. Derzeit sind Module für das amerikanische Positionssystem \gls{GPS} und das russische \gls{GLONASS} relevant. Das chinesische Äquivalent Compass und das -- im Aufbau befindliche -- europäische Galileo-System werden hingegen auf absehbare Zeit keine Rolle spielen.},
plural={Ortungsmodule}
}
\newglossaryentry{PyEgg}{
name={Python-Egg},
description={Paketformat zur einfachen Verbreitung von Python-Modulen.}
}

View file

@ -0,0 +1,51 @@
\newacronym{API}{API}{Application Programming Interface}
\newacronym{NFC}{NFC}{Near Field Communication}
\newacronym{NPA}{NPA}{Neuer Personalausweis}
\newacronym{BITKOM}{BITKOM}{Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V.}
\newacronym{JIM}{JIM-Studie}{Basisuntersuchung \enquote{Jugend, Information, (Mul\-ti-)Me\-dia}}
\newacronym{KIM}{KIM-Studie}{Basisuntersuchung \enquote{Kinder + Medien, Computer + Internet}}
\newacronym{MPFS}{MPFS}{Medienpädagogischer Forschungsverbund Südwest}
\newacronym{SWR}{SWR}{Südwestrundfunk}
\newacronymex{SoC}{SoC}{System-on-a-Chip}{Ein integrierter Schaltkreis, der alle wesentlichen Bestandteile eines Informatiksystems vereint.}
\newacronymex{OMP}{OMP}{Our Mobile Planet Survey}{Studie zur weltweiten Nutzung von mobilen Informatiksystemen. Beauftragt von Google, durchgeführt durch Ipsos und TMS-Infratest}
\newacronym{PDA}{PDA}{Personal Digital Assistant}
\newacronymex{UDID}{UDID}{Universal Device Identifier}{Eindeutige Gerätekennung mobiler Informatiksysteme des Herstellers Apple. Der Zugriff darauf ist inzwischen (seit März 2012) untersagt. Es besteht jedoch weiterhin die Möglichkeit, einen auf eine spezifische App eingeschränkten UDID zu generieren.}
\newacronymex{IMEI}{IMEI}{International Mobile Equipment Identity}{Eindeutige Gerätekennung von mobilen Informatiksystemen bei \gls{GSM}.}
\newacronymex{MEID}{MEID}{Mobile Equipment Identifier}{Eindeutige Gerätekennung von mobilen Informatiksystemen bei \gls{CDMA} bzw. \gls{UMTS}.}
\newacronym{GSM}{GSM}{Global System for Mobile Communications}
\newacronym{UMTS}{UMTS}{Universal Mobile Telecommunications System}
\newacronym{CDMA}{CDMA}{Code Division Multiple Access}
\newacronym{GPS}{GPS}{Global Positioning System}
\newacronym{GLONASS}{GLONASS}{Globalnaja Nawigazionnaja Sputnikowaja Sistema}
\newacronym{GPL}{GPL}{GNU General Public License}
\newacronym{SIM}{SIM}{Subscriber Identity Module}
\newacronym{SMS}{SMS}{Short Message Service}
\newacronym{WLAN}{WLAN}{Wireless Local Area Network}
\newacronym{PIN}{PIN}{Personal Identification Numbers}
\newacronym{RFID}{RFID}{Radio Frequency Identification}
\newacronym{OLPC}{OLPC}{One Laptop per Child}
\newacronym{SSL}{SSL}{Secure Socket Layer}
\newacronym{TLS}{TLS}{Transport Layer Security}
\newacronym{BSD}{BSD}{Berkley System Distribution}
\newacronym{BMFSFJ}{BMFSFJ}{Bundesministerium für Familie, Senioren, Frauen und Jugend}
\newacronym{LJS}{LJS}{Landesstelle Jugendschutz Niedersachsen}
\newacronym{SuM}{SuM}{Stifte und Mäuse}
\newacronym{GI}{GI}{Gesellschaft für Informatik}
\newacronym{HTML}{HTML}{Hypertext Markup Language}
\newacronym{XHTML}{XHTML}{Extensible Hypertext Markup Language}
\newacronym{CSS}{CSS}{Cascading Style Sheet}
\newacronymex{SL4A}{SL4A}{Scripting Layer for Android}{Die SL4A ist eine offiziell von Google angebotene Erweiterung für Android, mit der der Einsatz von in verschiedenen Sprachen programmierten Skripten möglich wird. Damit ist eine Automatisierung und Erweiterung der Systeme möglich.}
\newacronym{DRM}{DRM}{Digital Rights Management}
\newacronym{GEW}{GEW}{Gewerkschaft Erziehung und Wissenschaft}
\newacronym{HDMI}{HDMI}{High Definition Multimedia Interface}
\newacronym{USB}{USB}{Universal Serial Bus}
\newacronym{RIM}{RIM}{Research In Motion}
\newacronym{UEFI}{UEFI}{Unified Extensible Firmware Interface}
\newacronym{SDK}{SDK}{Software Development Kit}
\newacronym{NDK}{NDK}{Native Development Kit}
\newacronym{ADB}{ADB}{Android Debug Bridge}
\newacronym{JSON}{JSON}{Javascript Object Notation}
\newacronym{RPC}{RPC}{Remote Procedure Call}
\newacronym{UI}{UI}{User Interface}
\newacronym{GUI}{GUI}{Graphical User Interface}
\newacronym{SSID}{SSID}{Service Set Identifier}

File diff suppressed because it is too large Load diff

File diff suppressed because it is too large Load diff

View file

@ -0,0 +1,70 @@
\chapter{Einführung}
\section{Einleitung}
Informatiksysteme sind heute in modernen Gesellschaften in fast jeder denkbaren Alltagssituation anzutreffen. In \cite{Humbert2001b} wurde festgestellt:
\zitatblock[.]{Die sichtbare Informatisierung der Gesellschaft ist in vollem Gange. Informatiksysteme befinden sich im unmittelbaren Lebensumfeld und damit im Er\-fah\-rungs- und Er\-le\-bens\-be\-reich aller Menschen}{Humbert2001b}{122}
Der zweite Satz ist zweifellos noch immer -- und in steigendem Maße -- zutreffend. Der erste Satz muss hingegen differenziert betrachtet werden, denn während er für \enquote{Eingeweihte}, nämlich informatisch geschulte Menschen, unmittelbar als offensichtlich richtig gewertet werden kann, ist diese Aussage für die restliche Menschheit weniger offensichtlich geworden.
Die Erscheinungsformen von Informatik sind heute äußerst vielfältig, oft sind Informatiksysteme nicht einmal auf den ersten Blick als solche zu erkennen. Verkehrsleitsysteme, diverse Automaten, Haushaltsgeräte, Fernseher und die vielfältigen Multimediagadgets etwa werden weiterhin nicht ohne Weiteres der Informatik zugeordnet, obwohl sie -- zumindest inzwischen -- ausgesprochen komplexe Informatiksysteme darstellen und ohne Informatik nur noch schwer vorstellbar wären. Vielmehr erscheinen nur die klar als Computer identifizierbaren Systeme als genuin der Informatik zugehörig: Für Nichtinformatiker gilt die Informatik in der Regel noch immer als \enquote{Computerwissenschaft}.
Auch der Informatikunterricht in der Schule vermittelt noch oft genau dieses Bild. Nicht nur findet er in der Regel in Computerräumen statt, es besteht noch viel zu häufig eine Ausrichtung auf technische Fertigkeiten und die Fähigkeit zur Bedienung eben dieser klassischen Informatikssysteme.
Dabei wird verdeckt, wie stark die Informatik den Alltag in den modernen Gesellschaften inzwischen durchdringt. Diese Durchdringung sorgt jedoch dafür, dass informatische Allgemeinbildung dringender denn je benötigt wird, wenn das pädagogische Ziel der Befähigung zur \textit{mündigen Teilnahme an der Gesellschaft}\footnote{Diese Arbeit richtet sich nach den \enquote{Richtlinien für einen nicht-sexistischen Sprachgebrauch} der UNESCO \citep{EineSprache}, daher wird auf den geläufigeren Begriff des \enquote{mündigen Bürgers} verzichtet.} erreicht werden soll.
Es zeichnet sich ein klarer Trend ab, dass die Nutzung von Informatiksystemen in der Gesellschaft einem starken Wandel unterliegt. Die Informatiksysteme werden immer unauffälliger bei gleichzeitig zunehmender Präsenz. Die klassischen Computer haben in vielen Bereichen bereits ausgedient. Kleinere, mobilere und oft spezialisiertere Systeme haben ihren Platz eingenommen.
Der schulische Informatikunterricht reagiert auf diese Veränderungen allerdings bisher kaum. Lediglich eine breitere Berücksichtigung von Notebooks gegenüber stationären Computersystemen ist zu beobachten. Auch bei Neueinrichtungen bzw. Neuausstattung von \enquote{Informatikräumen} in Schulen dominieren die klassischen Informatiksysteme. Meist in der Form von Computerräumen mit fest installierten Informatiksystemen, die eine flexible Planung und Gestaltung des Unterrichts erschweren. Bestenfalls bieten Kurssätze von Notebooks etwas flexiblere Möglichkeiten.
Es ist jedoch keinesfalls so, dass es in der Fachdidaktik keine Konzepte für eine entsprechende Anpassung gäbe. Im Gegenteil haben etwa die Beiträge von \cite{Carrie2006}, \cite{HemingINFOS2009,Heming2009} und Humbert (\zb \cite{HumbertMobil2006}) sowie die resultierenden Pilotkurse an der Willy-Brandt-Gesamtschule Bergkamen gezeigt, dass es sinnvoll möglich ist, Informatikunterricht mit mobilen Informatiksystemen zu gestalten. Allerdings wird die Weiterführung dieser Konzepte durch den Wegfall der damals gewählten Plattform erschwert. Für die praktische Umsetzung der bisher entwickelten Konzepte bedeutet dies einen Neustart.
Das Ziel dieser Arbeit muss also die Fortführung dieser vielversprechenden Ansätze sein. Es erscheint geboten, eine tragfähige, didaktisch durchdachte und vor allem zukunftsfähige Basis für die Einbindung mobiler Informatiksysteme in den Unterricht zu schaffen. Es muss besonderer Wert auf eine Unabhängigkeit von bestimmten Plattformen gelegt werden.
In dieser Arbeit wird auch immer wieder auf die schulische Nutzung der mobilen Informatiksysteme außerhalb des Informatikunterrichts eingegangen werden müssen. Denn die mobilen Informatiksysteme sind vor allem auf Druck der Hersteller und Inhaltsanbieter dabei, den Bildungsbereich zu erobern. Die Anforderungen anderer Fächer könnten dazu führen dass Informatiksysteme beschafft werden, die für den Informatikunterricht unbrauchbar sind.
\section{Zum Aufbau dieser Arbeit}
Wie der Titel bereits verspricht, beschäftigt sich diese Arbeit mit der Auswahl und der Gestaltung mobiler Informatiksysteme für den Einsatz im Informatikunterricht. Hierzu ist es zunächst wichtig zu klären, warum mobile Informatiksysteme überhaupt im Unterricht eingesetzt werden sollten (\referenz{chpBedeutung}). Im Anschluss daran sollen Vor- und Nachteile einer möglichen Nutzung benannt und Chancen für den Unterricht beschrieben werden (\referenz{chpPerspektiven}). Diese ersten Kapitel mögen im Hinblick auf das eigentliche Thema dieser Arbeit als sehr umfangreich erscheinen. In den folgenden Kapiteln wird jedoch deutlich werden, dass diese breite Basis für die weitere Argumentation unumgänglich ist. Besonders für die Destillation geeigneter Kriterien, die als Grundlage für die Auswahl spezifischer Informatiksysteme dienen müssen, aber auch für die Gestaltung dieser Systeme für den Unterricht ist diese Basis dringend notwendig.
Zur Destillation geeigneter Kriterien wird zunächst der Frage nachgegangen, welche Anforderungen überhaupt für die Nutzung spezifischer mobiler Informatiksysteme herangezogen werden können (\referenz{chpKriterien}), dabei sind verschiedene Einsatzfelder und Motivationen zu bedenken. Diese grundlegende Betrachtung ist sowohl für die Auswahl als auch die Gestaltung mobiler Informatiksysteme elementar. Um zu entscheiden, welche Systeme eventuell für den Einsatz im Unterricht infrage kommen, muss aus diesen allgemeinen Kriterien dann eine Teilmenge destilliert werden, die für den schulischen Einsatz relevant ist. Im folgenden \referenz{chpAuswahl} werden die verschiedenen, aktuell verfügbaren Plattformen auf diese Kriterien hin überprüft. Die notwendigen technischen Merkmale geeigneter Geräte(-typen) werden anhand der entwickelten Kriterien benannt.
Mit der Auswahl einer Plattform und konkreter Geräte ist es natürlich nicht getan. Vielmehr müssen diese, fachdidaktisch fundiert, in den Unterricht eingebunden werden. \referenz{chpGestaltung} befasst sich also mit den notwendigen Voraussetzungen und Maßnahmen und der zentralen Frage, wie die verfügbaren Systeme für einen praktischen Einsatz (um-)gestaltet werden müssen. Um direkt einem möglichen Missverständnis vorzubeugen: Es geht hier tatsächlich um die Gestaltung der mobilen Informatiksysteme für den Unterrichtseinsatz und nicht etwa um die Gestaltung des Informatikunterrichts mit mobilen Informatiksystemen.
Im abschließenden Kapitel (\referenz{chpAndroid}) wird dann versucht, die theoretischen Überlegungen in eine reale Umsetzung zu überführen.
\section{Begriffsklärung}
Zunächst sind zwei für die folgenden Ausführungen wesentliche Begriffe zu klären: der des \enquote{Informatiksystems} im Allgemeinen und der des \enquote{mobilen Informatikssystems} im Speziellen. Im Anschluss daran sollen auch noch kurz die zentralen Unterscheidungsmerkmale der verschiedenen, für diese Arbeit relevanten Typen mobiler Informatiksysteme benannt werden. Eine detailliertere Beschreibung der Gerätetypen findet sich im Anhang\vglr{secTyp}.
\subsection{Informatiksysteme}\label{secInfSys}
Zu der Frage, was ein Informatiksystem auszeichnet, gibt es durchaus differenzierte Vorstellungen\footnote{Eine detaillierte Betrachtung der verschiedenen Ansätze würde den Rahmen dieser Arbeit sprengen. Daher sei hier auf die differenzierten Betrachtungen in \cite{stechert2009} verwiesen.}. Als elementar für die weiteren Betrachtungen ist der Aspekt der Vernetzung mehrerer Systeme anzusehen. Nicht nur, weil dies den Alltag widerspiegelt, in dem die meisten Systeme heute einen, wie auch immer gearteten, Netzwerkzugang aufweisen. Sondern auch, weil man es im Informatikunterricht zwingend mit einer größeren Anzahl an Systemen zu tun hat, zwischen denen im Idealfall Interaktionsmöglichkeiten bestehen sollten. Im Folgenden soll die Definition nach \cite{ClausSchwill2006} als Grundlage dienen, die sich -- abseits der angesprochenen Detailbetrachtungen -- sehr gut für die weiteren Betrachtungen eignet:
\zitatblock[.]{Als Informatiksystem bezeichnet man die spezifische Zusammenstellung von Hardware, Software und Netzverbindungen zur Lösung eines Anwendungsproblems. Eingeschlossen sind alle durch die Einbettung des Systems in den Anwendungsbereich beabsichtigten oder verursachten nichttechnischen Fragestellungen und ihre Lösungen, also Fragen der Gestaltung des Systems, der Qualifizierung der Nutzer, der Sicherheit sowie der Auswirkungen und Folgen des Einsatzes. Informatik ist dann die Wissenschaft von Entwurf und Gestaltung von Informatiksystemen}{ClausSchwill2006}{314}
Betrachtet man diese Definition, wird unmittelbar ersichtlich, dass ein Großteil moderner, technischer Systeme Informatiksysteme sind: Sie weisen sowohl Hardware- als auch Softwarekomponenten auf und verfügen über verschiedene Netzverbindungen.
\subsection{Mobile Informatiksysteme}\label{secMobInfSys}
Nun liegt die Idee nahe, alle leicht transportablen Geräte, die die Kriterien für Informatiksysteme erfüllen, als mobile Informatikssysteme zu bezeichnen, also etwa Notebooks. Dieser Ansatz ist natürlich nicht vollständig von der Hand zu weisen.
Eine derartige Definition ist allerdings wenig sinnvoll. Schließlich würden somit im Zuge der fortschreitenden Miniaturisierung immer mehr Gerätegruppen erfasst, die keine genuinen mobilen Systeme sind. Schon ein klassischer Personal Computer ist schließlich leidlich transportabel. Ein heutiger Nettop, als miniaturisierter PC ist verglichen damit sogar extrem \enquote{mobil}. Doch hier trifft ein ganz wesentlicher Punkt nicht zu: Es handelt sich nicht um Systeme, die für eine mobile Nutzung entwickelt wurden.
Note- und Netbooks kann man zugute halten, dass sie tatsächlich für eine weitgehend ortsunabhängige Nutzung konstruiert wurden. Trotzdem sollen sie in dieser Arbeit nicht zu den mobilen Informatiksystemen gerechnet werden. Denn ein wirklich mobiles Arbeiten erlauben sie nicht. Dafür bleiben sie zu groß, zu schwer und zu unhandlich. Vielmehr ermöglichen sie eine flexible Änderung des Nutzungsortes. Daher sollten diese Systeme wohl eher als \enquote{teilstationäre} oder \textit{transportable Informatiksysteme} bezeichnet werden.
Wenn hier also von mobilen Informatiksystemen die Rede ist, so sind explizit solche gemeint, die genuin für eine mobile Nutzung entwickelt wurden. Hierzu gehören sowohl speziell für einen Anwendungszweck konstruierte Systeme wie Mul\-ti\-me\-dia\-ab\-spiel- und Navigationsgeräte, einfache Mobiltelefone etc., aber eben auch eher universelle Vertreter wie Smartphones und Tabletcomputer. Dazwischen gibt es einige Graustufen, so wie die häufig als \enquote{Lesser Smartphones} bezeichneten Mobiltelefone, etwa mit Samsungs Betriebssystem Bada. Bei allen genannten Gerätetypen finden sich die wesentlichen Merkmale eines Informatiksystems: Hardware, Software und Netzverbindungen, obwohl letztere nicht bei allen Gerätemodellen (frei zugänglich) zur Verfügung stehen. Lediglich Mobiltelefone und Tabletcomputer verfügen immer über mindestens eine Art der Netzverbindung, die im Rahmen der vorgesehenen Benutzung eingesetzt werden kann.
Für die folgenden Betrachtungen wird die Bedeutung des Begriffs mobiler Informatiksysteme auf die universelleren Geräte eingeschränkt, soweit nicht anders angegeben, d.~h. auf Smartphones, Tablets und Hybride. Denn diese sind es, die für den Informatikunterricht besonders interessant sind, was im Folgenden noch genauer dargelegt werden wird.
\staticBox{Wolkige Aussichten}{\label{boxWolk}
Durch die starke Bindung der mobilen Geräte an bestimmte Internetdienste, gerne auch mit der unscharfen, wolkigen Bezeichnung Cloud-Dienste ausgestattet, muss man einen weiteren Aspekt bedenken, der zunächst nicht ganz offensichtlich erscheint. Denn die äußerst enge Bindung etwa zwischen einem Android-System und den Google-Diensten oder einem Apple-Gerät und der iCloud, kann (und sollte) so interpretiert werden, dass die mobilen Informatiksysteme letztlich Teile eines größeren, übergeordneten Informatiksystems sind, das sich aus den mobilen Geräten und den Rechenzentren der Cloud-Dienste zusammensetzt. Dies hat sehr direkte Auswirkungen auf die Anwenderinnen und Anwender mobiler Informatiksysteme, denn ein Teil der von ihnen genutzen und in ihrem Besitz geglaubten Informatiksysteme entzieht sich ihrem Zugriff vollständig. Am offensichtlichsten wird dies bei den Themen Datenschutz und Datensicherheit bemerkbar (siehe \referenz{secGefDat}).}
\subsection{Gerätekategorien}
Um im Folgenden die Übersicht über das breite Produktangebot zu verbessern, werden zunächst einige Gerätekategorien eingeführt, denn die übliche Kategorisierung in Handys, Smartphones und Tablets hat sich als zu starr erwiesen. Es existieren zu viele Zwischenformen, die einer derartigen Kategorisierung den Boden entziehen. Die hier vorgeschlagene Kategorisierung ist etwas genauer und somit grundsätzlich besser geeignet, auch wenn die Vielzahl der verschiedenen Gerätetypen keine absolut trennscharfe Kategorisierung erlaubt.
Die speziell für einen Anwendungszweck konstruierten Geräte werden bis auf die Handys im Weiteren nicht mehr betrachtet. Für einen sinnvollen, auf Dauer angelegten Unterrichtseinsatz unterscheiden sie sich zu stark. Für die wenigen Spezial-Gadgets, die auf einem Smartphone- bzw. Tablet-Betriebssystem (etwa Multimediaabspielgeräte auf Basis von Android oder iOS) basieren, sowie für die per Java programmierbaren Gadgets gilt hingegen dasselbe, was für die entsprechenden Java-Handys, Smartphones oder Tablets gilt. Allerdings mit der Einschränkung, dass sie in der Regel über wesentlich weniger Ressourcen, Sensoren und Schnittstellen verfügen -- nämlich nur genau die, die für den Haupteinsatzzweck erforderlich sind.
Der generische Begriff \enquote{\gls{MobTel}} wird im Folgenden für ausnahmslos alle Geräte verwendet, die eine echte Telefonfunktion mitbringen. Internettelefonie wird ausgeklammert, da diese prinzipiell mit allen betrachteten Gerätetypen möglich, wenn auch unterschiedlich sinnvoll, wäre.
Wichtig ist, dass in Ermangelung einer besseren Bezeichnung die Kategorie \enquote{Handy} gegenüber dem Alltagsverständnis geringfügig umdefiniert wurde. Besonders für die Entscheidung, ob und inwieweit die bestimmten Gerätekategorien für den Einsatz im Unterricht geeignet sind, ist diese Unterscheidung wichtig. Als \textbf{\gls{Handy}} wird im Folgenden ein nicht erweiterbares \gls{MobTel} bezeichnet, das vornehmlich dem Telefonieren dient. Handys sind inzwischen nur noch in bestimmten Nischen erhältlich. Dazu gehören Notfall- und einmalig nutzbare Geräte ebenso wie Großtastentelefone für Senioren. \textbf{\glspl{JavaHandy}} sind im Gegensatz zu normalen \glspl{Handy} mittels Ja\-va-Ap\-pli\-ka\-ti\-o\-nen erweiterbar. Zwischen den \glspl{JavaHandy} und den \glspl{Smartphone} liegt die Kategorie der \textbf{\glspl{LesserSP}}, die im Gegensatz zu \glspl{Smartphone} in der Regel über proprietäre, wenig verbreitete Betriebssysteme verfügen und somit, neben der geringeren Leistungsfähigkeit, nur äußerst begrenzt erweiterbar sind. Die oberste Kategorie der Mobiltelefone bilden die \textbf{\glspl{Smartphone}}. Sie sind in der Regel besonders leistungsfähig und gut ausgestattet, bieten aber immer auf Basis verbreiteter Systeme und verfügbarer \glspl{API} diverse Erweiterungsmöglichkeiten. \textbf{\glspl{Tablet}} sind \glspl{MobInfSys}, die über eine ähnliche Leistung und Ausstattung verfügen wie Smartphones, aber nicht über echte Telefoniefunktionen und die deutlich größer sind. Mit der Größe geht eine einfachere Bedienbarkeit einher, die etwa die Eingabe von Texten betrifft\footnote{Teile dieser Arbeit wurden ebenfalls auf Tablets und Hybriden verschiedener Hersteller verfasst.}. Zwischen \glspl{Smartphone} und \glspl{Tablet} existiert noch die Kategorie der \textbf{\glspl{Hybrid}}, die in etwa so groß wie kleine Tablets sind, aber echte Telefoniefunktionen und häufig auch typische Merkmale der alten \glspl{PDA}, wie Stiftbedienung, aufweisen.

View file

@ -0,0 +1,335 @@
\chapter{Realität vs. Schule}\label{chpBedeutung}
In der Einführung wurde bereits angemerkt, dass sich die Erscheinungsformen von Informatiksystemen wie auch das Nutzungsverhalten von Informatiksystemen in der Gesellschaft im Wandel befinden. In diesem Kapitel soll dies nun -- zunächst allgemein, dann spezifisch für Kinder und Jugendliche -- detaillierter gezeigt werden.
Das verwendete Zahlenmaterial unterliegt leider einigen Einschränkungen, vor allem sind verlässliche Werte kaum zu bekommen. Alle folgenden Betrachtungen geben daher Trends wieder und sollten nicht als absolute Werte interpretiert werden. Näheres hierzu in den Erläuterungen im Anhang\vglr{secZahl}.
\section{Informatische Omnipräsenz\dots}\label{secInfOmni}
\subsection{(Un-)sichtbare Informatik}
In modernen Gesellschaften hat die Informatik inzwischen -- auf den ersten Blick weitgehend unsichtbar -- eine dominierende Rolle eingenommen. Es gibt kaum mehr ein elektronisches Gerät, das ohne eine Kombination von Hardware und Software auskäme. Selbst Netzzugänge sind inzwischen für Systeme absolut üblich, bei denen bis vor einigen Jahren niemand damit gerechnet hätte. Als äußerst unvollständige Auflistung seien hier etwa die folgenden Gerätegruppen genannt: Haushaltsgeräte, Radios, Fernseher, Abspielgeräte für Musik und Videos, Fotoapparate, Mobiltelefone, selbst Stromzähler, sogenannte \enquote{Smart Meter}\vgl{Molina2010}{1~f.}, und sogar simple Gerätschaften wie Lampen sind an das Heimnetzwerk und -- in den meisten Fällen -- darüber direkt an das Internet angebunden.
Sich ausweisen (\gls{NPA}) und bezahlen (EC- oder Geldkarte) kann man mittels Smartcard. Letzteres funktioniert bald flächendeckend mit dem Smartphone per \gls{NFC}. Produkte weisen sich hingegen mittels der verwandten passiven Technologie \gls{RFID} aus.
Weder im kommerziellen, noch im privaten Bereich ist ohne diese Systeme das alltägliche Leben in der modernen Gesellschaft vorstellbar. Man hat folglich den Eindruck, dass fast alles -- und sei es nur aus Marketinggründen -- irgendwie \enquote{smart} ist. Näher betrachtet wird sofort klar: All diese \enquote{smarte} Herrlichkeit ist ohne Informatik nicht vorstellbar, handelt es sich doch um Informatiksysteme in diversen Erscheinungsformen.
\subsection{Miniaturisierung und Mobilisierung}\label{secMinMob}
\zitatblock[.]{Pervasive und Ubiquitous Computing scheinen durch die breite Nutzung von Computern in Form von Sekundärartefakten und die damit einhergehende engere Kopplung von Informationswelt und physischer Welt einen Paradigmenwechsel in den Informatik einzuleiten}{pervubco}{1}
Es ist besonders zu beachten, dass durch den fortschreitenden Prozess der Miniaturisierung viele dieser Systeme nicht mehr offensichtlich zu erkennen sind. Es \zitat{folgt auf das PC-Zeitalter nunmehr die Ära des überall vorhandenen, aber unsichtbaren Rechners}{pervubco}{1}. Die Zeiten der großen grauen Kisten sind vorbei, wie bereits in \cite[S.~151]{HemingSpittank2012} angemerkt wurde. Viele Angehörige moderner Gesellschaften tragen ständig diverse Informatiksysteme mit sich herum. Angefangen bei diversen Smartcards, Handys und Multimedia-Abspielgeräten über E-Book-Reader, Navigationssysteme bis hin zu Smartphones und Tablets sind sie mit Informatiksystemen bepackt, wenn sie das Haus verlassen. Auch zu Hause schätzen viele die Vorteile der mobilen Informatiksysteme, ist es doch viel bequemer, auf dem Sofa ein digitales Buch auf dem E-Book-Reader zu lesen oder mit dem Tablet im Internet zu surfen oder seine E-Mails abzurufen, als dies am Schreibtisch vor dem PC zu erledigen.
Der verfügbare -- auch stationär genutzte -- Computer ist im Übrigen in vielen Haushalten und Unternehmen inzwischen ein Notebook oder zumindest ein \gls{AllInOnePC}. So lag der Anteil der stationären Systeme an allen in Deutschland verkauften Computern 2010 bei nur noch 30\,\% gegenüber Note- und Netbooks mit zusammen 67\,\%, und das obwohl \zitat{erstmals seit Jahren wieder mehr stationäre PCs verkauft [wurden] als im Vorjahr}{bitkom2011a}. Allerdings zählen die \glspl{AllInOnePC} mit zu den stationären PCs, die zwar stationär sind, aber technisch eher mit Notebooks zu vergleichen sind. Damit teilen sie wesentliche Vorteile der Notebooks, die aus der Optimierung der Notebookkomponenten auf geringen Energieverbrauch resultieren. So sind durch die geringere Verlustleistung und damit geringere Abwärme nicht nur kompaktere und damit platzsparende und unaufälligere Bauweisen üblich, sondern durch fehlende oder reduzierte aktive Kühlung sogar extrem leise oder lautlose Systeme möglich. Nicht zuletzt macht sich die sparsamere Ausrichtung natürlich auf der Stromrechnung bemerkbar. Die Frage, ob der klassische Desktop-Computer stirbt\vgl{HemingSpittank2012}{151}, lässt sich also mit einem klaren Ja beantworten. Da die Leistung aktueller Notebookkomponenten für die Nutzung von Internetdiensten, Bürotätigkeiten, Foto-, Video- sowie Audiobearbeitung und nicht zuletzt für viele Spiele mehr als ausreichend ist, erklärt sich leicht die Beliebtheit dieser -- bei Notebooks zusätzlich noch mobil einsetzbaren -- Systeme. Trotzdem handelt es sich hierbei noch immer \zitat{eher um \enquote{alten Wein in neuen Schläuchen}}{HemingSpittank2012}{151}.
Im Jahr 2011 waren die leichten Zuwächse vom Vorjahr bei den Verkäufen stationärer Informatiksysteme wieder Geschichte. Nur noch 27\,\% der verkauften Systeme waren stationär, während 50\,\% Notebooks waren. Die deutlichste Veränderung war allerdings bei den Tablets zu beobachten, die mit nun mehr 16\,\% besonders den Netbooks\footnote{Mit nur noch 7\,\% statt 13\,\% halbierte sich der Marktanteil der Netbooks fast.}, und damit den vormals mobilsten Geräten, den Rang abliefen \citep{bitkom2011b}.
\DTLloaddb[]{ompSPGesamt}{chartdata/google/smartphone_gesamt_gender.csv}
% Tabelle: Smartphonenutzung in Europa
\begin{table}[htbp]
\centering
\newcommand{\DTLifGer}{\DTLifeq{\land}{Deutschland}{\bfseries}{}}
\begin{tabular}{l|rrr|rrr}
\toprule[2pt]
\textbf{Land} &
\textbf{W11} &
\textbf{M11} &
\textbf{G11} &
\textbf{W12} &
\textbf{M12} &
\textbf{G12}%
\DTLforeach*{ompSPGesamt}{
\land=Land,
\datwe=W11,
\datme=M11,
\datge=G11,
\datwz=W12,
\datmz=M12,
\datgz=G12%
}{%
\DTLiffirstrow{\\\midrule[1.5pt]}{\\}
\DTLifGer\land &
\DTLifGer\DTLfempty{\datwe} &
\DTLifGer\DTLfempty{\datme} &
\DTLifGer\DTLfempty{\datge} &
\DTLifGer\DTLfempty{\datwz} &
\DTLifGer\DTLfempty{\datmz} &
\DTLifGer\DTLfempty{\datgz} %
}%
\\
\bottomrule[2pt]
\end{tabular}
\caption[Smartphonenutzung in Europa]{Anteil der Smartphonenutzer an der Gesamtbevölkerung für diverse europäische Staaten, alle Angaben in Prozent, Mxx = männliche Bevölkerung, Wxx = weibliche Bevölkerung, Gxx = gesamte Bevölkerung, xx = Jahreszahl, vgl. \referenz{figSmartInEU}, Quelle: \cite{OMP}}\label{tabSmartInEU}
\end{table}
% Diagramm: Smartphonenutzung in der EU
\begin{figure}[htbp]
\centering
\begin{scriptsize}
\DTLsort{Land=descending}{ompSPGesamt}
\DTLsetbarcolor{1}{buwMid}
\DTLsetbarcolor{2}{buw}
\DTLmultibarchart{
variables={\datge,\datgz},
barwidth=8pt,
uppermultibarlabels={\DTLifeq{}{\datge}{}{\datge\,\%},\DTLifeq{}{\datgz}{}{\datgz\,\%}},
barlabel={\land},
axes=both,
max=60,
yticgap=10,
yticlabels={0,10,20,30,40,50,60},
verticalbars=false
}{ompSPGesamt}{%
\land=Land,
\datge=G11,
\datgz=G12%
}
\end{scriptsize}
\caption[Smartphonenutzung in Europa]{Anteil der Smartphonenutzer in Prozent der Gesamtbevölkerung für diverse europäische Staaten, {\bfseries\color{buw} hellgrün}=2012, {\bfseries\color{buwMid} dunkelgrün}=2011, vgl. \referenz{tabSmartInEU}, Quelle: \cite{OMP}}\label{figSmartInEU}
\end{figure}
Insgesamt zeigen sich bei den mobilen Informatiksystemen deutliche Zuwächse. So verfügten 2012\footnote{Erhebungszeitraum: Januar bis März}, nach den Daten des \gls{OMP}, 29\,\% aller Deutschen über ein Smartphone. Gegenüber dem Vorjahreswert von 18\,\%\footnote{Erhebungszeitraum: März bis Juli 2011} ein gewaltiger Zuwachs \citep[vgl.][]{OMP}. Diese Werte werden tendenziell von anderen Studien bestätigt, so ergab etwa eine Befragung\footnote{Diese Erhebung wurde ebenfalls von TNS Infratest durchgeführt, Projektpartner war hier mit Huawei ebenfalls ein großer Hersteller von Smartphones.} der Initiative D21, dass im Januar 2012 fast 24\,\% der Deutschen über ein Smartphone verfügten\vgl{d21mobi}{20}, weitere 9\,\% planten demnach konkret die Anschaffung eines Smartphones. Laut comScore\vgl{comscore2012}{7} verwendete im Dezember 2012 ein Anteil von 37\,\% der Mobilfunknutzer in Deutschland ein Smartphone.
Für Tablets lässt sich hingegen überhaupt noch keine klare Aussage zur tatsächlichen Verbreitung machen. Die Angaben der verschiedenen Studien schwanken hier zwischen etwa 5\,\% und rund 15\,\% der Gesamtbevölkerung. Dabei erscheinen eher die 5\,\%, wie sie etwa in \cite[S.~20]{d21mobi} angegeben werden, realistisch, wenn man berücksichtigt, dass die Tablets noch nicht sehr lange verfügbar sind und der Anteil von Tablets an allen neu verkauften Systemen 16\,\% betragen soll\vgln{bitkom2011b}. Allerdings wäre selbst dies eine beachtliche Größenordnung, wenn man bedenkt, dass diese Gerätekategorie erst seit Mitte 2010\footnote{Zeitpunkt der iPad-Einführung} verfügbar ist.
Der Trend zu mehr Smartphones lässt sich weltweit verfolgen. Auffällig ist, dass Deutschland bei der Smartphone-Nutzung sogar stark hinter den meisten anderen europäischen Staaten zurückliegt (vgl. \referenz{figSmartInEU} und \referenz{tabSmartInEU}). Man könnte also erwarten, dass hier noch stärkere Zuwachsraten bevorstehen, da der weltweite Mobilfunkmarkt sich eher auf (Lesser) Smartphones ausrichtet, wobei die Geräte selbst durch das größere Angebot -- immer mehr Hersteller bieten immer mehr verschiedene Geräte an -- günstiger werden und, aufgrund der Neuausrichtung des Marktes, auch stärker beworben werden. Aktionsverkäufe diverser (eigentlich eher auf Lebensmittel spezialisierter) Discounter scheinen dies zu bestätigen. All das könnte dafür sorgen, dass auch in Deutschland eine noch stärkere Nachfragesteigerung eintritt. Die zunehmende Verfügbarkeit erschwinglicher mobiler Internetzugänge\footnote{Dies wurde durch günstige Angebote zum Teil durch eben diese Discounter vorangetrieben, die als preisgünstige Reseller von Mobilfunkleistungen auftreten.} macht Smartphones und Tablets zusätzlich attraktiv:
\zitatblock[.]{Durch sinkende Kosten bei steigender Übertragungskapazität
schwinden die Nutzungsbarrieren und machen so den Weg frei für die massenhafte
Verbreitung der Smartphones}{gosmart}{5}
Legt man die Zahlen der Initiative D21 zu Grunde, so nutzen inzwischen 26,5\,\% der Deutschen das Internet mobil\vgl{d21mobi}{20}. Dabei führte die mobile Nutzung bei deutlich über der Hälfte der Befragten zu einer verstärkten Inter\-net\-nutzung insgesamt, zusätzlich zur allgemeinen Bedeutungssteigerung des Internets.
\subsection{Veränderte Nutzungsgewohnheiten}
\subsubsection{Gesamtgesellschaftliche Veränderung}\label{secVerNutz}
Insbesondere durch die zunehmende Bedeutung des Internets als universelles Kom\-muni\-ka\-ti\-ons-, Informations- und Unterhaltungsmedium in der Gesellschaft haben sich die Nutzungsgewohnheiten von Informatiksystemen grundlegend geändert. Informatiksysteme sind auch in ihren offensichtlicheren Erscheinungsformen ein viel zentralerer Bestandteil des Alltags geworden. Doch erst die mobilen Informatiksysteme haben zu einer grundlegenden Veränderung geführt: Erstmals ist tatsächlich jederzeit und überall ein Zugriff auf einen gigantischen Berg an Daten und Information\footnote{Hier (wie im Folgenden) wird die Terminologie nach \citep[S.~8~f.]{Fuhr2004} verwendet: Daten (syntaktisch) -- Information (semantisch) -- Wissen (pragmatisch)} möglich, gegen den selbst große Bibliotheken blass aussehen -- und das alles trägt der moderne Mensch in der Hosentasche mit sich herum. Nun ist die reine Verfügbarkeit von Daten und Information nicht alles, vielmehr bieten die Informatiksysteme heute viele, leistungsfähige Möglichkeiten, die zum Gewinn des situationsabhängig benötigten, pragmatischen Wissens beitragen. Allen voran sind hier natürlich die hoch optimierten Suchalgorithmen in den Geräten und von Suchmaschinen im Internet zu nennen, aber auch die ausgefeilten Möglichkeiten, mittels der (mobilen) Informatiksysteme Daten zu strukturieren, zu sammeln, weiter aufzubereiten und somit einen Informationsgewinn zu erzielen, sind nicht zu unterschätzen.
Letztlich tragen mobile Informatiksysteme also als universelle Werkzeuge zur Gewinnung und Bereitstellung des in konkreten Situationen benötigten Wissens bei. Sie sind demnach äußerst nützliche Hilfsmittel zur \zitat{informationellen Handlungsabsicherung}{Fuhr2004}{9}. Je größer die Menge an Information wird, die jederzeit zur Verfügung steht, und je besser die Werkzeuge zum gezielten Zugriff auf Teile davon werden, desto deutlicher wird, dass die Aneignung reinen Faktenwissens an Bedeutung verliert, und desto mehr gilt der Albert Einstein zugeschriebene Ausspruch: \enquote{Wissen heißt: Wissen, wo es geschrieben steht}.
Quasi nebenbei sind viele Bürgerinnen und Bürger über mobile Informatiksysteme ständig online, kommunizieren über Soziale Netzwerke und nutzen diverse Internet-Dienste. Insbesondere die Nutzung der Sozialen Netzwerke und diverser cloudbasierter Anwendungen erscheint als aktueller, gesellschaftlicher Trend, dem folgen muss, wer am sozialen Leben in der Gesellschaft vollumfänglich teilnehmen will\footnote{Einige Studien sehen hier sogar einen neuen Menschentypus, wie etwa den des \enquote{Digital-Native} bzw. \zitat{Smart-Native}{gosmart}{10}, der sich duch hohe \zitat{Nutzungsintensität [des Smartphones], Technik- und Webaffinität}{gosmart}{10} auszeichnet und der das mobile Internet und sein Smartphone fest und völlig selbstverständlich in seinen Alltag integriert hat.}. Dies trifft vor allem auf die jüngeren Generationen zu und ist daher für den Einsatz in der Schule durchaus relevant.
\subsubsection{Kinder und Jugendliche}\label{secVerNutzJu}
Die gesamtgesellschaftlichen Veränderungen der Nutzungsgewohnheiten und die Verfügbarkeit und Verbreitung von Informatiksystemen hat selbstverständlich direkte Auswirkungen auf Kinder und Jugendliche. Sie wachsen in dieser Gesellschaft auf und nehmen die technischen Möglichkeiten als natürlich gegeben hin. Seit längerer Zeit lässt sich somit beobachten, dass die verschiedenen Informatiksysteme zunehmende Bedeutung im Alltag von Kindern und Jugendlichen erlangen. Wie schon bei Trivialliteratur, Groschenromanen, Comics, dem Fernsehen, Computerspielen oder anderen Medien sorgt dies für Besorgnis bei den jeweiligen Elterngenerationen, die nicht damit aufgewachsen sind, für die diese Medien bzw. Geräte also nicht selbstverständlich zum Alltag gehören.
\zitatblock[.]{Vielmals wird heute der Begriff der \enquote{digital
natives} bemüht: Die Jugendlichen werden als \enquote{digitale Eingeborene} bezeichnet, da sie bereits in einer Welt mit einem vielfältigen Angebot an Medien aufwachsen und sich den Umgang nicht erst im Erwachsenenalter aneignen müssen
}{MPFS2011}{3}
Natürlich darf nicht von einer natürlichen Kompetenz ausgegangen werden\vglr{secDurchblick}:
\zitatblock[.]{Oftmals wird allerdings die unverkrampfte Herangehensweise von Jugendlichen an moderne Medientechnik missverstanden als eine Art angeborene Medienkompetenz
}{MPFS2011}{3}
Dennoch führt der natürliche Umgang der Kinder und Jugendlichen mit der Technik zu Missverständnissen mit älteren Generationen, die tendenziell (aufgrund ihrer höheren Lebenserfahrung und zum Teil fehlenden eigenen Erfahrungen mit den Neuerungen) eher skeptisch auf neue Medien und Technologien reagieren. Dies führt in Verbindung mit häufig lückenhaftem Wissen auf Seiten der Elterngeneration zu einer Überhöhung des Gefahrenpotentials und reflexhaften Verbotsrufen. Bei mobilen Informatiksystemen werden hier in der Regel der hohe Ablenkungsgrad, die meist eher nebulös umschriebenen Gefahren im Internet, Missbrauchsmöglichkeiten etwa für das Mobbing von Mitschülern und der Zugang zu Gewaltvideos und Pornographie genannt (Näheres hierzu im nächsten \referenz{secNeuChaGef}). Als Resultat dieses Diskurses sind Verbote von Mobiltelefonen und Multimediaabspielgeräten inzwischen an den meisten Schulen etabliert. In Bayern hat das Verbot sogar Gesetzesrang erlangt:
\zitatblock{Zwar erlaubt Art. 56 Abs. 5 Satz 1 BayEUG die Nutzung (\enquote{Einschaltung}) von Mobilfunkgeräten und digitalen Speichermedien zu Unterrichtszwecken. Dies ist aber keineswegs im Schulalltag angekommen. Dort ist nach wie vor pauschal von Handyverboten die Rede, die Erlaubnis wird kaum thematisiert, geschweige denn genutzt.}{CSUNetzrat}{12}
Eine ernsthafte Einschätzung des Gefahrenpotentials und des möglichen Nutzens für die Schule bedarf jedoch einer näheren Betrachtung, wie die Systeme tatsächlich verwendet werden. Mit den beiden Studien \gls{JIM} und \gls{KIM} liegen hierzu entsprechende Erkenntnisse vor.
\paragraph{Gerätebesitz und Zugang zu Geräten}\label{parVerNutzJuBes}
Zunächst ist zu betrachten, ob und wie Kinder und Jugendliche Zugang zu (mobilen) Informatiksystemen haben. Betrachtet man die aktuellsten Studien\footnote{Alle Angaben in diesem Abschnitt beziehen sich auf die jeweils neusten KIM- bzw. JIM-Studie, sofern nicht anders angegeben.} (\cite[S.~5~f.]{MPFS2011} und \cite[S.~7~f.]{MPFS2010a}), so wird deutlich, dass bereits die meisten Kinder (laut \gls{KIM}) in einem Haushalt leben, der über einen Computer (91\,\%) und einen Internetzugang (89\,\%) verfügt. In 97\,\% dieser Haushalte ist ein Mobiltelefon vorhanden und 71\,\% verfügen auch über eine Spielkonsole. Bei Jugendlichen verfügt laut \gls{JIM} sogar inzwischen jeder Haushalt über einen Computer, 99\,\% auch über einen Internetzugang, ebenso verbreitet sind hier Mobiltelefone (43\,\% der Haushalte haben sogar ein Smartphone, 10\,\% ein Tablet). Mindestens 77\,\%\footnote{Bei der \gls{JIM} 2011 wurden feste und tragbare Spielkonsolen noch nicht zusammengefasst, sodass der genaue Wert nicht ermittelbar ist.} der Jugendlichen haben darüber hinaus Zugang zu einer Spielkonsole.
Selbst wenn man alle weiteren erfassten Geräte (wie Multimediaabspielgeräte, Digitalkameras usw.) nicht beachtet, wird deutlich, dass Informatiksysteme zum \textit{Alltag} der \SuS gehören. Diese Bedeutung wird noch unterstrichen, wenn man einen Blick auf den \textit{persönlichen Gerätebesitz}, also eigene Geräte, über die sie (weitgehend) unabhängig verfügen können, der Kinder und Jugendlichen wirft. Hier zeigt sich, dass bereits 53\,\% der Mädchen und 52\,\% der Jungen unter 14 Jahren über ein eigenes Mobiltelefon verfügen. Bei den Jugendlichen sind es bereits 98\,\% der Mädchen und 94\,\% der Jungen. 27\,\% der Jungen verfügen über ein Smartphone, 4\,\% über ein Tablet. Bei den Mädchen sind es 22\,\% bzw 3\,\%\footnote{Der Autor hat seit seinem ersten Kontakt mit der Thematik des Einsatzes von Mobiltelefonen im Unterricht vor gut einem Jahr die Situation in allen durch ihn besuchten Kursen und Klassen (insgesamt drei an einer Hauptschule, vierzehn an Gesamtschulen, zwei an einer Realschule und zwölf an Gymnasien) sehr genau beobachtet und \SuS dazu befragt. Durchgehend und unabhängig von der besuchten Schulform ergaben sich Besitzquoten von 80\,\% bis 100\,\%. Ab der siebten Klasse lag der Anteil von Handybesitzern bei fast durchgehend 100\,\%. Der Smartphone-Anteil lag -- ebenfalls schulformunabhängig -- bei durchschnittlich 40\,\%. In den letzten acht besuchten Lerngruppen lag der Anteil sogar stabil bei über 70\,\%. Diese Werte sind zwar keinesfalls repräsentativ, zeigen aber eine deutliche Korrelation zu den Ergebnissen der \gls{JIM} (wenngleich der Startwert dabei etwas niedriger lag), wenn man die weitere Entwicklung extrapoliert. Es wird interessant sein, diese Werte mit den tatsächlichen Ergebnissen der \gls{JIM} 2012 zu vergleichen.}.
Wenn man die Entwicklung der vergangenen Jahre mit einbezieht, wird zudem deutlich, dass mobile Informatiksysteme einen sehr viel stärkeren Zuwachs verzeichneten als die klassischen Computer, die eher auf einem mittleren Level stagnieren. Die \referenz{tabJIMBesitz} und die \referenz{figJIMBesitz} stellen diese Entwicklung für die Jugendlichen deutlich dar. Insgesamt ist also davon auszugehen, dass die mobilen Systeme für die Jugendlichen eine größere Bedeutung haben als die stationären Informatiksysteme.
% Tabelle: Medienbesitz JIM
\begin{table}[htbp]
\DTLloaddb[]{JIMBesitz}{chartdata/jim/jim_besitz_t.csv}
\DTLsort{Jahr=descending}{JIMBesitz}
\centering
\begin{tabular}{l|rrr|rrr|rrr|rrr}
\toprule[2pt]
\textbf{Jahr} &
\multicolumn{3}{c|}{\textbf{PC/NB}} &
\multicolumn{3}{c}{\textbf{Handy}} &
\multicolumn{3}{c}{\textbf{Smartph.}} &
\multicolumn{3}{c}{\textbf{Tablet}}
\\&
\textbf{M} &
\textbf{J} &
\textbf{G} &
\textbf{M} &
\textbf{J} &
\textbf{G} &
\textbf{M} &
\textbf{J} &
\textbf{G} &
\textbf{M} &
\textbf{J} &
\textbf{G}%
\DTLforeach*{JIMBesitz}{
\datjahr=Jahr,
\datpnm=PNM,
\datpnj=PNJ,
\datpng=PNG,
\datham=HAM,
\dathaj=HAJ,
\dathag=HAG,
\datspm=SPM,
\datspj=SPJ,
\datspg=SPG,
\dattbm=TBM,
\dattbj=TBJ,
\dattbg=TBG%
}{%
\DTLiffirstrow{\\\midrule[1.5pt]}{\\}
\datjahr &
\DTLfempty{\datpnm} &
\DTLfempty{\datpnj} &
\DTLfempty{\datpng} &
\DTLfempty{\datham} &
\DTLfempty{\dathaj} &
\DTLfempty{\dathag} &
\DTLfempty{\datspm} &
\DTLfempty{\datspj} &
\DTLfempty{\datspg} &
\DTLfempty{\dattbm} &
\DTLfempty{\dattbj} &
\DTLfempty{\dattbg}%
}%
\\
\bottomrule[2pt]
\end{tabular}
\caption[Gerätebesitz von Jugendlichen]{Geräte im Besitz von Jugendlichen, alle Angaben in Prozent, M=Mädchen, J=Jungen, G=Gesamt, PC/NB=PC oder Notebook, Smartph.=Smartphone, vgl. \referenz{figJIMBesitz}, Quellen: \cite{MPFS1998, MPFS1999, MPFS2000, MPFS2001, MPFS2002, MPFS2003, MPFS2004, MPFS2005, MPFS2006, MPFS2007, MPFS2008, MPFS2009, MPFS2010, MPFS2011}}\label{tabJIMBesitz}
\end{table}
% Diagramm: Medienbesitz JIM
\DTLloaddb[]{JIMbesitzPNG}{chartdata/jim/jim_besitz_png.csv}
\DTLloaddb[]{JIMbesitzPNM}{chartdata/jim/jim_besitz_pnm.csv}
\DTLloaddb[]{JIMbesitzPNJ}{chartdata/jim/jim_besitz_pnj.csv}
\DTLloaddb[]{JIMbesitzHAG}{chartdata/jim/jim_besitz_hag.csv}
\DTLloaddb[]{JIMbesitzHAM}{chartdata/jim/jim_besitz_ham.csv}
\DTLloaddb[]{JIMbesitzHAJ}{chartdata/jim/jim_besitz_haj.csv}
\DTLloaddb[]{JIMbesitzSPG}{chartdata/jim/jim_besitz_spg.csv}
\DTLloaddb[]{JIMbesitzSPM}{chartdata/jim/jim_besitz_spm.csv}
\DTLloaddb[]{JIMbesitzSPJ}{chartdata/jim/jim_besitz_spj.csv}
\DTLloaddb[]{JIMbesitzTBG}{chartdata/jim/jim_besitz_tbg.csv}
\DTLloaddb[]{JIMbesitzTBM}{chartdata/jim/jim_besitz_tbm.csv}
\DTLloaddb[]{JIMbesitzTBJ}{chartdata/jim/jim_besitz_tbj.csv}
\begin{figure}[htbp]
\begin{scriptsize}
\centering
\setcounter{DTLplotroundYvar}{0}
\setlength{\DTLlegendxoffset}{40pt}
\renewcommand{\DTLmajorgridstyle}{color=grayOne,-}
\newcommand{\diagJIMls}{\pgfsetdash{{2pt}{2pt}}{0pt}}
\DTLplot{JIMbesitzPNG,JIMbesitzPNM,JIMbesitzPNJ,JIMbesitzHAG,JIMbesitzHAM,JIMbesitzHAJ,JIMbesitzSPG,JIMbesitzSPM,JIMbesitzSPJ,JIMbesitzTBG,JIMbesitzTBM,JIMbesitzTBJ}{x=JN, y=Prozent, maxy=100, maxx=14, xlabel=Jahr, ylabel={Anteil der \SuS, die mindestens eins dieser Geräte besitzen (\%).}, style=both, width=12.2cm, height=11.5cm, grid=true, legend=southeast, legendlabels={{PC und Noteb. (gesamt)},{PC und Noteb. (Mädchen)},{PC und Noteb. (Jungen)},{Handys (gesamt)},{Handys (Mädchen)},{Handys (Jungen)},{Smartphones (gesamt)},{Smartphones (Mädchen)},{Smartphones (Jungen)},{Tablets (gesamt)},{Tablets (Mädchen)},{Tablets (Jungen)}}, xticgap=1, xticlabels={1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010,2011}, linecolors={Red,BrickRed,Brown,Green,LimeGreen,OliveGreen,Blue,Cyan,NavyBlue,Magenta,Lavender,Fuchsia}, markcolors={Red,BrickRed,Brown,Green,LimeGreen,OliveGreen,Blue,Cyan,NavyBlue,Magenta,Lavender,Fuchsia}, lines={\diagJIMls,\diagJIMls,\diagJIMls,\diagJIMls,\diagJIMls,\diagJIMls,\diagJIMls,\diagJIMls,\diagJIMls,\diagJIMls,\diagJIMls,\diagJIMls}, marks={\pgfuseplotmark{square*},\pgfuseplotmark{*},\pgfuseplotmark{triangle*},\pgfuseplotmark{square*},\pgfuseplotmark{*},\pgfuseplotmark{triangle*},\pgfuseplotmark{square*},\pgfuseplotmark{*},\pgfuseplotmark{triangle*},\pgfuseplotmark{square*},\pgfuseplotmark{*},\pgfuseplotmark{triangle*}}}
\caption[Gerätebesitz von Jugendlichen]{Gerätebesitz von Jugendlichen (12-19 Jahre), vgl. \referenz{tabJIMBesitz}, Quellen: \cite{MPFS1998, MPFS1999, MPFS2000, MPFS2001, MPFS2002, MPFS2003, MPFS2004, MPFS2005, MPFS2006, MPFS2007, MPFS2008, MPFS2009, MPFS2010, MPFS2011}}
\label{figJIMBesitz}
\end{scriptsize}
\end{figure}
Zur Abhängigkeit des Gerätebesitzes von der sozialen Herkunft der Jugendlichen lassen sich anhand der JIM-Studie nur vage Aussagen treffen. Wenn man die Ergebnisse der verschiedenen Schulformen vergleicht und die starke Korrelation von sozialer Herkunft und Schullaufbahn im Blick behält, lassen sich jedoch zumindest Vermutungen anstellen. Es zeigen sich keine wesentlichen Unterschiede beim Gerätebesitz\vgl{MPFS2011}{57}. Im Gegenteil ist der Unterschied sogar geringer als der beim Besitz eines Computers\vgl{MPFS2011}{30}. Eine negative Auswirkung auf die Alltagserfahrungen ist also zunächst nicht anzunehmen. Dennoch muss dieser Aspekt -- besonders wenn in der Schule die Geräte der \SuS verwendet werden sollen -- berücksichtigt werden. Es ist zumindest davon auszugehen, dass sich die finanziellen Möglichkeiten des Elternhauses auf die Ausstattung der mobilen Informatiksysteme der \SuS auswirken. Die Schule muss den damit möglicherweise entstehenden Benachteiligungen aufgrund sozialer Ungleichheiten entgegenwirken, etwa durch die Bereitstellung von Leihgeräten.
Ein weiterer interessanter Aspekt ist, dass die verschiedenen Informatiksysteme recht ungleich zwischen den Geschlechtern verteilt sind. So verfügten immer mehr Mädchen über ein Mobiltelefon als Jungen (vgl. \referenz{tabJIMBesitz} und \referenz{figJIMBesitz}). Bei Smartphones und Tablets führen jedoch die Jungen leicht. Im Gegenzug verfügten weniger Mädchen als Jungen über einen Computer oder eine Spielekonsole. Besonders deutlich wird das bei Spielekonsolen (wobei tragbare Spielekonsolen bei Mädchen deutlich beliebter waren als feste): Hier besitzen aktuell fast doppelt so viele männliche wie weibliche Jugendliche eines dieser Geräte. Diese Ungleichverteilung lässt sich auf die unterschiedlichen Nutzungsgewohnheiten von Mädchen und Jungen zurückführen.
\paragraph{Nutzungsgewohnheiten} \label{parVerNutzJuNu}
Bereits bei den von der \gls{KIM} untersuchten Kindern zeigt sich, dass die Nutzung von Informatiksystemen einen sehr relevanten Anteil am Alltag der Kinder hat\vgl{MPFS2010a}{9~ff.}. Deutlich werden dabei zwei wichtige Aspekte. Erstens ist das Mobiltelefon das am regelmäßigsten genutzte Gerät. Zweitens nutzen Mädchen andere Informatiksysteme bzw. Informatiksysteme anders als Jungen\vgl{MPFS2010a}{11}. Jungen verwenden eher Geräte, mit denen man spielen kann, während Mädchen einzig bei den Mobiltelefonen eine intensivere Nutzung aufweisen als Jungen. Dies kann also eine Erklärung für den stärkeren Smartphone-Besitz von Jungen sein. Schließlich dienen Smartphones nicht nur der Kommunikation sondern können gerade durch Spiele erweitert werden. Das Internet nutzen in dieser Altersgruppe zwar ebenfalls weniger Mädchen als Jungen, jedoch ist der Unterschied sehr viel geringer als bei der sonstigen Computernutzung.
Bei den Jugendlichen sind diese Trends noch sehr viel deutlicher ausgeprägt\vgl{MPFS2011}{13~f.}. So nutzen 91\,\% der Jugendlichen ihr Mobiltelefon mehrmals pro Woche, 80\,\% sogar täglich, es ist somit das unumstritten am häufigsten genutzte Informatiksystem bei Jugendlichen. Außerdem ist es nach Einschätzung der Jugendlichen das wichtigste Informatiksystem\vgl{MPFS2011}{17}. Das Internet nutzen 90\,\% regelmäßig und 65\,\% täglich, damit ist es in dieser Altersgruppe das am meisten genutzte Informationsmedium, noch vor dem Fernsehen (89\,\% und 60\,\%) und für die Jugendlichen das wichtigste Informationsmedium\vgl{MPFS2011}{17}.
Wichtig ist, dass 2011 erstmals nicht mehr 100\,\% der Befragten das Internet (auch) an stationären Informatiksystemen nutzen\vgl{MPFS2011}{32~f.}. Vielmehr nutzen bereits 29\,\% dazu ihr Mobiltelefon, 7\,\% ihr Multimediaabspielgerät und 2\,\% ein Tablet. Vergleicht man diese Werte mit denen von 2008, wird unmittelbar deutlich, dass die Nutzung des Internets mittels mobiler Informatiksysteme gigantisch zugenommen hat. Allein bei den Mobiltelefonen ist eine Steigerung von 4\,\% auf 29\,\% festzustellen. Es zeigt sich also auch hier ein enormer Bedeutungsgewinn der mobilen Informatiksysteme.
Die Art der Internetnutzung zeigt noch einmal deutlich die Unterschiede zwischen männlichen und weiblichen Jugendlichen auf. Während sich die Mädchen das Internet hauptsächlich als Kommunikations- (50\,\%), Informations- und Unterhaltungsmedium nutzen, verwenden Jungen es sehr stark zum Spielen (28\,\%) und deutlich weniger als Mädchen zur Kommunikation (39\,\%)\vgl{MPFS2011}{33}.
\subsection{Neue Chancen, neue Gefahren}\label{secNeuChaGef}
Die ständig verfügbaren, einfachen und zugänglichen Möglichkeiten zur Kommunikation haben das Potential, kooperative, gesellschaftliche Tendenzen zu stärken und die notwendige Koordination innerhalb der Gesellschaft zu verbessern. Sie bergen jedoch auch Risiken und Gefahren, die entweder gänzlich neu sind oder durch die ständig verfügbaren Informatiksysteme in den Fokus gerückt werden.
Wie bereits im \referenz{secVerNutz} beschrieben, sind die mobilen Informatiksysteme zu einem festen Bestandteil des alltäglichen Lebens in modernen Gesellschaften geworden. Natürlich beeinflussen sie somit das gesellschaftliche Leben. Diese Veränderungen und deren Auswirkungen werden von Soziologen, Kommunikationswissenschaftlern und Psychologen unter den Schlagwörtern \enquote{Mediatisierung} und \enquote{Medialisierung} aus verschiedenen Perspektiven untersucht\footnote{Leider ist hierbei nicht immer deutlich, was mit \enquote{Medien} gemeint ist. Verschiedene Ansätze widersprechen sich hier deutlich. Mal sind Geräte gemeint, mal Informations-, Kommunikations- oder Massenmedien. Oft wird dies leider nicht explizit definiert.}. Hier wird also ein gesellschaftlich äußerst relevantes Thema berührt, das nicht nur aus Sicht der Informatik relevant ist, das aber zumindest ein informatisches Grundverständnis voraussetzt, um es in seiner gesamten Fülle erfassen zu können.
\subsubsection{Kommunikation und Koordination}
Die ständig verfügbaren Kommunikationsmöglichkeiten können die Kommunikation innerhalb der Gesellschaft fördern, wodurch viele Chancen eröffnet werden. So sind Absprachen und die Koordination von Tätigkeiten sehr viel einfacher und gezielter möglich als vor der Verfügbarkeit dieser Technologien, grundsätzlich sogar global und zwischen verschiedenen Gesellschaften. Die traditionellen Grenzen zwischen den Gesellschaften verschwimmen zum Teil. Potenziell kann dies also hilfreich sein, mehr und bessere Kooperation zwischen den Menschen zu erreichen.
Die ständige Erreichbarkeit kann jedoch auch zum Fluch werden und viel Stress erzeugen, besonders im beruflichen Alltag. Hier werden immer wieder Stimmen laut, die dies kritisieren:
\zitatblock[.]{Ständige Erreichbarkeit ist eine Arbeitsanforderung, der mittlerweile in allen Sektoren ein beträchtlicher Anteil der Beschäftigten unter-worfen ist [\dots] Beschäftigte, die unter der Arbeitsanforderung stehen, ständig erreichbar zu sein, sind auch von anderen Beanspruchungen und Belastungen [\dots] überdurchschnittlich stark betroffen [\dots] fällt es ihnen etwa auch deutlich schwerer, den Kopf von beruflichen Schwierigkeiten freizubekommen}{DGB2012}{11}
\subsubsection{Demokratie und Pluralismus}
Durch die besseren Kommunikations- und Kooperationsmöglichkeiten kann sich eine Stärkung demokratischer und pluralistischer Tendenzen ergeben, was zur Festigung oder Etablierung freiheitlicher Gesellschaften beitragen kann. Speziell in Verbindung mit dem \enquote{Arabischen Frühling} war immer wieder die Rede von Internet und mobilen Informatiksystemen.
Insbesondere Mobile Informatiksysteme können hier dabei helfen, Zensurmaßnahmen zu unterlaufen und ein Mindestmaß an Meinungsvielfalt sicherzustellen. Ein gutes Beispiel hierfür ist etwa das Commotion Wireless Project \citep{commotionWireless}, dessen Ziel es ist, mit mobilen Informatiksystemen unabhängige, dezentrale Peer-to-Peer-Kom\-mu\-ni\-ka\-ti\-ons\-netz\-werke zu etablieren.
\subsubsection{Cybermobbing, Zugang zu \enquote{jugendgefährdenden Medien}}
Cybermobbing und Zugang zu Gewaltdarstellungen und Pornographie werden oft als Argumente für Mobiltelefonverbote ins Feld geführt. Es ist auch sicherlich richtig, dass die ständige Verfügbarkeit der meist mit Kameras ausgestatteten Geräte sowie ihre Möglichkeiten zur schnellen Kommunikation Mobbing unterstützen kann. So konnte sich etwa das sogenannte \enquote{Happy Slapping} verbreiten. Jedoch ist dies grundsätzlich kein genuines Problem der mobilen Informatiksysteme. Außerdem ist nicht davon auszugehen, dass kein Mobbing mehr stattfindet, wenn die mobilen Geräte aus den Schulen verbannt werden. Sie gehören trotzdem zum Alltag der Schülerinnen und Schüler, sind dann aber jeglicher Einflussmöglichkeit durch die Schule entzogen, eine kritische Beschäftigung damit ist dann kaum mehr möglich.
Ähnlich verhält es sich mit dem Zugang zu \enquote{jugendgefährdenden Medien}. Diese können und werden auch ohne mobile Informatiksysteme genutzt werden. Außerdem erscheint es zweifelhaft, dass diese primär in der Schule konsumiert werden. Am ehesten ist hier noch von einer Verbreitung auszugehen. Diese könnte jedoch genauso gut in der Freizeit und über das Internet erfolgen, wenn mobile Informatiksysteme in der Schule verboten sind.
Es erscheint vielversprechender, auf die Entwicklung von Einsichts- und Reflexionsfähigkeit zu setzen statt auf Verbote, die ohnehin nur partiell wirken können (nämlich in den Schulen) und somit eher dafür sorgen, dass der Blick auf die möglichen Probleme nur verschleiert wird. Heming \citep[S.~14]{Heming2009} kam unter Bezugnahme auf eine Veröffentlichung des Landeskriminalamts Nordrhein-Westfalen bereits zu dem Schluss, dass es besser sei, auf einen verantwortungsvollen Umgang mit der Technik zu setzen.
\subsubsection{Internetkriminalität und Kostenfallen}\label{secNeuChaGefKost}
Ebenso wie beim Cybermobbing\footnote{Cybermobbing gehört nach einigen Definitionen selbst zur Internetkriminalität, wird hier jedoch als eigenständiges Phänomen gewertet.} werden unter dem Begriff der Internetkriminalität verschiedenste Straftaten subsumiert, die mithilfe des Internets verübt oder begünstigt werden. Bereits hier erkennt man, dass dies keine spezifisch auf mobile Informatiksysteme zutreffende Problematik ist. Diese könnten in dieser Hinsicht lediglich als begünstigende Werkzeuge angesehen werden, da sie den Internetzugriff allgegenwärtig werden lassen und weitere Daten zur Verfügung stellen, die besonders individualisierte, manipulative Strategien mit krimineller Absicht (kriminelles Social Engineering) unterstützen können.
Der Aspekt der Kostenfallen bekommt hierbei eine neue Dimension, da die mobilen Geräte diverse Möglichkeiten zur Abrechnung anbieten, die missbraucht werden können\footnote{Etwa Mobilfunkvertrag, Online-Banking- und Micropayment-Apps, \gls{NFC} oder Accounts diverser Content-Stores, wie Appstores, Video-, Musik- und E-Book-Angebote.}. Hinzu kommen die inzwischen breit in der öffentlichen Diskussion angekommenen klassischen Kostenfallen wie ungewollte Abonnements vorgeblich kostenloser Angebote. Einige der möglichen Fallstricke, vor allem die ausufernde Nutzung regulärer Telefonate und Textnachrichten (in der Regel via \gls{SMS}), haben jedoch aufgrund der Verbreitung von Flatrates und Prepaid-Verträgen sowie eines stärkeren Bewusstseins über die Problematik bei den Jugendlichen ihre Bedeutung verloren\footnote{Hierzu mehr im \referenz{secAktSit}}. Durch die Kostenobergrenze bei Prepaid-Zahlung, die die Mehrheit der Jugendlichen für den Zugang zum Mobilfunknetz nutzt (68\,\% laut \cite[S.~57]{MPFS2011}) und die ebenfalls für einige Appstores angeboten werden, sinkt das Risiko gegenüber Abofallen oder dem übermäßigen Kauf von Zusatzmaterial, wie Apps, Klingeltönen oder Logos.
\subsubsection{Datensicherheit und Datenschutz} \label{secGefDat}
Angesichts des grundsätzlich vorhandenen Problembewusstsein und der Reaktionen auf medial begleitete Datenpannen ist derzeit davon auszugehen, dass Datenschutz durchaus für die meisten Menschen nicht unwichtig ist.
\paragraph{Datenhalden}
Die starke persönliche Bindung der Geräte macht sie zusammen mit der großen Anzahl der Nutzungsmöglichkeiten zu wahren Sammelstätten \textit{persönlicher Daten}: E-Mails, SMS-Nachrichten, Chat-Protokolle, Adressbuch\-einträge, Termine, gespeicherte Passwörter, evtl. sogar Kontodaten bzw. Kreditkartennummern und natürlich dank Satellitennavigation auch die aktuelle Position sowie vieles mehr finden sich auf den Geräten.
Die offensichtlichste Gefahr für die Daten auf mobilen Informatiksystemen ist natürlich der Verlust des Gerätes. Hier besteht also grundsätzlich die Notwendigkeit von Backups. Aber auch Diebstahl der Geräte oder der Daten von den Geräten sind möglich. Die Gefahr ist also hoch, dass diese Daten in falsche Hände geraten. Der kurzfristige Zugriff auf das Gerät kann ausreichen, um an die Daten zu gelangen, wenn kein Zugriffsschutz\footnote{Der Zugriffsschutz lässt sich je nach System einfach umgehen, entsprechende Anleitungen sind im Internet leicht zu finden.} aktiviert wurde. Dann ist außerdem die Aktivierung von Ortungsdiensten möglich. Die \gls{PIN} des \gls{SIM}, die früher auch zum Sperren der mobilen Geräte verwendet wurde, bietet keinen universellen Schutz, denn diese kann nur die wenigen Daten auf der SIM-Karte schützen\footnote{Manche Betriebssysteme speichern die PIN sogar standardwidrig im unzureichend geschützten Speicher des Telefons \citep[11~f.]{Heider} und erlauben damit den Zugriff auf die SIM-Karte, die dann wiederum für kostenpflichtige Anrufe genutzt werden könnte.}. Der Schutz der Daten im Speicher des Telefons obliegt allein dem Betriebssystem. Die Daten auf etwaig verwendeten Speicherkarten sind hierbei in der Regel überhaupt nicht geschützt.
Die Verschlüsselung von Daten ist auf allen Systemen grundsätzlich möglich, mal mehr mal weniger umfangreich. Dennoch wird davon aktuell nur selten Gebrauch gemacht\footnote{Es war dem Autor trotz intensiver Suche nicht möglich, innerhalb des letzten Jahres auch nur einen Benutzer oder eine Benutzerin ohne direkten Bezug zur Informatik zu finden, der oder die Daten auf ihrem mobilen Gerät verschlüsseln.}. Dies mag an mangelndem Problembewusstsein genauso liegen, wie an mangelnder Aufgeklärtheit über die technischen Möglichkeiten. Auch Backups scheinen nur Wenige regelmäßig zu machen.
\paragraph{Malware}\label{parGefDatMal}
Die Möglichkeit, einfach Software nachzuinstallieren, macht die Geräte auch für Malware-Entwickler attraktiv. Inzwischen sind diverse Malware-Varianten für mobile Informatiksysteme bekannt. Besonders Daten sammelnde (Spyware) und Kosten erzeugende (bspw. per SMS-Versand) Malware sowie Phishing sind hier von Bedeutung. Insbesondere Adress- und Zahlungsdaten sind für die Malware-Entwickler interessant.
Dabei gelangen Spyware und Phishing-Apps durchaus in die offiziellen Appstores. Denn diese greifen häufig nur auf die regulären \glspl{API} und lassen sich daher nur schwer durch automatisierte Tests identifizieren. Zudem bedient sich auch ganz reguläre Software gerne an den Daten der Benutzerinnen und Benutzer der mobilen Informatiksysteme. So ist es üblich, dass kostenlose Software Werbenetzwerke verwendet, die die einmaligen Eigenschaften der mobilen Geräte ausnutzt. Hier stehen mit der eindeutigen Gerätekennung (etwa Apples \gls{UDID}), dem \gls{IMEI} bzw. dem \gls{MEID} und der Telefonnummer zumindest drei eindeutige Identifikationsmerkmale zur Verfügung. Durch weitere Einrichtungsdaten können Anwendungen teilweise auch auf den Namen des Besitzers und evtl. eingerichtete E-Mail-Adressen zugreifen. Bei klassischen, stationären Informatiksystemen besteht durch die große Softwarevielfalt und fehlende \glspl{API} in der Regel kein Zugriff auf derart eindeutige Identifikationsmerkmale. Diese eindeutige Identifikation ermöglicht es den Werbenetzwerken, sehr detaillierte Daten über die Nutzung der Geräte zu erstellen, etwa wann und wie lange, welche Apps, wo, von wem genutzt wurden. Der Zugriff auf die GPS-Empfänger, Kalenderdaten und Adressbücher vervollständigt das Gesamtbild.
Selbst für weit verbreitete, populäre Apps trifft dies zu. Zumindest die eindeutige Identifikation wird von sehr vielen (fast allen werbefinanzierten) Apps genutzt. Doch auch weitergehende Eingriffe in die Benutzerdaten finden regelmäßig statt. Für Benutzerinnen und Benutzer ist es, selbst bei Systemen, die wie etwa Android die Berechtigungen von Apps bestätigen lassen, schwierig bis unmöglich, sicher zu sein, was mit den Daten passiert. Denn selbst ein Datenzugriff, der auf den ersten Blick berechtigt wirkt, kann durchaus zu unkontrollierbaren Ergebnissen führen. Die Stiftung Warentest wertete 28 von 63 getesteten (und durchaus weit verbreiteten) Apps als potentiell problematisch, neun sogar als \enquote{sehr kritisch} \citep{testApps}. So stand die beliebte Kommunikationsapp \enquote{WhatsApp} in der Kritik, weil sie zwar berechtigt auf das Adressbuch des mobilen Geräts zugriff, dieses dann aber komplett auf die eigenen Server hochlud. Die App des sozialen Netzwerks Facebook gehört zu den als \enquote{sehr kritisch} bewerteten Apps. Sie ging sogar zuletzt noch weiter und änderte kurzerhand sämtliche E-Mail-Adressen im Adressbuch derart, dass Nachrichten an diese über Facebook umgeleitet wurden\vgln{heiseFacebookMail}. Dies wurde allerdings nach Entdeckung als Fehlfunktion bezeichnet und geändert. Falls dies zutreffen sollte, sind Veränderungen an den Adressbüchern der Benutzerinnen und Benutzer ohne deren vorherige Zustimmung doch zumindest fragwürdig.
\paragraph{Problembewusstsein und Schutzmöglichkeiten}
Inwieweit ein Schutz vor diesen Praktiken möglich ist, hängt von der jeweiligen Plattform und vom konkreten Gerät ab. Es zeigt sich jedoch, dass es bei den Benutzerinnen und Benutzern kaum eine Sensibilität für dieses Thema gibt. Das verwundert allerdings nicht unbedingt, da vieles davon im Verborgenen geschieht und in der Regel nicht bemerkt wird bzw. mit reinem Anwendungswissen ohne Kenntnis informatischer Hintergründe nicht bemerkt werden kann. Besonders bei Jugendlichen überwiegt zudem die Sorglosigkeit in Verbindung mit dem Wunsch (bzw. dem sozialen Druck\vgl{MPFS2011}{51}) eine bestimmte App oder einen bestimmten Dienst zu nutzen. Es ist für die Jugendlichen meist keine Option, eine bestimmte Anwendung oder einen Dienst nicht zu nutzen, wenn die Altersgenossen dies tun. Hier ist eine weitere Sensibilisierung dringend erforderlich, obwohl die Jugendlichen -- zumindest was die bewusste Preisgabe von Daten angeht -- vorsichtiger geworden sind:
\zitatblock[.]{Beim Einstellen persönlicher Angaben sind die Jugendlichen aber zurückhaltender geworden: Gegenüber den JIM-Studien der Jahre 2009 und 2010 ist der Anteil derjenigen, die ihre Daten online posten, insgesamt betrachtet eher rückläufig. [\dots] Dass Jugendliche im Umgang mit ihren Daten sensibler geworden sind, belegt auch die Verwendung von Sicherheitseinstellungen. Mit 79 Prozent ist der Anteil derer, die ihr Profil mit einer Privacy-Option vor dem Einblick Fremder geschützt haben, gegenüber 2010 (67\,\%) nochmals deutlich gestiegen. Mädchen und junge Frauen agieren hier merklich vorsichtiger (85\,\%) als Jungen und junge Männer (72\,\%)
}{MPFS2011}{50~f.}
\subsubsection{Sichere Kommunikation}\label{secGefKomm}
In einem mit dem Datenschutz verwandten Bereich ist dringend weitere Aufklärung vonnöten. Während die mobilen Informatiksysteme heute beste Voraussetzungen zu sicherer Kommunikation\footnote{Etwa Verschlüsselung von E-Mails und Textnachrichten, verschlüsselte (Video-)Telefonie und VPN-Verbindungen.} bieten, wird die meiste darüber abgewickelte Kommunikation nur unzureichend oder gar nicht abgesichert. Bestenfalls wird von Chat-Apps oder Mailprogrammen auf eine mittels SSL bzw. TLS verschlüsselte Verbindung zum Server gesetzt. Doch selbst das ist längst kein Standard. Auf der anderen Seite wächst das Bedrohungspotential. So gibt es inzwischen diverse fertige Apps\footnote{Bekannte Beispiele sind der WhatsAppSniffer und DroidSheep.}, die per Touch ohne weiteres Hintergrundwissen die Möglichkeit bieten, Nachrichten aus demselben Netz aufzufangen und mitzulesen oder Sitzungen von Apps und Webseiten zu übernehmen, sodass danach etwa auf fremde Profile in Sozialen Netzwerken zugegriffen werden kann. Besonders in WLAN-Hotspots, die -- auch aus Kostengründen -- immer beliebter werden, ist die Gefahr damit erhöht, da bei unverschlüsselten Verbindungen alle Hotspotnutzer/-innen Zugriff auf die Daten der anderen erhalten können.
\subsection[Durchblicken statt rumklicken?]{\enquote{Durchblicken statt rumklicken}\footnote{So lautet der Untertitel der Vorlesung \enquote{Informatik im Alltag} an der Bergischen Universität Wuppertal. Er zeigt sehr schön die Differenz zwischen informatischem Anspruch und Computer-Wirklichkeit.}?}\label{secDurchblick}
Um am sozialen Leben in der modernen Gesellschaft teilhaben zu können, ist es, aufgrund der Durchdringung der Gesellschaft mit Informatik, unabdinglich, ein Mindestmaß an technischen Fertigkeiten im Umgang mit Informatiksystemen zu besitzen. Das Angebot an Internetseiten, Schritt-für-Schritt-Anleitungen, Lernsoftware, Kursen und Schulungsmaßnahmen -- mit oder ohne entsprechende Zertifikate -- sowie vieler, vieler Bücher dazu ist inzwischen riesig. Doch leider handelt es sich in fast allen Fällen um reine Anwendungsanleitungen. Fast nie stehen grundlegende Prinzipien im Vordergrund. Somit ergibt sich zwar ein selbsterhaltender Markt, denn bei jeder neuen Programmversion wird im Zweifelsfall ein neuer Lehrgang fällig, doch leider keine vernunftgeleitete Auseinandersetzung mit den wesentlichen \textit{informatischen} Grundlagen. Dies gilt leider zum Teil auch für den Informatikunterricht, der damit zum Computerunterricht degradiert wird. Doch schon um beim Umgang mit Informatiksystemen selbstbestimmt und frei handeln und erst recht um aktiv und \textit{konstruktiv gestaltend} an der Gesellschaft mitwirken zu können, reichen technische Fertigkeiten nicht aus. Es ist vielmehr notwendig, \textit{informatische Vernunft} zu entwickeln, die ein Verständnis der zugrunde liegenden informatischen Prinzipien bedingt:
\zitatblock[.]{Informatische Vernunft will nicht nur instrumentelle Kenntnis sein, Informatische Vernunft will in dem epochaltypischen Schlüsselbereich der
\zitat{neuen technischen Steuerungs-, Informations- und Kommunikationsmedien}{Klafki1991a}{59} den philosophischen Anspruch der Aufklärung wach
halten}{GoerlichHumbert2005}{311}
Wie sollte aber der Aufklärungsanspruch durch reines Auswendiglernen von Bedienungsmustern erfüllt werden können? Dies ist schlicht nicht vorstellbar. Und wo, wenn nicht im Informatikunterricht, könnte dieser wichtige Beitrag zur Entwicklung der \SuS erbracht werden?
\section{\dots außer in der Schule?}\label{secAktSit}
Doch leider scheinen die gesellschaftlichen Entwicklungen auf den ersten Blick spurlos an der Schule vorbeizugehen. Nun ist es natürlich nicht die Aufgabe der Schule, kurzfristigen Modetrends hinterherzulaufen. Doch wie bereits ausführlich dargestellt wurde, bildet die technologische Entwicklung\vglr{secInfOmni} die Grundlage für gesellschaftliche Veränderungen\vglr{secVerNutz}, die das alltägliche Leben in der modernen Gesellschaft prägen und die aller Voraussicht nach weiterhin einschneidende Auswirkungen\vglr{secNeuChaGef} darauf haben werden.
Da eine der wichtigsten Aufgaben der Schule die Vorbereitung auf das mündige, selbstbestimmte Leben in der Gesellschaft ist, greifen simple Verbote zu kurz. Zumal die Geräte allen Verboten zum Trotz ihren festen Platz im Alltag der Schülerinnen und Schüler\vglr{secVerNutzJu} kaum verlieren werden. Diese Ansicht setzt sich immer mehr durch. Zuletzt hat ein Positionspapier des Netzrates der CSU für hohe mediale Aufmerksamkeit gesorgt:
\zitatblock{Dass ein Verbot von Smartphones und ähnlichen Geräten auf dem Schulgelände als abzuschaffender Anachronismus zu betrachten ist, verstehen wir als Selbstverständlichkeit.}{CSUNetzrat}{11}
Unabhängig von der Verbotsproblematik und der tatsächlichen Nutzung mobiler Informatiksysteme in der Schule scheint der Unterricht nicht mit den gesellschaftlichen Veränderungen mithalten zu können. Hier dominieren in Schulen noch immer die stationären Informatiksysteme in Form großer grauer oder schwarzer Kisten und die seit Jahren bekannte Gestaltung der Computerräume. In der Didaktik der Informatik wird immer wieder diskutiert, dass dies den Blick auf die Informatik verbaut und bei den \SuSn die Fehlvorstellung begünstigt wird, Informatik sei ausschließlich Programmierung und Bedienung von Informatiksystemen.
Die Fachdidaktik versucht auf vielen verschiedenen Wegen, mit diesem Problem umzugehen. So wird etwa versucht, Informatik ohne Informatiksysteme zu betreiben \footnote{vgl. etwa \enquote{Computer Science Unplugged} \citep{Bell2006} oder \enquote{SpionCamp} \citep{SpionCamp}}. Dies sind fraglos vielversprechende Ansätze, um den Fokus auf die informatischen Prinzipien und Sachverhalte zu lenken. Allerdings haben Informatiksysteme ihren festen Platz im Informatikunterricht. Ein vollständiger Verzicht auf sie wäre nicht sinnvoll, werden sie doch in den meisten Fällen für den entscheidenden Schritt benötigt, der die informatische Modellierung von der Modellierung in anderen Fächern unterscheidet: die tatsächliche Implementierung und damit die Rückwirkung auf die Welt.
Hier gibt es Ansätze, andere Informatiksysteme zu verwenden, etwa Roboter. Doch führt dies in der Regel nicht dazu, dass auf die klassischen stationären oder transportablen Informatiksysteme verzichtet werden könnte. Sie werden nach wie vor für die Programmierung benötigt. Somit besteht weiterhin eine große Abhängigkeit von der schulischen Informatikinfrastruktur. Das eigentliche Problem wird damit nicht gelöst, bestenfalls wird der Blickwinkel ein wenig erweitert.
Die eigentlich logische Konsequenz, nämlich die bei Kindern und Jugendlichen am weitesten verbreiteten und bedeutendsten Informatiksysteme für den Unterricht nutzbar zu machen, wird bisher nur selten aufgegriffen. Bei verschiedenen Vorträgen des Autors und Diskussionen mit Lehrkräften ergab sich allerdings, dass durchaus großes Interesse an einer Nutzung mobiler Informatiksysteme im Unterricht besteht. Die Sorgen, dass dies nicht sinnvoll umsetzbar sei und einen viel zu erheblichen Aufwand erfordere, sind allerdings groß. Zudem wird der mögliche Einsatz in der Regel auf den Teilbereich des \enquote{mobilen Programmierens} beschränkt. Dies stellt jedoch nur einen Teilbereich dar.
% Der Frage nach den Perspektiven für den schulischen Einsatz der mobilen Informatiksysteme wird im folgenden Kapitel nachgegangen.

View file

@ -0,0 +1,135 @@
\chapter{Nutzungsperspektiven für den Einsatz in der Schule}\label{chpPerspektiven}
\section{Mobile Informatiksysteme und Schule -- bisherige Ansätze}
\subsection{Pädagogische Ansätze}\label{secAnsPad}
Es gibt inzwischen einige Veröffentlichungen, die den Einsatz von mobilen Informatiksystemen (insbesondere iPads und iPhones\footnote{Siehe hierzu den Exkurs zur Nichteignung von Konsumgeräten für den Unterrichtseinsatz im Anhang dieser Arbeit (\referenz{secKonsum})}) in der Schule aus dem einen oder anderen Blickwinkel thematisieren. Fast allen ist jedoch eine Ausrichtung auf E-Learning-Apps und die Nutzung als multimediales Werkzeug für Präsentation und Recherche gemein. Auch diverse Ratgeber von Lehrkräften sind im Internet zu finden. Meist handelt es sich um Listen von für den Unterricht geeignet befundenen Apps und dazu passenden Schritt-für-Schritt-Anleitungen.
Eine weitere wesentliche Beschäftigung mit dem Thema findet im Rahmen von Informationsmaterial für Eltern statt. Hier herrschen ebenso Schritt-für-Schritt-An\-lei\-tun\-gen vor. Technische Hintergründe fehlen in der Regel oder werden sogar fehlerhaft dargestellt. Man kann sich hier des Verdachtes nicht erwehren, dass die Zielsetzung der Broschüren weniger das Verständnis der \enquote{Neuen Medien} bzw. \enquote{Neuen Technologien} ist, zu denen etwa Mobiltelefone und das Internet gerne zusammengefasst werden. Vielmehr scheint es um ein reines \enquote{irgendwie damit klarkommen} zu gehen. Teilweise scheint dies daran zu liegen, dass die Autoren und Autorinnen selbst nicht über die nötigen informatischen Hintergrundkenntnisse verfügen.
So entstehen teilweise recht seltsame Ergebnisse\footnote{Neben eindeutigen Fehlern finden sich in den Broschüren einige fast naiv anmutende Stilblüten, etwa: \zitat{Den Internetzugang zu deaktivieren ist für jüngere Kinder empfehlenswert, da sonst das ganze Internet zur Verfügung steht.}{HandyOhneRisiko}{28}}. Es werden etwa in der Broschüre \enquote{Handy ohne Risiko} des \gls{BMFSFJ} viele wichtige Aspekte der Nutzung mobiler Informatiksysteme angesprochen und direkt im Vorwort der Ministerin wird ein weitsichtiges Ziel gesetzt, auf das in der Broschüre mehrfach hingewiesen wird:
\zitatblock[.]{Erfolgreiche Medienerziehung setzt deshalb langfristig auf Kompetenz statt Kontrolle im Vertrauen darauf, dass niemand Jugendliche wirksamer vor den Gefahren der virtuellen Welt schützen kann als sie sich selbst}{HandyOhneRisiko}{3}
Der Rest der Broschüre hat dann jedoch einen starken Hang zur durchgehenden Kontrolle der Kinder. So werden einige Horrorszenarien aufgebaut, wie etwa das, dass potentielle \enquote{Belästiger} die Geräte für sich nutzen können. Auch ein Abschnitt über Killerspiele gehört -- wie es wohl inzwischen bei allen Berichten über Informatiksysteme im Zusammenhang mit Jugendlichen zum guten Ton gehört -- dazu. Ob, von wem und in welchem Umfang diese tatsächlich genutzt werden, wird anders als in der \gls{JIM} nicht gefragt.
Vielfältige Sperrmöglichkeiten, wie etwa fragwürdige Netzfilter\footnote{So wird etwa ein Mobilfunkvertrag für Kinder gelobt. Dieser wird von einem Joint-Venture von Bertelsmann und Disney angeboten und erlaubt ausschließlich den Zugriff auf Seiten und Dienste dieser Konzerne. Die Bewertung, inwiefern ein solches Angebot mit Demokratie, Pluralismus und dem Ziel der mündigen Gesellschaftsangehörigkeit, aber auch mit wirtschaftspolitischen Aspekten (Monopolbildung, Ausschluss von Mitbewerbern) vereinbar ist, soll hier nicht weiter diskutiert werden.} und Kindersicherungen werden in aller Breite dargestellt, während andere Alternativen, die einer vernunftgeleiteten Nutzung eher zuträglich wären, fast verschämt am Rande abgehandelt oder gar nicht erwähnt werden. Auch Ortungsdienste, die Eltern nutzen können, werden ausführlich berücksichtigt. Der Möglichkeit, dass diese Dienste von \enquote{Belästigern} missbraucht werden können, wird sehr viel Platz eingeräumt\vgl{HandyOhneRisiko}{20}. Dass dies nur möglich ist, wenn die Dienste überhaupt genutzt -- also in der Regel durch die Eltern aktiviert -- werden, wird nicht für erwähnenswert gehalten. Die möglichen Auswirkungen auf das selbst gesetzte Ziel des mündigen Umgangs mit den Geräten und das Vertrauensverhältnis zwischen Kindern und Eltern werden in eher unauffälliger Weise mit einem Satz in einem Kasten am Rand des Textes erwähnt.
Dass ein großer Teil der Broschüre als Werbebroschüre der jeweiligen Mobilfunkanbieter dienen könnte (großformatige Logos und Produktvorstellungen) sowie sämtliche der zahlreich verwendeten Screenshots von Apples iPhone stammen, ist hier nur ein kleiner, unschöner Nebenaspekt.
Es gibt allerdings einige positivere Beispiele für derartige Broschüren, etwa das Handy-ABC der \gls{LJS} \citep{LJS2010}, das sich in Form eines neutral gehaltenen Mini-Lexikons durchaus für einen Überblick über die Thematik eignet. Hier fehlen zwar auch weitgehend Hinweise auf die notwendigen informatischen Grundlagen, dies ist bei dieser Broschüre jedoch weit besser verschmerzbar als bei den Veröffentlichungen, die sich als umfassende Ratgeber ausweisen wollen.
In den einschlägigen pädagogischen Veröffentlichungen finden sich meist Ansammlungen möglicher Nutzungsszenarien sowie Vorstellungen bestimmter Software oder Dienste und penible Nutzungsanleitungen\vgln{HandyHerausforderung}. Die Nutzungsszenarien wirken allerdings teilweise recht konstruiert und gezwungen. Es wird offenbar versucht, um jeden Preis das Mobiltelefon in den Unterricht zu bringen. Dies ist nicht nur aus didaktischer Sicht fragwürdig. Allerdings heben sich hier einige Beiträge positiv hervor, in denen zumindest die Sinn-Frage gestellt und erkannt wird, dass hier ein Mehrwert für die \SuS erkennbar sein muss. Demgegenüber stehen Beschäftigungen mit gesellschaftlichen Auswirkungen, die wiederum fast ausschließlich auf die möglichen Gefahren gerichtet sind.
Wenn dies nicht der Fall ist, findet man meist eine übertrieben wirkende Begeisterung. Die Einführung der Geräte in den Unterricht erfolgt dann eher als Produktschulung bzw. entfällt ganz, da davon ausgegangen wird, dass die Schülerinnen und Schüler, die täglich mit den Geräten umgehen, ohnehin alles Relevante darüber wissen. Die informatischen Grundlagen, die notwendig wären, um die Funktionsweise der Geräte beurteilen und den Umgang damit kritisch reflektieren zu können, werden in der Regel vollständig ausgeblendet.
In Schulen werden zudem nach Erfahrung des Autors weiterhin \enquote{bewährte}\footnote{Um nicht zu sagen \enquote{verjährte}\dots} Materialien eingesetzt, die inzwischen nicht mehr ganz aktuell sind. Diese greifen etwa Probleme auf, die so nicht mehr existieren\vglr{secNeuChaGefKost}. Außerdem beziehen sie sich häufig auf Geräte und Anwendungsfälle, die längst nichts mehr mit dem Alltag der \SuS gemein haben. Hierbei handelt es sich natürlich um ein grundsätzliches Problem, wenn man sich statt auf grundlegende Prinzipien auf bestimmte Hard- oder Software bezieht. Die beobachtbaren Konsequenzen sind weitreichend: Die Lehrkraft wird von den \SuS als unmodern und uninformiert wahrgenommen, woraufhin sie nicht mehr richtig ernst genommen wird und weitere, wichtigere Äußerungen überhaupt nicht mehr aufgenommen werden.
Weder die durchaus positiven Nutzungsaspekte noch die notwendige Diskussion über mögliche Gefahren sollen durch diese Kritik kleingeredet werden. Sie werden in den folgenden Abschnitten dieses Kapitels auch noch thematisiert. Der Autor ist allerdings der Überzeugung, dass die Grundlage für den sinnvollen Einsatz von (nicht nur mobilen) Informatiksystemen in der Schule und damit eine wesentliche Vorbereitung auf das mündige, selbstbestimmte Leben in der modernen Gesellschaft, nur ein verpflichtender und hochwertiger Informatikunterricht sein kann. Denn nur hier kann die notwendige informatische Allgemeinbildung erreicht werden. Reine Nutzungskompetenzen sind zur Erreichung des Bildungsziels der mündigen Gesellschaftsangehörigen nicht hinreichend.
\subsection{Bisherige Ansätze der Fachdidaktik Informatik}
Dass es durchaus anders geht, zeigt der fachdidaktische Diskurs zum Einsatz der mobilen Informatiksysteme in der Schule. Besonders hervorzuheben sind hier die Arbeiten von Ralph Carrie und Matthias Heming sowie die Beiträge von Ludger Humbert und die an der Willy-Brandt-Gesamtschule in Bergkamen durchgeführten Pilotkurse. Die in diesem Zusammenhang entstandenen Arbeiten, Veröffentlichungen und Materialien bilden den Hauptzweig des aktuellen fachdidaktischen Diskurses.
Carrie hat in seiner Hausarbeit zum zweiten Staatsexamen zunächst gezeigt \citep{Carrie2006}, dass die Nutzung mobiler Informatiksysteme grundsätzlich im Rahmen des Informatikunterrichts möglich ist. Er unterschied zwischen der \textit{Pro\-gram\-mie\-rung auf den Geräten} und der \textit{Pro\-gram\-mie\-rung für die Geräte}\vglr{secPers}. Dank der Verfügbarkeit von Python für Symbian S60 konnte er die Vorarbeit von Ingo Linkweiler \citep{LinkweilerDA2002} aufgreifen, der die Klassenbibliothek \gls{SuM} nach Python übertragen hatte. Carrie konnte diese für die Nutzung auf Smartphones mit Symbian S60 anpassen. Damit konnte er zeigen, dass der Einsatz von mobilen Informatiksystemen nicht nur möglich ist, sondern mittels der \textit{Pro\-gram\-mie\-rung auf den Geräten} sogar die Nutzung klassischer, stationärer Informatiksysteme überflüssig machen könnte.
Matthias Heming setzte hier an und begleitete zunächst forschend die Pilotkurse an der Willy-Brandt-Gesamtschule in Bergkamen \citep{HemingINFOS2009} und erweiterte das mobile \gls{SuM} um ein Modul für den objektorientierten Zugang zu Vektorgrafiken (PyObjVG). In seiner Masterarbeit \citep{Heming2009} wies er dann überzeugend nach, dass die Umsetzung eines Informatikunterrichts ausschließlich mit mobilen Informatiksystemen nicht nur möglich, sondern auch mit den Lehrplänen und Abiturvorgaben in Nordrhein-Westfalen sowie den Bildungsstandards der \gls{GI} \citep{GI2008} konform ist. Zusätzlich stellte er ein Unterrichtskonzept samt Materialien für die Umsetzung vor.
Daneben gab es noch anderenorts weitere Veröffentlichungen, etwa die Examensarbeit von Nadine Pickert \citep{Pickert2006}. Diese hatten jedoch keine tieferen Auswirkungen auf den Diskurs und blieben eher wenig beachtet, sei es wegen offener didaktischer Fragen oder aufgrund einer anderen Ausrichtung. So ist die Arbeit von Pickert sehr stark auf die im Folgenden erläuterte\vglr{secPersFor} Programmierung für die Geräte ausgerichtet und berücksichtigt damit die Potentiale des Unterrichtseinsatzes mobiler Informatiksysteme fast gar nicht.
Die bisherigen Konzepte erlitten allerdings einen herben Rückschlag, als der angeschlagene Mobilfunkkonzern Nokia im Februar 2011 bekannt gab, zukünftig keine weiteren Symbian-Geräte mehr anzubieten und die Entwicklung einzustellen. Alle weiteren Hersteller hatten sich schon zuvor von Symbian ab- und dem aufstrebenden Android oder Windows Mobile zugewandt. Gleichzeitig kündigte Nokia den Rückzug aus der Weiterentwicklung der möglichen Alternative MeeGo an. Damit stand erst einmal keine zukunftsfähige Basis mehr für den Einsatz in der Schule zur Verfügung. Es war also ein Zustand eingetreten, mit dem noch zum Zeitpunkt der Arbeit von Heming nicht zu rechnen war, weil Symbian damals trotz Verlusten noch das bedeutendste Smartphone-Betriebssystem war.
\section{Vorteile und Hoffungen für den Informatikunterricht}\label{secVort}
\subsection{Motivation}\label{secVortMot}
Es besteht die Hoffnung, dass über die direkte Anbindung an den Alltag der \SuS und evtl. sogar die Nutzung der eigenen Geräte der \SuS eine höhere Motivation erreicht werden kann. Dies scheint nach den bisherigen Erkenntnissen zuzutreffen. Bisher lässt sich aber aufgrund der geringen Anzahl von Kursen nicht sicher sagen, ob es sich hier nicht nur um den \enquote{Reiz des Neuen} handelt. Dies wäre zumindest vorstellbar\vgl{HemingINFOS2009}{10}. Außerdem muss man sich darüber im Klaren sein,
\zitatblock{dass der Austausch des Informatiksystems alleine keine positiven Konsequenzen mit sich bringt, es ist weiterhin notwendig, auf die eventuell veränderten Bedürfnisse der Schülerinnen und Schüler einzugehen, um die hohe Motivation zu erzeugen bzw. zu erhalten.}{HemingINFOS2009}{11}
Dies ist natürlich am ehesten dann zu erwarten, wenn für die \SuS ein klarer Mehrwert zu erkennen ist, sie also etwa nach dem Unterricht etwas mit ihren Geräten erreichen können, was vorher nicht möglich war. Dies sollte durch die Programmierbarkeit der Geräte möglich sein, sofern die besonderen Eigenschaften der Geräte tatsächlich genutzt werden.
\subsection{Kosten}
Seit den Arbeiten von Carrie und Heming sind die Preise für mobile Informatiksysteme drastisch gesunken. Einfache Einstiegsgeräte auf Basis von Android sind inzwischen dauerhaft zu Preisen zwischen 69\,\euro\ (Smartphone) und 99\,\euro\ (Tablet) verfügbar. Die Ausstattung dieser Geräte genügt meist den Anforderungen des Informatikunterrichts\vglr{chpAuswahl}. Damit hat sich der damals schon vorhandene Preisvorteil gegenüber stationären Informatiksystemen vervielfacht. Der Nachteil der personengebundenen Nutzung der Geräte bleibt zwar bestehen, wird so aber weniger relevant. Sollte die Nutzung der persönlichen Geräte der \SuS möglich sein, sänken hier die Kosten sogar auf Null oder würden, bei gleichzeitiger Nutzung schuleigener Geräte, zumindest deutlich reduziert.
\subsection{Wartung}
Da die Geräte der Verantwortung der Schüler unterliegen (oder übergeben werden), könnte die Notwendigkeit der Wartung schulischer Infrastruktur weitgehend entfallen. \SuS \zitat[.]{übernehmen ebenfalls die Rolle eines Sys\-tem\-ad\-mi\-nis\-tra\-tors, sie tragen die Verantwortung dafür, dass ihre Informatiksysteme für den Informatikunterricht vorbereitet sind}{Heming2009}{20} Dies ergäbe die Chance, angesichts der immer noch viel zu wenigen ausgebildeten Informatiklehrkräfte, diese von unterrichtsfernen Wartungsarbeiten zu entbinden und ihre Kraft und Arbeitszeit ihrer eigentlichen Aufgabe zukommen zu lassen.
\subsection{Flexibilisierung des Unterrichts}
Die Bindung an die Computerräume kann nicht nur den Blick auf die Informatik verstellen, sie steht auch dem Einsatz viel versprechender, aber vom \enquote{üblichen} Informatikunterricht abweichenden, Unterrichtsmethoden im Weg. Die Bedeutung mobiler Informatiksysteme nimmt stetig zu, \zitat[.]{da ist es anachronistisch, wenn weiterhin ein Fachraumkonzept für den Informatikunterricht vertreten wird}{HumbertMWS2008}{84} Die baulichen Beschränkungen weisen den möglichen Unterricht in die Schranken. Üblicherweise wird der Informatikunterricht so sehr programmierlastig. Die Lernatmosphäre wird zudem dadurch eingeschränkt, dass oft nicht genug Informatiksysteme zur Verfügung stehen und die Kommunikation der \SuS untereinander und mit dem Lehrer durch die vorhandene Raumplanung eingeschränkt wird.
\zitatblock[.]{Für den Wechsel zwischen Unterrichtsphasen mit und ohne Informatiksystem müsste im Unterricht mit PCs sinnvollerweise ein zweiter Raum oder ein Raumteil mit Arbeitsplätzen ohne PCs zur Verfügung stehen. Allerdings kann wegen der damit verbundenen Unruhe und des Zeitaufwandes ein solcher Arbeitsplatzwechsel nur selten und für die gesamte Arbeitsgruppe gleichzeitig stattfinden. Die Bestimmungsmöglichkeit der eigenen Arbeitsphasen durch die Schülerinnen und Schüler ist reduziert}{Mueller2011}{171}
Mobile Informatiksysteme lassen sich hingegen flexibel einsetzen. Sowohl in normalen Kursräumen als auch an anderen Lernorten. Die Einteilung der Arbeitsphasen in solche mit und ohne Informatiksysteme ist fließend möglich. Dies eröffnet viele neue Möglichkeiten für eine flexible Unterrichtsgestaltung. Den Lehrkräften wird dabei eine Methodenvielfalt (zurück-)\allowbreak{}gegeben, die für den Informatikunterricht bisher nicht erschlossen werden konnte.
\subsection{Außerunterrichtliche Nutzung}
Natürlich ermöglichen die Mobilität der Geräte und die alltägliche Verfügbarkeit im Gegensatz zu schulischen Computerräumen die direkte Anwendung des Gelernten außerhalb der Schule, sei es zu Hause oder unterwegs. Wenn sich damit noch ein echter Vorteil gegenüber der üblichen Nutzung der Geräte erreichen lässt, ist es durchaus nicht unrealistisch, dass man neben Schülerinnen und Schülern, die im Bus mit dem Mobiltelefon spielen auch solche antreffen wird, die dabei sind, ihr mobiles Informatiksystem zum Programmieren zu verwenden. Damit wird also nicht nur der Informatikunterricht an den Alltag der \SuS angebunden, sondern beeinflusst und bereichert diesen im Gegenzug direkt wieder.
\subsection{Informatik und Gender}
Nicht zuletzt wird mit dem Einsatz der mobilen Informatiksysteme die Hoffnung verbunden, die Genderproblematik von einer neuen Seite angehen zu können. Legt man die Ergebnisse der \gls{KIM} und der \gls{JIM} zugrunde\vglr{parVerNutzJuNu}, so zeigt sich, dass die Nutzung klassischer Informatiksysteme und ein auf technische Fertigkeiten ausgerichteter Unterricht den Jungen entgegenkommt\vgl{HumbertMWS2008}{87~f.}. Zusätzlich muss man die häufig anzutreffende Ausrichtung des Unterrichts an Spielen oder spieleähnlichen Anwendungen als Aufhänger überdenken. Denn auch hier bedient man eher den Geschmack der Jungen.
Mobile Informatiksysteme bieten hier als einzige Systeme eine ausgeglichenere Verteilung bei der Nutzung. Ihre Ausrichtung auf Kommunikation und Information kann sogar eher einen Vorteil für Mädchen bedeuten. Es ist somit nicht unwahrscheinlich, dass sich Mädchen eher für einen Informatikunterricht mit mobilen Informatiksystemen begeistern lassen. Dies scheint nach den bisherigen Erkenntnissen aus den Pilotkursen tatsächlich zuzutreffen.
\section{Nachteile und Befürchtungen für den Informatikunterricht}
\subsection{Unergonomische Bedienung}
Weiterhin nicht von der Hand zu weisen sind die Nachteile, die sich aus der Mobilität der Geräte ergeben. Die kleinen Displays und die mitunter \enquote{friemelige} Bedienung sind echte Nachteile gegenüber klassischen Informatiksystemen, auch wenn sich dies durch die neueren Smartphones mit komfortablen \glspl{OSTastatur} und größeren Displays etwas gebessert hat. Diese Nachteile sollten jedoch generell nicht überbewertet werden, denn einerseits sollen gerade die informatischen Prinzipien in den Vordergrund gerückt und die tatsächlichen Programmieranteile verringert werden. Andererseits besteht auf Seiten der \SuS durch die tagtägliche Verwendung der Geräte eine hohe Nutzungskompetenz. Die allermeisten \SuS haben keinerlei Probleme mit der Eingabe von Texten auf den Geräten.
Als Ausweg stehen externe Eingabegeräte oder Tablets als Alternative zu Smartphones bereit. Letztere könnten, bei gleicher Plattform oder zumindest Verfügbarkeit einer gemeinsamen Basis\vglr{chpGestaltung}, sogar gleichzeitig ohne weitere Beschränkungen eingesetzt werden. Einige \SuS könnten dann mit Smartphones, andere mit Tablets arbeiten.
\subsection{Nachteile durch soziale Ungleichheit}\label{secNachtUng}
Bei der Nutzung von Geräten der \SuS darf nicht aus den Augen gelassen werden, dass trotzdem einige Geräte durch die Schule zur Verfügung gestellt werden müssen. Einmal, da -- zumindest derzeit -- nicht davon ausgegangen werden kann, dass alle \SuS über geeignete Geräte verfügen. Zum anderen weil die Gefahr besteht\footnote{Auch wenn sich derzeit, wie in \referenz{parVerNutzJuBes} beschrieben, keine gewaltigen Unterschiede bei der Geräteausstattung zeigen.}, durch die noch immer recht teuren Geräte eine weitere soziale Hürde im Schulsystem zu errichten. Dabei geht es nicht nur darum, Schülerinnen und Schüler, die sich entsprechende Geräte nicht leisten können, mit diesen ausstatten zu können. Es muss außerdem unbedingt beachtet werden, dass durch besser ausgestattete Geräte keine erheblichen Vorteile entstehen. Da die Systemleistung für den Informatikunterricht eine eher untergeordnete Rolle spielt, wären hier eher einfachere Bedienbarkeit oder bessere Displays und Touchscreens relevant.
Demgegenüber steht die oben genannte Chance zur Kostenersparnis. So könnte in Zukunft etwa auf die Anschaffung eines (grafikfähigen) Taschenrechners oder weiterer Unterrichtsmaterialien verzichtet werden.
\subsection{Exklusive Nutzung}
Anders als bei stationären Systemen ist bei mobilen Informatiksystemen aufgrund ihrer starken Personalisierung kaum eine geteilte Nutzung möglich. Daher werden prinzipiell mehr Geräte benötigt, was den Kostenvorteil bei schulischen Geräten zunichte machen kann. Aufgrund der geringen Größe ist die Zusammenarbeit an einem Gerät auch nur sehr begrenzt möglich.
\section{Perspektiven für den Unterrichtseinsatz}\label{secPers}
\cite{Heming2009} brachte zunächst die beiden Perspektiven \textit{Analyse der Wirklichkeit} und \textit{Veränderung der Wirklichkeit} in den Diskurs ein. Erstere bezieht sich auf die kritische Nutzung von Anwendungsprogrammen und letztere auf die kritische Nutzung von Programmiersoftware. Bezieht man die beiden Programmierperspektiven von \cite{Carrie2006} mit ein, so ergeben diese Teilaspekte der Perspektive der \textit{Veränderung der Wirklichkeit}. Zusammengenommen geben diese zwar die informatische Sicht schon sehr gut wieder, allerdings müssen sie aus Sicht des Autors ergänzt werden.
\subsection{Akzeptanz der Wirklichkeit}\label{secPersAkz}
Zunächst fehlt hier, bezogen auf die mobilen Informatiksysteme, eine Perspektive für die unkritische Nutzung der Geräte. Dies ist insofern klar, als sie im Kontext des Informatikunterrichts eigentlich nichts zu suchen hat. Natürlich ist die vernunftgeleitete Nutzung das Ziel, und so erscheint diese Perspektive für den Informatikunterricht nicht nur als nicht nützlich, sondern sogar als hinderlich. Dennoch muss sie berücksichtigt werden, denn bei genauerer Betrachtung wird klar: Dies ist die Perspektive, von der zunächst ausgegangen werden muss und die allgemein vorherrscht\vglr{secAnsPad}, so sehr dies bedauert werden mag. Informatische Hintergründe interessieren viel zu oft nicht. Dies gereicht den handelnden Personen zwar oft genug zum Nachteil, fällt diesen jedoch meist nicht auf. Der Mangel an Verständnis wird in diesen Fällen gern auf die verwendeten Systeme geschoben und entstehende Nachteile als generelle, nicht vermeidbare Probleme hingenommen.
Die Etablierung mobiler Informatiksysteme als reines Werkzeug in der Schule kann als Ausgangspunkt für den Einstieg in die informatische Allgemeinbildung genutzt werden. Denn immer, wenn die unkritische Nutzung an Grenzen stößt, kann das kritische Hinterfragen anhand informatischer Prinzipien den Blick für die Perspektive der Analyse öffnen.
Die reine Anwendung kann durchaus positive Effekte auf den Unterricht haben. So sind die vielfältigen Nutzungsmöglichkeiten, von denen einige bereits in \cite{Spittank2011} genannt wurden, durchaus dazu geeignet, den Unterricht zu verbessern, etwa durch die Nutzung geeigneter Apps, wie einer grafikfähigen Taschenrechnerapp im Mathematikunterricht, E-Books und Wörterbuch-Apps in den sprachlichen Fächern oder ganz einfach in Form digitaler Schulbücher. Der Motivationsaspekt kann auf diese Weise durchaus erfüllt werden. Selbst im Informatikunterricht wären hier entsprechende Apps vorstellbar, etwa zur Erzeugung und Simulation von Automaten. Ganz generell können die Geräte auch immer zur audiovisuellen Präsentation und zur Recherche verwendet werden. Dies führt natürlich keineswegs zur gewünschten Kompetenz im Umgang mit Informatiksystemen generell, sondern zur -- aus fachlicher und didaktischer Sicht problematischen -- reinen Nutzungskompetenz für spezifische Informatiksysteme.
Diese Perspektive kann in Anlehnung an Hemings Schema -- und mit leichtem Augenzwinkern -- in doppelter Hinsicht als Perspektive der \textit{Akzeptanz der Wirklichkeit} bezeichnet werden. Einerseits muss der im Sinne informatischer Vernunft handelnde Mensch akzeptieren, dass es eben auch die unkritische Seite gibt und diese sogar der eigentliche Ausgangspunkt ist. Andererseits muss zunächst in der Institution Schule akzeptiert werden, dass mobile Informatiksysteme ein Teil der Wirklichkeit sind, sodass ein Einsatz in der Schule generell in Betracht gezogen wird.
\subsection{Analyse der Wirklichkeit}\label{secPersAna}
Spätestens, wenn eines der verwendeten Systeme nicht funktioniert wie erwartet, kommt man mit der reinen Nutzungsperspektive keinen Schritt mehr weiter. Für den Informatikunterricht muss immer die analytische Perspektive angestrebt werden. Die reine Nutzung ist hier aus didaktischen Gründen abzulehnen, da sie das Ziel der informatischen Allgemeinbildung nicht befördert. Phasen reiner Nutzung sind jedoch absolut legitim. Die vielfältigen Ansatzpunkte für die kritisch-analytische Sicht haben Heming und Carrie in ihren Arbeiten und verschiedenen anderen Beiträgen ausführlich dargelegt.
Zur kritischen Analyse muss immer der Aspekt der gesellschaftlichen Auswirkungen, also das Inhaltsfeld \enquote{Informatik und Gesellschaft}, gehören, weil eine ernsthafte, vernunftgeleitete Anwendung von Technologien die gesellschaftlichen Konsequenzen berücksichtigen muss. Die starke Verzahnung der mobilen Informatiksysteme mit Internetdiensten bedarf immer einer kritischen Betrachtung dieser Dienste. Evtl. müssen diese zusammen mit den mobilen Informatiksystemen, wie im \referenz{boxWolk} beschrieben, als Teil eines größeren Informatiksystems betrachtet werden.
Die analytische Perspektive hat bereits erste Auswirkungen auf die Auswahl der zu verwendenden Informatiksysteme. Da sie grundsätzlich \zitat[,]{mit unterschiedlichen theoretischen und praktischen Elementen aus dem Bereich der Mobiltelefonie keine besonderen Anforderungen an die hardwaretechnische Ausstattung der verwendeten mobilen Informatiksysteme stellt}{Heming2009}{9} ist es allerdings nicht zwingend erforderlich, dass hier bestimmte Geräte verwendet werden. Die technischen Hintergründe und möglichen Auswirkungen könnten auch rein theoretisch als Informatikunterricht ohne Informatiksysteme oder mit stationären Informatiksystemen (evtl. mit Mobiltelefon-Emulatoren) durchgeführt werden. Dennoch fehlt hier dann mitunter die nötige Anbindung an den Alltag der Schülerinnen und Schüler. Es sollten also zumindest gelegentlich die Geräte der \SuS betrachtet und im Unterricht verwendet werden.
Es zeigt sich allerdings schnell, dass die Überprüfung bestimmter Sachverhalte und die Verdeutlichung informatischer Inhalte mit bestimmten Geräten überhaupt nicht möglich sind. So besteht etwa bei einigen Plattformen kein Zugriff auf das zugrunde liegende Dateisystem. Die Dateimetapher wird hier durch einen unübersichtlichen Brei aus verschiedenen Objekten ersetzt, die jeweils einer App gehören. Es gibt hier teilweise überhaupt keine Struktur zur Ordnung mehrerer dieser dateiähnlichen Objekte, weder hierarchischer noch sonstiger Natur. Wenn darüber hinaus kein einfacher Austausch von Dateien zwischen den Geräten möglich ist, wird selbst der rein nutzungsorientierte Ansatz kräftig konterkariert. Für die kritisch-analytische Perspektive bedeutet dies, dass diese ohne externe Hilfsmittel, die im schulischen Kontext nur begrenzt möglich sind (etwa zur Analyse des Netzwerkverkehrs), nur noch im Hinblick auf eine kritische Bewertung des Gesamtkonzepts eingenommen werden kann. Die Benutzerinnen und Benutzer haben in der Regel keine Entscheidungsspielräume bei der Nutzung der Geräte. Wenn also die einzigen Alternativen Nutzung oder Nichtnutzung sind, wird eine kritische Benutzung zumindest deutlich erschwert. Sind die verwendeten Geräte also hinreichend durch den Hersteller verbarrikadiert worden, wird grundsätzlich eine kritische Nutzung zumindest erschwert\footnote{Siehe Exkurs zur grundsätzlichen Nichteignung von Konsumgeräten (\referenz{secKonsum}).}.
\subsection{Veränderung der Wirklichkeit}\label{secPersVer}
Die zweite für die Informatik aufgrund der Besonderheit der informatischen Modellierung\footnote{Im Sinne direkter Umsetzung und Überprüfung von Modellen mittels der Konstruktion von Informatiksystemen} typische Perspektive ist die der Veränderung der Wirklichkeit. Diese hat ganz massiven Einfluss auf die Auswahl der Geräte, und für den tatsächlichen Einsatz der gebotenen Programmiermöglichkeiten ist eine didaktische (Um-)\allowbreak{}Gestaltung der Informatiksysteme unabdinglich. Die Teilaspekte nach Carrie bedürfen hier einer Anpassung. Denn einerseits ist die Möglichkeit von geräteunabhängigen Webapps hinzugekommen, die auf ihre Eignung hin untersucht werden muss, außerdem verschwimmt die Grenze zwischen den beiden Perspektiven der Entwicklung auf bzw. für die Geräte in wesentlichen Teilen.
\subsection{Programmieren von Webapps}\label{secPersWebApp}
Webapps sind inzwischen auf allen mobilen Informatiksystemen lauffähig. Hierbei handelt es sich um Gebilde aus \gls{HTML}, \glspl{CSS} und JavaScript. Es handelt sich also letztlich um Webseiten, die dank einiger Erweiterungen auf bestimmte Hardware- und Softwarefunktionen der mobilen Informatiksysteme zugreifen können und sich so in die jeweilige Benutzungsschnittstelle integrieren, dass sie sich für die Anwenderinnen und Anwender in Aussehen und Bedienung kaum von \enquote{echten}, also für die Geräte entwickelten Apps unterscheiden. Die Ansätze, solche Webapps zu integrieren, sind unterschiedlich. So lassen sich etwa unter Android und iOS direkt aus dem Browser Links zu Apps erstellen, die danach wie \enquote{echte Apps} wirken. Es ist hier ebenfalls auf verschiedenen Wegen möglich, die Webapps in App-Container zu verpacken, welche über die normalen Appstores verteilt werden können. Andere mobile Betriebssysteme (namentlich ChromeOS und FirefoxOS) setzen sogar vollständig auf WebApps.
Der große Vorteil von Webapps ist ihre nahezu vollkommene Plattformunabhängigkeit. Sie funktionieren auf jedem Informatiksystem, das über einen aktuellen Internet-Browser verfügt. Daher erscheinen sie auf den ersten Blick als idealer Ansatz für die Verwendung im Unterricht. Allerdings wird aus didaktischer Perspektive sehr schnell deutlich, dass ein Einsatz sich zumindest derzeit verbietet. Seit der Abkehr von einer strikten Struktur (vor allem nach der Einstellung der \gls{XHTML}) und der mit HTML5 begonnenen Ausrichtung auf einen, freundlich bestenfalls als pragmatisch zu bezeichnenden, neuen Ansatz scheidet \gls{HTML} bereits als strukturierter Dokumententyp aus, der noch gewinnbringend im Informatikunterricht behandelt werden könnte. Die zusätzliche Festlegung auf JavaScript als Programmiersprache ist jedoch der wesentlichere Knackpunkt des Konzepts. Dieses Konglomerat von Konzepten verschiedener Programmiersprachen erreicht nicht einmal die Mindestanforderungen einer Programmiersprache für den Informatikunterricht nach \cite{LinkweilerDA2002}. Vor allem die mangelhafte Orthogonalität und die fehlende bzw. nur simulierte Objektorientierung sind klare K.-o.-Kriterien für den Einsatz im Informatikunterricht.
Ein weiteres wesentliches Problem ist der fehlende Zugriff auf das Dateisystem bei geschlossenen Plattformen\vglr{secKonsum}. Somit wäre der Betrieb der Webapps nicht auf den Geräten selbst möglich, und es würde wiederum eine deutlichere Abhängigkeit von einer schulischen Infrastruktur eintreten, die die Vorteile des geringeren Wartungsaufwands, der geringeren Kosten und der Flexibilität einschränken würde. Zumindest ein externer Webserver würde benötigt, was die Bedienung erschweren würde, da die erzeugten Webapps jeweils zunächst auf den Server transferiert werden müssten.
Das Problem der Programmiersprache ließe sich vielleicht noch umgehen, indem man einen der verfügbaren, in JavaScript implementierten Interpreter \citep[etwa][]{Skulpt} oder Compiler \citep[etwa][]{Pyjs}, die den Code anderer Sprachen nach JavaScript bzw. einem mittels JavaScript interpretierbaren Bytecode umwandeln, entsprechend anpasst und verwendet. Mit entsprechendem Aufwand wäre so auch die Generierung des nötigen HTML-Codes möglich. Damit sähe die didaktische Bewertung schon anders aus. Jedoch bezweifelt der Autor derzeit, dass der hohe Aufwand, der bis zu einem im Unterricht einsetzbaren Ergebnis notwendig wäre, angesichts der Alternativen derzeit zu rechtfertigen ist. Zumal der Ansatz weiterhin nur auf -- zumindet teilweise -- offenen Plattformen vollständig umsetzbar wäre, auf denen diese Alternativen auch verfügbar wären. Trotzdem sollte man den Ansatz für zukünftige Entwicklungen im Auge behalten.
\subsection{Programmieren für die Geräte}\label{secPersFor}
Das Programmieren für die Geräte unter Zuhilfenahme stationärer Informatiksysteme ist weiterhin eine Möglichkeit. Hier haben sich keine wesentlichen Änderungen ergeben. Lediglich die notwendigen Werkzeuge und Sprachen haben sich aufgrund anderer Plattformen verändert. Dieser Zugang ist zwar bei allen mobilen Informatiksystemen möglich (je nach Plattform mit zusätzlichen Kosten verbunden), bietet sich allerdings für den Informatikunterricht eher nicht an, wie bereits im bisherigen fachdidaktischen Diskurs deutlich wurde. Denn die zentralen Vorteile der mobilen Informatiksysteme können nicht genutzt werden\vglr{secVort}, sodass die an den Einsatz gebundenen Hoffnungen nicht erfüllt werden können. Lediglich die Hoffnung auf eine erhöhte Motivation und eine etwas bessere Anbindung an die Alltagswelt der \SuS stehen hierbei auf der Habenseite. Die zentralen Probleme des Informatikunterrichts mit klassischen Informatiksystemen werden hiermit jedoch nicht einmal tangiert.
\subsection{Programmieren mit den Geräten}\label{secPersMit}
Der Königsweg des Unterrichtseinsatzes ist der Ersatz der klassischen durch die mobilen Informatiksysteme. Hier haben sich -- teilweise erst während der Erstellung dieser Arbeit -- sehr wesentliche und weitreichende Änderungen ergeben. So kann man inzwischen nicht mehr klar zwischen den Perspektiven des Programmierens \textit{für} und \textit{auf} den Geräten trennen, sodass man hier von einer \textit{Programmierung mit den Geräten} sprechen muss. Für Android und andere offene Systeme existieren (inzwischen) diverse Compiler und Entwicklungsumgebungen, die die Entwicklung \enquote{echter} Apps allein mit den mobilen Informatiksystemen ermöglichen. Echt meint in diesem Zusammenhang Apps, die einerseits speziell für die jeweilige Plattform entwickelt werden, also etwa Zugriff auf alle relevanten \glspl{API} erhalten. Andererseits meint es solche Apps, die im für die Plattform regulären Format vorliegen und somit ohne weitere Laufzeitumgebungen auf den meisten Geräten lauffähig sind. Daher können diese problemlos über die regulären Appstores angeboten werden.
Wurde vorher tendenziell eher von der Nutzung von Skriptsprachen zur Erweiterung der Funktionalität der mobilen Informatiksysteme ausgegangen, bei der man auf das Vorhandensein entsprechender \glspl{API} und den Umfang der jeweiligen Interpreter angewiesen ist, so bietet sich neben dem oben bereits erwähnten Ansatz der Erzeugung von Webapps auch die Entwicklung vollständiger, uneingeschränkter Apps als weitere Möglichkeit an. Dies alles ist tendenziell allein mit den mobilen Informatiksystemen ohne Rückgriff auf stationäre Informatiksysteme möglich. So können durch die exklusive Nutzung der mobilen Informatiksysteme im Unterricht alle möglichen Vorteile voll ausgeschöpft werden.

View file

@ -0,0 +1,168 @@
\chapter{Kriterien für die Nutzung mobiler Informatikssysteme}\label{chpKriterien}
\section{Notwendigkeit neuer Kriterien}
Für den Einsatz von Mobiltelefonen im Unterricht hat \cite[S.~4~ff.]{Carrie2006} bereits einige Kriterien benannt, die bedacht werden müssen. Allerdings sind diese zu einem entscheidenen Teil überholt bzw. überhaupt nicht anwendbar, wenn man aktuelle mobile Informatiksysteme betrachtet. Auch die (wenigen) von \cite[S.~15~f.]{Heming2009} getroffenen Aussagen zur Geräteauswahl sind nicht mehr hinreichend: War damals noch eine sehr überschaubare Anzahl von Systemen und nur eine einzige Plattform -- Symbian S60 -- überhaupt geeignet, hat man es heute mit einer Vielfalt möglicher Geräte zu tun, die einen schnell den Überblick verlieren lässt. Es ist daher, auch in Hinblick auf die notwendige Zukunftsfähigkeit, erforderlich, neue Kriterien einzuführen, die sich weder auf eine bestimmte Plattform noch auf konkrete Geräte beziehen.
\subsection{Stetige Weiterentwicklung}
Der stetige technische Fortschritt verändert die verwendeten Informatiksysteme massiv. Natürlich funktionieren die Geräte dabei weiterhin nach denselben Grundprinzipien. So ändern sich etwa die fundamentalen Ideen der Informatik\vgl{ClausSchwill2006}{307} nicht. Trotzdem können bei der Frage nach Kriterien für den Einsatz bestimmter Informatiksysteme diese technischen Veränderungen nicht ausgeklammert werden. Denn allein ihre Beschaffenheit und Verfügbarkeit verändern massiv die Art, wie und wo Informatiksysteme eingesetzt werden. Dieser gesellschaftliche Aspekt ist im Rahmen einer didaktischen Betrachtung natürlich absolut relevant. Es ist hier also -- zumindest in Teilen -- eine stetige Weiterentwicklung der Kriterien erforderlich. Somit sind die im Folgenden zu entwickelnden Kriterien nicht als \enquote{der Weisheit letzter Schluss} zu betrachten, sondern vielmehr als eine aktuelle Version solcher Kriterien. Dies gilt natürlich ebenso für die daraus abgeleitete Gestaltung der mobilen Informatiksysteme für den Unterricht.
Die durch das mooresche Gesetz\vgl{ClausSchwill2006}{431} vorgegebene Entwicklung trifft bei mobilen Informatiksystemen ebenso zu wie bei stationären. Gleichsam werden durch die Miniaturisierung immer mehr Funktionen auf die mobilen Systeme übertragen. So sind die Einschränkungen bei Rechenleistung und Arbeitsspeicher inzwischen wesentlich weniger relevant als zum Zeitpunkt der früheren Arbeiten. Zwar ist die Leistung der mobilen Informatiksysteme der ihrer stationären Verwandten noch immer unterlegen, doch gibt es inzwischen potente Smartphones und Tablets mit Mehrkern-Prozessoren, dedizierten Grafikchips, Hardware-Decodern für gängige Multimedia-Codecs und mehreren Gigabyte großem Arbeitsspeicher. Beim Festspeicher sind inzwischen mehrere hundert Megabyte bis zu einigen Gigabyte üblich. Viele Modelle lassen sich zusätzlich durch externe Medien nahezu unbegrenzt erweitern. Selbst günstige Geräte bieten inzwischen Ressourcen, die für den schulischen Einsatz in allen Belangen mehr als ausreichend sind. Dies ist insbesondere im Hinblick auf das für den Unterricht favorisierte objektorientierte Paradigma wichtig. Dieses kann ohne relevante Einschränkungen verwendet werden. Die von Carrie noch hervorgehobene Einschränkung auf kleine, einfache -- oder besser gar keine -- Objekte\vgl{Carrie2006}{6} gilt nicht mehr. Auch die Einschränkungen bezüglich der Netzwerkverbindungen gelten für aktuelle mobile Plattformen (selbst bei Lesser Smartphones, Handys und Abspielgeräten) nicht mehr. Die möglichen Beeinträchtigungen des Bedienkomforts aufgrund der Größe der Geräte treffen hingegen teilweise weiterhin zu. Allerdings eröffnen der zunehmende Verzicht auf Hardware-Bedienelemente und die weite Verbreitung von Touchscreens sowie alternative Steuerungsoptionen, wie Spracheingabe, Gestenerkennung und Lagesensoren, deutlich flexiblere Interaktionsmöglichkeiten. Galt damals noch, dass \zitat{bei den Eingabemöglichkeiten [\dots] kaum Modifikationen vorgenommen werden [können]}{Carrie2006}{6}, sieht man sich heute eher mit dem Problem konfrontiert, aus der Vielzahl an Eingabemöglichkeiten die sinnvollste auswählen zu müssen.
\subsection{Diversifikation}
Der zweite wesentliche Grund für den Bedarf neuer Kriterien ist das stark veränderte Angebot an mobilen Informatiksystemen. Dabei sind zwei verschiedene Aspekte besonders augenfällig. Erstens ist die schiere Anzahl an Geräten fast unüberschaubar geworden, und es gibt keine Hinweise dafür, dass sich das in absehbarer Zeit ändern könnte. Im Gegenteil werden beständig neue Geräte angekündigt. Zweitens haben die \enquote{smarten} mobilen Informatiksysteme sehr stark an Bedeutung gewonnen\vglr{secMinMob}.
Bei den mobilen Informatiksystemen wird deutlich, dass die Geräte immer \enquote{smarter} werden\vglr{figSmartInEU}. Klassische Handys sind inzwischen nahezu bedeutunglos geworden, während immer mehr Menschen (Lesser) Smartphones verwenden. Tablets sind ebenfalls sehr erfolgreich. Am Produktangebot zeigt sich zudem, dass die klassischen Mobiltelefone, ohne die Möglichkeit der Installation von Zusatzprogrammen und ohne eine Vielzahl von Sensoren, inzwischen deutlich unterrepräsentiert sind.
\section{Nutzungsanforderungen und Benutzerrollen}
Für die Frage nach den relevanten Kriterien zur Auswahl geeigneter mobiler Informatiksysteme für den Einsatz im Unterricht sind nicht nur die für den Unterricht benötigten technischen Eigenschaften bedeutend. Vielmehr sind didaktische Aspekte zu beachten, die aus den verschiedenen Perspektiven zum Unterrichtseinsatz resultieren\vglr{secPers}. Dabei sollen die spezifischen Vorteile der mobilen Informatiksysteme genutzt werden\vglr{secVort}. So sollen die mobilen Informatiksysteme Verwendung finden, weil sie im Alltag der \SuS eine wichtige Rolle spielen. Würden nun Geräte eingesetzt, die perfekt auf den Unterricht zugeschnitten wären, etwa keine Möglichkeiten zur individuellen Anpassung böten oder keine Unterhaltungssoftware (Spiele, Videoplayer usw.) zulassen würden, würde der Alltagsbezug verloren gehen\vglr{parVerNutzJuNu}.
Es müssen also bei der Aufstellung von Kriterien deutlich mehr Faktoren bedacht werden als die für den reinen Unterrichtseinsatz relevanten. Hierzu ist es wichtig zu verstehen, welche Anforderungen überhaupt an mobile Informatiksysteme gestellt werden können. Bei der genaueren Betrachtung wird unmittelbar klar, dass viele verschiedene Menschen mit ganz unterschiedlichen Interessen und Anforderungen mit mobilen Informatiksystemen in Berührung kommen. Es erscheint hier zweckmäßig, auf eine stark vereinfachte Variante der soziologischen Rollentheorie nach Dahrendorf zurückzugreifen. Denn die Schülerinnen und Schüler, die im Unterricht mit den mobilen Informatiksystemen arbeiten sollen, nehmen mindestens drei verschiedene Rollen ein, die sich auf die (explizit auch private) Anwendung, den Unterricht sowie die Modellierung und Implementierung beziehen. Natürlich kann es zwischen diesen Rollen zu Konflikten kommen, die -- so gut wie möglich -- vorab bedacht werden müssen.
Da das Ziel einer zukunftsfähigen Einbindung der mobilen Informatiksysteme gesetzt ist, müssen weitere Rollen, wie etwa die der Lehrkräfte, der Unternehmen (als Anbieter entsprechender Systeme) und der kommerziellen Softwareentwickler bedacht werden. Obwohl dies durchaus Konfliktpotential für den Unterrichtseinsatz mitbringt, bieten am ehesten kommerziell erfolgreiche Systeme die notwendigen Voraussetzungen zur Grundlage eines auf Dauer angelegten, zukunftssicheren Konzepts zu werden\footnote{Eine Ausnahme würden speziell für den Unterrichtseinsatz konzipierte Geräte bilden, die jedoch wie bereits angemerkt, auch andere Einsatzzwecke zulassen müssten. Näheres hierzu im folgenden \referenz{secKrit}}. Der Alltagsbezug ist vor allem bei den Systemen vorhanden, die so oder zumindest in sehr ähnlicher Form im Alltag der \SuS außerhalb der Schule von Bedeutung sind.
Die folgenden Rollen sind natürlich idealisiert. Tatsächlich haben die individuellen Anwender/-innen der mobilen Informatiksysteme durchaus sehr unterschiedliche Anforderungen an die Systeme oder gewichten bestimmte Kriterien anders. Allein der persönliche Geschmack kann hier zu starken Abweichungen führen. Dennoch stellt die folgende Auswahl eine belastbare Grundlage für die Entwicklung allgemeiner Kriterien für den Unterrichtseinsatz dar.
\subsection{Anwender/-in}\label{secKritAnw}
\subsubsection{Zielkompatibilität}\label{secKritAnwZiel}
Es wird im Folgenden davon ausgegangen, dass der Einsatz eines mobilen Informatiksystems generell \textit{zielgerichtet} erfolgt. Anwenderinnen bzw. Anwender verfolgen also eine feste Absicht, wenn sie zum mobilen Informatiksystem greifen. Dies kann durchaus ziel- und planlos erscheinendes \enquote{Surfen} im Internet oder die Nutzung von Apps sein. Hier kann als Ziel jedoch offensichtlich die Überbrückung von Wartezeiten oder das Vertreiben von Langeweile gesehen werden. Damit bleibt also festzuhalten, dass die grundlegende Anforderung die Möglichkeit der \textit{Erfüllung der persönlichen Nutzungsszenarien} ist. Es geht also grundsätzlich um die \textit{technischen Eigenschaften} sowie die \textit{Softwareaustattung} des Systems. Als allgemeine Mindestanforderungen lassen sich hier Möglichkeiten zur \textit{Kommunikation}, \textit{Informationsgewinnung}, \textit{Unterhaltung} und \textit{Arbeitserleichterung} (im Sinne von nützlichen Werkzeugen) festhalten. Weitergehende Details zu technischen Möglichkeiten und Ausstattung sind hingegen sehr stark von den persönlichden Anforderungen abhängig.
\subsubsection{Ausstattungsdetails}
Grundsätzlich ist aus Anwendersicht eine gewisse \textit{Modellvielfalt} wünschenswert. Ein One-Size-Fits-All-Ansatz ist hier eher hinderlich, da die letzlich nicht genutzten Komponenten mitbezahlt werden müssen. Außerdem kann die Optimierung auf einen spezifischen Anwendungszweck große Vorteile bringen. Soll etwa neben der Telefonfunktion das Smartphone hauptsächlich als Navigationsgerät eingesetzt werden, wird man zugunsten eines besseren GPS-Empfängers gerne auf eine hochauflösende Kamera verzichten, wenn die Wahl besteht. Ebenso ist bei einem Gerät, das hauptsächlich zur Internetnutzung und für das Lesen von elektronischen Büchern eingesetzt wird, die schnelle CPU mit hochwertigem Grafikprozessor vollkommen überflüssig.
\subsubsection{Bedienkomfort}
Der \textit{Bedienkomfort} der Geräte ist dabei ein wichtiger Aspekt. Die Bedienung sollte so einfach wie möglich sein, sodass sich die vorgesehenen Nutzungsszenarien möglichst einfach und schnell umsetzen lassen. Hierzu zählen neben den verschiedenen Eingabemöglichkeiten auch die sinnvolle Gestaltung der Benutzungsschnittstelle sowie die Beschaffenheit der Hardware. Beispielsweise sieht ein glattes, hochglänzendes Mobiltelefon sicherlich gut aus, rutscht es deswegen jedoch ständig aus der Hand der bedienenden Person, schmälert dies den Bedienkomfort enorm.
\subsubsection{Kosten}
Ein für die allermeisten Anwenderinnen und Anwender relevanter Punkt sind die \textit{Kosten} des Systems. Jedoch sind die tatsächlichen Kosten, insbesondere bei Mobiltelefonen, teilweise verdeckt. Werden die Geräte doch häufig als Bestandteil langfristiger Mobilfunkverträge zu sehr niedrigen Preisen abgegeben, tatsächlich werden die Gerätekosten natürlich über die monatliche Telefonrechnung abgegolten. Dies kann also dazu führen, dass der konkreten Anwenderin bzw. dem konkreten Anwender das Kostenkriterium als weniger relevant erscheint. Die Kosten für den Mobilfunkvertrag oder das Prepaid-Guthaben sind ebenso mögliche Folgekosten wie die Beschaffungskosten für Apps und Zubehör.
\subsubsection{Langlebigkeit}\label{secKritAnwLang}
Eng mit dem Kostenkriterium verbunden ist der Wunsch nach \textit{Langlebigkeit und Robustheit der Geräte}. So können verdeckte Kosten (wie die Querfinanzierung über einen Mobilfunkvertrag, s.~o.) auch dieses Kriterium als weniger wichtig erscheinen lassen: Wenn ein neues Gerät in regelmäßigen Abständen vom Mobilfunkprovider zur Verfügung gestellt wird, verliert die Langlebigkeit des Geräts an Bedeutung.
Eine grundlegende \textit{Robustheit} bleibt jedoch wichtig. So sollten die Geräte dem Alltagsgebrauch standhalten und am besten kleinere Unfälle überleben. Die Robustheit ist dabei nicht zwingend preisabhängig. Teurere Geräte mit Metallgehäuse und gläserner Displayoberfläche sind zwar resistenter gegen Kratzer, verzeihen aber Stürze wesentlich weniger als günstigere Geräte mit Gehäusen und Displayoberflächen aus Kunststoff. So hat sich inzwischen besonders für Geräte von Apple ein eigener Markt zur Beschaffung und zum Einbau von Displaymodulen und Gehäuseteilen etabliert. Die \textit{Verfügbarkeit von Ersatzteilen} ist grundsätzlich ein wichtiges Argument. Generell lohnen sich Reparaturen allerdings nur bei teureren Geräten und nur selten, wenn diese vom Hersteller durchgeführt werden.
Zudem ist es aus Sicht der Anwenderinnen und Anwender schlecht, wenn die Geräte deutliche Merkmale geplanter Obsoleszenz, also bauartbedingter Höchstaltersgrenzen unterliegen. Aus umweltorientierten und gesellschaftlichen Überlegungen heraus sollten derartige Geräte gemieden werden. Hierzu gehören etwa Geräte mit \textit{fest eingebauten Akkus}, da diese ein Maximalalter definieren, nach dem die Geräte deutlich weniger oder sogar vollständig unbrauchbar werden.
Zur Langlebigkeit zählt jedoch auch der Kundenservice, vor allem die Verfügbarkeit von \textit{Updates}. Diese berührt unmittelbar Datenschutz und Datensicherheit\footnote{Siehe den gleichnamigen \referenz{secKritAnwDat}.}, denn die komplexeren Smartphone- und Tabletbetriebssysteme sind wesentlich komplexer und damit tendenziell anfälliger für Sicherheitslücken und Angriffe als die Firmware von Handys. Zumindest Korrekturen von Sicherheitslücken sollten also über einen längeren Zeitraum zur Verfügung gestellt werden.
\subsubsection{Erweiterbarkeit und Softwarevielfalt}\label{secKritAnwErw}
Die \textit{Verfügbarkeit verschiedener Zusatzprogramme} ist bei smarten Geräten besonders relevant. Denn sie erhöht die Wahrscheinlichkeit, dass die persönlichen Nutzungsszenarien optimal umgesetzt werden können. Zusätzlich erhältliche Hardware und die \textit{Erweiterbarkeit} sind aus demselben Grund wichtig. Allein eine Erweiterbarkeit des zur Verfügung stehenden Speichers kann die Nutzungsmöglichkeiten des Systems stark vergrößern. Die Ausstattung mit \textit{Schnittstellen} für den Anschluss externer Hardware, wie Displays, Eingabegeräte oder andere Peripherie (etwa TV-Karten, Drucker oder Sensoren), kann weitere Nutzungsmöglichkeiten eröffnen und andere Geräte überflüssig machen.
\subsubsection{Verfügbarkeit digitaler Inhalte}\label{secKritAnwCont}
Die gerne als \textit{Content-Verfügbarkeit} bezeichnete Verfügbarkeit digitaler Medien für die mobilen Informatiksysteme zielt voll und ganz auf den Zielaspekt der Unterhaltung (vgl. \referenz{secKritAnwZiel}) ab. Zusätzlich zur Verfügbarkeit von Unterhaltungssoftware ist hier der einfache Zugang zu elektronischen Büchern, Musik und Filmen gefragt. Sollte es sich dabei um kommerzielle Angebote handeln, muss zudem eine einfache und bequeme \textit{Abrechnungsmöglichkeit} existieren.
\subsubsection{Datensicherheit und Datenschutz} \label{secKritAnwDat}
Im \referenz{secGefDat} wurden viele der möglichen Gefahren für die eigenen Daten auf den mobilen Informatiksystemen bereits beschrieben. Obwohl es oft an der notwendigen Sensibilisierung mangelt, kann doch für die weitaus meisten Nutzer unterstellt werden, dass sie -- zumindest die umittelbar als solche erkennbaren -- sensiblen persönlichen Daten nicht ohne weiteres weitergeben wollen.
Der mögliche vollständige Verlust der Daten (\zb durch Hardwareschäden, Verlust des Gerätes, Diebstahl oder Malware) ist ein ebenso wichtiger Aspekt. Nicht für alle Plattformen gibt es komfortable Backup-Lösungen, und das Sichern der Daten kann so sehr zeitraubend werden.
\subsection{Jugendliche}\label{secKritJu}
\subsubsection{Wesentliche Differenzen zu Erwachsenen}
Jugendliche sind zunächst einmal \enquote{normale} Anwenderinnen und Anwender. Somit treffen die oben aufgeführten Anforderungen auch hier zu. Jedoch gibt es einige wesentliche Unterschiede zu beachten. Diese resultieren im Wesentlichen aus zwei starken Einflüssen: Erstens sind die Platzierung und der eigene Status in der Peergroup von hoher Bedeutung. Zweitens liegen diese Unterschiede im spezifischen Nutzungsverhalten von mobilen Informatiksystemen durch Jugendliche begründet (vgl. \referenz{secVerNutzJu}). Zusätzlich lässt sich, wie bereits in \referenz{secVerNutzJu} angemerkt, eine grundlegende Unbefangenheit und Sorglosigkeit gegenüber den neuen technischen Möglichkeiten und den Gefahren (vgl. \referenz{secNeuChaGef}) erkennen. So scheinen Jugendliche zwar häufig über eine höhere Nutzungskompetenz zu verfügen, informatische Vernunft (vgl. \referenz{secDurchblick}), im Sinne von Aufgeklärtheit über die Hintergründe der bunten Kommunikationswerk- und Spielzeuge besitzen sie jedoch häufig noch weniger als die Erwachsenengenerationen. Dies erklärt teilweise, warum etwa \textit{Datenschutz und Datensicherheit} für Jugendliche im Zweifelsfall weniger relevante Anforderungen sind.
\subsubsection{Zielkompatibilität}
Jugendliche zeigen tendenziell einen stärkere Neigung zur Nutzung der Geräte zum Zwecke von Unterhaltung und Kommunikation. Dabei ist nach den Erkenntnissen aus der \gls{JIM}\vglr{secVerNutzJu} klar, dass Mädchen eher den Kommunikationsaspekt stärker gewichten und Jungen vornehmlich den Unterhaltungsaspekt, vor allem Spiele, favorisieren.
\subsubsection{Kosten}
Bei den \textit{Kosten} unterscheiden sich die jugendlichen von den erwachsenen Anwenderinnen und Anwendern. Sind für die Erwachsenen sowohl Anschaffungskosten als auch monatliche Gebühren von Bedeutung, sind letztere für Jugendliche weniger relevant, da die meisten Prepaid-Tarife oder Flatrates nutzen. Nach Beobachtungen des Autors ist die Frage der Kosten für Jugendliche insgesamt deutlich weniger relevant. Sie tritt nur noch zu zwei Zeitpunkten in den Vordergrund: Erstens wenn ein neues Gerät angeschafft werden soll, was durch die Erweiterbarkeit der smarteren Geräte nicht mehr so oft vorkommt, wie zu Zeiten der Handys. Zweitens wenn etwaige Guthaben aufgebraucht sind.
\subsubsection{Individualisierbarkeit}\label{secKritJuIndiv}
Dass mobile Informatiksysteme für Jugendliche auch Statussymbole sind, kann man leicht beobachten. Hierzu muss man nur einmal den Gesprächen von \SuSn untereinander zuhören. Hier werden die technischen Vorzüge ebenso diskutiert wie die individuelle Umgestaltung der Geräte. Dabei werden alle verfügbaren Möglichkeiten genutzt. Neben der Ausstattung mit Apps, Bildern, Klingeltönen auch Hardwareerweiterungen, Hüllen, Taschen und weiteres Zubehör. Es wirken sich offensichtlich sowohl die technischen Eigenschaften der Geräte als auch bestimmte Marken oder Modelle und die persönliche Gestaltung der Geräte auf die Platzierung und den Status in der Peergroup aus.
\subsection{Schüler/-in}\label{secKritSuS}
\subsubsection{Zielkompatibilität}
In der Rolle der \SuS sehen die Anforderungen der Jugendlichen hingegen ganz anders aus. Das \textit{Lernen} steht in der Schule natürlich zunächst als Ziel im Vordergrund, ist allerdings kein Selbstzweck und für die \SuS nur sehr beschränkt das vorrangige Ziel. Zudem ist eher von einer extrinsischen Motivation auszugehen. Ein wesentliches Ziel der \SuS ist also das möglichst \enquote{schmerzfreie} Herumbringen der Unterrichtszeit. Es ist also generell im Interesse der Schülerinnen und Schüler, dass der Unterricht aufgelockert und so \textit{angenehm} wie möglich gestaltet wird. Wenn zudem noch ein \textit{direkter Nutzen} erkennbar ist, kann durch die entstehende intrinsische Motivation der Lernerfolg verbessert werden.
\subsubsection{Sinn}
An erster Stelle steht hier die Frage nach dem Sinn. Der mögliche Einsatz der Geräte muss sich hieran orientieren. Wenn für die \SuS kein Sinn im Einsatz der Geräte zu erkennen ist, wird er nur wenig zu einem erfolgreichen Unterricht beitragen. Wie immer ist natürlich auch hier klar, dass sich der subjektive Sinn zwischen \SuSn und Lehrkräften stark unterscheiden kann.
Die Verwendung der Geräte der \SuS im Informatikunterricht verspricht hier, unter Berücksichtigung der Perspektive der Veränderung der Wirklichkeit, nützliche Erweiterungen der Funktion der Geräte für den Alltag der Schülerinnen und Schüler, womit ein hoher subjektiver Sinn erreicht werden kann.
\subsubsection{Angenehme Lernatmosphäre}
Die Lernatmosphäre sollte für die \SuS angenehm sein. Es sollten möglichst wenige Hürden oder Unwägbarkeiten existieren, sodass das notwendige, extrinsisch motivierte Lernen -- nach Möglichkeit mit Erfolg -- ohne besonders unangenehme Nebenaspekte möglich ist. Idealerweise sollte der Unterricht nicht langweilig und eintönig, sondern abwechslungsreich sein, Spaß machen und -- mit erfülltem Sinn-Kriterium -- einen sichtbaren Nutzen versprechen. Dies kann für den Einsatz mobiler Informatiksysteme anfangs sicherlich als gegeben angenommen werden. Ob dies dauerhaft funktioniert, hängt allerdings weniger vom Informatiksystem als von den Unterrichtsinhalten und -methoden ab. Die mobilen Informatiksysteme bieten dabei viele Möglichkeiten, die Vorgaben auf spannende Weise anzugehen und ermöglichen erst die Nutzung vieler unterschiedlicher Unterrichtsmethoden im Informatikunterricht.
\subsubsection{Einfache Bedienung}
Eine \textit{einfache Bedienung} und ein leicht \textit{durchschaubares Bedienkonzept} sind erforderlich, um keine zusätzlichen Hürden im Lernprozess aufzubauen. Hier kann es durchaus zu einem Interrollenkonflikt zwischen der Rolle der \SuS und der der Jugendlichen kommen. Denn der Einsatz der Geräte in der Schule könnte optimal mit Geräten erfolgen, die perfekt auf den Unterrichtseinsatz zugeschnitten wären. Diese reinen Lerngeräte könnten zwar die Anforderungen der \SuS erfüllen, würden jedoch nicht zu den Anforderungen der Jugendlichen passen. So wären individuelle Anpassungen aus pädagogischer Sicht wohl eher hinderlich, Spiele wären tendenziell eher gar nicht möglich, da es an der -- für den Unterricht nicht notwendigen -- Rechenleistung mangeln würde. Die Kommunikationsfunktionen wären dabei generell nicht notwendig, sodass ein zentraler Einsatzbereich aus dem Alltag der Jugendlichen wegfallen würde\vglr{secGerAusw}. Diese Geräte würden also tendenziell nicht außerhalb der Schule eingesetzt werden und ausschließlich für schulische Zwecke genutzt.
\subsection{Lehrkräfte}\label{secKritLehr}
Die zentrale Anforderung für den Unterrichtseinsatz von mobilen Informatiksystemen ist für Lehrkräfte die Unterstützung des eigenen Unterrichts durch diese Hilfsmittel. Das wesentliche Ziel ist also eine Erfolg versprechende Erweiterung der eigenen Unterrichtskonzepte und -methoden. Hierzu müssen sich die Geräte also als hilfreiche Werkzeuge für den jeweiligen Fachunterricht erweisen. Dies ist am ehesten zu erwarten, wenn eine breite Basis an Apps zur Verfügung steht\vglr{secPersAkz}. Die \textit{Einfachheit der Bedienung} stellt hier ebenfalls einen wichtigen Aspekt dar. Die verwendeten Geräte sollten zudem \textit{einfach bedienbar} und das Bedienkonzept unkompliziert erlernbar sein, damit sie nicht den Blick auf das Wesentliche verstellen, sondern tatsächlich als hilfreiche Werkzeuge genutzt werden können. Da hier generell nur eine Nutzungskompetenz gefordert wird, kann es durchaus zu völlig anderen Auswahlkriterien für einzusetzende Geräte kommen, die zwar für den Einsatz als Werkzeuge im jeweiligen Fachunterricht geeignet sein mögen, jedoch die Einsatzmöglichkeiten im Informatikunterricht stark einschränken\vglr{secKonsum}.
\subsection{Informatiklehrkräfte}\label{secKritInfoLehr}
\subsubsection{Freie Programmierbarkeit}
Informatiklehrkräfte haben grundzätzlich dieselben Anforderungen an die Geräte wie alle anderen Lehrkräfte auch. Ein wesentlicher Unterschied ist allerdings das Ziel der Erreichung informatischer Vernunft. Im Informatikunterricht werden die Geräte nicht nur als Unterrichtsmittel, sondern eben auch als Unterrichtsinhalt verwendet. Hierzu müssen die einzusetzenden Geräte nicht nur die Perspektive der Veränderung der Wirklichkeit\vglr{secPersVer} zulassen, sondern sie müssen es auch erlauben, die Perspektive der Analyse der Wirklichkeit\vglr{secPersAna} einzunehmen. Sie dürfen diese also nicht durch \textit{künstliche Einschränkungen} der Hersteller verstellen\vglr{secKonsum}.
\subsubsection{Early Adopter}
Informatiklehrkräfte zeigen darüber hinaus meist eine starke Technikaffinität. Dies führt zur Tendenz, dass neue technische Gadgets an einer Schule zuerst bei ihnen anzutreffen sind. Sie sind also echte \enquote{Early Adopter}, die damit nicht nur für ihre Kolleginnen und Kollegen sondern auch für die \SuS eine \textit{Vorbildfunktion} einnehmen können, derer sie sich vielleicht nicht einmal bewusst sind. Hier kann es durchaus zu einem Intrarollenkonflikt kommen, da die Ziele von Lehrkraft und Early Adopter durchaus nicht deckungsgleich sind. Die Begeisterung für technische Neuerungen kann hier durchaus systematischen Betrachtungen im Weg stehen. Dies kann dazu führen, dass etwa mobile Informatiksysteme bevorzugt werden, die für den Informatikunterricht nur schlecht oder gar nicht geeignet sind. Dabei könnte durch die Vorbildfunktion eine Basis bei Kolleginnen und Kollegen und \SuSn geschaffen werden, die den möglichen, späteren Einsatz im Unterricht konterkariert.
\subsection{Entwickler/-in}
\subsubsection{nichtkommerziell}
Nichtkommerzielle Entwickler entwickeln meist aus Spaß an der Sache. Sie werden daher in der Regel für Plattformen entwickeln, die sie selbst verwenden. Außerdem werden sie tendenziell eher in Sprachen programmieren wollen, die ihnen bereits bekannt sind. Entsprechend ist die \textit{Verfügbarkeit dieser Sprachen} für die jeweilige Plattform ein wichtiges Kriterium. Zudem wird das Entwickeln ohne kommerziellen Hintergrund begünstigt, wenn viele gute \textit{Werkzeuge und Softwarebibliotheken} und eine ausreichende Dokumentation verfügbar sind. Besonders die Verfügbarkeit von \textit{Open-Source-Software} ist hierbei hilfreich. Beides hängt natürlich stark von der Größe der jeweiligen \textit{Entwicklergemeinschaft} und damit von der \textit{Verbreitung} der Plattform ab. Da kein kommerzieller Hintergrund vorliegt, ist zudem die Frage nach den \textit{Kosten der notwendigen Werkzeuge und Lizenzen} relevant.
\subsubsection{kommerziell}
Kommerzielle Entwickler (sowohl Einzelpersonen, Entwicklerteams als auch Konzerne) haben als oberstes Ziel den \textit{Verkauf der Software}. Dazu gehört meist ein Interesse am Schutz der eigenen Software durch entsprechende \textit{Sperren und Beschränkungen} der Plattform, die das Verändern oder Kopieren der Software verhindern. Das für den erfolgreichen Verkauf wichtigste Argument ist die Anzahl der potentiellen Kunden und damit die \textit{Verbreitung} der Plattform. Dies kann zwar in bestimmten Sparten durch hohe Preise kompensiert werden (etwa für Spezialsoftware), im Kontext der mobilen Informatiksysteme und speziell für den schulischen Bereich ist dies jedoch nicht relevant. Die Preise für Apps sind hier im Allgemeinen sehr niedrig.
Die Verfügbarkeit entsprechender \textit{Entwicklungswerkzeuge} ist natürlich auch für kommerzielle Softwareentwickler wichtig. Jedoch sind hier ganz andere Kriterien entscheidend. Während ein nichtkommerzieller Entwickler durchaus leicht mit sehr einfachen Werkzeugen auskommen kann, setzen die meisten kommerziellen Entwickler auf \textit{umfangreichere Entwicklungsumgebungen}, mit denen viele Arbeitsschritte automatisiert oder vereinfacht werden können. Die Kosten für Entwicklungswerkzeuge und Lizenzen spielen im kommerziellen Bereich keine große Rolle, da sie in der Regel nur einen kleinen Teil der gesamten Entwicklungskosten ausmachen. Auch die Verfügbarkeit einer bestimmten, bevorzugten Programmiersprache ist nicht zwingend notwendig, wenngleich wünschenswert, solange die Absatzmöglichkeiten groß genug sind. Natürlich profitieren auch kommerzielle Entwickler von der Verfügbarkeit umfangreicher \textit{Softwarebibliotheken}. Doch werden hier oft kommerzielle Varianten eingekauft oder selbst entwickelte eingesetzt, sodass keine unmittelbare Abhängigkeit von der Größe der Entwicklergemeinschaft besteht. Eine nur kleine Menge von Konkurrenten kann sogar sehr nützlich sein.
\subsection{Produzierendes Unternehmen}\label{secKritProd}
Die Hersteller mobiler Informatiksysteme haben eine zentrale Anforderung an die Geräte: Sie \textit{sollen sich verkaufen}. Daher wird das Unternehmen solche Geräte herstellen, die sich entweder bereits gut verkaufen (zumindest in ähnlicher Form) oder denen gute Verkaufschancen prognostiziert werden. Eine vorhandene Infrastruktur einer Plattform kann und wird hier grundsätzlich zu einer Pfadabhängigkeit und damit einer tendenziellen Stärkung dieser Plattform beitragen. Ein Wechsel wird nur dann erfolgen, wenn eine bei den Kunden beliebtere Alternative entsteht. Die Unternehmen haben darüber hinaus ein großes Interesse daran, neue Produkte zu verkaufen. Langfristiger Support ist daher gerade im Endkundenbereich die Ausnahme. Man muss sogar bei einigen Konstruktionen vermuten, dass diese mit der Absicht so angeboten werden, dass die Geräte nach einiger Zeit wertlos werden. Fest verbaute Akkus sind hierfür das Paradebeispiel.
\section{Kriterien für den Einsatz in der Schule}\label{secKrit}
Nun wurden bereits viele Kriterien für die einzelnen Rollen genannt. Doch welche davon müssen für die Auswahl und Gestaltung der Informatiksysteme in der Schule berücksichtigt werden?
\subsection{Notwendige Voraussetzungen}
\subsubsection{Sinnvolle Einbindung}\label{secKritEin}
Das grundlegende Kriterium entspringt direkt den beiden am offensichtlichsten betroffenen Rollen, der der \SuS sowie der der Lehrkräfte. Die Einbindung der Geräte muss \textit{sinnvoll} möglich sein. Unter Berücksichtigung der oben genannten Anforderungen bedeutet dies also: Die Vorgaben müssen sich damit umsetzen lassen und für die \SuS muss der Sinn der Nutzung erkennbar sein. Es müssen also tatsächlich relevante Vorteile gegenüber der Nichtnutzung erkennbar werden. Für den Informatikunterricht bedeutet dies in erster Linie, dass es im Zusammenhang mit den Geräten problemlos möglich sein muss, die beiden Perspektiven nach \cite{Heming2009} einzunehmen. Reine Nutzung allein ist im Kontext des Informatikunterrichts nicht sinnvoll. Es muss möglich sein, zumindest Software und selbst erstellten Quellcode \textit{uneingeschränkt ausführen} zu können und Dateien zwischen verschiedenen Geräten einfach \textit{auszutauschen}, um etwa Ergebnisse zu präsentieren oder neue Aufgaben zu verteilen. Insbesondere für die gemeinsame Bearbeitung von Aufgaben in Partner- oder Gruppenarbeit ist das wichtig.
\subsubsection{Programmierbarkeit}\label{secKritProg}
Um die Perspektive der Veränderung der Wirklichkeit\vglr{secPersVer} einnehmen zu können, bedarf es der Möglichkeit, die Geräte programmieren zu können. Doch dass dies irgendwie möglich ist, reicht keineswegs aus. Um alle Vorteile der mobilen Informatiksysteme für den Informatikunterricht nutzbar zu machen, ist es notwendig, dass das \textit{Programmieren mit den Geräten} möglich ist. Dabei muss eine Programmiersprache zur Verfügung stehen, die aus didaktischer Sicht geeignet ist. Die Kriterien nach Linkweiler \citep[S.~22~ff.]{LinkweilerDA2002} bieten hier eine gute Entscheidungsbasis. Die derzeitige Sprache der Wahl ist zweifelsfrei \textit{Python}.
\subsubsection{Verfügbarkeit von Werkzeugen und Dokumentation}\label{secKritWerk}
Da die Schüler im Informatikunterricht als Entwickler tätig werden, müssen entsprechende Werkzeuge zur Verfügung stehen. Die Werkzeuge, die Programmiersprache und die evtl. verwendeten Bibliotheken müssen dabei ausreichend dokumentiert sein.
Die Kriterien für die Schule orientieren sich deutlich stärker an den nichtkommerziellen Entwicklern, denn es ist nicht das Ziel der allgemeinbildenden Schulen, professionelle Entwickler hervorzubringen\vgl{HumbertProgrammieren}{2}. Vielmehr erscheint es aus didaktischer Sicht sogar sinnvoll, sehr einfache, reduzierte Werkzeuge einzusetzen. Dies kann nicht nur den Blick auf das Wesentliche freimachen\vglr{secKritLehr}, sondern trägt auch zu einer einfacheren Bedienbarkeit bei. Diese ist, wie bereits festgestellt, für alle Anwenderinnen und Anwender sowie in besonderem Maße für \SuS\vglr{secKritSuS} und Lehrkräfte\vglr{secKritLehr} wichtig.
Was jedoch in jedem Fall erforderlich ist, sind ein guter \textit{Editor} und eine geeignete Eingabemethode (bei mobilen Informatiksystemen heute in der Regel eine \gls{OSTastatur}). Der Editor muss aus Gründen der einfachen Bedienbarkeit zumindest über die Möglichkeiten verfügen, mehrere Quelldateien zu bearbeiten und einfach zwischen ihnen zu wechseln, sowie Quelldateien direkt ausführen bzw. compilieren zu können. Die Eingabemethode muss die einfache Eingabe programmiertypischer Zeichen erlauben. Es ist unzumutbar, wenn für jede Klammer in die siebte Shift-Ebene der virtuellen Tastatur gewechselt werden muss.
Einfache Eingabehilfen wie automatische Vervollständigung sind auf den mobilen Informatiksystemen wegen der begrenzten Eingabemöglichkeiten wünschenswert, aber nicht zwingend erforderlich.
\subsubsection{Kosten}\label{secKritKost}
Ein für den schulischen Einsatz absolut relevantes Kriterium sind die Kosten. Einerseits sind natürlich die Anschaffungskosten für schulische Geräte aufzubringen. Andererseits müssen die Geräte evtl. noch mit passender Software ausgestattet werden.
Sollen Geräte der \SuS eingesetzt werden, verringert sich die Bedeutung dieses Punktes zwar, es ergibt sich jedoch die neue Frage, wie mit evtl. notwendigen Anschaffungskosten der Software umgegangen werden kann. Bei kommerzieller Software ist die Nutzung von der Schule beschaffter Software in der Regel nicht möglich und rechtlich problematisch, da die Software bei den aktuellen mobilen Systemen an den Appstore-Account des Besitzers gebunden wird und die Installation auf Geräten, die nicht mit diesem Account verbunden sind, nicht möglich ist. Da die Geräte im Besitz der \SuS sind, wäre es rechtlich nicht möglich, diese Accounts zusätzlich auf den Geräten einzurichten, sofern dies technisch überhaupt praktikabel ist. Es empfiehlt sich also die Nutzung \textit{Freier Software}\vglr{secKritOSS}.
\subsubsection{Alltagsbezug und Verbreitung}\label{secKritVer}
Die Verbreitung einer Plattform ist für die Schule ein wesentliches Kriterium, denn im Wesentlichen haben verbreitete (mit Ausnahme neuer) Plattformen die besten Aussichten auf eine langfristige Verfügbarkeit. Außerdem kann nur bei verbreiteten Plattformen davon ausgegangen werden, dass die entsprechenden Geräte zum Alltag vieler \SuS gehören. Die reine Verbreitung reicht allerdings nicht aus. Es muss darauf geachtet werden, dass entsprechende Geräte tatsächlich im Umfeld der \SuS verbreitet sind. So sind etwa reine Business-Smartphones tendenziell eher ungeeignet. Aber auch absolute Luxusmodelle scheiden von vornherein (eben nicht nur wegen der Kosten) aus. Der Aspekt der sozialen Situation\vglr{secNachtUng} der \SuS muss hierbei stets mit bedacht werden.
Der Alltagsbezug ist, wie bereits vielfach angemerkt, ein zentraler Punkt der Konzepte zur Einbeziehung mobiler Informatiksysteme in den Unterricht. Daher muss dieser gewahrt werden. Hierzu ist es neben der Nutzung einer im Umfeld der \SuS verbreiteten Plattform relevant, dass die Anforderungen von Jugendlichen\vglr{secKritJu} mit in die Auswahl einbezogen werden. Hierzu gehört die Nutzbarkeit der Geräte für Kommunikations- und Unterhaltungszwecke ebenso wie ausreichende Möglichkeiten zur Individualisierung\vglr{secKritJuIndiv}. Denn nur wenn die Geräte tatsächlich alltäglich genutzt werden, können die erhofften Vorteile der Nutzung eintreten.
\subsubsection{Langlebigkeit}\label{secKritLang}
Ist die Langlebigkeit der Geräte, insbesondere aus Kostengründen, eine grundsätzliche Anforderung aller Anwenderinnen und Anwender mobiler Informatiksysteme\vglr{secKritAnwLang}, so gilt diese für den schulischen Einsatz in besonderem Maße. Die Geräte können hier einerseits durchaus härteren Belastungen ausgesetzt sein, andererseits müssen gerade schuleigene Geräte aus haushaltsrechtlichen Gründen längerfristig eingesetzt werden. Es ist also besonders wichtig, Geräte mit Aussicht auf \textit{lange verfügbaren Support durch den Hersteller} (Verfügbarkeit von Updates und evtl. sogar Garantieleistungen) auszuwählen. In diesem Sinne sollten Geräte mit eingebautem Verfallsdatum, etwa fest verbauten Akkus gemieden werden.
Diese Anforderung kollidiert bis zu einem gewissen Punkt mit den Interessen der Gerätehersteller\vglr{secKritProd}. Die Berücksichtigung dieses Kriteriums wird daher tendenziell die Kosten erhöhen, da die Geräte mit besserer Unterstützung durch die Hersteller in der Regel teurer sind.
\subsection{Wünschenswerte Eigenschaften}
\subsubsection{Gute Ausstattung}
Eine gute Ausstattung der Geräte sowohl im Bezug auf Rechenleistung, Softwareangebot und Hardwareausstattung ist wünschenswert. Es muss jedoch wie im \referenz{secNachtUng} beschrieben, darauf geachtet werden, dass es bei Verwendung unterschiedlicher Geräte im Unterricht durch die Ausstattung nicht zu Benachteiligungen kommt.
\subsubsection{Freie Software}\label{secKritOSS}
Die Nutzung Freier Software kann dazu beitragen, Kosten zu senken, da diese meist kostenfrei angeboten wird. Außerdem können Probleme mit nötigen Lizenzen damit vermieden werden. So wird die Nutzung von Geräten der \SuS problemlos möglich, da die notwendige Software entweder direkt zur Verfügung steht oder weitergegeben werden darf. Freie mobile Plattformen sind zudem tendenziell besser geeignet, da sie weniger oder keine künstlichen Einschränkungen aufweisen und sich besser an die Bedürfnisse der Schule anpassen lassen.
\subsubsection{Umweltfreundlichkeit und Sozialverträglichkeit}
Zugegebenermaßen ist es derzeit schwierig, Geräte zu finden, die umwelfreundlich und sozialverträglich produziert werden. Dennoch steht die Institution Schule aus Sicht des Autors in der Verantwortung, diese Punkte zu berücksichtigen. Schließlich soll sie die \SuS auf ein verantwortungsbewusstes, selbstbestimmtes Leben in der Gesellschaft vorbereiten. Sollte also ein, selbst etwas schlechter ausgestattetes oder ein wenig teureres Gerät, verfügbar sein, so sollte dies anderen Geräten vorgezogen werden.
Grundsätzlich kann die Berücksichtigung des Kriteriums der Langlebigkeit schon einen Beitrag zur Umweltfreundlichkeit und Sozialverträglichkeit leisten. Sollte es aber zukünftig echte \enquote{Green-IT} geben, die nicht nur dem Marketing dient, sollte der Einsatz entsprechender Geräte in der Schule präferiert werden.

View file

@ -0,0 +1,208 @@
\chapter{Auswahl mobiler Informatiksysteme für den Unterricht}\label{chpAuswahl}
\section{Geräteauswahl}\label{secGerAusw}
Im Gegensatz zur Situation vor einigen Jahren, als die Arbeiten von \cite{Carrie2006} und \cite{Heming2009} entstanden, ist es heute relevanter, sich für eine Plattform, als für ein bestimmtes Gerät\footnote{Da sich das Angebot an Geräten sehr schnell ändert und einige Modelle nur für wenige Monate oder sogar nur in einzelnen Aktionen erhältlich sind, ist es nicht sinnvoll, konkrete Modelle anzugeben. Für diese Arbeit wurden die folgenden Modelle getestet, die allesamt die vollständigen Möglichkeiten der jeweiligen Plattform unterstützen. \textit{Android}: Medion Lifetab S9512, Samsung Galaxy Ace, Samsung Galaxy Fit, Samsung Galaxy S, Samsung Galaxy Tab (P1000), Sony Xperia U, Touchlet X4 (mit Einschränkungen bei der \gls{SL4A} und Kivy, außerdem eher träge); \textit{BlackBerry OS}: BlackBerry Curve 8520; \textit{iOS}: iPad 1, iPad 2, iPhone 3GS, iPhone 4, iPhone 4S, iPod Touch 3G, iPod Touch 4G; \textit{Windows Phone}: Nokia Lumia 610, Nokia Lumia 800. Die Samsung-Geräte geizten ähnlich mit Standardschnittstellen wie die von Apple und \gls{RIM} (BlackBerry). Dagegen haben sich die folgenden Geräte wegen deutlicher Verarbeitungsmängel oder starker Einschränkungen der durch die Plattform vorgegebenen Möglichkeiten als ungeeignet erwiesen: \textit{Android}: Motorola Backflip, ZTPad ZT-280; \textit{iOS}: iPhone 3.} zu entscheiden, da diese die Fähigkeiten und Einschränkungen der Geräte wesentlich mitbestimmen. Die Frage der richtigen Plattform stellte sich damals natürlich in dieser Form nicht, da nur eine Plattform, nämlich Symbian S60 zur Verfügung stand. Die konkrete technische Ausstattung der Geräte ist nur noch als sekundär zu betrachten, da es für alle im Moment relevanten Plattformen diverse Modelle gibt. Dies gilt zumindest, wenn man sich auf \textit{Smartphones}, \textit{Hybride} und \textit{Tablets} beschränkt, was derzeit aufgrund der Leistungsfähigkeit und Ausstattung der Geräte sinnvoll erscheint. Außerdem ist mit diesen am ehesten die Entwicklung auf den Geräten möglich. Die Frage nach dem Gerätetyp tritt auch insofern in den Hintergrund, als die meisten Plattformen jeweils für unterschiedliche Gerätetypen zur Verfügung stehen. Es besteht also inzwischen die komfortable Situation, nicht mehr exklusiv zwischen verschiedenen Gerätetypen entscheiden zu müssen. So sind gemischte Einsatzszenarien denkbar.
Die technischen Details der einzelnen Gerätetypen treten also, anders als noch in \cite{Spittank2011} vermutet, in den Hintergrund. Trotzdem muss eine gewisse technische Mindestausstattung als notwendige Grundlage betrachtet werden. So müssen sie etwa, da in der Schule -- zumindest bei schuleigenen Geräten -- standardmäßig kein Zugang zu Mobilfunknetzen genutzt werden kann, in der Lage sein, sich mit einem \gls{WLAN} zu verbinden. Zur schnellen und bequemen Vernetzung (etwa zum Austausch von Nachrichten) sollten sie über \textit{Bluetooth} verfügen. Auch weitere Standard-Schnittstellen sind hilfreich, jedoch nicht unbedingt erforderlich. Zu nennen sind hier etwa \textit{USB-Host} oder ein \textit{Videoausgang} zum Anschluss an einen Beamer zur Präsentation von Ergebnissen.
Zumindest eine \textit{Kamera} sollte aufgrund der vielfältigen Anwendungsmöglichkeiten, wie sie in \cite{Heming2009} beschrieben werden, vorhanden sein. Weitere \textit{Sensoren} und \textit{Ortungsmodule} können die Einsatzmöglichkeiten bereichern, sind jedoch nicht zwingend erforderlich. Eine lange \textit{Akkulaufzeit} erscheint hier als wichtigeres Kriterium. Außerdem sollte der \textit{Akku austauschbar} sein.
Ein \textit{kapazitiver Touchscreen} sollte heute auf jeden Fall einem resistiven Modell vorgezogen werden, da die Bedienung damit deutlich angenehmer und flüssiger möglich ist. Die verwendete Display-Technologie spielt hingegen keine wesentliche Rolle für den Unterricht. Lediglich könnte man hier festhalten, dass eine \textit{höhere Auflösung} besser ist, da sich Texte dann leichter lesen lassen. Der Einblickwinkel des Displays spielt hingegen keine besonders große Rolle, da die Arbeit an den Geräten aufgrund ihrer Größe tendenziell allein erfolgt.
Generell sollte für schulische Geräte das Kriterium der Langlebigkeit\vglr{secKritLang} berücksichtigt werden. Zumindest sollten die Geräte einigermaßen gut verarbeitet sein und längere Benutzung unbeschadet überstehen. Vorteilhaft wäre es, wenn die Geräte kleinere Stürze überleben würden, daher kann die Anschaffung \textit{zusätzlicher Schutzhüllen} sinnvoll sein. Dies setzt wiederum eine gewisse Verbreitung\vglr{secKritVer} voraus, damit diese überhaupt als Zubehör angeboten werden. Auch die Verfügbarkeit von Ersatzteilen (vor allem Akkus) und Reparaturmöglichkeiten sollte berücksichtigt werden.
Aktuell würde der Autor den Einsatz von Smartphones und Hybriden empfehlen, da diese derzeit noch einen stärkeren Alltagsbezug aufweisen als Tablets und zumindest die Smartphones sehr günstig zu bekommen sind. Durch die zunehmende Verbreitung von Tablets kann sich dies jedoch schnell ändern. Beim Einsatz von Smartphones ist eine gewisse Vorsicht geboten, da nach Erfahrungen des Autors nicht alle Smartphones vollständig ohne SIM-Karte betrieben werden können, obwohl die Betriebssyteme dies grundsätzlich zulassen. Auf einigen Plattformen (bzw. von einigen Apps) wird das \gls{SIM} als eindeutiges Identifikationsmerkmal für die Lizensierung kommerzieller Applikationen verwendet, sodass diese nicht ohne eigelegte SIM-Karte funktionieren.
Insgesamt sollten bei der Anschaffung schuleigener Geräte diese auf jeden Fall zuvor auf die Kriterien hin überprüft werden. Durch Anpassungen der Gerätehersteller an den Betriebssystemen könnte man sonst unangenehme Überraschungen erleben. Teilweise schränken diese nämlich Funktionen und Eigenschaften ein, die die Plattformen grundsätzlich besitzen.
Das optionale Kriterium \enquote{Umweltfreundlichkeit und Sozialverträglichkeit} sollte ebenfalls berücksichtigt werden. Dass dies im Moment nur sehr eingeschränkt möglich ist, wurde bereits bei der Beschreibung des Kriteriums erwähnt. Trotzdem kann dieses Kriterium zumindest teilweise befolgt werden, wenn das Kriterium der Langlebigkeit erfüllt ist.
\section{Plattformauswahl}
Wünschenswert wäre es natürlich -- insbesondere unter dem Aspekt der Einbindung von den \SuSn gehörenden Geräten in den Unterricht --, wenn mit denselben Unterrichtsmaterialien alle relevanten Plattformen abgedeckt werden könnten, sodass diese gleichberechtigt im Unterricht eingesetzt werden könnten. Hierauf wird im \referenz{chpGestaltung} zur Gestaltung der mobilen Informatiksysteme für den Unterricht noch genauer eingegangen.
\subsection{Vorauswahl -- Systemrelevanz}
Trotzdem muss zunächst betrachtet werden, inwieweit die verschiedenen verfügbaren Plattformen sich überhaupt für den Einsatz im Unterricht eignen. Aus rein praktischen Gründen stellt sich zudem die Frage, welche Plattformen vorrangig betrachtet werden sollten. Offensichtlich sind also für eine Vorauswahl zunächst die Kriterien der Verbreitung und des Alltagsbezugs\vglr{secKritVer} von Bedeutung.
Die \referenz{figOSMarkt} stellt hier die aktuelle Verbreitung der verschiedenen Plattformen sowie die Veränderung zum Vorjahr dar. Die Ergebnisse der Erhebung \citep{Bitkom2012a} passen zu denen der früher, aber ebenfalls von comScore durchgeführten Studie \citep{comscore2012}. Andere Studien kommen hier zu tendenziell ähnlichen Ergebnissen. Einzig das \gls{OMP} \citep{OMP} weicht hier deutlich ab. Dies mag aber daran liegen, dass die Daten auf einer Umfrage basieren, die die Antwort \enquote{weiß nicht} zuließ, die mit einem Anteil von 15\,\% der Befragten viel Zuspruch erhielt.
Zur Verbreitung der Plattformen bei Jugendlichen gibt es leider keine stichhaltig belegbaren Ergebnisse. Android und iOS sind aber auch hier beliebt. Nach den (natürlich keineswegs repräsentativen) Erfahrungen des Autors liegt Android derzeit mit leichtem Vorsprung vor iOS, während die anderen Plattformen praktisch keine Rolle spielen.
\DTLloaddb[]{csSPOS}{chartdata/comscore/smartphone_os.csv}
\begin{figure}[htbp]
\begin{scriptsize}
\centering
\begin{normalsize}
\textbf{Marktanteile von Smartphone-Betriebssystemen in Deutschland}
\end{normalsize}
\vspace{0.5cm}
\DTLsetpiesegmentcolor{1}{green}
\DTLsetpiesegmentcolor{2}{grayTwo}
\DTLsetpiesegmentcolor{3}{yellow}
\DTLsetpiesegmentcolor{4}{blue}
\DTLsetpiesegmentcolor{5}{black}
\DTLsetpiesegmentcolor{6}{red}
\DTLpiechart{
variable=\datpz,
radius=2.5cm,
cutaway={1-2,3},
innerratio=0.8,
innerlabel={},%\DTLpiepercent\,\%},
outerlabel={\datn\ -- \textbf{\datpz\,\%}\ (\datpe\,\%)}%
}{csSPOS}{\datn=Name,\datpz=2012,\datpe=2011}
\setlength{\DTLbarwidth}{10pt}
\setcounter{DTLbarroundvar}{0}
\setlength{\DTLticklabeloffset}{10pt}
\setlength{\DTLbarlabeloffset}{20pt}
\DTLsetbarcolor{1}{green}
\DTLsetbarcolor{2}{grayTwo}
\DTLsetbarcolor{3}{yellow}
\DTLsetbarcolor{4}{blue}
\DTLsetbarcolor{5}{black}
\DTLsetbarcolor{6}{red}
\vspace{1cm}
\begin{normalsize}
\textbf{Veränderung der Marktanteile von 2011 bis 2012}
\end{normalsize}
\vspace{0.5cm}
\DTLbarchart{variable=\datd,upperbarlabel={\datn\ -- \textbf{\datd}},
ylabel={Veränderung in Prozentpunkten 2012 zu 2011},verticalbars=false,axes=y,yticgap=10,
maxdepth=-20,max=30}{csSPOS}{\datd=Differenz,\datn=Name}
\caption[Smartphone-Betriebssysteme (Deutschland, 2012)]{Betriebssysteme von aktiven Smartphones in Deutschland für das Jahr 2012, Werte des Jahres 2011 in Klammern, jeweils 1. Quartal, nach einer Presseveröffentlichung des \gls{BITKOM}, Quelle: \cite{Bitkom2012a}}\label{figOSMarkt}
\end{scriptsize}
\end{figure}
Hieraus und aus der allgemeinen Verbreitung\vglr{figOSMarkt} wird deutlich, dass die beiden relevantesten Plattformen iOS und Android sind. Bei einem Blick auf die Veränderungen erkennt man zudem, dass Windows deutliche Umsatzeinbußen verzeichnen musste, was mit der Plattformumstellung auf Windows Phone 8 zu tun haben kann. Die Abkündigung von Symbian durch Nokia hatte hingegen einen dramatischen Einbruch der Marktanteile dieser Plattform zur Folge. Symbian und HPs Tabletbetriebssytem WebOS sind zwar inzwischen als Open-Source-Software verfügbar, es ist jedoch bisher nicht abzusehen, ob sich ein Hersteller findet, der entsprechende Hardware anbieten wird.
Windows scheint derzeit bei \SuSn nicht sonderlich verbreitet zu sein, allerdings, muss es -- vor allem im Hinblick auf den Plattformwechsel zu Windows (Phone) 8 -- trotzdem weiter betrachtet werden. BlackBerry OS hingegen ist weder vom Marktanteil noch von der Ausrichtung der Plattform für die Schule relevant. Es ist voll und ganz auf den geschäftlichen Einsatz ausgerichtet und verfehlt sowohl im Hinblick auf die Individualisierbarkeit, als auch bei den Unterhaltungsmöglichkeiten (vor allem bei Spielen) die Anforderungen der Jugendlichen\vglr{secKritJu} und damit das Kriterium des Alltagsbezugs\vglr{secKritVer}. Da außerdem bei den Kommunikationsfunktionen spezielle BlackBerry-Produkte und besondere Tarife der Mobilfunkanbieter notwendig sind, wird das Kostenkriterium\vglr{secKritKost} ebenfalls verfehlt. Es gibt zwar Anzeichen dafür, dass der Hersteller hier sein Konzept anpassen wird, derzeit rechtfertigt dies aber keine besondere Betrachtung.
Kurz zusammengefasst kann man also festhalten, dass derzeit lediglich die Plattformen iOS, Android und Windows wirklich relevant sind. iOS und Android weisen den höchsten Alltagsbezug und die höchste Verbreitung auf. Trotzdem werden im \referenz{secPlatOth} noch einige weitere, derzeit nicht relevante Plattformen betrachtet, die möglicherweise in Zukunft gute Alternativen sein könnten.
\input{imgs/mobos/mobos_preamble.tex}
\subsection{iOS}
\begin{figure}[htbp]
\centering
\begin{scriptsize}
\textsf{\input{imgs/mobos/mobos_app.tikz}}
\end{scriptsize}
\caption{Abstammung von mobilen Betriebssystemen 1: iOS}\label{figPlatApp}
\end{figure}
\subsubsection{Sinnvolle Einbindung und Programmierbarkeit}
Apples iOS ist sowohl für Tablets (iPad), Smartphones (iPhone) und Multimediaabspielgeräte (iPod Touch und AppleTV) verfügbar\vglr{figPlatApp}. Dabei sind die bei \SuSn verbreiteten iPhones und iPods von der Leistung und Ausstattung gleichermaßen für den Unterrichtseinsatz geeignet. Die iOS-Geräte sind allerdings reine \glspl{KonsumG}\vglr{secKonsum}. Die vorhandenen Einschränkungen, etwa der fehlende Zugriff auf das Dateisystem, die eingeschränkten Möglichkeiten zum Austausch von Dateien, die exklusive Bindung an Apples Distributionskanäle für digitale Inhalte und rigide rechtliche Beschränkungen zusammen mit der festen Bindung an Apples Cloud-Infrastruktur erschweren die kritische Benutzung der Plattform. Zudem gibt es für die Apps, zumindest bis zum noch nicht veröffentlichten iOS 6, kein Rechtesystem für den Zugriff auf API-Funktionen mit Ausnahme des Zugriffs auf die Ortungsfunktionen. Es ist also zu keinem Zeitpunkt ersichtlich, was die Apps tatsächlich tun. Ein Spiel könnte also nebenbei etwa Kontaktdaten auslesen und ins Internet senden. Damit ist die Einnahme der analytischen Perspektive zumindest erschwert.
Eine Programmierung der Geräte ohne Zuhilfenahme von stationären Informatiksystemen ist nicht vorgesehen. Zudem erfordert die Entwicklung für die Geräte einen kostenpflichtigen Entwicklerzugang, ohne den keine Apps auf echten Geräten installiert werden können, und Informatiksysteme mit Mac OS X, also Apple-Rechner. Es ist also von mittleren bis hohen zusätzlichen \textit{Kosten} auszugehen. Für die Programmierung steht außerdem im Wesentlichen nur die appleeigene Programmiersprache ObjectiveC zur Verfügung, die im Hinblick auf die Kriterien eher ungeeignet erscheint. Vor allem die Orthogonalität (Verwendung von Klammern u.~a.~m.) und die einfache Erlernbarkeit sind nicht gegeben.
Die Ausführung von Code, der nicht aus dem Appstore stammt, ist nicht zulässig, damit sind keine Interpreter und Compiler für iOS möglich\footnote{Tatsächlich gibt es zwar einige entsprechende Apps, diese behelfen sich jedoch durch Tricks. Mit der App \enquote{Codea} etwa kann zwar programmiert und der Code ausgeführt werden, ein Export des Codes vom eigenen Gerät herunter (auch über die Zwischenablage) ist jedoch ebenso unmöglich wie der Import von fremdem Code. Mit \enquote{Python for iOS} ist dies zwar möglich, dafür stehen nur eine Textkonsole und Standard-Python-Pakete zur Verfügung. Zugriff auf die \glspl{API} von iOS erhält man damit auch nicht.}. Einzig die Entwicklung von Webapps wäre möglich, jedoch aufgrund des fehlenden Dateisystemzugriffs nur mittels eines externen Servers. Durch die fehlende Programmierbarkeit erübrigt sich die Frage nach der \textit{Verfügbarkeit von Werkzeugen und Dokumentation} natürlich direkt. Außerdem wird so durch den fehlenden Zugang zur Perspektive der Veränderung der Wirklichkeit das Sinn-Kriterium auf Seiten der \SuS konterkariert, da sich durch den Unterrichtseinsatz keine neuen Möglichkeiten im Alltag ergeben.
\subsubsection{Andere Kriterien}
Zwar hat sich die Plattform an dieser Stelle bereits disqualifiziert, aber aufgrund ihrer hohen Verbreitung sollen die übrigen Kriterien der Vollständigkeit halber zumindest noch knapp angesprochen werden.
Die Geräte von Apple sind zwar vergleichsweise hochpreisig, dafür sind sie aber gut verarbeitet und weisen generell eine recht hohe Lebensdauer auf. Allerdings wird dieser positive Eindruck durch die fest verbauten Akkus konterkariert, die nicht nur die Lebensdauer verringern, sondern auch das optionale Kriterium \textit{Umweltfreundlichkeit und Sozialverträglichkeit} negativ beeinflussen. Die andauernden Berichte in den Medien über schlechte Arbeitsbedingungen in den Produktionsländern tragen nicht zu einer besseren Bewertung für dieses Kriterium bei.
Generell bieten die Geräte eine gute Ausstattung, allerdings verfügen sie nicht über Standardschnittstellen (HDMI oder analoge Videoausgabe sind über einen recht teuren Adapter möglich) und übliche Erweiterungsmöglichkeiten. Allerdings gibt es sehr viel proprietäres Zubehör. Die eingebaute Bluetoothunterstützung kann nur für den Anschluss von Audiogeräten und proprietäre Profile genutzt werden. Der übliche Datenaustausch ist nicht möglich.
Viele Open-Source-Lizenzen, nämlich alle, die öffentliche Zugänglichmachung des Codes erfordern (\zb die \gls{GPL}), sind nicht mit den Bedingungen von Apples Appstore kompatibel. Dies führt dazu, dass nur wenig Freie Software im Appstore zu finden ist.
Der Vollständigkeit halber sei erwähnt, dass es mittels \gls{Jailbreaking} möglich wäre, alle relevanten Einschränkungen zu umgehen. Im dann zugänglichen, alternativen Appstore Cydia finden sich Python und andere Freie Software. So wäre es möglich, eine didaktisch fundierte Klassenbibliothek zu entwickeln und die Geräte vollumfänglich im Informatikunterricht zu nutzen. Doch das Jailbreaking ist leider für die Schulen derzeit keine Option\vglr{secKonsum}. Sollten die Einschränkungen irgendwann aufgehoben werden, wovon nicht auszugehen ist, oder das Jailbreaking rechtlich unproblematisch werden, wäre iOS eine nahezu ideale Plattform für den Informatikunterricht.
\subsection{Android}
\begin{figure}[htbp]
\centering
\begin{scriptsize}
\textsf{\input{imgs/mobos/mobos_lin.tikz}}
\end{scriptsize}
\caption{Abstammung von mobilen Betriebssystemen 2: Linux}\label{figPlatLin}
\end{figure}
\subsubsection{Sinnvolle Einbindung}
Android ist das derzeit am weitesten verbreitete mobile Betriebssystem\vglr{figOSMarkt}. Allerdings wird Android inzwischen auch auf anderen Informatiksystemen genutzt. Dazu zählen Multimediaabspielgeräte, Setopboxen und Fernseher (GoogleTV) aber auch Autoradios, Navigationssysteme und andere Exoten. Sogar eine Spielekonsole auf Android-Basis (Ouya) wurde bereits angekündigt. Da Android sogar auf x86-Systemen läuft, steht einer Verwendung mit stationären Informatiksystemen ebenfalls nichts im Wege. (Korrekt erstellte) Apps laufen auf all diesen Systemen gleichermaßen. Android-Geräte sind häufig bei \SuSn anzutreffen. Aufgrund der auf \textit{ Freier Software} gründenden Basis gibt es keine wesentlichen, künstlichen Einschränkungen. Lediglich die Modifikation des Betriebssystems selbst oder die Installation eines selbst erzeugten Betriebssystems bedürfen in der Regel des Rootings der Geräte. Allerdings fehlen dem normalen Android einige, von Desktop-Linux-Distributionen bekannte Softwarebibliotheken. Dies ist für die Nutzung im Unterricht aber nur in einigen, wenigen Fällen relevant\vglr{chpAndroid}.
Die Nutzung der Geräte zu Kommunikations- und Unterhaltungszwecken ist problemlos möglich, das App-Angebot ist riesig und inzwischen fast so groß wie bei iOS. Im offiziellen Appstore sind, anders als bei anderen Plattformen, sehr viele Open-Source-Apps zu finden. Die Installation von Apps aus Fremdquellen ist möglich, somit gibt es auch diverse alternative Appstores. Dabei ist Android das am stärksten individualisierbare System. Selbst ohne Rooting lässt sich nahezu die gesamte grafische Oberfläche inklusive diverser Standardprogramme austauschen.
Die kritische Nutzung wird dadurch begünstigt, dass ein grundlegendes Rechtesystem für Apps existiert. Vor Installationen wird detailliert angezeigt, welche Berechtigungen eine App erfordert. Benutzer oder Benutzerinnen können dann entscheiden, ob sie dies akzeptieren. Eine Einschränkung der Berechtigungen einer App ist entweder mittels Rooting oder per Modifikation der Manifest-Datei der jeweiligen App möglich. Dazu ist inzwischen mit AppGuard eine entsprechende App aus dem Umfeld der Universität Saarbrücken verfügbar\vgln{AppGuard}. Die beiden letzteren Möglichkeiten sind allerdings mit dem Verlust der regulären Updatefunktion verbunden. Updates für die veränderten Apps müssen danach manuell installiert und erneut angepasst werden.
\subsubsection{Programmierbarkeit}
Bei Android bestehen derzeit mindestens vier verschiedene Möglichkeiten zur Programmierung mit den Geräten für die Geräte. Außerdem bestehen weitere Möglichkeiten etwa über WebApps, grafische Programmierung oder auf Makros basierenden Automatisierungstools. Natürlich ist die Programmierung für die Geräte mit einem stationären Informatiksystem möglich. Es lassen sich allerdings auch reguläre Apps nur mittels der mobilen Informatiksysteme erzeugen. Die verschiedenen Ansätze werden im \referenz{chpAndroid} noch ausführlicher diskutiert. Die \enquote{Verfügbarkeit von Werkzeugen und Dokumentation}, die bei allen Ansätzen unterschiedlich ist, wird dort ebenfalls erörtert.
\subsubsection{Kosten}
Android-Geräte gibt es in allen Preislagen. Es ist hier letztlich eine Frage der gewünschten Ausstattung, wieviel man für ein konkretes Gerät bezahlen muss. Weitere direkte Folgekosten entstehen bei Android nicht. Durch die Verfügbarkeit von Open-Source-Software kann ein großer Teil des schulischen Bedarfs abgedeckt werden. Eine kostenpflichtige Registrierung als Entwickler gibt es nicht, auch die Veröffentlichung von Apps im Google Play Store ist nicht mit Kosten verbunden.
\subsubsection{Langlebigkeit}
Es gibt extrem günstige Geräte mit Android, die teilweise sehr schlecht verarbeitet sind. Bei den meisten Geräten ist dies jedoch kein Problem.
Wie bei anderen Plattformen sind bei Tablets die Akkus in der Regel fest verbaut, sodass die Lebensdauer eingeschränkt wird. Bei anderen Android-Geräten ist dies jedoch die absolute Ausnahme.
Sehr schwer wiegt allerdings das Problem der Fragmentierung von Android. Da die Hersteller in der Regel starke Anpassungen am System vornehmen, sind diese vollumfänglich für Updates zuständig. Die Versorgung mit Updates ist daher sehr stark herstellerabhängig. Lediglich gerootete und die von Google direkt oder in Kooperation mit bestimmten Partnern angebotenen Nexus-Geräte erhalten garantiert schnell, regelmäßig und langfristig neue Updates. In Bezug auf Sicherheitslücken und Malware ist das ein elementarer Schwachpunkt der Plattform.
Ein anderes Problem sind günstige Geräte, die für ältere Android-Versionen konstruiert wurden und nun mit dem aktuellen Android 4 ausgestattet wurden. Derartige Geräte findet man für rund 100\euro\ in Baumärkten, Ramschläden und in diversen Onlineshops. Es hat sich gezeigt, dass derzeit keines der günstigen Geräte mit Android 4 wirklich zufriedenstellend funktioniert.
Bei der Anschaffung von Android-Geräten ist für den sinnvollen schulischen Einsatz mindestens die Version 2.2 erforderlich. Dies stellt jedoch kein wesentliches Problem dar, da es kaum noch Geräte mit älteren Versionen im Handel gibt.
\subsubsection{Gute Ausstattung}
Im Allgemeinen (Ausnahme: Samsung) verfügen Android-Geräte über diverse Stan\-dard-Schnitt\-stel\-len. Weitgehend uneingeschränktes Bluetooth, Speicherkartenslots, USB-Host- und HDMI-Schnitt\-stel\-len gehören inzwischen zur Standardausstattung der Geräte. Bei Smartphones sind dazu allerdings oft Adapter nötig, die jedoch meist für wenig Geld zu bekommen sind.
\subsection{Windows}
\begin{figure}[htbp]
\centering
\begin{scriptsize}
\textsf{\input{imgs/mobos/mobos_win.tikz}}
\end{scriptsize}
\caption{Abstammung von mobilen Betriebssystemen 3: Windows}\label{figPlatWin}
\end{figure}
Windows ist derzeit bei mobilen Informatiksystemen nicht sehr verbreitet, es hat sogar Marktanteile eingebüßt\vglr{figOSMarkt}. Dies hat sicherlich damit zu tun, dass die aktuelle Plattform Windows Phone 7 kurz vor der Ablösung steht und die aktuellen Geräte keine Updates auf Windows Phone 8 erhalten werden, das nicht mehr auf der CE-Linie von Windows, sondern auf Windows 8 basiert\vglr{figPlatWin}. Es ist jedoch nicht unwahrscheinlich, dass sich die neue Plattform deutlich stärker verbreiten wird. Zumindest ist Microsoft bereit, zur Optimierung seiner Betriebssysteme für mobile Informatiksysteme die Desktop-Version komplett umzugestalten. So wurde dem Desktop-Windows die \enquote{Metro} genannte Bedienoberfläche des mobilen Windows implantiert. Aufgrund fehlender Touchscreens bei stationären Systemen erscheint dies nur im Hinblick auf die Gewöhnung der Benutzerinnen und Benutzer an das Bedienkonzept der mobilen Systeme sinnvoll.
Microsoft verfügt bei seiner neuen Betriebssystemgeneration über drei Systeme für mobile Geräte: Windows Phone 8 für Smartphones, Windows 8 für x86-Tablets und Windows RT für ARM-Tablets. Die drei relevanten, verschiedenen Varianten von Windows müssen im Folgenden getrennt betrachtet werden, da sie die verschiedenen Kriterien unterschiedlich gut erfüllen. Es ist noch nicht in allen Punkten klar, was überhaupt möglich sein wird, da noch keine mobilen Informatiksysteme mit diesen Plattformen erhältlich sind.
\subsubsection{Sinnvolle Einbindung und Programmierbarkeit}
Die Einnahme der kritisch-analytischen Perspektive erscheint durchweg gut möglich, da die vorhandenen Einschränkungen im Wesentlichen dem \gls{DRM} und dem Kopierschutz bestimmter Inhalte dienen, aber keine bedeutenden, grundlegenden Sperren vorhanden sind. Der Einsatz Freier Software ist grundsätzlich möglich, der offizielle Distributionsweg über den Windows Marketplace bleibt vielen Lizenzen jedoch aus demselben Grund wie bei Apple verwehrt. Anders als bei Apple werden diese Lizenzen, allen voran die \gls{GPL}, sogar explizit vom Marketplace ausgeschlossen\vgl{MicrosoftAgreement}{1}.
Es gibt genügend Möglichkeiten zur Individualisierung der Geräte etwa über entsprechende Apps und Metro-Kacheln. Die Möglichkeiten für die kommunikative Nutzung der Geräte sind reichhaltig, und es ist ein ausreichendes Angebot an Unterhaltungsmöglichkeiten zu erwarten. Bei Windows Phone 7 war dies schon recht ordentlich. Durch die teilweise gemeinsame Unterstützung von Windows 8, Windows RT und Windows Phone 8 sind hier allerdings noch deutliche Verbesserungen zu erwarten.
Bei der Programmierbarkeit sieht die Sache allerdings etwas anders aus. Windows 8 stellt hier naturgemäß kein Problem dar, da es die freie Installation und Nutzung beliebiger Desktop-Software zulässt. Es ist die gesamte Palette an Windows-Software verfügbar. Bei Windows Phone und Windows RT ist man hingegen im Wesentlichen auf Metro-Apps und Webapps beschränkt. Auch hier spricht jedoch kein handfester Grund gegen die Programmierung auf den Geräten. Es gibt sogar seit langem eine offizielle, \enquote{Touchstudio} genannte, App für Windows Phone, die auch für Windows Phone 8 verfügbar sein wird. Mit dieser ist eine grundlegende Programmierung der Geräte möglich. Da es sich jedoch um eine eingeschränkte -- und aus didaktischer Sicht eher ungeeignete -- grafische Programmierumgebung handelt, ist sie für den Unterricht nicht relevant. Dennoch bestünde die Möglichkeit, eine entsprechende App für die Ausführung von (\zb in Python geschriebenem) Code zu entwickeln. Dies wäre zwar aufwendig, anders als bei Apple aber möglich. Es stehen also für Windows 8 alle notwendigen Werkzeuge und Dokumentationen bereit, für Windows RT und Windows Phone wären hingegen noch deutliche Vorarbeiten zu erbringen.
\subsubsection{Kosten}
Die Anschaffungskosten für gut ausgestattete Smartphones mit Windows Phone 7 liegen derzeit deutlich unter vergleichbaren Geräten der anderen Plattformen. Allerdings gibt es keine besonders günstigen Einstiegsgeräte. Die Preise für die nächste, aktuelle Generation, inklusive der neuen Tablets, sind noch weitgehend unbekannt. Weitere Kosten entstehen nicht zwingend, so ist zwar für die Verbreitung von Windows Phone Apps ein Entwicklerzugang notwendig, das Testen von unsigniertem Code auf der eigenen Hardware erfordert jedoch nur eine kostenfreie Registrierung.
\subsubsection{Langlebigkeit}
Grundsätzlich scheint Microsoft eine recht sinnvolle Update-Politik zu verfolgen. Regelmäßige Updates für alle Geräte sind üblich, da diese weitgehend herstellerunabhängig sind. Die verfügbaren Geräte selbst unterscheiden sich in Verarbeitung und Haltbarkeit nicht wesentlich von anderen mobilen Informatiksystemen. Allerdings gibt es bisher keine sehr günstigen, tendenziell eher schlecht verarbeiteten Geräte.
\subsection{Andere}\label{secPlatOth}
Neben den bereits weit verbreiteten Plattformen gibt es einige weitere, sehr interessante Ansätze, die allesamt auf Linux basieren\vglr{figPlatLin}. Bisher ist ihnen allerdings gemein, dass die nötige Hardwarebasis fehlt. Außer einigen Testgeräten sind de facto keine Modelle mit den Systemen erhältlich.
Es zeigt sich erneut, wie bedeutungsvoll das optionale Kriterium der Verwendung Freier Software\vglr{secKritOSS} ist, denn alle als Freie Software verfügbaren Plattformen erfüllen grundsätzlich die Anforderungen für den Unterricht. Die Verfügbarkeit des Quellcodes und die zugrunde liegende Basis erlauben eine weitreichende Anpassung und die Ausführung der meisten als Freie Software vorliegenden Programme. Außerdem sind viele Standardbibliotheken verfügbar, sodass die Programmierbarkeit und die Verfügbarkeit von Werkzeugen kein Problem darstellen. Spezialfälle sind jedoch die Betriebssysteme \textit{Tizen}, \textit{Chrome OS} und \textit{Firefox OS}, da diese entweder teilweise (Tizen) oder vollständig auf Webapps setzen. Dies schränkt natürlich die Perspektive der Veränderung der Welt auf den Aspekt der Erzeugung von Webapps\vglr{secPersWebApp} ein.
Im Hinblick auf die Einsatzmöglichkeiten für die Schule erscheinen derzeit die beiden Plattformen MeeGo-Ableger \textit{mer} und \textit{Jolla} als besonders aussichtsreich. Da mer allerdings zunächst hauptsächlich den Aufbau einer entsprechenden technischen Basis vorantreibt, ist Jolla hier wohl die bessere Option. Ob sich diese Systeme tatsächlich etablieren können, ist derzeit allerdings fraglich.
Für den Einsatz von Tablets kommen noch weitere Kandidaten infrage. Neben üblichen Desktop-Linux-Distributionen und solchen mit speziell auf Touchscreens optimierten Benutzungsschnittstellen (etwa Ubuntus Unity Desktop) sind hier speziell entwickelte Ansätze wie Plasma Active\vglr{figPlatLin} verfügbar. Allerdings fehlt auch hier derzeit noch die Hardwarebasis. Mit der Verbreitung von Windows 8 Tablets könnte jedoch die Bedeutung dieser Systeme geringfügig zulegen. Zumindest die Windows 8 Tablets erlauben die Installation alternativer Betriebssysteme, da sich hier \gls{SecBoot} deaktivieren lässt. Bei den eigentlich interessanteren Tablets mit Windows RT\vglr{figPlatWin}, auf Basis der ARM-Architektur, wird dies jedoch nicht ohne Weiteres möglich sein, sodass hier vermutlich die Rooting-Problematik\vglr{secRoot} greift.
\subsection{Fazit}
Das bei \SuSn durchaus beliebte iOS muss derzeit für den Informatikunterricht als unbrauchbar gewertet werden. Daher ist Android in der jetzigen Situation die einzig sinnvolle Basis. Es erübrigt sich also die Frage, welche Plattform zunächst für die Umsetzung berücksichtigt werden sollte.
Es gibt zwar viele Anzeichen dafür, dass in Zukunft weitere Plattformen genutzt werden können, dem steht jedoch im Moment in erster Linie die Verbreitung dieser Plattformen im Weg. Einzig bei Windows scheint es mittelfristig einigermaßen sicher, dass eine entsprechende Verbreitung erreicht werden kann. Windows 8 bietet gute Möglichkeiten für den Einsatz im Informatikunterricht, Windows RT und Windows Phone sind hingegen relativ stark geschlossene Plattformen. Trotzdem erscheint ihr Einsatz mit entsprechendem Aufwand durchaus möglich.
Da potentiell eine Vielzahl von Plattformen infrage kommt, muss bei der Gestaltung der Systeme eine grundlegende Plattformunabhängigkeit berücksichtigt werden.

View file

@ -0,0 +1,58 @@
\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}.

View file

@ -0,0 +1,44 @@
\chapter{Konkrete Umsetzung mit Android}\label{chpAndroid}
\section{Untersuchte Umsetzungsmöglichkeiten}
\subsection{Automatisierung}
Für Android sind verschieden Apps zur profil- oder regelbasierten Automatisierung des Systems erhältlich, die allesamt sehr zuverlässig funktionieren. Hervorzuheben sind die Apps \textit{Llama -- Location Profiles}, \textit{Locate} und \textit{Tasker}. Allen gemein sind die umfangreichen Möglichkeiten zur automatischen Reaktion auf bestimmte Ereignisse. Durch die Verfügbarkeit von Variablen und Kontrollstrukturen sind zwar grundsätzlich einige Betrachtungen unter der Perspektive der Veränderung der Wirklichkeit möglich. Tatsächliche Programmierung ist dies jedoch nicht, Objektorientierung ist schon gar nicht möglich. Dennoch kann dieser Ansatz für den Informatikunterricht interessant sein, denn alle Apps dieser Art können auch Skripte aufrufen, die etwa mit dem \gls{SL4A} entwickelt wurden.
\subsection{Programmieren für Android}
Unabhängig von den weiteren Ansätzen ist wie bei allen Plattformen die Entwicklung von mobilen Apps mittels stationärer Informatiksysteme möglich. Dies erfolgt grundsätzlich mittels der androidspezifischen Java-Variante, deren kompilierter Code nicht zum Bytecode von Standard-Java kompatibel ist. Hierzu stehen das umfangreiche \gls{SDK} und für rechenintensive Anwendungen zusätzlich das \gls{NDK} zur Verfügung, welches die Nutzung von C- und C++-Code erlaubt. Zum \gls{SDK} gehören diverse Werkzeuge, etwa eine auf \textit{Eclipse} aufbauende Entwicklungsumgebung, aber auch ein Emulator und die äußerst nützliche \gls{ADB}. Mit letzterer können \zb ein an den Entwicklungsrechner angeschlossenes Android-Gerät ferngesteuert und Dateien übertragen werden. Dies kann auch gelegentlich für die weiteren Ansätze nützlich sein. Erzeugte Apps (bis auf native Teile) laufen unter Android jeweils in einer eigenen \gls{Dalvik}, abgeschottet von den übrigen Programmen. Da die Entwicklung für die Systeme bereits ausgeschlossen wurde, sind diese Details zunächst nur von begrenztem Interesse für den Unterrichtseinsatz.
\subsection{Java}
Inzwischen ist es auf Android-Geräten jedoch möglich, reguläre Apps komplett auf den Geräten zu erstellen, zu kompilieren und in ein App-Paket zu verpacken. Mit \textit{AIDE} steht hierzu sogar eine komplette Entwicklungsumgebung zur Verfügung, die mit Eclipse-Projekten kompatibel ist und sich somit in das \gls{SDK} einfügt. Dieser Ansatz hat auf allen getesteten Systemen reibungslos funktioniert. Die Vorteile liegen klar auf der Hand: Es besteht vollständiger Zugriff auf alle API-Funktionen und die erzeugten Apps lassen sich auf nahezu alle Android-Systeme transferieren sowie dort ausführen, ohne weitere Laufzeitkomponenten zu benötigen. Zudem bietet AIDE intensive Eingabehilfen, die die Programmierung erleichtern, etwa Autovervollständigung. So kann es kaum verwundern, dass der Autor nach Bekanntwerden dieses Ansatzes sein bisheriges Konzept verwarf und versuchte, diesen Ansatz für den Unterrichtseinsatz fit zu machen. Dass hier nur Java, nicht aber Python zur Verfügung stand, das nach den Kriterien nach Linkweiler \citep[S.~22~ff.]{LinkweilerDA2002} weniger gut geeignet erscheint, schien verschmerzbar zu sein.
Leider waren die Versuche mit diesem Ansatz vergleichsweise fruchtlos. Es ergaben sich nämlich massive Probleme, die aus didaktischer Sicht nicht ignoriert werden können. So ist derzeit die vollständige Verkapselung der Android-API in Java nicht möglich. Grundlegende Elemente, etwa die bei Android üblichen Activitys, also Bildschirmansichten, müssen zumindest von den Android-Klassen abgeleitet werden. Dies führt dazu, dass die Autovervollständigung von AIDE faktisch unbrauchbar wird und ihre Ergebnisse mehr verwirren als helfen, da alle geerbten Attribute und Methoden in der Liste auftauchen. Außerdem muss für jede App eine Manifest-Datei erstellt werden, die alle wichtigen Bestandteile der App umfasst. Diese Dateien liegen im XML-Format vor und müssen manuell bearbeitet werden, was erweiterte Kenntnisse über strukturierte Dokumente voraussetzt. Eine didaktische Reduktion erscheint kaum möglich. Am schwersten wiegt jedoch die -- besonders auf den wohl in Schulen einzusetzenden, günstigeren Geräten -- extrem lange Dauer, die zum Testen des Codes erforderlich ist. Ist neben dem Compilieren doch noch das Verpacken, Signieren und Installieren notwendig. Dies geschieht zwar fast vollständig automatisch, kann aber selbst auf schnelleren Systemen einige Minuten dauern.
\subsection{Pygame Subset for Android und Kivy}
Mit dem \textit{Pygame Subset for Android} steht ein komplettes Framework für die Verwendung von Python und Pygame zur Verfügung. Die grundsätzliche Platt\-form\-un\-ab\-hän\-gig\-keit und die Verfügbarkeit der Pygame-Erweiterungen lassen den Ansatz attraktiv erscheinen. Der Autor hatte daher auf dieser Basis versucht, die Klassenbibliothek zu entwickeln. Zwar gab es teilweise massive Performanceprobleme mit leistungsschwächeren Geräten, dennoch erschien eine Umsetzung sinnvoll möglich. Die Beschränkung auf einige wenige, speziellere Eigenschaften der mobilen Geräte (nur Beschleunigungssensoren, kein GPS usw.) erschienen zu Gunsten der Plattformunabhängigkeit verschmerzbar. Jedoch wurde noch während der Entwicklung klar, dass dieser Ansatz keine Zukunft hat. Recht plötzlich wurde die offizielle Unterstützung des Interpreters zu Gunsten von Build-Skripten aufgegeben, die die Entwicklung auf stationären Informatiksystemen erfordern. Hier kollidieren die didaktischen Interessen mit den Zielsetzungen des Projekts, das eine einfache Möglichkeit bieten will, Spiele in den Google Play Store zu bringen.
Mit \textit{Kivy} steht ein Abkömmling von Pygame mit erweitertem \gls{API} zur Verfügung, der eine stärkere Plattformunabhängigkeit und zahlreiche UI-Komponenten bietet. Außerdem ist hier (noch) ein eigenständiger Interpreter verfügbar. Tests auf verschiedenen Geräten zeigten allerdings massive Instabilitäten, sodass der Einsatz von Kivy ebenfalls nicht sinnvoll erscheint.
\subsection{Scripting Layer for Android}
Letztlich blieb also nur der zuallererst untersuchte Ansatz der offiziellen \gls{SL4A}. Diese bietet die Möglichkeit, Python-Code auszuführen und verfügt über eine interaktive Konsole\footnote{Diese ist jedoch insofern eingeschränkt, als hier aufgrund der in Android fehlenden Unterstützung von \enquote{readline} keine Befehlshistorie und keine Autovervollständigung möglich sind. Außerdem funktionierte sie nicht auf allen getesteten Geräten einwandfrei und zeigte teils wirre Ergebnisse.}. Außerdem läuft es grundsätzlich auf allen (auch älteren) Android-Geräten. Allerdings weist der Ansatz diverse Probleme auf. Interessante Module (Pygame, SDL usw.), die native Komponenten enthalten, sind nicht möglich. Die eingebauten Trigger zur Aktivierung von Skripten als Reaktion auf bestimmte Ereignisse funktionierten nur auf zwei der getesteten Geräte überhaupt und dort nur sehr unzuverlässig, die restlichen wurden beim Versuch Trigger einzurichten blockiert oder neu gestartet. Die Entwicklung des SL4A verläuft insgesamt äußerst schleppend. Das letzte Release des Python-Interpreters stammt aus dem März 2011. Von der Hauptanwendung ist zwar kürzlich nach über drei Monaten eine neue Version erschienen, diese adressiert jedoch keinen der wesentlichen Fehler, die noch in SL4A enthalten sind.
Lässt man diese Probleme jedoch beiseite, funktioniert die SL4A von allen Python-Ansätzen am besten und zuverlässigsten. Die Python-Android-API stellt jedoch im Gegensatz zum Pygame Subset und zu Kivy nur einen Wrapper für als \gls{JSON} formatierte \glspl{RPC} zu einem laufenden SL4A-Server dar, den der Interpreter auf dem Gerät starten kann, wenn er benötigt wird. Dieser Wrapper ist wenig übersichtlich und die Dokumentation hinkt dem Entwicklungsstand hinterher. Die Menge der möglichen Funktionen ist jedoch sehr hoch. Einzig beim Zugriff auf die grafische Oberfläche bestehen große Lücken. Daran hat sich auch seit \cite{Spittank2011} nichts geändert. Es gibt insgesamt drei konkurrierende Varianten, von denen derzeit nur die DialogFacade für den Einsatz im Unterricht infrage kommt. Die WebViews kann man aus demselben Grund ausschließen wie Webapps, zudem ist die Verzahnung von WebViews und Skripten ausgesprochen umständlich und kaum sinnvoll zu verkapseln, da auf beiden Seiten Endlosschleifen erforderlich sind, die auf Events warten müssen. Da die Events nicht vorgefiltert werden können, sind während der Darstellung der Webviews keine weiteren Events möglich. Die FullScreenFacade unterstützt zwar theoretisch die androidtypischen GUI-Komponenten und -Konzepte, kann derzeit bestenfalls als Betaversion angesehen werden, auch wenn sie grundsätzlich vielversprechend ist.
\section{Notwendige Werkzeuge}
Für den Einsatz des \gls{SL4A} benötigt man nicht nur die entsprechende App, sondern auch den passenden Interpreter, in diesem Fall \textit{Python for Android}. Beides lässt sich nicht über den Google Playstore beziehen, sondern lediglich über die Projektwebseite bei GoogleCode \citep{SL4A}. Hier könnte im Unterrichtseinsatz eine Verteilung der notwendigen Pakete wie bei den ersten Aufgaben aus dem Konzept von Heming\vgl{Heming2009}{45} erfolgen.
\gls{SL4A} bringt zwar bereits einen sehr einfachen Editor mit, Apps wie \textit{Touchqode} oder \textit{DroidEdit} haben allerdings angenehmere Bedienkonzepte und ermöglichen das einfache Wechseln zwischen verschiedenen Dateien. Außerdem bieten sie zusätzliche Funktionen, etwa Suchen und Ersetzen sowie die Möglichkeit der Rücknahme von Änderungen. Zumindest Touchqode bietet zusätzlich zur Tastatur eine Reihe von Tasten an, die zur Eingabe von Sonderzeichen dienen, wie sie für die Programmierung notwendig sind. Besser ist allerdings die Verwendung einer geeigneteren \gls{OSTastatur}. Ideal ist hier die Open-Source-Tastatur \textit{Hacker's Keyboard}. Diese bildet eine vollständige PC-Tastatur inklusive Sondertasten nach. Diese kann aufgrund der schieren Anzahl von Tasten natürlich nur auf Tablets ihre volle Wirkung entfalten, trotzdem funktioniert sie auch auf Smartphones ordentlich. Dort wird die volle Belegung allerdings nur im Querformat angezeigt. Im Hochformat sind einige Tasten überhaupt nicht erreichbar.
Sollen Trigger bzw. Events genutzt werden, muss eine geeignete App zur Profilbasierten Automatisierung installiert werden. Hier stehen, wie bereits erwähnt, Llama, Tasker und Locate zur Verfügung. Der Autor würde zu \textit{Llama} raten, da dieses nicht nur übersichtlicher als die anderen Apps ist, sondern zudem kostenlos angeboten wird. Zum Austausch von Quelltexten mittels QR-Codes wird ebenfalls eine passende App benötigt. Als gut geeignet hat sich hierbei \textit{QR Droid} erwiesen.
\section{Klassenbibliothek}
Der Aufbau und die Struktur einer Klassenbibliothek für mobile Informatiksysteme wurde im \referenz{chpGestaltung} beschrieben. Hier sind also nur die Besonderheiten für die Umsetzung auf Android zu bedenken. Es ist bei der \gls{SL4A} absolut unumgänglich, eine Klassenbibliothek zu erstellen, da die vorhandene \gls{API} lediglich die JSON-Calls abbildet, die zum SL4A-Server gesendet werden. Aus didaktischer Sicht ist dies vollkommen ungeeignet, da damit nicht objektorientiert gearbeitet werden kann und es sich um eine unübersichtliche Zusammenstellung verschiedenster Funktionen handelt, die keine besondere Orthogonalität aufweist. Es werden etwa ähnliche Strukturen (\zb Listen von Nachrichten und Listen von Kontakten) vollständig unterschiedlich behandelt.
Da die SL4A Python als Skriptsprache anbietet, ist die Implementierung einer geeigneten Klassenbibliothek weitgehend problemlos möglich. Verpackt in \glspl{PyEgg} lassen sich diese auch leicht installieren. Allerdings ist an eine vollständige Umsetzung aufgrund der oben benannten Beschränkungen des Ansatzes nicht zu denken. Derzeit ist außer im Bezug auf Dialoge keine sinnvolle Umsetzung von UI-Klassen erreichbar. Die damit verbundenen Probleme wären für den Unterrichtseinsatz deutlich zu komplex. Damit fällt natürlich vorübergehend jegliche Chance auf die Weiterverwendung eines großen Teils von \gls{SuM} weg. In anderen Bereichen muss man ebenfalls mit Abstrichen leben. Viele Events (Tastendrücke, Ortung, Sensoren usw.) sind nicht unmittelbar zugänglich. Entweder man verwendet hierzu externe Werkzeuge oder man fragt Sensorwerte ständig in einer Polling-Schleife ab. Letzteres geht jedoch zu Lasten der Akkuleistung und ist keine besonders clevere Idee, da dies im Standbymodus der Geräte nicht funktioniert und zu Deadlocks führen kann.
\section{Aktueller Stand}
Da zunächst andere Ansätze präferiert wurden und hierfür die notwendigen Klassen erstellt wurden, liegt noch keine vollständige Umsetzung der Klassenbibliothek für Android vor. Die mehrfachen Neustarts bei der Implementierung zeigen hier ihre Folgen. Allerdings ist im jetzigen Zustand bereits ersichtlich, dass die Umsetzung mit Android grundsätzlich möglich ist, obwohl der Autor weiterhin Zweifel am \gls{SL4A} hat. Die de facto fehlenden Trigger sind ein Problem. Das Schlimmste ist jedoch die äußerst schleppende Weiterentwicklung, die die Zukunftsfähigkeit des Ansatzes zumindest mit kleinen Fragezeichen versieht.
Da der Autor einen vollständigen Abdruck der Quelltexte für nur wenig sinnvoll hält, findet sich im Anhang lediglich ein kurzes Beispiel mit den notwendigen Klassen\vglr{secQuell}. Der Rest der bisher umgesetzten Klassenbibliothek findet sich auf der beiliegenden CD. Der gesamte Code wird zu einem späteren Zeitpunkt vom Autor unter einer freien Lizenz an geeigneter Stelle zur Verfügung gestellt werden, in der Hoffnung, dass sich Mitstreiter finden werden, die dabei helfen werden, die bestehenden Lücken zu füllen.

View file

@ -0,0 +1,23 @@
\chapter{Rückblick und Ausblick}\label{chpAusblick}
Die selbst gestellte Anforderung, die Erfolg versprechenden Ansätze zur Nutzung der mobilen Informatiksysteme im Unterricht weiterzuführen, konnte aus Sicht des Autors erreicht werden. Mit den neuen Kriterien für die Auswahl von Informatiksystemen steht eine Basis für diese notwenige Entscheidung zur Verfügung, die es erlaubt, die Vielzahl möglicher Geräte sinnvoll zu kategorisieren und auf die Nutzbarkeit für den Unterricht hin zu untersuchen.
Derzeit steht zwar mit Android wiederum nur eine Plattform zur Verfügung, die tatsächlich die Anforderungen erfüllen kann. Es gibt jedoch Anlass zur Hoffnung, da einige weitere, mögliche Kandidaten bereit stehen, die in Zukunft im Unterricht eingesetzt werden könnten. Besonders die freien Betriebssystemvarianten erscheinen geeignet. Es bleibt zu hoffen, dass diese sich soweit durchsetzen können, dass tatsächlich passende Hardware erscheinen wird.
Wenig hoffnungsfroh stimmt hingegen der große Erfolg der Konsumgeräte, die wie im Exkurs dazu\vglr{secKonsum} beschrieben, kaum sinnvoll für den Unterricht nutzbar sind. Diese Geräte stehen den wesentlichen Zielen des Informatikunterrichts und eigentlich grundsätzlich denen der allgemeinen Bildung fundamental entgegen. Zwar besteht die Möglichkeit, diese nutzbar zu machen, wie im Exkurs zum Rooting angesprochen, doch begibt man sich damit -- zumindest im schulischen Kontext -- auf rechtlich sehr unsicheres Terrain, sodass dies als kaum verantwortbar erscheinen muss. Besonders der Erfolg dieser Geräte und die Begeisterung für sie unter Pädagogen und Lehrkräften lässt befürchten, dass sie an vielen Schulen Einzug halten werden. Hier müssen die Informatiklehrkräfte, die sich ihrem Fach und ihrer Profession verpflichtet fühlen, nach Ansicht des Autors Widerstand leisten. Denn im Sinne der Pfadabhängigkeit wird es nur schwer möglich sein, nach einer breiten Einführung noch Änderungen zu erreichen.
Für die Zukunft wird es erforderlich sein, die Entwicklung auf dem Markt der mobilen Betriebssysteme sehr genau zu verfolgen. Es gibt zwar viele hoffnungsvolle Punkte, jedoch sollte von langfristigen Prognosen, speziell nach den Erfahrungen mit Symbian, Abstand genommen werden. Daher wurde in der Arbeit viel Wert darauf gelegt, unabhängig von bestimmten Plattformen oder Geräten zu bleiben. Speziell der vergleichsweise geringe Umfang der praktischen Umsetzung mit Android mag hier manchen missfallen. Es war jedoch aus Sicht des Autors der einzig gangbare Weg für eine zukunftsfähige Lösung.
Für die Gestaltung der Informatiksysteme konnte mit der Weiterentwicklung des SuM-Konzepts eine bewährte Basis im Hinblick auf die neuen Anforderungen erweitert werden. Dies erscheint sinnvoller als der noch in \cite{Spittank2011} und \cite{HemingSpittank2012} angedachte vollkommen neue Ansatz. Die jetzt (wieder) vorhandene Basis ist flexibel genug, auf verschiedensten Informatiksystemen genutzt werden zu können.
Die Untersuchung der verschiedenen Betriebssysteme und Möglichkeiten zur Umsetzung der Klassenbibliothek hat jedoch sehr viel mehr Zeit und Arbeit gekostet als ursprünglich angenommen. Besonders die teilweise sehr plötzlichen Änderungen von Spezifikationen oder kompletten Neuausrichtungen bei den verschiedenen Interpretern und Compilern für Android haben dem Autor hier einige frustrierende Erfahrungen bereitet. Zwischenzeitlich musste sogar ein fast fertiges Konzept für Pygame verworfen werden. Dies zeigt, wie wichtig es ist, hierbei auf Standards und allgemeine Konzepte zu setzen. Die Abstraktionsebene eines zusätzlichen Wrappers erweist sich hier als goldrichtig, wenngleich sie nicht verhindern konnte, dass viel Code neu geschrieben werden musste.
Leider war es so im Rahmen dieser Arbeit nicht möglich, den theoretischen Ansatz vollständig in die Praxis umzusetzen, zudem fehlen noch die genauen Spezifikationen für einige Teile der Klassenbibliothek, die derzeit nicht wirklich plattformunabhängig gestaltet werden können. Auch wenn inzwischen ein Punkt erreicht ist, an dem der Einsatz im Unterricht mit einer neuen Plattform wieder möglich erscheint: Hier bleibt noch viel zu tun. Zudem wird sich erst in Zukunft zeigen, ob bei Android die Entscheidung für die \gls{SL4A} langfristig richtig war, einige Zweifel hieran bleiben bestehen.
Ein bedeutsamer Punkt, nämlich die der Fehlerbehandlung, fiel dem Autor dabei erst spät auf und ihm fehlt hierzu noch eine sinnvoll begründete Idee zur Realisierung. Da es bei den meisten Umsetzungsansätzen an einer Konsole mangelt und zudem weitere Hilfsmittel zur Fehlersuche fehlen, muss hier dringend ein geeignetes Konzept gefunden werden, das auf den mobilen Systemen umsetzbar ist.
Eine Anpassung für weitere Plattformen muss bereits ins Auge gefasst werden. Aktuell erscheint es hierbei besonders vielversprechend zu sein, eine Umsetzung für die x86-Varianten von Linux und Windows in Angriff zu nehmen. Denn während man die Perspektiven der alternativen mobilen Betriebssysteme nur schwerlich abschätzen kann, sind die Tablets mit x86- bzw. x64-Architektur und die passenden stationären Informatiksysteme bereits da oder stehen zumindest in den Startlöchern. Von letzteren wollen wir zwar langfristig Abstand nehmen, es spricht jedoch nichts dagegen und vieles dafür, die vorhandenen Konzepte auch auf die flächendeckend bestehende schulische Infrastruktur zurück zu übertragen. Zumindest für die Übergangszeit, die, selbst optimistisch betrachtet, lang werden wird.
Die Perspektive, WebApps zu entwickeln\vglr{secPersWebApp} darf nicht aus den Augen verloren werden. Auch wenn der notwendige Aufwand, um dies didaktisch sinnvoll zu gestalten, erheblich zu groß erscheint, könnte dies ein geeigneter Ausweg sein, falls sich Konsumgeräte in den Schulen durchsetzen sollten. Wahrscheinlich wäre dies dann sogar der letzte gangbare Weg, die Mobilgeräte sinnvoll für den Informatikunterricht zu nutzen.
Die Vorteile der Nutzung mobiler Informatiksyteme liegen auf der Hand, und die Hoffnungen sind weiterhin groß. Es obliegt der Fachdidaktik und den Lehrkräften, die Chancen zu nutzen.

View file

@ -0,0 +1,7 @@
Name,2012,2011,Differenz
Android,40,17,23
iOS,22,21,1
Symbian,24,42,-18
Windows,7,11,-4
BlackBerry OS,3,4.5,-1.5
Sonstige,4,4.5,-0.5
1 Name 2012 2011 Differenz
2 Android 40 17 23
3 iOS 22 21 1
4 Symbian 24 42 -18
5 Windows 7 11 -4
6 BlackBerry OS 3 4.5 -1.5
7 Sonstige 4 4.5 -0.5

View file

@ -0,0 +1,16 @@
Land,M11,W11,G11,M12,W12,G12
Belgien,,,,28,17,22
Deutschland,24,13,18,33,25,29
Dänemark,37,24,30,51,39,45
Finnland,35,23,29,45,32,38
Frankreich,31,23,27,42,34,38
Großbritannien,33,28,30,54,48,51
Italien,29,19,24,32,24,28
Niederlande,40,26,33,48,39,43
Norwegen,36,31,33,56,52,54
Polen,29,18,24,,,
Schweden,36,24,30,56,46,51
Schweiz,40,27,34,49,36,43
Spanien,40,27,33,51,38,44
Tschech. Rep.,36,22,29,,,
Österreich,26,17,21,42,30,36
1 Land M11 W11 G11 M12 W12 G12
2 Belgien 28 17 22
3 Deutschland 24 13 18 33 25 29
4 Dänemark 37 24 30 51 39 45
5 Finnland 35 23 29 45 32 38
6 Frankreich 31 23 27 42 34 38
7 Großbritannien 33 28 30 54 48 51
8 Italien 29 19 24 32 24 28
9 Niederlande 40 26 33 48 39 43
10 Norwegen 36 31 33 56 52 54
11 Polen 29 18 24
12 Schweden 36 24 30 56 46 51
13 Schweiz 40 27 34 49 36 43
14 Spanien 40 27 33 51 38 44
15 Tschech. Rep. 36 22 29
16 Österreich 26 17 21 42 30 36

View file

@ -0,0 +1,13 @@
Typ,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010,2011
PC/Notebook (gesamt),35,42,46,49,47,53,54,57,60,67,71,75,79,79
PC/Notebook (Jungen),46,,55,58,54,62,64,65,69,72,77,77,80,81
PC/Notebook (Mädchen),27,,37,40,39,44,43,48,51,61,64,72,77,76
Handy (gesamt),8,14,49,74,82,86,90,92,92,94,95,95,97,96
Handy (Jungen),8,,46,69,77,84,88,90,89,92,94,93,96,94
Handy (Mädchen),7,,51,80,87,89,91,94,94,95,96,97,98,98
Smartphone (gesamt),,,,,,,,,,,,,14,25
Smartphone (Jungen),,,,,,,,,,,,,16,27
Smartphone (Mädchen),,,,,,,,,,,,,11,22
Tablet (gesamt),,,,,,,,,,,,,,3
Tablet (Jungen),,,,,,,,,,,,,,4
Tablet (Mädchen),,,,,,,,,,,,,,3
1 Typ 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011
2 PC/Notebook (gesamt) 35 42 46 49 47 53 54 57 60 67 71 75 79 79
3 PC/Notebook (Jungen) 46 55 58 54 62 64 65 69 72 77 77 80 81
4 PC/Notebook (Mädchen) 27 37 40 39 44 43 48 51 61 64 72 77 76
5 Handy (gesamt) 8 14 49 74 82 86 90 92 92 94 95 95 97 96
6 Handy (Jungen) 8 46 69 77 84 88 90 89 92 94 93 96 94
7 Handy (Mädchen) 7 51 80 87 89 91 94 94 95 96 97 98 98
8 Smartphone (gesamt) 14 25
9 Smartphone (Jungen) 16 27
10 Smartphone (Mädchen) 11 22
11 Tablet (gesamt) 3
12 Tablet (Jungen) 4
13 Tablet (Mädchen) 3

View file

@ -0,0 +1,15 @@
JN,Jahr,Prozent
1,1998,8
2,1999,14
3,2000,49
4,2001,74
5,2002,82
6,2003,86
7,2004,90
8,2005,92
9,2006,92
10,2007,94
11,2008,95
12,2009,95
13,2010,97
14,2011,96
1 JN Jahr Prozent
2 1 1998 8
3 2 1999 14
4 3 2000 49
5 4 2001 74
6 5 2002 82
7 6 2003 86
8 7 2004 90
9 8 2005 92
10 9 2006 92
11 10 2007 94
12 11 2008 95
13 12 2009 95
14 13 2010 97
15 14 2011 96

View file

@ -0,0 +1,15 @@
JN,Jahr,Prozent
1,1998,8
2,1999,
3,2000,46
4,2001,69
5,2002,77
6,2003,84
7,2004,88
8,2005,90
9,2006,89
10,2007,92
11,2008,94
12,2009,93
13,2010,96
14,2011,94
1 JN Jahr Prozent
2 1 1998 8
3 2 1999
4 3 2000 46
5 4 2001 69
6 5 2002 77
7 6 2003 84
8 7 2004 88
9 8 2005 90
10 9 2006 89
11 10 2007 92
12 11 2008 94
13 12 2009 93
14 13 2010 96
15 14 2011 94

View file

@ -0,0 +1,15 @@
JN,Jahr,Prozent
1,1998,7
2,1999,
3,2000,51
4,2001,80
5,2002,87
6,2003,89
7,2004,91
8,2005,94
9,2006,94
10,2007,95
11,2008,96
12,2009,97
13,2010,98
14,2011,98
1 JN Jahr Prozent
2 1 1998 7
3 2 1999
4 3 2000 51
5 4 2001 80
6 5 2002 87
7 6 2003 89
8 7 2004 91
9 8 2005 94
10 9 2006 94
11 10 2007 95
12 11 2008 96
13 12 2009 97
14 13 2010 98
15 14 2011 98

View file

@ -0,0 +1,15 @@
JN,Jahr,Prozent
1,1998,35
2,1999,42
3,2000,46
4,2001,49
5,2002,47
6,2003,53
7,2004,54
8,2005,57
9,2006,60
10,2007,67
11,2008,71
12,2009,75
13,2010,79
14,2011,79
1 JN Jahr Prozent
2 1 1998 35
3 2 1999 42
4 3 2000 46
5 4 2001 49
6 5 2002 47
7 6 2003 53
8 7 2004 54
9 8 2005 57
10 9 2006 60
11 10 2007 67
12 11 2008 71
13 12 2009 75
14 13 2010 79
15 14 2011 79

View file

@ -0,0 +1,15 @@
JN,Jahr,Prozent
1,1998,46
2,1999,
3,2000,55
4,2001,58
5,2002,54
6,2003,62
7,2004,64
8,2005,65
9,2006,69
10,2007,72
11,2008,77
12,2009,77
13,2010,80
14,2011,81
1 JN Jahr Prozent
2 1 1998 46
3 2 1999
4 3 2000 55
5 4 2001 58
6 5 2002 54
7 6 2003 62
8 7 2004 64
9 8 2005 65
10 9 2006 69
11 10 2007 72
12 11 2008 77
13 12 2009 77
14 13 2010 80
15 14 2011 81

View file

@ -0,0 +1,15 @@
JN,Jahr,Prozent
1,1998,27
2,1999,
3,2000,37
4,2001,40
5,2002,39
6,2003,44
7,2004,43
8,2005,48
9,2006,51
10,2007,61
11,2008,64
12,2009,72
13,2010,77
14,2011,76
1 JN Jahr Prozent
2 1 1998 27
3 2 1999
4 3 2000 37
5 4 2001 40
6 5 2002 39
7 6 2003 44
8 7 2004 43
9 8 2005 48
10 9 2006 51
11 10 2007 61
12 11 2008 64
13 12 2009 72
14 13 2010 77
15 14 2011 76

View file

@ -0,0 +1,15 @@
JN,Jahr,Prozent
1,1998,
2,1999,
3,2000,
4,2001,
5,2002,
6,2003,
7,2004,
8,2005,
9,2006,
10,2007,
11,2008,
12,2009,
13,2010,14
14,2011,25
1 JN Jahr Prozent
2 1 1998
3 2 1999
4 3 2000
5 4 2001
6 5 2002
7 6 2003
8 7 2004
9 8 2005
10 9 2006
11 10 2007
12 11 2008
13 12 2009
14 13 2010 14
15 14 2011 25

View file

@ -0,0 +1,15 @@
JN,Jahr,Prozent
1,1998,
2,1999,
3,2000,
4,2001,
5,2002,
6,2003,
7,2004,
8,2005,
9,2006,
10,2007,
11,2008,
12,2009,
13,2010,16
14,2011,27
1 JN Jahr Prozent
2 1 1998
3 2 1999
4 3 2000
5 4 2001
6 5 2002
7 6 2003
8 7 2004
9 8 2005
10 9 2006
11 10 2007
12 11 2008
13 12 2009
14 13 2010 16
15 14 2011 27

View file

@ -0,0 +1,15 @@
JN,Jahr,Prozent
1,1998,
2,1999,
3,2000,
4,2001,
5,2002,
6,2003,
7,2004,
8,2005,
9,2006,
10,2007,
11,2008,
12,2009,
13,2010,11
14,2011,22
1 JN Jahr Prozent
2 1 1998
3 2 1999
4 3 2000
5 4 2001
6 5 2002
7 6 2003
8 7 2004
9 8 2005
10 9 2006
11 10 2007
12 11 2008
13 12 2009
14 13 2010 11
15 14 2011 22

View file

@ -0,0 +1,15 @@
Jahr,PNG,PNJ,PNM,HAG,HAJ,HAM,SPG,SPJ,SPM,TBG,TBJ,TBM
1998,35,46,27,8,8,7,,,,,,
1999,42,,,14,,,,,,,,
2000,46,55,37,49,46,51,,,,,,
2001,49,58,40,74,69,80,,,,,,
2002,47,54,39,82,77,87,,,,,,
2003,53,62,44,86,89,84,,,,,,
2004,54,64,43,90,88,91,,,,,,
2005,57,65,48,92,90,94,,,,,,
2006,60,69,51,92,89,94,,,,,,
2007,67,72,61,94,92,95,,,,,,
2008,71,77,64,95,94,96,,,,,,
2009,75,77,72,95,93,97,,,,,,
2010,79,80,77,97,96,98,14,16,11,,,
2011,79,81,76,96,94,98,25,27,22,3,4,3
1 Jahr PNG PNJ PNM HAG HAJ HAM SPG SPJ SPM TBG TBJ TBM
2 1998 35 46 27 8 8 7
3 1999 42 14
4 2000 46 55 37 49 46 51
5 2001 49 58 40 74 69 80
6 2002 47 54 39 82 77 87
7 2003 53 62 44 86 89 84
8 2004 54 64 43 90 88 91
9 2005 57 65 48 92 90 94
10 2006 60 69 51 92 89 94
11 2007 67 72 61 94 92 95
12 2008 71 77 64 95 94 96
13 2009 75 77 72 95 93 97
14 2010 79 80 77 97 96 98 14 16 11
15 2011 79 81 76 96 94 98 25 27 22 3 4 3

View file

@ -0,0 +1,15 @@
JN,Jahr,Prozent
1,1998,
2,1999,
3,2000,
4,2001,
5,2002,
6,2003,
7,2004,
8,2005,
9,2006,
10,2007,
11,2008,
12,2009,
13,2010,
14,2011,3
1 JN Jahr Prozent
2 1 1998
3 2 1999
4 3 2000
5 4 2001
6 5 2002
7 6 2003
8 7 2004
9 8 2005
10 9 2006
11 10 2007
12 11 2008
13 12 2009
14 13 2010
15 14 2011 3

View file

@ -0,0 +1,15 @@
JN,Jahr,Prozent
1,1998,
2,1999,
3,2000,
4,2001,
5,2002,
6,2003,
7,2004,
8,2005,
9,2006,
10,2007,
11,2008,
12,2009,
13,2010,
14,2011,4
1 JN Jahr Prozent
2 1 1998
3 2 1999
4 3 2000
5 4 2001
6 5 2002
7 6 2003
8 7 2004
9 8 2005
10 9 2006
11 10 2007
12 11 2008
13 12 2009
14 13 2010
15 14 2011 4

View file

@ -0,0 +1,15 @@
JN,Jahr,Prozent
1,1998,
2,1999,
3,2000,
4,2001,
5,2002,
6,2003,
7,2004,
8,2005,
9,2006,
10,2007,
11,2008,
12,2009,
13,2010,
14,2011,3
1 JN Jahr Prozent
2 1 1998
3 2 1999
4 3 2000
5 4 2001
6 5 2002
7 6 2003
8 7 2004
9 8 2005
10 9 2006
11 10 2007
12 11 2008
13 12 2009
14 13 2010
15 14 2011 3

View file

@ -0,0 +1,4 @@
Typ,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010,2011
Spielekonsole (gesamt),23,31,31,32,34,35,34,37,42,45,45,45,50,45
Spielekonsole (Jungen),34,,44,46,48,50,49,52,54,59,60,56,64,58
Spielekonsole (Mädchen),11,,19,18,22,20,19,20,30,39,29,33,35,31

View file

@ -0,0 +1,27 @@
% Metadaten und Konfiguration
\setUniName{Bergische Universität Wuppertal}
\setUniLogo{imgs/logos/uni_logo}
\setFbName{Fachbereich C - Mathematik und Informatik}
\setFbLogo{imgs/logos/ddi_logo}
\setGutachter{Prof. Dr. Ludger Humbert}
\setGutachterZwei{Dr. Holger Arndt}
\setVeranstaltung{Spezielle Themen aus der Didaktik der Informatik}
\setTitel{Auswahl und Gestaltung mobiler Informatiksysteme für den Einsatz im Informatikunterricht}
\setDatum{06.08.2012}
\setZusammenfassung{Informatiksysteme bestimmen heute den Alltag in modernen Gesellschaften, doch viele werden nicht einmal als solche wahrgenommen. Smartphones und Tablets lösen heute die Versprechungen der PDAs von gestern ein. Der moderne Mensch ist ständig online und auch mobil bestens vernetzt.
Beständig prasselt eine Flut von Daten und Information auf jeden einzelnen Menschen ein. Um dennoch nicht den Überblick und die Fähigkeit zum selbstbestimmten Leben zu verlieren, bedarf es informatischer Vernunft. Doch gerade im Informatikunterricht ist dieser Wandel bisher nicht angekommen. Man hat den Eindruck, in den Informatikräumen Deutschlands wäre die Zeit stehen geblieben.
Zwar waren Versuche mit mobilen Informatiksystemen vielversprechend und erfolgreich, aber die Entwicklung des Marktes für mobile Informatiksysteme hat die bisherigen Ansätze überholt und ihnen die Basis entzogen. Diese Arbeit soll helfen, eine neue, zukunftsfähige Basis zu begründen, die den bestehenden Ansätzen den Weg in die Zukunft ebnet.
Dazu werden neue und erneuerte Kriterien benannt, mit denen eine didaktisch begründete Auswahl mobiler Informatiksysteme, unabhängig von konkreten Plattformen und Modellen, möglich wird. Außerdem wird der Grundstein für ein neues, plattformunabhängiges Konzept der didaktisch sinnvollen Gestaltung der mobilen Systeme gelegt.}
%\addBib{bibs/Komplett}
\addBib{bibs/examen}
% Autoren
\setAutor{Daniel Spittank}{Barmer Str. 23, 45549 Sprockhövel}{mobile@daniel.spittank.net}{710435}{Lehramt, LPO 2003}{Informatik, Sozialwissenschaften}

Binary file not shown.

Binary file not shown.

View file

@ -0,0 +1,453 @@
% Vorlage für Examensarbeit
% Classfile
% Version: 1.0
% Autor: Daniel Spittank
% E-Mail: vorlagen.latex@daniel.spittank.net
% Lizenz: CC-BY-NC-SA
\NeedsTeXFormat{LaTeX2e}
\ProvidesClass{examensarbeit}[2011/11/11]
% Sprache, Codierung
\RequirePackage[utf8]{inputenc}
\RequirePackage[T1]{fontenc}
\RequirePackage[ngerman]{babel}
% Paketoptionen
\PassOptionsToPackage{left=5cm,top=1.5cm,right=2cm,bottom=1.5cm,footskip=0.8cm}{geometry}
% Print: Für Ausdruck optimieren (Keine Linkhervorhebung etc.)
\newcommand{\farbigelinks}{true}
\newcommand{\glossarstil}{altlisthypergroup}
\PassOptionsToClass{oneside}{scrreprt}
\DeclareOption{print}{
\renewcommand{\farbigelinks}{false}
\renewcommand{\glossarstil}{altlistgroup}
}
% Metadaten-Standardwerte
\newcommand{\veranstaltung}{Der Titel des Seminars}
\newcommand{\gutachter}{Prof. Dr. Name des Gutachters}
\newcommand{\gutachterzwei}{Prof. Dr. Name des Gutachters}
\newcommand{\titel}{Der Titel der Arbeit}
\newcommand{\uniname}{Bergische Universität Wuppertal}
\newcommand{\unilogo}{imgs/logos/uni_logo}
\newcommand{\fbname}{Fachbereich C - Mathematik und Informatik}
\newcommand{\fblogo}{imgs/logos/uni_logo}
\newcommand{\datum}{10.10.2010}
\newcommand{\zusammenfassung}{Eine Zusammenfassung.}
% Metadaten-Setter
\newcommand{\setVeranstaltung}[1]{\renewcommand{\veranstaltung}{#1}}
\newcommand{\setGutachter}[1]{\renewcommand{\gutachter}{#1}}
\newcommand{\setGutachterZwei}[1]{\renewcommand{\gutachterzwei}{#1}}
\newcommand{\setTitel}[1]{\renewcommand{\titel}{#1}}
\newcommand{\setUniName}[1]{\renewcommand{\uniname}{#1}}
\newcommand{\setUniLogo}[1]{\renewcommand{\unilogo}{#1}}
\newcommand{\setFbName}[1]{\renewcommand{\fbname}{#1}}
\newcommand{\setFbLogo}[1]{\renewcommand{\fblogo}{#1}}
\newcommand{\setDatum}[1]{\renewcommand{\datum}{#1}}
\newcommand{\setZusammenfassung}[1]{\renewcommand{\zusammenfassung}{#1}}
% Weitere Optionen durchreichen
\DeclareOption*{\PassOptionsToClass{\CurrentOption}{scrreprt}}
\ProcessOptions
\LoadClass[abstracton,a4paper]{scrreprt}
% Struktur
\setcounter{secnumdepth}{3}
\setcounter{tocdepth}{3}
\makeatletter
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
{-3.25ex\@plus -1ex \@minus -.2ex}%
{1.5ex \@plus .2ex}%
{\normalfont\normalsize\bfseries}}
\makeatother
% Farben
\RequirePackage[usenames,dvipsnames]{xcolor}
\definecolor{buw}{RGB}{153,204,51}
\definecolor{buwMid}{RGB}{118,153,51}
\definecolor{buwDark}{RGB}{79,102,34}
\definecolor{grayOne}{gray}{0.90}
\definecolor{grayTwo}{gray}{0.80}
\definecolor{grayThree}{gray}{0.70}
\definecolor{grayFour}{gray}{0.60}
\definecolor{grayFive}{gray}{0.50}
% Formatierung
\RequirePackage{geometry}
%\RequirePackage[onehalfspacing]{setspace} % Für optimierten 1,5fachen Zeilenabstand
\RequirePackage{multicol}
\RequirePackage{ragged2e}
\RequirePackage{booktabs}
\RequirePackage{tabularx}
\RequirePackage[final]{pdfpages}
\RequirePackage[font=small,labelfont=bf]{caption}
% Überschriftenformatierung
\renewcommand{\partheadstartvskip}{% Teil-Überschrift beginnen mit
\cleardoublepage% neuer Seite
}
% Grafik
\RequirePackage{graphicx}
\RequirePackage{tikz}
\usetikzlibrary{positioning}
\usetikzlibrary{plotmarks}
% Aufzählungen
\RequirePackage{paralist}
% Links und Bookmarks
\RequirePackage[hyphens]{url}
\RequirePackage[pdftex,unicode]{hyperref}
\RequirePackage{bookmark}
% Tools
\RequirePackage{etoolbox}
\RequirePackage{ifthen}
\RequirePackage{xstring}
\RequirePackage{blindtext}
\RequirePackage{eurosym}
% Tabellen
\RequirePackage{booktabs}
\RequirePackage{tabularx}
% Datenaufbereitung und Statistiken
\RequirePackage{datatool}
\RequirePackage{datapie}
\RequirePackage{databar}
\RequirePackage{dataplot}
\newcommand{\DTLfempty}[1]{\DTLifeq{}{#1}{---}{#1}}
% Autoren
\newcommand{\autorblock}[6]{ % Ein Block im Autorenblock
\multicolumn{2}{c}{\Large\textsc{#1}\vspace{0.2cm}} \\
& \\
\textbf{Adresse: } & #2 \\
\textbf{E-Mail: } & #3 \\
\textbf{Matrikelnr.: } & #4 \\
& \\
\textbf{Studiengang: } & #5 \\
\textbf{Studienfächer: } & #6 \\
}
\newcommand{\autorenblock}{}
\newcommand{\autorenstring}{}
\newcommand{\setAutor}[6]{ % Name, Adresse, E-Mail, Matrikelnummer, Studiengang, Studienfächer
% Block für den Autor zum Autorenblock hinzufügen
\renewcommand{\autorenblock}{\autorblock{#1}{#2}{#3}{#4}{#5}{#6}}
% Autor zum Autorenstring hinzufügen
\renewcommand{\autorenstring}{#1}
}
% TODOs
%\RequirePackage[textsize=footnotesize,textwidth=30mm]{todonotes}
%\reversemarginpar
%\setlength{\marginparwidth}{30mm}
%\newcommand{\td}[2][]
%{\todo[caption={#2}, size=\footnotesize, #1]{\renewcommand{\baselinestretch}{0.5}\selectfont#2\par}}
% Abkürzungen
\newcommand{\SuS}{Schülerinnen und Schüler }
\newcommand{\SuSn}{Schülerinnen und Schülern }
% Abkürzungsverzeichnis und Glossar
\RequirePackage[toc,translate=false,acronym,nonumberlist]{glossaries}
\renewcommand{\acronymname}{Abkürzungsverzeichnis}
\renewcommand{\glossaryname}{Glossar}
\renewcommand*{\glspostdescription}{}
\RequirePackage{glossary-mcols}
\renewcommand*{\glsmcols}{2}
\makeglossaries
% Akronym mit Glossareintrag
\newcommand{\newacronymex}[4]{
\newacronym{#1}{#2}{\gls{long#1}}
\newglossaryentry{long#1}{
name={#3},
description={#4}
}
}
% z.B.
\newcommand{\zb}{z.\,B. }
% Quelltexte
\RequirePackage{listings}
\lstset{showspaces=false,
showstringspaces=false
showtabs=false}
\lstset{tabsize=3}
\lstset{frame=single,
frameround=ffff}
\lstset{extendedchars=true}
\lstset{basicstyle=\ttfamily\small,
keywordstyle=\color{black}\underbar\bfseries,
identifierstyle=,
commentstyle=\color{gray}}
\lstset{backgroundcolor=\color{white}}
\lstset{numbers=left,
numberstyle=\sffamily\tiny,
stepnumber=1,
numbersep=5pt}
\lstset{captionpos=b}
\lstset{breaklines=true}
\lstset{literate=%
{Ö}{{\"O}}1
{Ä}{{\"A}}1
{Ü}{{\"U}}1
{ß}{{\ss}}2
{ü}{{\"u}}1
{ä}{{\"a}}1
{ö}{{\"o}}1
}
% Referenzen
\newcommand{\referenztyp}[1]{\IfBeginWith{#1}{fig}{Abbildung}{\IfBeginWith{#1}{alg}{Algorithmus}{\IfBeginWith{#1}{tab}{Tabelle}{\IfBeginWith{#1}{sec}{Abschnitt}{\IfBeginWith{#1}{chp}{Kapitel}{\IfBeginWith{#1}{par}{Abschnitt}{\IfBeginWith{#1}{box}{Kasten in Abschnitt}{}}}}}}}}
\newcommand{\referenz}[1]{\referenztyp{#1}~\ref{#1}}
\newcommand{\referenzseite}[1]{\referenztyp{#1}~\ref{#1} auf Seite~\pageref{#1}}
% Zitation
\RequirePackage[german=quotes,threshold=15,thresholdtype=words]{csquotes}
\RequirePackage{natbib}
\newcommand{\allebibs}{}
\newcommand{\addBib}[1]{
% Bib hinzufügen
\csappto{allebibs}{\bibliography{#1}}
}
% Zitate
\newcommand{\zitat}[4][]{\textquote[{\citealp[S.~#4]{#3}}]{#2}#1}
%\newcommand{\zitatblock}[4][]{\singlespacing \small \blockquote[{\citealp[S.~#4]{#3}}]{\textcolor{gray}{#2}}#1 \normalsize \onehalfspacing}
\newcommand{\zitatblock}[4][]{\small \blockquote[{\citealp[S.~#4]{#3}}]{\textcolor{gray}{#2}}#1 \normalsize}
\newcommand{\vgl}[3][vgl.]{\footnote{\cite[#1][S.~#3]{#2}}}
\newcommand{\vgln}[2][vgl.]{\footnote{\cite[#1][]{#2}}}
\newcommand{\vglr}[2][vgl.]{\footnote{(#1 \referenz{#2})}}
% Boxen
\RequirePackage[framemethod=tikz]{mdframed}
\definecolor{grey}{rgb}{0.5,0.5,0.5}
\RequirePackage{wrapfig}
\setlength{\fboxsep}{10pt}
\newcommand{\floatingBox}[3]{
\begin{wrapfigure}{r}{#1}
\vspace{-10pt}
\begin{mdframed}[roundcorner=10,%
frametitle=#2,%
frametitlerule=true,%
frametitlebackgroundcolor=grayTwo,%
backgroundcolor=grayOne,%
]
\small #3
\end{mdframed}
\vspace{-10pt}
\end{wrapfigure}
}
\newcommand{\staticBox}[2]{
\begin{mdframed}[%
roundcorner=10,%
skipabove=5pt,%
frametitle=#1,%
frametitlerule=true,%
frametitlebackgroundcolor=grayTwo,%
backgroundcolor=grayOne,%
]
\small #2
\end{mdframed}
}
% Metadaten
\title{\titel}
\author{\autorenstring}
% PDF-Daten
\AtEndPreamble{\hypersetup{
unicode=true, % non-Latin characters in Acrobats bookmarks
pdftoolbar=true, % show Acrobats toolbar?
pdfmenubar=true, % show Acrobats menu?
pdffitwindow=false, % window fit to page when opened
pdfstartview={FitH}, % fits the width of the page to the window
pdftitle={\titel}, % title
pdfauthor={\autorenstring}, % author
pdfsubject={\veranstaltung}, % subject of the document
pdfkeywords={\titel \veranstaltung \gutachter}, % list of keywords
pdfborder={0 0 0},
colorlinks=\farbigelinks, % false: boxed links; true: colored links
linkcolor=buwDark, % color of internal links
citecolor=buwDark, % color of links to bibliography
filecolor=buw, % color of file links
urlcolor=buwDark % color of external links
}}
% Titelseite
\AtBeginDocument{
\begin{titlepage}
\begin{center}
\textsc{\Huge \titel}
\vspace*{1.5cm}
\parbox{10cm}{
Schriftliche Hausarbeit im Rahmen der ersten Staatsprüfung, dem Landesprüfungsamt für Erste Staatsprüfungen für Lehrämter an Schulen vorglegt von:
}
\vspace*{1cm}
\begin{tabular}{ll}
\autorenblock
& \\
& \\
\textbf{Beilage:} & CD mit Materialien \\
\textbf{Abgabedatum:} & \datum \\
\textbf{Erstgutachter:} & \gutachter \\
\textbf{Zweitgutachter:} & \gutachterzwei
\end{tabular}
\vfill
\includegraphics[width=0.5\textwidth]{\fblogo}
\vfill
\textsc{\Large \veranstaltung}
\bigskip
\textsc{\large \gutachter}
\vspace*{1cm}
\includegraphics[width=0.1\textwidth]{\unilogo}
\uniname
\fbname
\end{center}
\end{titlepage}
\cleardoublepage
\begin{abstract}
\zusammenfassung
\end{abstract}
\cleardoublepage
\tableofcontents
\cleardoublepage
\newpage
%\onehalfspacing
}
\newcommand{\Erklaerung}{
\
\vfill
\begin{center}
\addcontentsline{toc}{chapter}{Erklärungen}
{\bfseries\Huge Abschließende Erklärung}
\vspace*{0.4cm}
{\Large gem. §~17~Abs.~7 LPO 2003}
\vspace*{0.8cm}
\end{center}
\noindent Ich versichere, dass ich die schriftliche Hausarbeit -- einschließlich beigefügter Zeichnungen, Kartenskizzen und Darstellungen -- selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Alle Stellen der Arbeit, die dem Wortlaut oder dem Sinne nach anderen Werken entnommen sind, habe ich in jedem Fall unter Angabe der Quelle deutlich als Entlehnung kenntlich gemacht.
\vspace*{2cm}
\noindent \hrulefill \hfill \hrulefill
\noindent Datum \hfill Unterschrift
\vfill
\begin{center}
{\bfseries\Huge Erklärung zur weiteren Verwendung}
\vspace*{0.8cm}
\end{center}
\noindent Hiermit erkläre ich mich damit einverstanden, dass diese Arbeit wissenschaftlich interessierten Personen oder Institutionen zur Einsichtnahme zur Verfügung gestellt werden kann.
Korrektur- oder Bewertungshinweise in meiner Arbeit dürfen nicht zitiert werden.
\vspace*{2cm}
\noindent \hrulefill \hfill \hrulefill
\noindent Datum \hfill Unterschrift
\vfill
}
% Verzeichnisse, Glossar, Bibliographie, Erklärung
\renewcommand{\glsnamefont}[1]{\textsf{#1}}
\renewcommand{\lstlistlistingname}{Quelltextverzeichnis}
\newcommand{\examenAbschluss}{
\glsaddall
{\RaggedRight
\glossarystyle{mcolindex}
\printglossary[type=\acronymtype]
}
\newpage
\glossarystyle{\glossarstil}
\printglossary
\newpage
\addcontentsline{toc}{chapter}{Abbildungsverzeichnis}
\listoffigures
\begingroup
\addcontentsline{toc}{chapter}{Tabellenverzeichnis}
\let\clearpage\relax
\listoftables
\endgroup
\begingroup
\addcontentsline{toc}{chapter}{Quelltextverzeichnis}
\let\clearpage\relax
\lstlistoflistings
\endgroup
\begin{flushleft}
\bibliographystyle{natdin}
\addcontentsline{toc}{chapter}{Literaturverzeichnis}
\allebibs
\end{flushleft}
\newpage
\Erklaerung
}

Binary file not shown.

View file

@ -0,0 +1,118 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
id="svg2"
version="1.1"
inkscape:version="0.48.3.1 r9886"
width="335"
height="146.25"
xml:space="preserve"
sodipodi:docname="ddi_logo_head.svg"><metadata
id="metadata8"><rdf:RDF><cc:Work
rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title></dc:title></cc:Work></rdf:RDF></metadata><defs
id="defs6" /><sodipodi:namedview
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1"
objecttolerance="10"
gridtolerance="10"
guidetolerance="10"
inkscape:pageopacity="0"
inkscape:pageshadow="2"
inkscape:window-width="613"
inkscape:window-height="406"
id="namedview4"
showgrid="false"
inkscape:zoom="1.519403"
inkscape:cx="125.92251"
inkscape:cy="81.672669"
inkscape:window-x="1746"
inkscape:window-y="174"
inkscape:window-maximized="0"
inkscape:current-layer="g10" /><g
id="g10"
inkscape:groupmode="layer"
inkscape:label="logoddi"
transform="matrix(1.25,0,0,-1.25,0,146.25)"><g
id="g20"
style="fill:#b3b3b3;fill-opacity:1"><text
id="text22"
transform="matrix(1,0,0,-1,3.80313,1.8082)"
style="fill:#b3b3b3;fill-opacity:1"><tspan
id="tspan24"
sodipodi:role="line"
y="0"
x="0 17.327864 23.999859 38.663754 52.007668 65.351578 73.343559 80.015556 100.031 114.69501 128.03903 144.047 150.71904 165.38298 173.37502 188.03896 197.37497 218.71083 232.05479 240.04681 246.71886"
style="font-size:23.99970055000000002px;font-variant:normal;font-weight:bold;writing-mode:lr-tb;fill:#b3b3b3;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Arial;-inkscape-font-specification:ArialMT-Bold">DidaktikderInformatik</tspan></text>
</g><path
inkscape:connector-curvature="0"
id="path56"
style="fill:#b3b3b3;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 78.6969,66.9562 c 4.2609,-0.0152 8.5222,-0.0203 12.7832,-0.0332 2.8597,-0.0101 5.0121,-0.2089 6.4097,-0.573 1.9082,-0.4961 3.4102,-1.4199 4.5592,-2.7461 1.173,-1.3519 1.947,-3.0437 2.27,-5.0758 0.341,-2.1461 0.195,-4.8312 -0.525,-8.2101 -0.66,-3.0938 -1.631,-5.8641 -3.016,-8.2969 C 99.4469,38.977 97.293,36.441 94.8039,34.4301 92.8641,32.8621 90.443,31.5922 87.5762,30.7219 85.377,30.0551 82.616,29.766 79.266,29.777 c -5.6762,0.0191 -11.3519,0.0402 -17.0031,0.064 3.3531,7.5981 6.4582,14.5852 9.2633,20.9328 2.5699,5.8164 4.9816,11.2301 7.1707,16.1824 z m 5.0359,-5.064 C 80.941,54.6582 77.798,46.568 74.2762,37.491 c 2.1437,-0.009 4.2879,-0.018 6.4308,-0.0269 2.411,-0.009 4.1821,0.132 5.3442,0.407 1.4898,0.3531 2.8226,0.9437 3.9937,1.7961 1.1403,0.8281 2.236,2.1269 3.3192,3.9687 1.0558,1.7993 1.973,4.1512 2.7468,7.0453 0.7422,2.7719 1.0243,4.8098 0.8961,6.211 -0.1281,1.4 -0.5218,2.4359 -1.1929,3.1726 -0.6879,0.7563 -1.684,1.2301 -2.961,1.5063 -0.941,0.2039 -2.9031,0.3059 -5.857,0.309 -1.0883,0.0019 -2.175,0.0082 -3.2633,0.0121" /><path
inkscape:connector-curvature="0"
id="path58"
style="fill:#b3b3b3;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 127.856,66.8301 c 4.26,-0.0141 8.522,-0.025 12.802,-0.0328 2.9,-0.0063 5.106,-0.2043 6.686,-0.5743 2.099,-0.4921 3.985,-1.43 5.65,-2.755 1.7,-1.352 3.156,-3.0489 4.298,-5.091 1.202,-2.1489 2.071,-4.8598 2.675,-8.2438 0.555,-3.1094 0.647,-5.8773 0.217,-8.3312 -0.535,-3.0481 -1.683,-5.6122 -3.388,-7.6231 -1.339,-1.5789 -3.249,-2.841 -5.81,-3.7269 -1.918,-0.6629 -4.601,-0.9622 -7.976,-0.9469 -5.702,0.0242 -11.378,0.048 -17.08,0.073 0.396,7.6199 0.751,14.6371 1.077,21.0129 0.298,5.843 0.601,11.2641 0.849,16.2391 z m 7.032,-5.0789 c 0.023,-7.2641 0.052,-15.3793 0.09,-24.5012 2.143,-0.009 4.287,-0.0219 6.455,-0.0258 2.411,-0.0062 4.154,0.1309 5.202,0.4067 1.375,0.3621 2.478,0.9492 3.332,1.8101 0.817,0.8242 1.411,2.1422 1.757,3.982 0.341,1.8122 0.346,4.1711 -0.015,7.0739 -0.346,2.7801 -0.853,4.8281 -1.519,6.2301 -0.669,1.4082 -1.505,2.4371 -2.478,3.1832 -0.969,0.7418 -2.148,1.2378 -3.547,1.5109 -1.024,0.1988 -3.039,0.3078 -6.035,0.3187 -1.067,0.0032 -2.155,0.0071 -3.242,0.0114" /><path
inkscape:connector-curvature="0"
id="path60"
style="fill:#b3b3b3;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 200.182,29.2602 c -3.08,7.664 -5.921,14.7187 -8.496,21.1207 -2.361,5.8683 -4.55,11.3043 -6.565,16.2964 2.348,-0.0074 4.715,-0.0062 7.062,-0.0144 2.294,-4.9949 4.779,-10.4457 7.476,-16.3117 2.948,-6.4102 6.168,-13.4629 9.702,-21.1313 -3.068,0.0129 -6.136,0.0262 -9.179,0.0403" /><path
inkscape:connector-curvature="0"
id="path62"
style="fill:#d3e9a7;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 47.243,67.3379 c 3.3261,-0.0059 5.264,-1.0059 5.8711,-3.0598 0.7347,-2.4859 -0.7071,-6.8402 -4.7153,-13.434 -4.409,-7.2562 -9.2648,-12.9589 -14.3476,-16.6062 -4.4043,-3.159 -8.8063,-4.7188 -13.1403,-4.7 -4.3347,0.0183 -6.5218,1.7414 -6.5187,5.2543 0.0039,3.2687 3.075,8.8566 8.8457,16.1988 5.1422,6.541 9.7531,10.8762 13.9871,13.3762 3.398,2.0058 6.6922,2.9769 10.018,2.9707 z M 43.9828,62.6488 C 43.166,62.6512 42.2551,62.4332 41.293,61.977 40.302,61.5059 39.1629,60.6773 37.9238,59.4551 36.3039,57.857 34.0059,55.0422 30.9801,50.9012 27.7609,46.4953 25.6371,43.2832 24.8352,41.4961 24.0129,39.6629 23.702,38.3809 24,37.7582 c 0.3102,-0.648 1.0172,-0.9562 1.9719,-0.9602 1.0043,-0.0039 2.107,0.3122 3.3222,0.9559 1.1879,0.6301 2.5379,1.7801 4.05,3.393 1.868,1.9922 4.3438,5.3144 7.259,9.7172 2.7457,4.1492 4.3297,6.8531 4.861,8.2929 0.5109,1.3871 0.5898,2.3469 0.2629,2.8051 -0.3372,0.4699 -0.9282,0.684 -1.7442,0.6867" /><path
inkscape:connector-curvature="0"
id="path64"
style="fill:#d3e9a7;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 257.463,28.9 c -2.917,0.0129 -5.809,0.025 -8.7,0.0379 -7.651,10.9504 -14.35,20.5519 -20.257,29.0101 -1.099,-2.2191 -3.163,-3.864 -6.154,-4.9511 -1.247,2.0172 -2.488,3.9801 -3.698,5.9 1.526,0.5222 2.874,1.5304 4.063,2.9551 1.172,1.405 1.487,3.0101 1.009,4.7781 1.814,0.0031 3.628,-0.0031 5.422,-0.009 3.77,-5.0231 7.893,-10.5109 12.327,-16.4191 4.853,-6.4649 10.174,-13.5637 15.988,-21.302" /><path
inkscape:connector-curvature="0"
id="path66"
style="fill:#d3e9a7;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 69.0738,98.6621 c 2.5071,-0.0039 4.0942,-0.557 4.7992,-1.693 0.852,-1.373 0.2809,-3.7461 -1.8589,-7.2793 -2.2879,-3.7757 -5.036,-6.6476 -8.1711,-8.4777 -2.659,-1.5519 -5.525,-2.3379 -8.561,-2.334 -3.0179,0.0028 -4.814,0.875 -5.3621,2.5899 -0.5269,1.648 0.7942,4.4718 3.8039,8.2902 2.7492,3.4887 5.4852,5.8688 8.2602,7.2418 2.248,1.1129 4.598,1.6672 7.0898,1.6621 z m -1.816,-2.6059 c -0.6058,8e-4 -1.2449,-0.123 -1.9008,-0.371 -0.6761,-0.2551 -1.3922,-0.7161 -2.1449,-1.3829 -0.9762,-0.8652 -2.2691,-2.3875 -3.8793,-4.591 -1.6867,-2.3101 -2.7156,-3.948 -3.0289,-4.8644 -0.316,-0.9239 -0.3348,-1.577 -0.0398,-1.8848 0.3168,-0.3312 0.848,-0.4832 1.5218,-0.4851 0.709,-8e-4 1.459,0.1652 2.22,0.4921 0.7511,0.3231 1.5703,0.8938 2.4113,1.6969 1.075,1.025 2.3969,2.727 3.9269,5.0371 1.459,2.2051 2.259,3.6719 2.4629,4.4481 0.2008,0.759 0.1539,1.2859 -0.164,1.5359 -0.3149,0.2488 -0.7641,0.368 -1.3852,0.3691" /><path
inkscape:connector-curvature="0"
id="path68"
style="fill:#d3e9a7;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 103.092,98.6191 c 2.506,-0.0039 4.307,-0.5609 5.426,-1.6968 1.349,-1.37 1.64,-3.7575 0.765,-7.2914 -0.935,-3.7778 -2.639,-6.6649 -5.108,-8.4926 -2.111,-1.5633 -4.707,-2.3453 -7.7262,-2.341 -3.0359,0.0039 -5.1636,0.88 -6.3316,2.5976 -1.1262,1.6551 -0.8434,4.4762 0.7808,8.3051 1.4848,3.498 3.384,5.8863 5.6641,7.2613 1.852,1.1168 4.0229,1.6629 6.5299,1.6578 z m -0.87,-2.6132 c -0.622,0.0023 -1.229,-0.1219 -1.781,-0.3637 -0.582,-0.2539 -1.1289,-0.7223 -1.643,-1.3871 -0.6742,-0.8711 -1.425,-2.3899 -2.2449,-4.6039 -0.8562,-2.3121 -1.284,-3.9582 -1.2812,-4.8774 0.0043,-0.9269 0.2402,-1.5625 0.6781,-1.8816 0.4398,-0.3211 1.0059,-0.4922 1.698,-0.4942 0.7079,-0.0019 1.3821,0.1649 2.0411,0.493 0.6499,0.3242 1.2639,0.8922 1.8089,1.7012 0.689,1.025 1.398,2.7316 2.098,5.0519 0.667,2.209 0.958,3.6809 0.866,4.4508 -0.091,0.7692 -0.325,1.2891 -0.72,1.541 -0.404,0.2571 -0.899,0.3692 -1.52,0.37" /><path
inkscape:connector-curvature="0"
id="path70"
style="fill:#d3e9a7;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 139.881,98.5812 c 2.521,-0.005 4.54,-0.5652 6.104,-1.7042 1.901,-1.384 3.142,-3.768 3.653,-7.304 0.548,-3.7968 -0.023,-6.6847 -1.79,-8.5269 -1.497,-1.5602 -3.803,-2.352 -6.856,-2.3481 -3.054,0.004 -5.519,0.8883 -7.363,2.6059 -1.787,1.6652 -2.605,4.5012 -2.471,8.3293 0.122,3.5129 1.072,5.8867 2.848,7.2758 1.422,1.1109 3.354,1.6762 5.875,1.6722 z m 0.154,-2.6222 c -0.621,0.0012 -1.165,-0.1149 -1.651,-0.3649 -0.482,-0.248 -0.845,-0.725 -1.099,-1.391 -0.334,-0.875 -0.489,-2.4 -0.442,-4.609 0.049,-2.323 0.274,-3.966 0.646,-4.891 0.377,-0.9351 0.854,-1.582 1.4,-1.8969 0.565,-0.3273 1.197,-0.4863 1.906,-0.4871 0.708,-0.0019 1.318,0.1661 1.847,0.4938 0.523,0.3262 0.907,0.9 1.14,1.707 0.298,1.0324 0.345,2.7332 0.137,5.0582 -0.199,2.2168 -0.497,3.6949 -0.881,4.4641 -0.386,0.775 -0.84,1.2949 -1.337,1.5457 -0.5,0.2512 -1.044,0.3703 -1.666,0.3711" /><path
inkscape:connector-curvature="0"
id="path72"
style="fill:#d3e9a7;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 186.729,78.807 c -2.015,0.0059 -4.047,0.011 -6.044,0.0082 -2.183,5.4059 -4.186,10.3278 -5.999,14.82 -1.46,-1.2 -3.414,-2.0743 -5.877,-2.6571 -0.362,1.0719 -0.721,2.1258 -1.071,3.1629 1.273,0.2781 2.538,0.825 3.839,1.6172 1.257,0.7648 1.972,1.6559 2.125,2.6477 1.344,-0.0016 2.702,0.0043 4.061,0.0023 1.279,-2.7883 2.634,-5.748 4.071,-8.891 1.522,-3.3293 3.162,-6.9031 4.895,-10.7102" /><path
inkscape:connector-curvature="0"
id="path74"
style="fill:#d3e9a7;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 220.069,78.7398 c -2.051,-0.0027 -4.065,0.0024 -6.08,0.0082 -3.777,5.409 -7.2,10.343 -10.341,14.8442 -1.11,-1.1942 -2.823,-2.0781 -5.148,-2.6621 -0.672,1.0738 -1.34,2.139 -1.991,3.1691 1.19,0.2879 2.322,0.8348 3.38,1.6207 1.045,0.7754 1.503,1.6602 1.366,2.6551 1.358,-0.0031 2.717,-0.0059 4.075,0.0012 2.091,-2.7942 4.321,-5.7653 6.681,-8.911 2.506,-3.3402 5.196,-6.9179 8.058,-10.7254" /><path
inkscape:connector-curvature="0"
id="path76"
style="fill:#d3e9a7;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 81.4371,116.399 c 2.032,-0.001 3.3879,-0.372 4.0699,-1.118 0.8192,-0.895 0.6008,-2.439 -0.773,-4.693 -1.443,-2.368 -3.3238,-4.156 -5.5969,-5.291 -1.9101,-0.954 -4.073,-1.434 -6.4402,-1.431 -2.368,0.003 -3.884,0.527 -4.525,1.576 -0.6289,1.028 0.0652,2.781 1.9531,5.185 1.7578,2.238 3.6578,3.768 5.748,4.676 1.693,0.736 3.5442,1.097 5.5641,1.096 z m -1.1949,-1.726 c -0.4891,0 -0.9981,-0.084 -1.4942,-0.243 -0.5082,-0.162 -1.0308,-0.449 -1.5679,-0.888 -0.6871,-0.563 -1.543,-1.534 -2.5731,-2.945 -1.0629,-1.455 -1.684,-2.483 -1.8218,-3.059 -0.1383,-0.575 -0.0801,-0.964 0.1968,-1.16 0.2918,-0.206 0.7258,-0.306 1.2692,-0.307 0.5429,-0.001 1.1136,0.104 1.6886,0.312 0.5512,0.2 1.1243,0.553 1.6891,1.053 0.7352,0.65 1.6031,1.696 2.575,3.156 0.9383,1.408 1.425,2.353 1.5039,2.851 0.0781,0.495 -0.0289,0.828 -0.2988,0.986 -0.282,0.165 -0.666,0.244 -1.1668,0.244" /><path
inkscape:connector-curvature="0"
id="path78"
style="fill:#d3e9a7;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 109.068,116.388 c 2.021,-0.001 3.52,-0.374 4.472,-1.121 1.145,-0.898 1.469,-2.433 0.906,-4.698 -0.589,-2.37 -1.809,-4.169 -3.674,-5.305 -1.572,-0.958 -3.565,-1.426 -5.932,-1.427 -2.368,-0.001 -4.087,0.531 -5.1111,1.581 -0.9969,1.024 -0.9699,2.789 0.0602,5.191 0.9579,2.235 2.3189,3.769 4.0879,4.68 1.419,0.73 3.147,1.1 5.191,1.099 z m -0.584,-1.731 c -0.501,0 -0.982,-0.076 -1.417,-0.235 -0.451,-0.164 -0.862,-0.464 -1.244,-0.899 -0.491,-0.56 -0.993,-1.532 -1.517,-2.945 -0.542,-1.461 -0.782,-2.49 -0.724,-3.067 0.057,-0.577 0.27,-0.967 0.633,-1.164 0.363,-0.196 0.819,-0.298 1.376,-0.298 0.557,-0.001 1.078,0.102 1.577,0.304 0.495,0.199 0.946,0.553 1.335,1.056 0.495,0.641 0.971,1.702 1.413,3.164 0.428,1.414 0.573,2.351 0.469,2.859 -0.101,0.489 -0.313,0.828 -0.645,0.989 -0.338,0.163 -0.754,0.236 -1.256,0.236" /><path
inkscape:connector-curvature="0"
id="path80"
style="fill:#d3e9a7;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 138.912,116.376 c 2.032,-0.001 3.672,-0.373 4.905,-1.116 1.507,-0.907 2.449,-2.448 2.773,-4.711 0.339,-2.369 -0.177,-4.176 -1.607,-5.313 -1.199,-0.955 -3,-1.43 -5.382,-1.431 -2.381,-0.001 -4.312,0.526 -5.756,1.577 -1.416,1.03 -2.043,2.797 -1.962,5.207 0.075,2.242 0.827,3.775 2.254,4.685 1.156,0.736 2.73,1.103 4.775,1.102 z m 0.089,-1.727 c -0.501,0.001 -0.938,-0.079 -1.323,-0.245 -0.386,-0.166 -0.684,-0.455 -0.892,-0.893 -0.271,-0.569 -0.402,-1.542 -0.374,-2.953 0.029,-1.463 0.197,-2.487 0.489,-3.068 0.29,-0.576 0.649,-0.968 1.077,-1.167 0.441,-0.205 0.936,-0.299 1.492,-0.3 0.557,-10e-4 1.036,0.103 1.457,0.305 0.415,0.2 0.734,0.547 0.936,1.051 0.257,0.643 0.314,1.719 0.185,3.174 -0.126,1.421 -0.359,2.358 -0.652,2.859 -0.292,0.498 -0.651,0.831 -1.044,0.991 -0.404,0.165 -0.85,0.246 -1.351,0.246" /><path
inkscape:connector-curvature="0"
id="path82"
style="fill:#d3e9a7;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 201.205,103.866 c -1.585,0.003 -3.157,0.005 -4.728,0.007 -2.319,3.322 -4.47,6.405 -6.475,9.268 -1.017,-0.756 -2.475,-1.327 -4.384,-1.695 -0.432,0.686 -0.86,1.364 -1.279,2.033 0.972,0.185 1.939,0.536 2.879,1.046 0.923,0.501 1.392,1.083 1.39,1.734 1.089,0 2.19,0 3.291,-0.001 1.369,-1.824 2.797,-3.73 4.306,-5.737 1.578,-2.099 3.244,-4.319 5,-6.655" /><path
inkscape:connector-curvature="0"
id="path84"
style="fill:#d3e9a7;fill-opacity:1;fill-rule:nonzero;stroke:none"
d="m 175.254,103.886 c -1.586,0.002 -3.157,0.004 -4.715,0.006 -1.337,3.314 -2.59,6.4 -3.745,9.265 -1.251,-0.754 -2.865,-1.333 -4.868,-1.7 -0.232,0.685 -0.462,1.362 -0.675,2.029 1.026,0.193 2.087,0.534 3.171,1.044 1.062,0.499 1.697,1.088 1.884,1.739 1.089,-0.001 2.179,-0.001 3.28,-0.002 0.838,-1.82 1.702,-3.727 2.622,-5.724 0.968,-2.1 1.971,-4.318 3.046,-6.657" /></g></svg>

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

View file

@ -0,0 +1,56 @@
\begin{tikzpicture}[]
\node[osGen,osPhone] (iPOS) {iPh. OS $\leq$ 3.1};
\node[osGen,osMob,below=of iPOS] (iPOS32) {iPh. OS 3.2};
\node[osGen,osMob,below=of iPOS32] (iOS42) {iOS 4.2};
\node[osGen,osMobEmb,below=of iOS42] (iOS) {iOS $\geq$ 4.3};
\node[osGen,osPC,left=0.5cm of iOS] (mSLion) {Mac OS X 10.8};
\node[osGen,osPC,above=of mSLion] (mLion) {Mac OS X 10.7};
\node[osGen,osPC,minimum height=2.15cm,above=of mLion] (mOSX) {Mac OS X};
\node[osGen,osEmb,left=3.5cm of iPOS] (osATV) {Mac OS X ATV};
\draw[pkrn] (mOSX.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn] (mLion.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn] (iPOS.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn] (iPOS32.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn] (iOS42.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn] (mOSX.west) ++(0,0.65cm) -- +(-0.5cm,0);
\draw[pkrn] (mOSX.east) ++(0,0.65cm) -- +(0.5cm,0);
\draw[pui, dashed] (mOSX.south) ++(0.15cm,0) -- +(0,-0.5cm);
\draw[pui, dashed] (mLion.south) ++(0.15cm,0) -- +(0,-0.5cm);
\draw[pui, dashed] (iPOS.south) ++(0.15cm,0) -- +(0,-0.5cm);
\draw[pui, dashed] (iPOS32.south) ++(0.15cm,0) -- +(0,-0.5cm);
\draw[pui, dashed] (iOS42.south) ++(0.15cm,0) -- +(0,-0.5cm);
\draw[pui, dashed] (iOS42.west) -- (mLion.east);
\draw[pui, dashed] (iOS.west) -- (mSLion.east);
% Legende
\node[] at (3.6cm,0.85cm) (osLegendPos) {};
\node[below=of osLegendPos] (osLegendTitle) {\bfseries Legende};
\matrix [below=0.15cm of osLegendTitle,row sep=0.1cm,column sep=0.1cm] (osLegend) {
\node[osGen,osPC,osLegend]{}; & \node[osLegendText]{Desktop OS}; \\
\node[osGen,osEmb,osLegend]{}; & \node[osLegendText]{Embedded OS};\\
\node[osGen,osMob,osLegend]{}; & \node[osLegendText]{Mobiles OS};\\
\node[osGen,osPhone,osLegend]{}; & \node[osLegendText]{Smartphone OS}; \\
\draw[dashed] +(-0.25cm,-0.25cm) -- +(0.25cm,-0.25cm); & \node[osLegendText]{Stark angepasst}; \\
\draw[pkrn] +(-0.25cm,-0.25cm) -- +(0.25cm,-0.25cm); & \node[osLegendText]{System- \& Dienstprog.}; \\
\draw[pui] +(-0.25cm,-0.25cm) -- +(0.25cm,-0.25cm); & \node[osLegendText]{Benutzungs-schnittstelle}; \\
};
\draw (osLegend.north east) rectangle (osLegend.south west);
\draw (osLegend.north east) ++(0,0.8cm) rectangle (osLegend.south west);
\end{tikzpicture}

View file

@ -0,0 +1,76 @@
\begin{tikzpicture}[]
\node[osGen,osPCEmb,minimum width=13.2cm] at (0,0) (lin) {GNU/Linux etc.};
\node[osGen,osMobPC] at (-5.35cm,-1.35cm) (moblin) {Moblin};
\node[osGen,osMobEmb,right=1cm of moblin] (maemo) {Maemo};
\node[osGen,osMobPCEmb,minimum width=6.05cm] at (-3.59cm,-2.7cm) (meego) {MeeGo};
\node[osGen,osPhone,right=1cm of maemo] (bada) {Bada};
\node[osGen,osTab,below=of bada] (plasma) {Plasma Active};
\node[osGen,osPC,below=of plasma] (cos) {Chrome OS};
\node[osGen,osMob,below=of cos] (fos) {Firefox OS};
\node[osGen,osPhone,left=1cm of cos] (jolla) {Jolla};
\node[osGen,osMobPCEmb,left=1cm of jolla] (tizen) {Tizen};
\node[osGen,osMob,below=1.85cm of meego] (mer) {mer};
\node[osGen,osPhonePCEmb,right=1cm of bada] (android2) {Android $<$ 3};
\node[osGen,osTabPC,below=of android2] (android3) {Android 3.x};
\node[osGen,osMobPCEmb,below=of android3] (android) {Android $\geq$ 4};
\node[osGen,osEmb,below=of android] (gtv) {Google TV};
\draw[pkrn] (moblin.north) ++(0cm,0.5cm) -- +(0,-0.5cm);
\draw[pkrn] (maemo.north) ++(0cm,0.5cm) -- +(0,-0.5cm);
\draw[pkrn,<-,dashed] (fos.east) -- +(0.5,0cm) -- +(0.5cm,4.95cm);
\draw[pkrn,<-,dashed] (cos.east) -- +(0.5,0cm);
\draw[pkrn,<-] (plasma.east) -- +(0.5,0cm) -- +(0.5cm,2.3cm);
\draw[pkrn,<-] (bada.east) -- +(0.5,0cm);
\draw[pkrn,dashed] (android2.north) ++(0cm,0.5cm) -- +(0,-0.5cm);
\draw[pkrn] (android2.south) -- (android3.north);
\draw[pkrn] (android3.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn] (android.south) -- (gtv.north);
\draw[pkrn,dashed] (moblin.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn,dashed] (maemo.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn,<-] (tizen.north) ++(-0.15cm,0) -- +(0,0.5cm);
\draw[pkrn] (mer.north east) ++(-0.5cm,0) -- (jolla.south);
\draw[pkrn,<->] (mer.north west) ++(0.5cm,0) -- (tizen.south);
\draw[pkrn,<-] (mer.north) ++(-0.15cm,0) -- +(0,1.85cm);
\draw[pui] (android3.south) ++(0.15cm,0) -- +(0,-0.5cm);
\draw[pui,<-] (maemo.east) -- +(0.45cm,0cm) -- +(0.45cm,0.95cm) node [sloped,midway,above] {QT};
\draw[pui,<-] (plasma.west) -- +(-0.45cm,0cm) -- +(-0.45cm,2.29cm) node [sloped,near start,below] {KDE};
\draw[pui,<-] (moblin.east) -- +(0.5cm,0cm) -- +(0.5cm,0.95cm) node [sloped,midway,above] {GTK};
\draw[pui,<-] (maemo.west) -- +(-0.5cm,0cm);
\draw[pui,dashed] (moblin.south) ++(0.15cm,0) -- +(0,-0.5cm);
\draw[pui,dashed] (maemo.south) ++(0.15cm,0) -- +(0,-0.5cm);
\draw[pui,<-,dashed] (tizen.north) ++(0.15cm,0) -- +(0,0.5cm);
\draw[pui,<-,dashed] (mer.north) ++(0.15cm,0) -- +(0,1.85cm);
% Legende
\node[] at (0cm,-6cm) (osLegendPos) {};
\node[below=of osLegendPos] (osLegendTitle) {\bfseries Legende};
\matrix [below=0.15cm of osLegendTitle,row sep=0.2cm,column sep=0.1cm] (osLegend) {
\node[osGen,osPC,osLegend]{}; & \node[osLegendText]{Desktop OS}; & \node[osGen,osEmb,osLegend]{}; & \node[osLegendText]{Embedded OS}; & \node[osGen,osMob,osLegend]{}; & \node[osLegendText]{Mobiles OS}; & \node[osGen,osTab,osLegend]{}; & \node[osLegendText]{Tablet OS}; \\
\node[osGen,osPhone,osLegend]{}; & \node[osLegendText]{Smartphone OS}; & \draw[dashed] +(-0.25cm,-0.25cm) -- +(0.25cm,-0.25cm); & \node[osLegendText]{Stark angepasst}; & \draw[pui] +(-0.25cm,-0.25cm) -- +(0.25cm,-0.25cm); & \node[osLegendText]{Benutzungs-schnittstelle}; & \draw[pkrn] +(-0.25cm,-0.25cm) -- +(0.25cm,-0.25cm); & \node[osLegendText]{System- \& Dienstprog.}; \\
};
\draw (osLegend.north east) rectangle (osLegend.south west);
\draw (osLegend.north east) ++(0,0.8cm) rectangle (osLegend.south west);
\end{tikzpicture}

View file

@ -0,0 +1,92 @@
\usetikzlibrary{positioning,arrows,matrix,shadings}
\tikzset{
% Standardpfeilspitze
>=,
% Knotenabstand
on grid=false,
node distance=0.5cm,
% Stile
osGen/.style={
rectangle,
rounded corners,
minimum height=0.8cm,
minimum width=2.5cm,
text centered
},
osPC/.style={
draw=red, very thick,
fill=red!50,},
osTab/.style={
draw=yellow, very thick,
fill=yellow!50,},
osPhone/.style={
draw=blue, very thick,
fill=blue!50,
},
osMob/.style={
draw=green, very thick,
fill=green!50,
},
osEmb/.style={
draw=gray, very thick,
fill=gray!50,
},
osMobEmb/.style={
shade,
draw=green,very thick,
top color=green!50,
bottom color=gray!50,
},
osMobPC/.style={
shade,
draw=green,very thick,
top color=green!50,
bottom color=red!50,
},
osMobPCEmb/.style={
shade,
draw=red,very thick,
top color=green!50,
bottom color=gray!50,
},
osPhonePCEmb/.style={
shade,
draw=red,very thick,
top color=blue!50,
bottom color=gray!50,
},
osTabPC/.style={
shade,
draw=red,very thick,
top color=yellow!50,
bottom color=red!50,
},
osPCEmb/.style={
shade,
draw=red,very thick,
top color=red!50,
bottom color=gray!50,
},
osLegend/.style={
minimum height=0.4cm,
minimum width=0.4cm,
},
osLegendText/.style={
minimum width=2.3cm,
text width=2.3cm,
},
% Pfeilstile
pui/.style={
->,
thick,
black,
>=latex
},
pkrn/.style={
->,
thick,
orange,
>=latex
}
}

View file

@ -0,0 +1,72 @@
\begin{tikzpicture}[]
\node[osGen,osPC] (winNT) {Win. NT};
\node[osGen,osPC, below=of winNT] (win2000) {Win. 2000};
\node[osGen,osPC, below=of win2000] (winXP) {Win. XP};
\node[osGen,osPC, below=of winXP] (winVista) {Win. Vista};
\node[osGen,osPC, below=of winVista] (win7) {Win. 7};
\node[osGen,osTabPC, below=of win7] (win8) {Win. 8};
\node[osGen,osTab,right=0.5cm of win8] (winRT) {Win. RT};
\node[osGen,osPhone,left=0.5cm of win7] (winP7) {Win. Phone 7};
\node[osGen,osPhone,left=0.5cm of win8] (winP8) {Win. Phone 8};
\node[osGen,osMob,above=of winP7,minimum height=2.1cm] (winMob) {Win. Mobile};
\node[osGen,osEmb,left=0.5cm of winP8] (winEC) {Win. EC};
\node[osGen,osEmb,above=of winEC,minimum height=6.16cm] (winCE) {Win. CE/ECE};
\draw[pkrn] (winNT.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn] (win2000.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn] (winXP.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn] (winVista.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn] (win7.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn] (winCE.south) ++(-0.15cm,0) -- +(0,-0.5cm);
\draw[pkrn] (winCE.east) ++(0,-0.3cm) -- +(0.5cm,0);
\draw[pkrn] (winMob) -- (winP7);
\draw[pkrn] (win8.east)++(0,-0.15cm) -- +(0.5cm,0);
\draw[pkrn] (win8.west)++(0,-0.15cm) -- +(-0.5cm,0);
\draw[pui,dashed] (winNT.west) -- +(-3.5cm,0);
\draw[pui] (winCE.east) -- +(0.5cm,0);
\draw[pui,dashed] (winXP) -- (winMob);
\draw[pui,dashed] (winVista) -- (winMob);
\draw[pui, dashed] (winNT.south) ++(0.15cm,0) -- +(0,-0.5cm);
\draw[pui, dashed] (win2000.south) ++(0.15cm,0) -- +(0,-0.5cm);
\draw[pui,dashed] (winXP.south) ++(0.15cm,0) -- +(0,-0.5cm);
\draw[pui,dashed] (winVista.south) ++(0.15cm,0) -- +(0,-0.5cm);
\draw[pui,dashed] (win7.south) ++(0.15cm,0) -- +(0,-0.5cm);
\draw[pui,dashed] (winP7) -- (win8);
\draw[pui] (win8.east) ++(0,0.15cm) -- +(0.5cm,0);
\draw[pui] (win8.west) ++(0,0.15cm) -- +(-0.5cm,0);
\draw[pui] (winCE.south) ++(0.15cm,0) -- +(0,-0.5cm);
% Legende
\node[] at (3.4cm,1.0cm) (osLegendPos) {};
\node[below=of osLegendPos] (osLegendTitle) {\bfseries Legende};
\matrix [below=0.15cm of osLegendTitle,row sep=0.2cm,column sep=0.1cm] (osLegend) {
\node[osGen,osPC,osLegend]{}; & \node[osLegendText]{Desktop OS}; \\
\node[osGen,osEmb,osLegend]{}; & \node[osLegendText]{Embedded OS};\\
\node[osGen,osMob,osLegend]{}; & \node[osLegendText]{Mobiles OS};\\
\node[osGen,osPhone,osLegend]{}; & \node[osLegendText]{Smartphone OS}; \\
\node[osGen,osTab,osLegend]{}; & \node[osLegendText]{Tablet OS}; \\
\draw[dashed] +(-0.25cm,-0.25cm) -- +(0.25cm,-0.25cm); & \node[osLegendText]{Stark angepasst}; \\
\draw[pkrn] +(-0.25cm,-0.25cm) -- +(0.25cm,-0.25cm); & \node[osLegendText]{System- \& Dienstprog.}; \\
\draw[pui] +(-0.25cm,-0.25cm) -- +(0.25cm,-0.25cm); & \node[osLegendText]{Benutzungs-schnittstelle}; \\
};
\draw (osLegend.north east) rectangle (osLegend.south west);
\draw (osLegend.north east) ++(0,0.8cm) rectangle (osLegend.south west);
\end{tikzpicture}

File diff suppressed because it is too large Load diff

View file

@ -0,0 +1,38 @@
input metauml;
beginfig(1);
% Klassen
Class.Dialog("Dialog")
("zTitel", "zNachricht")
("+Dialog(pTitel, pNachricht)", "+nachricht()", "+setzeNachricht(pNachricht)", "+setzeTitel(pTitel)", "+titel()", "+zeige()");
Class.EingabeDialog("EingabeDialog")
("zErgebnis")
("+EingabeDialog(pTitel, pNachricht)", "+ergenis()");
Class.PasswortDialog("PasswortDialog")
()
("+PasswortDialog(pTitel, pNachricht)");
Class.EntscheidungsDialog("EntscheidungsDialog")
("zErgebnis", "zText1 = 'Ja'", "zText2 = 'Nein'", "zText3 = 'Vielleicht'", "zZeigeDrei = False")
("+EntscheidungsDialog(pTitel, pNachricht)", "+ergebnis()", "+text1()", "+text2()", "+text3()", "+dreiTaster()", "+setzeDreiTaster(pDreiTaster)", "+setzeText1(pText)", "+setzeText2(pText)", "+setzeText3(pText)");
% Modul
Package.Dialoge("Dialoge")(Dialog, EingabeDialog, PasswortDialog, EntscheidungsDialog);
% Objekte anordnen
topToBottom(30)(Dialog, EingabeDialog);
topToBottom(30)(EingabeDialog, PasswortDialog);
leftToRight(30)(EingabeDialog, EntscheidungsDialog);
% Objekte zeichnen
drawObjects(Dialog, EingabeDialog, PasswortDialog, EntscheidungsDialog, Dialoge);
% Assoziatonen
clink(realization)(EingabeDialog, Dialog);
clink(realization)(PasswortDialog, EingabeDialog);
clink(realization)(EntscheidungsDialog, Dialog);
endfig;
end

View file

@ -0,0 +1,704 @@
%!PS
%%BoundingBox: -94 -157 184 28
%%HiResBoundingBox: -93.8551 -156.52289 183.55443 27.00458
%%Creator: MetaPost 1.504
%%CreationDate: 2012.08.01:0458
%%Pages: 1
%*Font: ptmro8r 9.96265 9.96265 4d:80000188808
%*Font: ptmr8r 9.96265 9.96265 28:c000004a0483007fcfbc2
%%BeginProlog
%%EndProlog
%%Page: 1 1
0.7 0.7 0.7 setrgbcolor
newpath 1 -1 moveto
96.58447 -1 lineto
96.58447 -90.76373 lineto
1 -90.76373 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 0 0 moveto
95.58447 0 lineto
95.58447 -89.76373 lineto
0 -89.76373 lineto
closepath fill
0 0 0 setrgbcolor 0 0.5 dtransform truncate idtransform setlinewidth pop
[] 0 setdash 1 setlinejoin 10 setmiterlimit
newpath 0 0 moveto
95.58447 0 lineto
95.58447 -89.76373 lineto
0 -89.76373 lineto
closepath stroke
1 setlinecap
newpath 0 -12.75458 moveto
95.58447 -12.75458 lineto stroke
newpath 0 -22.75916 moveto
95.58447 -22.75916 lineto stroke
30.9107 -9.75458 moveto
(Medium) ptmro8r 9.96265 fshow
13 -20.75916 moveto
(zPfad) ptmr8r 9.96265 fshow
13 -33.26373 moveto
(Medium\(pPfad\)) ptmr8r 9.96265 fshow
13 -43.76373 moveto
(gibWieder\(\)) ptmr8r 9.96265 fshow
13 -54.26373 moveto
(loesche\(\)) ptmr8r 9.96265 fshow
13 -64.76373 moveto
(nimmAuf\(pDauer\)) ptmr8r 9.96265 fshow
13 -75.26373 moveto
(nimmManuellAuf\(\)) ptmr8r 9.96265 fshow
13 -85.76373 moveto
(pfad\(\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath 2 -18.0592 moveto
7.95004 -18.0592 lineto
7.95004 -20.75916 lineto
2 -20.75916 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -20.75916 moveto
9 -19.7092 lineto
9 -17.00925 lineto
7.95004 -18.0592 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -18.0592 moveto
9 -17.00925 lineto
3.04996 -17.00925 lineto
2 -18.0592 lineto
closepath fill
0.3 0.3 0.3 setrgbcolor 0 0.79701 dtransform truncate idtransform setlinewidth pop
0 setlinecap
newpath 3.57498 -15.28423 moveto
4.09233 -14.64905 4.68942 -13.99338 5.5 -14.00916 curveto
6.97562 -14.03789 7.46918 -15.83012 7.42502 -17.53423 curveto stroke
0.4 0.4 0.4 setrgbcolor
newpath 2 -30.56378 moveto
7.95004 -30.56378 lineto
7.95004 -33.26373 lineto
2 -33.26373 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -33.26373 moveto
9 -32.21378 lineto
9 -29.51382 lineto
7.95004 -30.56378 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -30.56378 moveto
9 -29.51382 lineto
3.04996 -29.51382 lineto
2 -30.56378 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -41.06378 moveto
7.95004 -41.06378 lineto
7.95004 -43.76373 lineto
2 -43.76373 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -43.76373 moveto
9 -42.71378 lineto
9 -40.01382 lineto
7.95004 -41.06378 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -41.06378 moveto
9 -40.01382 lineto
3.04996 -40.01382 lineto
2 -41.06378 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -51.56378 moveto
7.95004 -51.56378 lineto
7.95004 -54.26373 lineto
2 -54.26373 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -54.26373 moveto
9 -53.21378 lineto
9 -50.51382 lineto
7.95004 -51.56378 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -51.56378 moveto
9 -50.51382 lineto
3.04996 -50.51382 lineto
2 -51.56378 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -62.06378 moveto
7.95004 -62.06378 lineto
7.95004 -64.76373 lineto
2 -64.76373 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -64.76373 moveto
9 -63.71378 lineto
9 -61.01382 lineto
7.95004 -62.06378 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -62.06378 moveto
9 -61.01382 lineto
3.04996 -61.01382 lineto
2 -62.06378 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -72.56378 moveto
7.95004 -72.56378 lineto
7.95004 -75.26373 lineto
2 -75.26373 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -75.26373 moveto
9 -74.21378 lineto
9 -71.51382 lineto
7.95004 -72.56378 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -72.56378 moveto
9 -71.51382 lineto
3.04996 -71.51382 lineto
2 -72.56378 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -83.06378 moveto
7.95004 -83.06378 lineto
7.95004 -85.76373 lineto
2 -85.76373 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -85.76373 moveto
9 -84.71378 lineto
9 -82.01382 lineto
7.95004 -83.06378 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -83.06378 moveto
9 -82.01382 lineto
3.04996 -82.01382 lineto
2 -83.06378 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath -88.6051 -120.76373 moveto
-16.82089 -120.76373 lineto
-16.82089 -152.52289 lineto
-88.6051 -152.52289 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath -89.6051 -119.76373 moveto
-17.82089 -119.76373 lineto
-17.82089 -151.52289 lineto
-89.6051 -151.52289 lineto
closepath fill
0 0 0 setrgbcolor 0 0.5 dtransform truncate idtransform setlinewidth pop
newpath -89.6051 -119.76373 moveto
-17.82089 -119.76373 lineto
-17.82089 -151.52289 lineto
-89.6051 -151.52289 lineto
closepath stroke
newpath -89.6051 -132.51831 moveto
-17.82089 -132.51831 lineto stroke
newpath -89.6051 -137.01831 moveto
-17.82089 -137.01831 lineto stroke
-66.16624 -129.51831 moveto
(Audio) ptmr8r 9.96265 fshow
-76.6051 -147.52289 moveto
(Audio\(pPfad\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath -87.6051 -144.82294 moveto
-81.65506 -144.82294 lineto
-81.65506 -147.52289 lineto
-87.6051 -147.52289 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath -81.65506 -147.52289 moveto
-80.6051 -146.47293 lineto
-80.6051 -143.77298 lineto
-81.65506 -144.82294 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath -81.65506 -144.82294 moveto
-80.6051 -143.77298 lineto
-86.55515 -143.77298 lineto
-87.6051 -144.82294 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 13.17911 -120.76373 moveto
84.40536 -120.76373 lineto
84.40536 -152.52289 lineto
13.17911 -152.52289 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 12.17911 -119.76373 moveto
83.40536 -119.76373 lineto
83.40536 -151.52289 lineto
12.17911 -151.52289 lineto
closepath fill
0 0 0 setrgbcolor
newpath 12.17911 -119.76373 moveto
83.40536 -119.76373 lineto
83.40536 -151.52289 lineto
12.17911 -151.52289 lineto
closepath stroke
newpath 12.17911 -132.51831 moveto
83.40536 -132.51831 lineto stroke
newpath 12.17911 -137.01831 moveto
83.40536 -137.01831 lineto stroke
35.61798 -129.51831 moveto
(Video) ptmr8r 9.96265 fshow
25.17911 -147.52289 moveto
(Video\(pPfad\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath 14.17911 -144.82294 moveto
20.12915 -144.82294 lineto
20.12915 -147.52289 lineto
14.17911 -147.52289 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 20.12915 -147.52289 moveto
21.17911 -146.47293 lineto
21.17911 -143.77298 lineto
20.12915 -144.82294 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 20.12915 -144.82294 moveto
21.17911 -143.77298 lineto
15.22906 -143.77298 lineto
14.17911 -144.82294 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 114.40536 -120.89824 moveto
179.55443 -120.89824 lineto
179.55443 -152.38838 lineto
114.40536 -152.38838 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 113.40536 -119.89824 moveto
178.55443 -119.89824 lineto
178.55443 -151.38838 lineto
113.40536 -151.38838 lineto
closepath fill
0 0 0 setrgbcolor
newpath 113.40536 -119.89824 moveto
178.55443 -119.89824 lineto
178.55443 -151.38838 lineto
113.40536 -151.38838 lineto
closepath stroke
newpath 113.40536 -132.3838 moveto
178.55443 -132.3838 lineto stroke
newpath 113.40536 -136.8838 moveto
178.55443 -136.8838 lineto stroke
136.84424 -129.3838 moveto
(Foto) ptmr8r 9.96265 fshow
126.40536 -147.38838 moveto
(Foto\(pPfad\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath 115.40536 -144.68843 moveto
121.35541 -144.68843 lineto
121.35541 -147.38838 lineto
115.40536 -147.38838 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 121.35541 -147.38838 moveto
122.40536 -146.33842 lineto
122.40536 -143.63847 lineto
121.35541 -144.68843 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 121.35541 -144.68843 moveto
122.40536 -143.63847 lineto
116.45532 -143.63847 lineto
115.40536 -144.68843 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 183.55443 11 moveto
-92.6051 11 lineto
-92.6051 -156.52289 lineto
183.55443 -156.52289 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 182.55443 12 moveto
-93.6051 12 lineto
-93.6051 -155.52289 lineto
182.55443 -155.52289 lineto
closepath fill
0 0 0 setrgbcolor
newpath 182.55443 12 moveto
-93.6051 12 lineto
-93.6051 -155.52289 lineto
182.55443 -155.52289 lineto
closepath stroke
0.9 0.9 0.9 setrgbcolor
newpath -39.11015 26.75458 moveto
-93.6051 26.75458 lineto
-93.6051 12 lineto
-39.11015 12 lineto
closepath fill
0 0 0 setrgbcolor
newpath -39.11015 26.75458 moveto
-93.6051 26.75458 lineto
-93.6051 12 lineto
-39.11015 12 lineto
closepath stroke
-89.6051 16 moveto
(Multimedia) ptmr8r 9.96265 fshow
0.7 0.7 0.7 setrgbcolor
newpath 1 -1 moveto
96.58447 -1 lineto
96.58447 -90.76373 lineto
1 -90.76373 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 0 0 moveto
95.58447 0 lineto
95.58447 -89.76373 lineto
0 -89.76373 lineto
closepath fill
0 0 0 setrgbcolor
newpath 0 0 moveto
95.58447 0 lineto
95.58447 -89.76373 lineto
0 -89.76373 lineto
closepath stroke
newpath 0 -12.75458 moveto
95.58447 -12.75458 lineto stroke
newpath 0 -22.75916 moveto
95.58447 -22.75916 lineto stroke
30.9107 -9.75458 moveto
(Medium) ptmro8r 9.96265 fshow
13 -20.75916 moveto
(zPfad) ptmr8r 9.96265 fshow
13 -33.26373 moveto
(Medium\(pPfad\)) ptmr8r 9.96265 fshow
13 -43.76373 moveto
(gibWieder\(\)) ptmr8r 9.96265 fshow
13 -54.26373 moveto
(loesche\(\)) ptmr8r 9.96265 fshow
13 -64.76373 moveto
(nimmAuf\(pDauer\)) ptmr8r 9.96265 fshow
13 -75.26373 moveto
(nimmManuellAuf\(\)) ptmr8r 9.96265 fshow
13 -85.76373 moveto
(pfad\(\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath 2 -18.0592 moveto
7.95004 -18.0592 lineto
7.95004 -20.75916 lineto
2 -20.75916 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -20.75916 moveto
9 -19.7092 lineto
9 -17.00925 lineto
7.95004 -18.0592 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -18.0592 moveto
9 -17.00925 lineto
3.04996 -17.00925 lineto
2 -18.0592 lineto
closepath fill
0.3 0.3 0.3 setrgbcolor 0 0.79701 dtransform truncate idtransform setlinewidth pop
newpath 3.57498 -15.28423 moveto
4.09233 -14.64905 4.68942 -13.99338 5.5 -14.00916 curveto
6.97562 -14.03789 7.46918 -15.83012 7.42502 -17.53423 curveto stroke
0.4 0.4 0.4 setrgbcolor
newpath 2 -30.56378 moveto
7.95004 -30.56378 lineto
7.95004 -33.26373 lineto
2 -33.26373 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -33.26373 moveto
9 -32.21378 lineto
9 -29.51382 lineto
7.95004 -30.56378 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -30.56378 moveto
9 -29.51382 lineto
3.04996 -29.51382 lineto
2 -30.56378 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -41.06378 moveto
7.95004 -41.06378 lineto
7.95004 -43.76373 lineto
2 -43.76373 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -43.76373 moveto
9 -42.71378 lineto
9 -40.01382 lineto
7.95004 -41.06378 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -41.06378 moveto
9 -40.01382 lineto
3.04996 -40.01382 lineto
2 -41.06378 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -51.56378 moveto
7.95004 -51.56378 lineto
7.95004 -54.26373 lineto
2 -54.26373 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -54.26373 moveto
9 -53.21378 lineto
9 -50.51382 lineto
7.95004 -51.56378 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -51.56378 moveto
9 -50.51382 lineto
3.04996 -50.51382 lineto
2 -51.56378 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -62.06378 moveto
7.95004 -62.06378 lineto
7.95004 -64.76373 lineto
2 -64.76373 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -64.76373 moveto
9 -63.71378 lineto
9 -61.01382 lineto
7.95004 -62.06378 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -62.06378 moveto
9 -61.01382 lineto
3.04996 -61.01382 lineto
2 -62.06378 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -72.56378 moveto
7.95004 -72.56378 lineto
7.95004 -75.26373 lineto
2 -75.26373 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -75.26373 moveto
9 -74.21378 lineto
9 -71.51382 lineto
7.95004 -72.56378 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -72.56378 moveto
9 -71.51382 lineto
3.04996 -71.51382 lineto
2 -72.56378 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -83.06378 moveto
7.95004 -83.06378 lineto
7.95004 -85.76373 lineto
2 -85.76373 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -85.76373 moveto
9 -84.71378 lineto
9 -82.01382 lineto
7.95004 -83.06378 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -83.06378 moveto
9 -82.01382 lineto
3.04996 -82.01382 lineto
2 -83.06378 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath -88.6051 -120.76373 moveto
-16.82089 -120.76373 lineto
-16.82089 -152.52289 lineto
-88.6051 -152.52289 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath -89.6051 -119.76373 moveto
-17.82089 -119.76373 lineto
-17.82089 -151.52289 lineto
-89.6051 -151.52289 lineto
closepath fill
0 0 0 setrgbcolor 0 0.5 dtransform truncate idtransform setlinewidth pop
newpath -89.6051 -119.76373 moveto
-17.82089 -119.76373 lineto
-17.82089 -151.52289 lineto
-89.6051 -151.52289 lineto
closepath stroke
newpath -89.6051 -132.51831 moveto
-17.82089 -132.51831 lineto stroke
newpath -89.6051 -137.01831 moveto
-17.82089 -137.01831 lineto stroke
-66.16624 -129.51831 moveto
(Audio) ptmr8r 9.96265 fshow
-76.6051 -147.52289 moveto
(Audio\(pPfad\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath -87.6051 -144.82294 moveto
-81.65506 -144.82294 lineto
-81.65506 -147.52289 lineto
-87.6051 -147.52289 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath -81.65506 -147.52289 moveto
-80.6051 -146.47293 lineto
-80.6051 -143.77298 lineto
-81.65506 -144.82294 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath -81.65506 -144.82294 moveto
-80.6051 -143.77298 lineto
-86.55515 -143.77298 lineto
-87.6051 -144.82294 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 13.17911 -120.76373 moveto
84.40536 -120.76373 lineto
84.40536 -152.52289 lineto
13.17911 -152.52289 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 12.17911 -119.76373 moveto
83.40536 -119.76373 lineto
83.40536 -151.52289 lineto
12.17911 -151.52289 lineto
closepath fill
0 0 0 setrgbcolor
newpath 12.17911 -119.76373 moveto
83.40536 -119.76373 lineto
83.40536 -151.52289 lineto
12.17911 -151.52289 lineto
closepath stroke
newpath 12.17911 -132.51831 moveto
83.40536 -132.51831 lineto stroke
newpath 12.17911 -137.01831 moveto
83.40536 -137.01831 lineto stroke
35.61798 -129.51831 moveto
(Video) ptmr8r 9.96265 fshow
25.17911 -147.52289 moveto
(Video\(pPfad\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath 14.17911 -144.82294 moveto
20.12915 -144.82294 lineto
20.12915 -147.52289 lineto
14.17911 -147.52289 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 20.12915 -147.52289 moveto
21.17911 -146.47293 lineto
21.17911 -143.77298 lineto
20.12915 -144.82294 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 20.12915 -144.82294 moveto
21.17911 -143.77298 lineto
15.22906 -143.77298 lineto
14.17911 -144.82294 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 114.40536 -120.89824 moveto
179.55443 -120.89824 lineto
179.55443 -152.38838 lineto
114.40536 -152.38838 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 113.40536 -119.89824 moveto
178.55443 -119.89824 lineto
178.55443 -151.38838 lineto
113.40536 -151.38838 lineto
closepath fill
0 0 0 setrgbcolor
newpath 113.40536 -119.89824 moveto
178.55443 -119.89824 lineto
178.55443 -151.38838 lineto
113.40536 -151.38838 lineto
closepath stroke
newpath 113.40536 -132.3838 moveto
178.55443 -132.3838 lineto stroke
newpath 113.40536 -136.8838 moveto
178.55443 -136.8838 lineto stroke
136.84424 -129.3838 moveto
(Foto) ptmr8r 9.96265 fshow
126.40536 -147.38838 moveto
(Foto\(pPfad\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath 115.40536 -144.68843 moveto
121.35541 -144.68843 lineto
121.35541 -147.38838 lineto
115.40536 -147.38838 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 121.35541 -147.38838 moveto
122.40536 -146.33842 lineto
122.40536 -143.63847 lineto
121.35541 -144.68843 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 121.35541 -144.68843 moveto
122.40536 -143.63847 lineto
116.45532 -143.63847 lineto
115.40536 -144.68843 lineto
closepath fill
0 0 0 setrgbcolor [3 3 ] 0 setdash
newpath -35.95392 -119.76395 moveto
-9.31816 -95.94742 lineto stroke
1 1 1 setrgbcolor
newpath -9.31816 -95.94742 moveto
-12.65091 -92.22015 lineto
0.00008 -87.61548 lineto
-5.98541 -99.67468 lineto
closepath fill
0 0 0 setrgbcolor [] 0 setdash
newpath -9.31816 -95.94742 moveto
-12.65091 -92.22015 lineto stroke
newpath -9.31816 -95.94742 moveto
-5.98541 -99.67468 lineto stroke
newpath 0.00008 -87.61548 moveto
-12.65091 -92.22015 lineto stroke
newpath 0.00008 -87.61548 moveto
-5.98541 -99.67468 lineto stroke
0.5 0 dtransform exch truncate exch idtransform pop setlinewidth
[3 3 ] 0 setdash
newpath 47.79224 -119.76395 moveto
47.79224 -102.26341 lineto stroke
1 1 1 setrgbcolor
newpath 47.79224 -102.26341 moveto
42.79224 -102.26341 lineto
47.79224 -89.76358 lineto
52.79224 -102.26341 lineto
closepath fill
0 0 0 setrgbcolor 0 0.5 dtransform truncate idtransform setlinewidth pop
[] 0 setdash
newpath 47.79224 -102.26341 moveto
42.79224 -102.26341 lineto stroke
newpath 47.79224 -102.26341 moveto
52.79224 -102.26341 lineto stroke
newpath 47.79224 -89.76358 moveto
42.79224 -102.26341 lineto stroke
newpath 47.79224 -89.76358 moveto
52.79224 -102.26341 lineto stroke
[3 3 ] 0 setdash
newpath 128.9466 -119.89825 moveto
104.76299 -97.54373 lineto stroke
1 1 1 setrgbcolor
newpath 104.76299 -97.54373 moveto
101.36905 -101.21538 lineto
95.58386 -89.05885 lineto
108.15692 -93.87209 lineto
closepath fill
0 0 0 setrgbcolor [] 0 setdash
newpath 104.76299 -97.54373 moveto
101.36905 -101.21538 lineto stroke
newpath 104.76299 -97.54373 moveto
108.15692 -93.87209 lineto stroke
newpath 95.58386 -89.05885 moveto
101.36905 -101.21538 lineto stroke
newpath 95.58386 -89.05885 moveto
108.15692 -93.87209 lineto stroke
showpage
%%EOF

View file

@ -0,0 +1,29 @@
input metauml;
beginfig(1);
% Klassen
EClass.Medium(iAbstractClass)("Medium")
("zPfad")
("+Medium(pPfad)", "+gibWieder()", "+loesche()", "+nimmAuf(pDauer)", "+nimmManuellAuf()", "+pfad()");
Class.Audio("Audio")()("+Audio(pPfad)");
Class.Video("Video")()("+Video(pPfad)");
Class.Foto("Foto")()("+Foto(pPfad)");
% Modul
Package.Multimedia("Multimedia")(Medium, Audio, Video, Foto);
% Objekte anordnen
topToBottom(30)(Medium, Video);
leftToRight(30)(Audio, Video, Foto);
% Objekte zeichnen
drawObjects(Medium, Audio, Video, Foto, Multimedia);
% Assoziatonen
clink(realization)(Audio, Medium);
clink(realization)(Video, Medium);
clink(realization)(Foto, Medium);
endfig;
end

View file

@ -0,0 +1,383 @@
%!PS
%%BoundingBox: -167 -89 210 28
%%HiResBoundingBox: -166.489 -88.51831 209.69312 27.00458
%%Creator: MetaPost 1.504
%%CreationDate: 2012.08.02:0952
%%Pages: 1
%*Font: ptmr8r 9.96265 9.96265 20:80c0000a2008100055cb3d
%%BeginProlog
%%EndProlog
%%Page: 1 1
0.7 0.7 0.7 setrgbcolor
newpath 1 -1 moveto
42.33842 -1 lineto
42.33842 -32.75916 lineto
1 -32.75916 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 0 0 moveto
41.33842 0 lineto
41.33842 -31.75916 lineto
0 -31.75916 lineto
closepath fill
0 0 0 setrgbcolor 0 0.5 dtransform truncate idtransform setlinewidth pop
[] 0 setdash 1 setlinejoin 10 setmiterlimit
newpath 0 0 moveto
41.33842 0 lineto
41.33842 -31.75916 lineto
0 -31.75916 lineto
closepath stroke
1 setlinecap
newpath 0 -12.75458 moveto
41.33842 -12.75458 lineto stroke
newpath 0 -17.25458 moveto
41.33842 -17.25458 lineto stroke
7.11018 -9.75458 moveto
(Sensor) ptmr8r 9.96265 fshow
13 -27.75916 moveto
(wert\(\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath 2 -25.0592 moveto
7.95004 -25.0592 lineto
7.95004 -27.75916 lineto
2 -27.75916 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -27.75916 moveto
9 -26.7092 lineto
9 -24.00925 lineto
7.95004 -25.0592 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -25.0592 moveto
9 -24.00925 lineto
3.04996 -24.00925 lineto
2 -25.0592 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath -161.239 -57.89595 moveto
-102.86955 -57.89595 lineto
-102.86955 -79.38152 lineto
-161.239 -79.38152 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath -162.239 -56.89595 moveto
-103.86955 -56.89595 lineto
-103.86955 -78.38152 lineto
-162.239 -78.38152 lineto
closepath fill
0 0 0 setrgbcolor
newpath -162.239 -56.89595 moveto
-103.86955 -56.89595 lineto
-103.86955 -78.38152 lineto
-162.239 -78.38152 lineto
closepath stroke
newpath -162.239 -69.38152 moveto
-103.86955 -69.38152 lineto stroke
newpath -162.239 -73.88152 moveto
-103.86955 -73.88152 lineto stroke
-155.739 -66.38152 moveto
(Lagesensor) ptmr8r 9.96265 fshow
0.7 0.7 0.7 setrgbcolor
newpath -82.86955 -52.75916 moveto
126.208 -52.75916 lineto
126.208 -84.51831 lineto
-82.86955 -84.51831 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath -83.86955 -51.75916 moveto
125.208 -51.75916 lineto
125.208 -83.51831 lineto
-83.86955 -83.51831 lineto
closepath fill
0 0 0 setrgbcolor
newpath -83.86955 -51.75916 moveto
125.208 -51.75916 lineto
125.208 -83.51831 lineto
-83.86955 -83.51831 lineto
closepath stroke
newpath -83.86955 -64.51373 moveto
125.208 -64.51373 lineto stroke
newpath -83.86955 -79.01831 moveto
125.208 -79.01831 lineto stroke
-26.09496 -61.51373 moveto
(Beschleunigungssensor) ptmr8r 9.96265 fshow
-70.86955 -75.01831 moveto
(<<constructor>>\040Beschleunigungssensor\(achse\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath -81.86955 -72.31836 moveto
-75.91951 -72.31836 lineto
-75.91951 -75.01831 lineto
-81.86955 -75.01831 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath -75.91951 -75.01831 moveto
-74.86955 -73.96835 lineto
-74.86955 -71.2684 lineto
-75.91951 -72.31836 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath -75.91951 -72.31836 moveto
-74.86955 -71.2684 lineto
-80.8196 -71.2684 lineto
-81.86955 -72.31836 lineto
closepath fill
0.3 0.3 0.3 setrgbcolor 0 0.79701 dtransform truncate idtransform setlinewidth pop
0 setlinecap
newpath -80.29457 -69.54338 moveto
-79.77722 -68.9082 -79.18013 -68.25253 -78.36955 -68.26831 curveto
-76.89394 -68.29704 -76.40038 -70.08928 -76.44453 -71.79338 curveto stroke
0.7 0.7 0.7 setrgbcolor
newpath 146.208 -57.76144 moveto
205.69312 -57.76144 lineto
205.69312 -79.51602 lineto
146.208 -79.51602 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 145.208 -56.76144 moveto
204.69312 -56.76144 lineto
204.69312 -78.51602 lineto
145.208 -78.51602 lineto
closepath fill
0 0 0 setrgbcolor 0 0.5 dtransform truncate idtransform setlinewidth pop
newpath 145.208 -56.76144 moveto
204.69312 -56.76144 lineto
204.69312 -78.51602 lineto
145.208 -78.51602 lineto
closepath stroke
newpath 145.208 -69.51602 moveto
204.69312 -69.51602 lineto stroke
newpath 145.208 -74.01602 moveto
204.69312 -74.01602 lineto stroke
151.708 -66.51602 moveto
(Lichtsensor) ptmr8r 9.96265 fshow
0.7 0.7 0.7 setrgbcolor
newpath 209.69312 11 moveto
-165.239 11 lineto
-165.239 -88.51831 lineto
209.69312 -88.51831 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 208.69312 12 moveto
-166.239 12 lineto
-166.239 -87.51831 lineto
208.69312 -87.51831 lineto
closepath fill
0 0 0 setrgbcolor
newpath 208.69312 12 moveto
-166.239 12 lineto
-166.239 -87.51831 lineto
208.69312 -87.51831 lineto
closepath stroke
0.9 0.9 0.9 setrgbcolor
newpath -121.71626 26.75458 moveto
-166.239 26.75458 lineto
-166.239 12 lineto
-121.71626 12 lineto
closepath fill
0 0 0 setrgbcolor
newpath -121.71626 26.75458 moveto
-166.239 26.75458 lineto
-166.239 12 lineto
-121.71626 12 lineto
closepath stroke
-162.239 16 moveto
(Sensoren) ptmr8r 9.96265 fshow
0.7 0.7 0.7 setrgbcolor
newpath 1 -1 moveto
42.33842 -1 lineto
42.33842 -32.75916 lineto
1 -32.75916 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 0 0 moveto
41.33842 0 lineto
41.33842 -31.75916 lineto
0 -31.75916 lineto
closepath fill
0 0 0 setrgbcolor
newpath 0 0 moveto
41.33842 0 lineto
41.33842 -31.75916 lineto
0 -31.75916 lineto
closepath stroke
newpath 0 -12.75458 moveto
41.33842 -12.75458 lineto stroke
newpath 0 -17.25458 moveto
41.33842 -17.25458 lineto stroke
7.11018 -9.75458 moveto
(Sensor) ptmr8r 9.96265 fshow
13 -27.75916 moveto
(wert\(\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath 2 -25.0592 moveto
7.95004 -25.0592 lineto
7.95004 -27.75916 lineto
2 -27.75916 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -27.75916 moveto
9 -26.7092 lineto
9 -24.00925 lineto
7.95004 -25.0592 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -25.0592 moveto
9 -24.00925 lineto
3.04996 -24.00925 lineto
2 -25.0592 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath -161.239 -57.89595 moveto
-102.86955 -57.89595 lineto
-102.86955 -79.38152 lineto
-161.239 -79.38152 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath -162.239 -56.89595 moveto
-103.86955 -56.89595 lineto
-103.86955 -78.38152 lineto
-162.239 -78.38152 lineto
closepath fill
0 0 0 setrgbcolor
newpath -162.239 -56.89595 moveto
-103.86955 -56.89595 lineto
-103.86955 -78.38152 lineto
-162.239 -78.38152 lineto
closepath stroke
newpath -162.239 -69.38152 moveto
-103.86955 -69.38152 lineto stroke
newpath -162.239 -73.88152 moveto
-103.86955 -73.88152 lineto stroke
-155.739 -66.38152 moveto
(Lagesensor) ptmr8r 9.96265 fshow
0.7 0.7 0.7 setrgbcolor
newpath -82.86955 -52.75916 moveto
126.208 -52.75916 lineto
126.208 -84.51831 lineto
-82.86955 -84.51831 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath -83.86955 -51.75916 moveto
125.208 -51.75916 lineto
125.208 -83.51831 lineto
-83.86955 -83.51831 lineto
closepath fill
0 0 0 setrgbcolor
newpath -83.86955 -51.75916 moveto
125.208 -51.75916 lineto
125.208 -83.51831 lineto
-83.86955 -83.51831 lineto
closepath stroke
newpath -83.86955 -64.51373 moveto
125.208 -64.51373 lineto stroke
newpath -83.86955 -79.01831 moveto
125.208 -79.01831 lineto stroke
-26.09496 -61.51373 moveto
(Beschleunigungssensor) ptmr8r 9.96265 fshow
-70.86955 -75.01831 moveto
(<<constructor>>\040Beschleunigungssensor\(achse\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath -81.86955 -72.31836 moveto
-75.91951 -72.31836 lineto
-75.91951 -75.01831 lineto
-81.86955 -75.01831 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath -75.91951 -75.01831 moveto
-74.86955 -73.96835 lineto
-74.86955 -71.2684 lineto
-75.91951 -72.31836 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath -75.91951 -72.31836 moveto
-74.86955 -71.2684 lineto
-80.8196 -71.2684 lineto
-81.86955 -72.31836 lineto
closepath fill
0.3 0.3 0.3 setrgbcolor 0 0.79701 dtransform truncate idtransform setlinewidth pop
newpath -80.29457 -69.54338 moveto
-79.77722 -68.9082 -79.18013 -68.25253 -78.36955 -68.26831 curveto
-76.89394 -68.29704 -76.40038 -70.08928 -76.44453 -71.79338 curveto stroke
0.7 0.7 0.7 setrgbcolor
newpath 146.208 -57.76144 moveto
205.69312 -57.76144 lineto
205.69312 -79.51602 lineto
146.208 -79.51602 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 145.208 -56.76144 moveto
204.69312 -56.76144 lineto
204.69312 -78.51602 lineto
145.208 -78.51602 lineto
closepath fill
0 0 0 setrgbcolor 0 0.5 dtransform truncate idtransform setlinewidth pop
newpath 145.208 -56.76144 moveto
204.69312 -56.76144 lineto
204.69312 -78.51602 lineto
145.208 -78.51602 lineto
closepath stroke
newpath 145.208 -69.51602 moveto
204.69312 -69.51602 lineto stroke
newpath 145.208 -74.01602 moveto
204.69312 -74.01602 lineto stroke
151.708 -66.51602 moveto
(Lichtsensor) ptmr8r 9.96265 fshow
[3 3 ] 0 setdash
newpath 145.20828 -57.66063 moveto
53.18939 -26.78964 lineto stroke
1 1 1 setrgbcolor
newpath 53.18939 -26.78964 moveto
51.59904 -31.53001 lineto
41.33894 -22.81396 lineto
54.77974 -22.04927 lineto
closepath fill
0 0 0 setrgbcolor [] 0 setdash
newpath 53.18939 -26.78964 moveto
51.59904 -31.53001 lineto stroke
newpath 53.18939 -26.78964 moveto
54.77974 -22.04927 lineto stroke
newpath 41.33894 -22.81396 moveto
51.59904 -31.53001 lineto stroke
newpath 41.33894 -22.81396 moveto
54.77974 -22.04927 lineto stroke
[3 3 ] 0 setdash
newpath -103.86987 -57.81229 moveto
-11.84619 -26.82764 lineto stroke
1 1 1 setrgbcolor
newpath -11.84619 -26.82764 moveto
-13.44173 -22.08902 lineto
-0.0005 -22.83914 lineto
-10.25066 -31.56625 lineto
closepath fill
0 0 0 setrgbcolor [] 0 setdash
newpath -11.84619 -26.82764 moveto
-13.44173 -22.08902 lineto stroke
newpath -11.84619 -26.82764 moveto
-10.25066 -31.56625 lineto stroke
newpath -0.0005 -22.83914 moveto
-13.44173 -22.08902 lineto stroke
newpath -0.0005 -22.83914 moveto
-10.25066 -31.56625 lineto stroke
0.5 0 dtransform exch truncate exch idtransform pop setlinewidth
[3 3 ] 0 setdash
newpath 20.66922 -51.75937 moveto
20.66922 -44.25882 lineto stroke
1 1 1 setrgbcolor
newpath 20.66922 -44.25882 moveto
15.66922 -44.25882 lineto
20.66922 -31.75876 lineto
25.66922 -44.25882 lineto
closepath fill
0 0 0 setrgbcolor 0 0.5 dtransform truncate idtransform setlinewidth pop
[] 0 setdash
newpath 20.66922 -44.25882 moveto
15.66922 -44.25882 lineto stroke
newpath 20.66922 -44.25882 moveto
25.66922 -44.25882 lineto stroke
newpath 20.66922 -31.75876 moveto
15.66922 -44.25882 lineto stroke
newpath 20.66922 -31.75876 moveto
25.66922 -44.25882 lineto stroke
showpage
%%EOF

View file

@ -0,0 +1,29 @@
input metauml;
beginfig(1);
% Klassen
Class.Sensor("Sensor")
()
("+wert()");
Class.Licht("Lichtsensor")()();
Class.Beschl("Beschleunigungssensor")("<<constructor>> Beschleunigungssensor(achse)")();
Class.Lage("Lagesensor")()();
% Modul
Package.Sensoren("Sensoren")(Sensor, Lage, Beschl, Licht);
% Objekte anordnen
topToBottom(20)(Sensor, Beschl);
leftToRight(20)(Lage, Beschl, Licht);
% Objekte zeichnen
drawObjects(Sensor, Lage, Beschl, Licht, Sensoren);
% Assoziatonen
clink(realization)(Licht, Sensor);
clink(realization)(Lage, Sensor);
clink(realization)(Beschl, Sensor);
endfig;
end

View file

@ -0,0 +1,519 @@
%!PS
%%BoundingBox: -5 -78 229 28
%%HiResBoundingBox: -4.25 -77.99472 228.88916 27.00458
%%Creator: MetaPost 1.504
%%CreationDate: 2012.08.01:0458
%%Pages: 1
%*Font: ptmr8r 9.96265 9.96265 28:c000000002180075d3bca
%%BeginProlog
%%EndProlog
%%Page: 1 1
0.7 0.7 0.7 setrgbcolor
newpath 1 -1 moveto
107.63316 -1 lineto
107.63316 -73.99472 lineto
1 -73.99472 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 0 0 moveto
106.63316 0 lineto
106.63316 -72.99472 lineto
0 -72.99472 lineto
closepath fill
0 0 0 setrgbcolor 0 0.5 dtransform truncate idtransform setlinewidth pop
[] 0 setdash 1 setlinejoin 10 setmiterlimit
newpath 0 0 moveto
106.63316 0 lineto
106.63316 -72.99472 lineto
0 -72.99472 lineto
closepath stroke
1 setlinecap
newpath 0 -12.75458 moveto
106.63316 -12.75458 lineto stroke
newpath 0 -26.99014 moveto
106.63316 -26.99014 lineto stroke
23.43886 -9.75458 moveto
(Sprachausgabe) ptmr8r 9.96265 fshow
13 -22.99014 moveto
(zText) ptmr8r 9.96265 fshow
13 -37.49472 moveto
(Sprachausgabe\(pText\)) ptmr8r 9.96265 fshow
13 -47.99472 moveto
(setzeText\(pText\)) ptmr8r 9.96265 fshow
13 -58.49472 moveto
(text\(\)) ptmr8r 9.96265 fshow
13 -68.99472 moveto
(sprichtNoch\(\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath 2 -20.29019 moveto
7.95004 -20.29019 lineto
7.95004 -22.99014 lineto
2 -22.99014 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -22.99014 moveto
9 -21.94019 lineto
9 -19.24023 lineto
7.95004 -20.29019 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -20.29019 moveto
9 -19.24023 lineto
3.04996 -19.24023 lineto
2 -20.29019 lineto
closepath fill
0.3 0.3 0.3 setrgbcolor 0 0.79701 dtransform truncate idtransform setlinewidth pop
0 setlinecap
newpath 3.57498 -17.51521 moveto
4.09233 -16.88004 4.68942 -16.22437 5.5 -16.24014 curveto
6.97562 -16.26888 7.46918 -18.06111 7.42502 -19.76521 curveto stroke
0.4 0.4 0.4 setrgbcolor
newpath 2 -34.79477 moveto
7.95004 -34.79477 lineto
7.95004 -37.49472 lineto
2 -37.49472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -37.49472 moveto
9 -36.44476 lineto
9 -33.74481 lineto
7.95004 -34.79477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -34.79477 moveto
9 -33.74481 lineto
3.04996 -33.74481 lineto
2 -34.79477 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -45.29477 moveto
7.95004 -45.29477 lineto
7.95004 -47.99472 lineto
2 -47.99472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -47.99472 moveto
9 -46.94476 lineto
9 -44.24481 lineto
7.95004 -45.29477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -45.29477 moveto
9 -44.24481 lineto
3.04996 -44.24481 lineto
2 -45.29477 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -55.79477 moveto
7.95004 -55.79477 lineto
7.95004 -58.49472 lineto
2 -58.49472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -58.49472 moveto
9 -57.44476 lineto
9 -54.74481 lineto
7.95004 -55.79477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -55.79477 moveto
9 -54.74481 lineto
3.04996 -54.74481 lineto
2 -55.79477 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -66.29477 moveto
7.95004 -66.29477 lineto
7.95004 -68.99472 lineto
2 -68.99472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -68.99472 moveto
9 -67.94476 lineto
9 -65.24481 lineto
7.95004 -66.29477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -66.29477 moveto
9 -65.24481 lineto
3.04996 -65.24481 lineto
2 -66.29477 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 137.63316 -6.25 moveto
224.88916 -6.25 lineto
224.88916 -68.74472 lineto
137.63316 -68.74472 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 136.63316 -5.25 moveto
223.88916 -5.25 lineto
223.88916 -67.74472 lineto
136.63316 -67.74472 lineto
closepath fill
0 0 0 setrgbcolor 0 0.5 dtransform truncate idtransform setlinewidth pop
newpath 136.63316 -5.25 moveto
223.88916 -5.25 lineto
223.88916 -67.74472 lineto
136.63316 -67.74472 lineto
closepath stroke
newpath 136.63316 -18.00458 moveto
223.88916 -18.00458 lineto stroke
newpath 136.63316 -32.24014 moveto
223.88916 -32.24014 lineto stroke
150.93637 -15.00458 moveto
(Spracheingabe) ptmr8r 9.96265 fshow
149.63316 -28.24014 moveto
(zText) ptmr8r 9.96265 fshow
149.63316 -42.74472 moveto
(Sprachausgabe\(\)) ptmr8r 9.96265 fshow
149.63316 -53.24472 moveto
(erkenneSprache\(\)) ptmr8r 9.96265 fshow
149.63316 -63.74472 moveto
(text\(\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath 138.63316 -25.54019 moveto
144.5832 -25.54019 lineto
144.5832 -28.24014 lineto
138.63316 -28.24014 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 144.5832 -28.24014 moveto
145.63316 -27.19019 lineto
145.63316 -24.49023 lineto
144.5832 -25.54019 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 144.5832 -25.54019 moveto
145.63316 -24.49023 lineto
139.68312 -24.49023 lineto
138.63316 -25.54019 lineto
closepath fill
0.3 0.3 0.3 setrgbcolor 0 0.79701 dtransform truncate idtransform setlinewidth pop
newpath 140.20815 -22.76521 moveto
140.7255 -22.13004 141.32259 -21.47437 142.13316 -21.49014 curveto
143.60878 -21.51888 144.10234 -23.31111 144.05818 -25.01521 curveto stroke
0.4 0.4 0.4 setrgbcolor
newpath 138.63316 -40.04477 moveto
144.5832 -40.04477 lineto
144.5832 -42.74472 lineto
138.63316 -42.74472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 144.5832 -42.74472 moveto
145.63316 -41.69476 lineto
145.63316 -38.99481 lineto
144.5832 -40.04477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 144.5832 -40.04477 moveto
145.63316 -38.99481 lineto
139.68312 -38.99481 lineto
138.63316 -40.04477 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 138.63316 -50.54477 moveto
144.5832 -50.54477 lineto
144.5832 -53.24472 lineto
138.63316 -53.24472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 144.5832 -53.24472 moveto
145.63316 -52.19476 lineto
145.63316 -49.49481 lineto
144.5832 -50.54477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 144.5832 -50.54477 moveto
145.63316 -49.49481 lineto
139.68312 -49.49481 lineto
138.63316 -50.54477 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 138.63316 -61.04477 moveto
144.5832 -61.04477 lineto
144.5832 -63.74472 lineto
138.63316 -63.74472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 144.5832 -63.74472 moveto
145.63316 -62.69476 lineto
145.63316 -59.99481 lineto
144.5832 -61.04477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 144.5832 -61.04477 moveto
145.63316 -59.99481 lineto
139.68312 -59.99481 lineto
138.63316 -61.04477 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 228.88916 11 moveto
-3 11 lineto
-3 -77.99472 lineto
228.88916 -77.99472 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 227.88916 12 moveto
-4 12 lineto
-4 -76.99472 lineto
227.88916 -76.99472 lineto
closepath fill
0 0 0 setrgbcolor 0 0.5 dtransform truncate idtransform setlinewidth pop
newpath 227.88916 12 moveto
-4 12 lineto
-4 -76.99472 lineto
227.88916 -76.99472 lineto
closepath stroke
0.9 0.9 0.9 setrgbcolor
newpath 36.0894 26.75458 moveto
-4 26.75458 lineto
-4 12 lineto
36.0894 12 lineto
closepath fill
0 0 0 setrgbcolor
newpath 36.0894 26.75458 moveto
-4 26.75458 lineto
-4 12 lineto
36.0894 12 lineto
closepath stroke
0 16 moveto
(Sprache) ptmr8r 9.96265 fshow
0.7 0.7 0.7 setrgbcolor
newpath 1 -1 moveto
107.63316 -1 lineto
107.63316 -73.99472 lineto
1 -73.99472 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 0 0 moveto
106.63316 0 lineto
106.63316 -72.99472 lineto
0 -72.99472 lineto
closepath fill
0 0 0 setrgbcolor
newpath 0 0 moveto
106.63316 0 lineto
106.63316 -72.99472 lineto
0 -72.99472 lineto
closepath stroke
newpath 0 -12.75458 moveto
106.63316 -12.75458 lineto stroke
newpath 0 -26.99014 moveto
106.63316 -26.99014 lineto stroke
23.43886 -9.75458 moveto
(Sprachausgabe) ptmr8r 9.96265 fshow
13 -22.99014 moveto
(zText) ptmr8r 9.96265 fshow
13 -37.49472 moveto
(Sprachausgabe\(pText\)) ptmr8r 9.96265 fshow
13 -47.99472 moveto
(setzeText\(pText\)) ptmr8r 9.96265 fshow
13 -58.49472 moveto
(text\(\)) ptmr8r 9.96265 fshow
13 -68.99472 moveto
(sprichtNoch\(\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath 2 -20.29019 moveto
7.95004 -20.29019 lineto
7.95004 -22.99014 lineto
2 -22.99014 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -22.99014 moveto
9 -21.94019 lineto
9 -19.24023 lineto
7.95004 -20.29019 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -20.29019 moveto
9 -19.24023 lineto
3.04996 -19.24023 lineto
2 -20.29019 lineto
closepath fill
0.3 0.3 0.3 setrgbcolor 0 0.79701 dtransform truncate idtransform setlinewidth pop
newpath 3.57498 -17.51521 moveto
4.09233 -16.88004 4.68942 -16.22437 5.5 -16.24014 curveto
6.97562 -16.26888 7.46918 -18.06111 7.42502 -19.76521 curveto stroke
0.4 0.4 0.4 setrgbcolor
newpath 2 -34.79477 moveto
7.95004 -34.79477 lineto
7.95004 -37.49472 lineto
2 -37.49472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -37.49472 moveto
9 -36.44476 lineto
9 -33.74481 lineto
7.95004 -34.79477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -34.79477 moveto
9 -33.74481 lineto
3.04996 -33.74481 lineto
2 -34.79477 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -45.29477 moveto
7.95004 -45.29477 lineto
7.95004 -47.99472 lineto
2 -47.99472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -47.99472 moveto
9 -46.94476 lineto
9 -44.24481 lineto
7.95004 -45.29477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -45.29477 moveto
9 -44.24481 lineto
3.04996 -44.24481 lineto
2 -45.29477 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -55.79477 moveto
7.95004 -55.79477 lineto
7.95004 -58.49472 lineto
2 -58.49472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -58.49472 moveto
9 -57.44476 lineto
9 -54.74481 lineto
7.95004 -55.79477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -55.79477 moveto
9 -54.74481 lineto
3.04996 -54.74481 lineto
2 -55.79477 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 2 -66.29477 moveto
7.95004 -66.29477 lineto
7.95004 -68.99472 lineto
2 -68.99472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 7.95004 -68.99472 moveto
9 -67.94476 lineto
9 -65.24481 lineto
7.95004 -66.29477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 7.95004 -66.29477 moveto
9 -65.24481 lineto
3.04996 -65.24481 lineto
2 -66.29477 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 137.63316 -6.25 moveto
224.88916 -6.25 lineto
224.88916 -68.74472 lineto
137.63316 -68.74472 lineto
closepath fill
0.9 0.9 0.9 setrgbcolor
newpath 136.63316 -5.25 moveto
223.88916 -5.25 lineto
223.88916 -67.74472 lineto
136.63316 -67.74472 lineto
closepath fill
0 0 0 setrgbcolor 0 0.5 dtransform truncate idtransform setlinewidth pop
newpath 136.63316 -5.25 moveto
223.88916 -5.25 lineto
223.88916 -67.74472 lineto
136.63316 -67.74472 lineto
closepath stroke
newpath 136.63316 -18.00458 moveto
223.88916 -18.00458 lineto stroke
newpath 136.63316 -32.24014 moveto
223.88916 -32.24014 lineto stroke
150.93637 -15.00458 moveto
(Spracheingabe) ptmr8r 9.96265 fshow
149.63316 -28.24014 moveto
(zText) ptmr8r 9.96265 fshow
149.63316 -42.74472 moveto
(Sprachausgabe\(\)) ptmr8r 9.96265 fshow
149.63316 -53.24472 moveto
(erkenneSprache\(\)) ptmr8r 9.96265 fshow
149.63316 -63.74472 moveto
(text\(\)) ptmr8r 9.96265 fshow
0.4 0.4 0.4 setrgbcolor
newpath 138.63316 -25.54019 moveto
144.5832 -25.54019 lineto
144.5832 -28.24014 lineto
138.63316 -28.24014 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 144.5832 -28.24014 moveto
145.63316 -27.19019 lineto
145.63316 -24.49023 lineto
144.5832 -25.54019 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 144.5832 -25.54019 moveto
145.63316 -24.49023 lineto
139.68312 -24.49023 lineto
138.63316 -25.54019 lineto
closepath fill
0.3 0.3 0.3 setrgbcolor 0 0.79701 dtransform truncate idtransform setlinewidth pop
newpath 140.20815 -22.76521 moveto
140.7255 -22.13004 141.32259 -21.47437 142.13316 -21.49014 curveto
143.60878 -21.51888 144.10234 -23.31111 144.05818 -25.01521 curveto stroke
0.4 0.4 0.4 setrgbcolor
newpath 138.63316 -40.04477 moveto
144.5832 -40.04477 lineto
144.5832 -42.74472 lineto
138.63316 -42.74472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 144.5832 -42.74472 moveto
145.63316 -41.69476 lineto
145.63316 -38.99481 lineto
144.5832 -40.04477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 144.5832 -40.04477 moveto
145.63316 -38.99481 lineto
139.68312 -38.99481 lineto
138.63316 -40.04477 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 138.63316 -50.54477 moveto
144.5832 -50.54477 lineto
144.5832 -53.24472 lineto
138.63316 -53.24472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 144.5832 -53.24472 moveto
145.63316 -52.19476 lineto
145.63316 -49.49481 lineto
144.5832 -50.54477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 144.5832 -50.54477 moveto
145.63316 -49.49481 lineto
139.68312 -49.49481 lineto
138.63316 -50.54477 lineto
closepath fill
0.4 0.4 0.4 setrgbcolor
newpath 138.63316 -61.04477 moveto
144.5832 -61.04477 lineto
144.5832 -63.74472 lineto
138.63316 -63.74472 lineto
closepath fill
0.7 0.7 0.7 setrgbcolor
newpath 144.5832 -63.74472 moveto
145.63316 -62.69476 lineto
145.63316 -59.99481 lineto
144.5832 -61.04477 lineto
closepath fill
0.6 0.6 0.6 setrgbcolor
newpath 144.5832 -61.04477 moveto
145.63316 -59.99481 lineto
139.68312 -59.99481 lineto
138.63316 -61.04477 lineto
closepath fill
showpage
%%EOF

View file

@ -0,0 +1,23 @@
input metauml;
beginfig(1);
% Klassen
Class.TTS("Sprachausgabe")
("zText")
("+Sprachausgabe(pText)", "+setzeText(pText)", "+text()", "+sprichtNoch()");
Class.STT("Spracheingabe")
("zText")
("+Sprachausgabe()", "+erkenneSprache()", "+text()");
% Modul
Package.Sprache("Sprache")(TTS, STT);
% Objekte anordnen
leftToRight(30)(TTS, STT);
% Objekte zeichnen
drawObjects(TTS, STT, Sprache);
endfig;
end

View file

@ -0,0 +1,53 @@
# -*- coding: utf-8 -*-
import android
class Dialog:
"""Die Klasse Dialog stellt einen einfachen Dialog zur
Verfuegung, der eine Nachricht anzeigen kann."""
def __init__(self, pTitel, pNachricht):
"""Auftrag [Konstruktor]: __init__
nachher
Der Dialog ist initialisiert.
"""
self.__androide = android.Android()
self.zTitel = pTitel
self.zNachricht = pNachricht
def setzeNachricht(self, pNachricht):
"""Auftrag: setzeNachricht(pNachricht : Zeichenkette)
nachher
Die Nachricht des Dialogs wurde geändert.
"""
self.zNachricht = pNachricht
def setzeTitel(self, pTitel):
"""Auftrag: setzeTitel(pTitel : Zeichenkette)
nachher
Der Titel des Dialogs wurde geändert.
"""
self.zTitel = pTitel
def nachricht(self):
"""Anfrage: nachricht : Zeichenkette
nachher
Diese Anfrage liefert die Nachricht des Dialogs.
"""
return self.zTitel
def titel(self):
"""Anfrage: titel : Zeichenkette
nachher
Diese Anfrage liefert den Titel des Dialogs.
"""
return self.zTitel
def zeige(self):
"""Auftrag: zeige
nachher
Der Dialog wurde angezeigt.
"""
self.__androide.dialogCreateAlert(self.zTitel, self.zNachricht)
self.__androide.dialogSetPositiveButtonText('Ok')
self.__androide.dialogShow()
self.__androide.dialogGetResponse()

View file

@ -0,0 +1,33 @@
# -*- coding: utf-8 -*-
from Dialog import *
class EingabeDialog(Dialog):
"""Die Klasse EingabeDialog stellt einen einfachen Dialog zur
Eingabe von Texten zur Verfügung."""
def __init__(self, pTitel, pNachricht):
"""Auftrag [Konstruktor]: __init__
nachher
Der Dialog ist initialisiert.
"""
self.__androide = android.Android()
self.zTitel = pTitel
self.zNachricht = pNachricht
self.zErgebnis = ""
def ergebnis(self):
"""Anfrage: ergebnis : Zeichenkette
nachher
Diese Anfrage liefert die Eingabe aus dem Dialog.
"""
return self.zErgebnis
def zeige(self):
"""Auftrag: zeige
nachher
Der Dialog wurde angezeigt und die Eingabe übernommen.
"""
self.__androide.dialogCreateInput(self.zTitel, self.zNachricht)
self.__androide.dialogSetPositiveButtonText('Ok')
self.__androide.dialogShow()
self.zErgebnis = self.__androide.dialogGetResponse().result['value']

View file

@ -0,0 +1,43 @@
# -*- coding: utf-8 -*-
import android
class Sprachausgabe:
"""Die Klasse Sprachausgabe ermöglicht die Umwandlung von
Text in Sprache."""
def __init__(self, pText):
"""Auftrag [Konstruktor]: __init__
nachher
Die Sprachausgabe ist initialisiert.
"""
self.__androide = android.Android()
self.zText = pText
def setzeText(self, pText):
"""Auftrag: setzeText(pText : Zeichenkette)
nachher
Der auszugebende Text wurde geändert.
"""
self.zText = pText
def text(self):
"""Anfrage: text : Zeichenkette
nachher
Gibt den zu sprechenden Text zurück.
"""
return self.zTitel
def sprichtNoch(self):
"""Anfrage: sprichtNoch : bool
nachher
Liefert True, wenn die Sprachausgabe noch läuft,
sonst False.
"""
return self.__androide.ttsIsSpeaking().result
def sprich(self):
"""Auftrag: sprich
nachher
Spricht den eingestellten Text.
"""
self.__androide.ttsSpeak(self.zText)

View file

@ -0,0 +1,18 @@
from velamentum.gui.dialoge.Dialog import *
from velamentum.gui.dialoge.EingabeDialog import *
from velamentum.sprache.Sprachausgabe import *
dialog = Dialog("Sprachausgabe", "Willkommen zum Sprachtest.")
dialog.zeige()
eDialog = EingabeDialog("Sprachausgabe", "Bitte geben Sie einen Text ein.")
eDialog.zeige()
sprachausgabe = Sprachausgabe(eDialog.ergebnis())
sprachausgabe.sprich()
while sprachausgabe.sprichtNoch():
pass
dialog.setzeNachricht("Ich habe gesprochen!")
dialog.zeige()