Die Vorgaben und Empfehlungen legen verbindlich den Bereich Modellieren und Implementieren als Aufgabe und Ziel des Informatikunterrichts fest. Im schulischen Kontext bietet es sich häufig an, Problemstellungen mit grafischen Ausgaben/ Lösungen zu behandeln. Dafür sprechen die gegebene Anschauung, der motivierende Charakter der Lösungen und die durch sie gegebene Möglichkeit einer „visuellen Rückmeldung“ und damit teilweisen Überprüfbarkeit von Programmlösungen.
Dabei kommen in der gymnasialen Oberstufe – nicht nur bei der Wahl des objektorientierten Paradigmas und der Programmiersprache Java – häufig sog. Turtle- oder Stift-basierte Konzepte zum Einsatz (z.B. Konzept „Stifte und Mäuse“ oder „Hidden Classes“) . Eine Turtle oder ein Stift wird über eine Zeichenfläche navigiert und hinterlässt im abgesetzten Zustand eine Zeichenspur auf dieser. Didaktisch ist der Ansatz wertvoll und legitimiert, weil sich den Lernenden aufgrund der Analogie zu einem realen Stift das programmgesteuerte Zeichnen intuitiv sowie einleuchtend erschließt.
Den Vorzügen solcher Konzepte stehen jedoch auch Problematiken gegenüber, aufgrund derer sie nicht uneingeschränkt zur Schulung des Prozressbereiches Modellieren und Implementieren empfohlen werden können. Die Problematiken werden im Folgenden anhand der Aufgabenstellung der Programmierung einer grafischen Ampel:
Kommt man dem Aufforderungscharakter des Stift-Ansatzes zu einer einfachen und naheliegenden Modellierung der grafischen Ampel nach, so besteht diese aus der Klasse Ampel, welche einen Stift zum Zeichnen aggregiert. Sicherlich ist dieses naive Modell zulässig und es existiert auch nicht das richtige Modell. Allerdings erscheint mit objektorientiertem Verstand das Modell bestehend aus einer Ampel, welche drei Lampen aggregiert, angemessener. Die Lampen stellen schließlich abgrenzbare Objekte mit eigenen Attributen (An-Aus-Zustand und Leuchtfarbe) und Diensten (an- und ausschalten) dar, die auch als solche gehandhabt werden wollen. Überdies ist dieses Modell geeigneter für die Implementierung (siehe Problematik 2).
Das naive Modell und das Stift-basierte Zeichnen offenbaren eine weitere Problematik. Dazu betrachte man die Programmierung eines Phasenwechsels der Ampel, beispielsweise von Grün auf Gelb, dessen Lösung in etwa so aussieht:
Man erkennt leicht, dass zur eigentlichen Problemlsung der Fokus erheblich auf Zeichenprimitiven liegen muss. Auch tritt damit eine Vermischung von Zuständigkeiten ein, wie man sie eigentlich beim Programmieren zu vermeiden versucht. Dabei liegt doch eher der Wunsch nahe, objektorientiert zu programmieren und, statt eines Stift-Objekts, Lampen-Objekte zu benutzen: Schalte die grüne Lampe aus und schalte die gelbe Lampe an. Ein weiteres Resultat ist, dass Quelltexte aufgebläht werden und sie weniger gut lesbar sind.
Es ist leicht einsehbar, dass die genannten Problematiken beim grafikorientierten Programmieren, z.B. bei der Erstellung grafischer Benutzeroberflächen in realen Software-Projekten, möglichst nicht anfallen dürfen. Java bietet mit Swing eine modular aufgebaute, objektorientierte Grafikbibliothek, die sich für die Entwicklung selbst komplexer Oberflächen eignet.
Warum also sollte nicht der Versuch unternommen werden, sich Swing für die geometrischen Bausteine grafischer Lösungen im schulischen Informatikunterricht zu Nutze zu machen?