„WIE SCHÜLERGERECHT IST OBJEKTORIENTIERUNG … · Katharina Fritz, 0060308 4 Fachdidaktik Seminar SS2004 imperativen Paradigma beruhen und Bestandteile einer informatischen Ausbildung

„WIE SCHÜLERGERECHT IST OBJEKTORIENTIERUNG WIRKLICH?“

Katharina FRITZ, 0060308

[email protected]

SEMINAR AUS

INFORMATIK FACHDIDAKTIK

Dr. rer. nat. habil. Peter HUBWIESER

LV-Nr: 624.900 SS2004

Hubwieser

Schreibmaschinentext

Hauptseminar "Didaktik der Informatik" im SoSe 2004 an der Universität Klagenfurt Leitung: Prof. Dr. Peter Hubwieser

Katharina Fritz, 0060308 1 Fachdidaktik Seminar SS2004

INHALTSVERZEICHNIS

ABSTRACT .............................................................................................................................. 2

1. EINLEITUNG ...................................................................................................................... 2

2. DER SPRACHENSTREIT.................................................................................................. 2

2.1. PASCAL vs. BASIC – Der Sprachenstreit der 70er/80er Jahre ................................................ 2

2.2. Die Neuauflage des Sprachenstreits.............................................................................................. 3

2.3. Programmierstile............................................................................................................................ 3 2.3.1 Imperative Programmierung ..................................................................................................... 3 2.3.2. Prädikative Programmierung .................................................................................................... 4 2.3.3. Funktionale Programmierung ................................................................................................... 4 2.3.4. Objektorientierte Programmierung ........................................................................................... 5

3. OBJEKTORIENTIERTE PROGRAMMIERUNG – EINE GUTE IDEE FÜR DEN INFORMATIK-UNTERRICHT?........................................................................................... 5

3.1. Vorteile objektorientierter Sprachen ........................................................................................... 6

3.2. Mängel objektorientierter Sprachen im Anfangsunterricht ...................................................... 6

3.3. Auswirkungen auf den Informatikunterricht.............................................................................. 7

4. VERMITTLUNG VON OBJEKTORIENTIERUNG ...................................................... 8

4.1. Objektorientierte Modellierung lehren ........................................................................................ 8

4.2. Die Wahl der „richtigen“ objektorientierten Sprache................................................................ 9 4.2.1. JAVA als „Muttersprache“ – nein, danke!.............................................................................. 10 4.2.2. JAVA als „Muttersprache“ – unbedingt! ................................................................................ 11

5. CONCLUSIO...................................................................................................................... 13

LITERATURVERZEICHNIS .............................................................................................. 14

ABBILDUNGSVERZEICHNIS ........................................................................................... 14

LINKS ..................................................................................................................................... 14

ANHANG ................................................................................................................................ 15

A) Hello, world! (in JAVA) ......................................................................................................... 15

B1) Pullover (in JAVA)................................................................................................................. 16

B2) Testprogramm für Pullover (in JAVA)................................................................................ 17


Wie schülergerecht ist Objektorientierung wirklich?

Abstract In dieser Arbeit nähere ich mich dem Thema „Objektorientierung im Informatikunterricht“ sowohl von theoretischer als auch praktischer Seite und erläutere, ob und wie Objektorientie-rung im Informatikunterricht funktionieren könnte.

Als erstes ist es natürlich nötig, sich mit der Frage, welche Art des Programmierens für Schüler am effizientesten ist, auseinander zu setzen. Hierbei wird auch kurz auf den Spra-chenstreit der 70er Jahre1 eingegangen, der heute - in leicht veränderter Form - wieder an Aktualität gewonnen hat. Ziel hierbei ist es, zu thematisieren, welche informatische(n) Denk-weise(n) sich am besten für den Informatikunterricht eignet/eignen.

In weiterer Folge konzentriere ich mich auf die Möglichkeiten, die Objektorientierung SchülerInnen bieten kann, wobei auch auf didaktische Ansätze der Vermittlung objektorien-tierter Inhalte eingegangen wird.

Weiters werden Vor- und Nachteile des objektorientierten Paradigmas (anhand der Pro-grammiersprache JAVA) aufgezeigt.

1. Einleitung In den letzten Jahren hat Objektorientierung, nicht zuletzt mit dem verstärkten Aufkommen objektorientierter Sprachen wie JAVA oder C++, an Bedeutung gewonnen, weshalb sich auch für den Informatikunterricht die Frage stellt, inwieweit das Konzept der Objektorientierung gelehrt werden soll. Für die professionelle Softwareentwicklung steht fest, dass heute kaum noch ein Weg an der Objektorientierung vorbei führt. In der Schule sieht die Situation (teil-weise noch) anders aus. Jedoch ist auch hier ein Trend in Richtung Objektorientierung aus-zumachen. So werden neben PASCAL und C, das vorwiegend in HTBLAs2 unterrichtet wird, auch VISUAL BASIC, DELPHI oder PYTHON, seltener jedoch JAVA, gelehrt. Im Folgen-den möchte ich darlegen, inwieweit sich dieser Trend im Informatikunterricht durchsetzen lässt. 2. Der Sprachenstreit 2.1. PASCAL vs. BASIC – Der Sprachenstreit der 70er/80er Jahre Bereits in den 70er Jahren stellte sich die Frage nach der am besten geeigneten Programmier-sprache für den Anfangsunterricht in Informatik. Plädierten die einen für BASIC, setzten sich die anderen für PASCAL ein. Programmiert wurde im Endeffekt beides, denn als wichtig wurde schließlich nicht die Sprache sondern die „richtige Denkweise“ erachtet [vgl. Schw95]. Allerdings halte ich diesen „Kompromiss“ durchwegs für problematisch, da die „Mutterspra-che“ sowohl für das Erlernen informatischer Inhalte als auch weiterer Sprachen ausschlagge-bend ist. Auch der Ausdruck „richtige Denkweise“ wirft mehr Fragen als Antworten auf, weshalb es nicht verwunderlich ist, dass der Sprachenstreit, gerade mit einem verstärkten Aufkommen objektorientierter Sprachen, wieder neu entflammt ist. 1 In Österreich kam der Sprachenstreit eher in den 80er Jahren auf. 2 Höhere technische Bundeslehranstalten


2.2. Die Neuauflage des Sprachenstreits Zusätzlich zu der Frage „Welche Programmiersprache ist für die Schule am besten geeignet?“ [Schw95] stellt sich seit Beginn der 90er Jahre die Frage „Welche Denkweise ist für die Schule am besten geeignet?“[Schw95]. Grundsätzlich bieten sich vier Programmierstile an: Imperative, prädikative, funktionale und objektorientierte Programmierung. Jede dieser Pro-grammierarten weist sowohl Vor- als auch Nachteile auf, was eine Entscheidung zugunsten beziehungsweise gegen ein Programmierparadigma nicht leicht macht. Auch hier befinden wir uns in einer ähnlichen Lage wie schon vor etwa dreißig Jahren – abermals streiten sich Anhänger der verschiedenen Paradigmen und abermals wird ein nicht sehr aussagekräftiger Kompromiss, der auf die „Betonung der korrekten Meta-Denkweise“ [vgl. Schw95] abzielt, geschlossen. 2.3. Programmierstile Damit man sich selbst ein Bild über die verschiedenen Programmierstile machen kann, wer-den im Folgenden kurz die einzelnen Paradigmen vorgestellt und ihre Vor- und Nachteile für den Informatikunterricht (mit Bezug auf eine für sie repräsentative Sprache) erläutert. 2.3.1 Imperative Programmierung „Bei der imperativen Programmierung besteht ein Programm aus einer Folge von Befehlen. Wesentlich an imperativen Sprachen ist das Variablenkonzept: Eingabewerte werden in Vari-ablen (Speicherzellen) gespeichert und weiterverarbeitet. In diesen Sprachen spiegelt sich deutlich die Architektur des Von-Neumann-Rechners wider.“ [Dude93] Als Hauptvertreter imperativer Programmiersprachen an Schulen sind sicherlich PASCAL, BASIC und C zu nennen. Inwieweit PASCAL und BASIC noch an Schulen gelehrt werden, ist meiner Meinung nach jedoch fraglich.3 Allerdings waren BASIC und PASCAL, die auch in Schulbüchern wie „Grundzüge der Informatik I - III“ ausführlich behandelt werden, sicher-lich die klassischen Ausbildungssprachen im Informatikunterricht. Im Folgenden werden die Vor- und Nachteile anhand einer dieser Sprachen, nämlich PASCAL, genauer analysiert.

PASCAL ermöglicht ein Lehren nach dem „bottom-up“ Prinzip. Das heißt: Die Konzepte (wie etwa Datentypen, bedingte Anweisungen, Schleifen, Felder, Prozeduren, Modularisie-rung) werden den SchülerInnen (wie in vielen anderen Fächern) klassisch schrittweise näher gebracht. Das bietet den Vorteil, dass die Konzepte durch ein ständiges Wiederholen in klei-nen, fiktiven Übungen gefestigt werden. Schwills Kritikpunkt, dass diese Übungen wenig praktische Relevanz der Informatik vermitteln, sind durchwegs begründet. [vgl. Schw01] Al-lerdings bietet eine fundierte Grundausbildung auch eine gewisse Sicherheit für SchülerInnen, in weiterer Folge vernünftige Programme mit Anwendungsbezug erstellen zu können. Bis man allerdings diesen Punkt erreicht hat, können sich Motivationsprobleme bei SchülerInnen ergeben, die eben gerade wegen mangelndem Anwendungsbezug entstehen. Aber auch ein „Lernen auf Vorrat“ wegen der großen Syntax von PASCAL mit ihren vielen Verboten und Nebenbedingungen kann dazu führen. [vgl. Schw01], [vgl. Schw95]

Dennoch erscheint eine Auseinandersetzung mit prozeduralen Sprachen, sei es nun als Erst- oder Zweitsprache, in der Schule als wünschenswert, da eine Reihe informatischer „Systeme“ darauf aufbauen. Das rechtfertigt auch den Einsatz dieser Sprachen in dem Sinn, dass man die SchülerInnen nicht nur zu reinen ProgrammiererInnen macht, sondern mit ihnen auch Turingmaschinen, Registermaschinen [vgl. Schw95] und Betriebssysteme, die auf dem

3 Daten zur Nutzung von Programmiersprachen im Unterricht sind leider nicht erhältlich.


imperativen Paradigma beruhen und Bestandteile einer informatischen Ausbildung sein soll-ten, behandeln kann. Diese Programmiersprachen stellen ebenfalls die sequentiellen Befehls-folgen der „Von-Neumann-Architektur“ dar, die wiederum Gegenstand des Informatikunter-richts sein sollte. 2.3.2. Prädikative Programmierung „Bei prädikativen Programmiersprachen wird Programmierung als beweisen in einem Sys-tem von Tatsachen und Schlussfolgerungen aufgefasst: Der Anwender gibt ein Menge von Fakten und Regeln (d.h. wie man aus Fakten neue Fakten gewinnt) vor, und die Aufgabe des Rechners ist es, eine gestellte Frage als richtig oder falsch zu beantworten.“ [Dude93] Während davon ausgegangen werden kann, dass die imperative Programmierung an vielen Schulen sicher noch unterrichtet wird, findet sich der prädikative (oder logische) Program-mierstil eher selten. Obwohl PROLOG als Vertreter der logischen Programmiersprachen, der natürlichen Sprache ähnelt und damit Probleme (nicht Lösungen, wie in anderen Program-miersprachen!) eigentlich „einfach“ zu beschreiben wären, eignet sich diese Sprache (eigent-lich das gesamte Paradigma) nur schwer für die Schule.

Gründe hierfür sind laut Schwill vor allem darin zu suchen, dass logische Sprachen auf der Prädikatenlogik aufbauen, die nicht viel mit der Alltagssprache und –logik gemein hat. [vgl. Schw95]

Daraus lässt sich ableiten, dass SchülerInnen bereits Erfahrungen aus dem Bereich der Prädikatenlogik mitbringen müssen, um mit PROLOG arbeiten zu können. Allerdings ist das Thema Prädikatenlogik weder im Lehrplan Mathematik noch im Lehrplan Informatik zwin-gend vorgeschrieben, weshalb SchülerInnen wenig Erfahrungen diesbezüglich haben dürften, was wiederum PROLOG und andere logische Sprachen unbrauchbar für anfängliches Pro-grammieren macht.

Schwill zeigt auch die „closed world assumption“ als Kritikpunkt auf. Er sieht ein Problem darin, dass es nur „ja“ oder „nein“ als „Output“, jedoch keine Graustufen dazwischen gibt, wie die sehr „menschlichen“ Antworten „vielleicht“ oder „ich weiß nicht“. [vgl. Schw95]

Jedoch schwerer wiegen, meiner Meinung nach, folgende „Eigentümlichkeiten“ von PROLOG:

Elemente wie etwa „for“-Schleifen oder Funktionen (im eigentlichen Sinne) fehlen. Das Konzept der Rekursion, worauf PROLOG aufbaut, ist nur schwer, wenn über-

haupt, für Anfänger vermittelbar. An dem (für PROLOG eher einfachen) Beispiel der Summenbildung einer Liste kann dies verdeutlicht werden:

summe_liste([],0). summe_liste([H|T],Summe) :- summe_liste(T,NeueSumme), Summe is H + NeueSumme. 2.3.3. Funktionale Programmierung „Programme berechnen Funktionen, die Eingabedaten in Ausgabedaten abbilden. In der funktionalen Programmierung beschreibt man die Beziehungen zwischen Ein- und Ausgabe-daten mit Hilfe mathematischer Ausdrücke, indem man elementare Ausdrücke für einfache Funktionen zugrunde legt und hieraus mit Operationen, die auf Funktionen definiert sind, komplexere Funktionen darstellt. Das wichtigste Konstruktionsprinzip ist hierbei die Rekur-sion.“ [Dude93]


Das zuvor angesprochene Problem der Rekursion tritt nicht nur bei prädikativen sondern auch bei funktionalen Sprachen, wie etwa LISP oder LOGO, auf. Überdies besteht die Gefahr, dass SchülerInnen die Sprachen aufgrund ihrer mathematischen Notation, bauen sie doch auf dem Lambda-Kalkül auf, als abschreckend empfinden. [vgl. Schw95] 2.3.4. Objektorientierte Programmierung „Bei objektorientierten Sprachen werden alle zum Lösen eines Problems notwendigen Infor-mationen (Daten und Anweisungen) als Objekte aufgefasst. Objekte können durch Senden von „Nachrichten“ (Mitteilungen an andere Objekte) miteinander Informationen austauschen.“ [Dude93] Die in den letzten beiden Paradigmen notwendige Vorbildung (einerseits Prädikatenlogik, andererseits ein Wissen über mathematische Funktionen) ist bei dem objektorientierten An-satz nicht vonnöten. Hier wird vor allem auf typische kognitive Aspekte des Erkennens, Den-kens und Problemlösens eingegangen [vgl. Schw95].

Bereits kleine Kinder besitzen erstaunliche kognitive Fähigkeiten, die es ihnen ermögli-chen, Dinge aufgrund ihrer Eigenschaften zu kategorisieren und zu beurteilen, was man mit ihnen machen kann [vgl. Rays00]. Dieses natürliche Phänomen wurde auch bei der Entwick-lung von objektorientierten Sprachen herangezogen, die eine sehr „lebensnahe“ Programmie-rung ermöglichen und deshalb gut für den Informatikunterricht geeignet sind.

Objektorientierte Sprachen ermöglichen auch Erweiterbarkeit, Anpassbarkeit, Vererbung und Kapselung – also lauter Dinge, die wir aus dem „normalen“ Leben (von Kindesalter an) kennen und anwenden, um verschiedene Dinge zu klassifizieren. Diese Vertrautheit mit der Klassifikation von Objekten, ermöglicht den Einsatz von objektorientierten Programmierspra-chen bereits mit wenig mathematischen Vorkenntnissen und nicht erst nach Erwerb spezifi-scher (mathematischer) Kenntnisse (wie etwa Prädikatenlogik). Diese Nichtgebundenheit an die Mathematik ermöglicht auch einen Unterricht, der vermehrt auf die praktische Relevanz der Informatik hinweist (was im Vergleich mit prozeduralen Sprachen anfänglich schwierig ist).

Aufgrund dessen spricht sehr viel für einen Anfangsunterricht mit Objektorientierung. Al-lerdings werden auch immer wieder Stimmen dagegen laut. Im folgenden Abschnitt werden Vor- und Nachteile dieses Paradigmas nochmals genauer analysiert. 3. Objektorientierte Programmierung – Eine gute Idee für den Informatik-Un-terricht? Wie schon im vorigen Abschnitt beleuchtet, erlangt Objektorientierung im Unterricht immer mehr an Bedeutung, da funktionale und prädikative Programmierung im Anfangsunterricht ausscheiden und prozedurale Programmierung scheinbar momentan einen schlechteren Ruf besitzt, als ich es für gerechtfertigt halte. Trotz der Euphorie bezüglich Objektorientierung, wagen es einige, unter ihnen Broy und Siederslieben, diese auch aufgrund einiger vorhande-ner Schwachstellen vor allem in Bezug auf Vererbung hin zu kritisieren [vgl. Broy02]. Auf-grund dieser Schwachstellen jedoch keine Objektorientierung zu betreiben, ist natürlich auch Unsinn, denn Objektorientierung bietet viele Vorteile und Möglichkeiten (für die Schule), die ebenfalls in diesem Kapitel genauer betrachtet werden.


Abb. 1 - OOP

3.1. Vorteile objektorientierter Sprachen Objektorientierte Sprachen bieten in hohem Maße Lösungen für die in der Softwareentwick-lung (ersichtlich aus Abbildung 1) geforderten Ziele.

So ist es mit objektorientierten Sprachen sehr gut möglich, Problemangemessenheit zu erzielen, da sich auf objektorientierter Ebene Dinge im Prinzip ähnlich beschreiben lassen wie sie im Alltag wahrgenommen werden. Bietet die Programmiersprache geeignete Konstrukte, um Objekte ähnlich (einfach) zu klassifizieren wie wir es auf nicht-informatischer Ebene tun, können bei SchülerInnen gute Erfolge erzielt werden [vgl. Spol99].

Im Zuge der Problemangemessenheit ist es natürlich auch wichtig, zu abstrahieren und die wichtigsten Eigenschaften und „Verhaltensmuster“ ausfindig zu machen. Für objekt-orientierte Sprachen bietet sich hier insbesondere UML an, da sich hier sehr schön Eigenschaften und Verhalten von Objek-ten (Klassen) und deren Beziehungen untereinander darstellen lassen.

Klassen und Objekte, die über „Botschaften“ (eigentlich nichts anderes als Methoden) miteinander kommunizieren, strukturieren auch den gesamten Code. Anders als bei prozeduralen Sprachen, werden in objektorientierten Sprachen Daten und Methoden nicht von einander getrennt. Das

ermöglicht auch Datenkapselung, was nichts anderes bedeutet, als dass Daten in Objekten „versteckt“ und nur über definierte Methoden zugänglich sind. [vgl. Midd03]

Aber auch das Ziel der Wiederverwendbarkeit und Erweiterbarkeit wird mit objektorien-tierten Sprachen sehr gut erreicht, obwohl sich gerade mit der Implementierungsvererbung eine Reihe von Problemen wie etwa eine Verletzung des Geheimnisprinzips ergeben können (aber nicht zwangsläufig müssen) [vgl. Broy02]. Anhand der Vererbung wird auch die Klas-senhierarchie verdeutlicht. Subklassen erben Methoden und Elemente der Superklasse und können sie entweder überschreiben oder noch zusätzliche spezifische Methoden hinzufügen.

Wie in diesem Abschnitt beschrieben wurde, eignet sich die Objektorientierung sehr gut für eine sehr „wirklichkeitsnahe“ Art der Programmierung, die auch auf eine klare Strukturie-rung im Sinn von Objekten Wert legt und es ermöglicht, Codewiederverwendung und –er-weiterbarkeit zu betreiben. Jedoch ergeben sich aus dem objektorientierten Paradigma auch eine Reihe von Schwierigkeiten für den Informatikunterricht, die im folgenden Abschnitt er-läutert werden. 3.2. Mängel objektorientierter Sprachen im Anfangsunterricht Für den Anfangsunterricht ergeben sich jedoch aufgrund der Mächtigkeit objektorientierter Sprachen eine Reihe von Problemen. Konnten beim prozeduralen Paradigma die Konzepte schrittweise vermittelt werden, ist das bei objektorientierten Sprachen schon wesentlich schwieriger, hängen doch Klassen, Objekte, Methoden eng zusammen. Deren Wichtigkeit und Mächtigkeit einzeln zu erklären gestaltet sich annähernd ebenso schwierig wie dies nicht zu tun. Für Lingl ergeben sich bei der Einführung von objektorientierter Programmierung drei Pro-blemfelder:


1.) „Der Lernende hat lange Zeit das Gefühl, die Dinge nicht genügend zu durch-

schauen.“ [Ling03] Dieser Argumentation stimme ich aus eigener Erfahrung durchwegs zu. Nur zu gut kann ich mich daran erinnern, in Objekten so etwas Ähnliches wie Methoden gesehen zu haben… Al-lerdings könnte durch eine gute didaktische Vermittlung solchen Problemen vorgebeugt wer-den. Auf die Vermittlung des objektorientierten Paradigmas wird deshalb auch im nächsten Abschnitt eingegangen.

2.) Ein Übermaß an Sprachelementen und syntaktischen Konstruktionen finden sich schon in einfachsten Programmen wieder.[vgl. Ling03]

Selbst das gerne als Einstieg verwendete Mini-Programm – „Hello, world“4 in JAVA birgt eine Reihe von Konzepten und syntaktischen Elementen in sich, die ein Anfänger einfach nicht verstehen kann.

3.) „Das gesamte Arsenal der Algorithmik und der strukturierten Programmie-rung wie auch umfassende Kenntnisse von Daten und Datenstrukturen müssen angewendet werden.“ [Ling03]

Ein großes Problem der Objektorientierung besteht auch darin, dass im Prinzip Klassen zeit-gleich mit Objekten und diese wiederum gleichzeitig mit Methoden eingeführt werden müss-ten. Typdeklaration, Übergabeparameter, Schleifen, Konstruktoren, Interfaces, der Umgang mit Klassenbibliotheken müssten nebenbei auch noch gelehrt werden. Überdies sollten die Programme nicht in Spaghetticode enden, sondern vielmehr strukturiert und objektorientiert (!) gestaltet werden. Eine Herausforderung nicht nur für die SchülerInnen sondern (vor allem) auch für die LehrerInnen. Also entscheiden wir uns gegen den objektorientierten Ansatz? Keineswegs – jedoch müssen einige Aspekte bei der Einführung beachtet werden, die im Folgenden kurz beschrieben wer-den. 3.3. Auswirkungen auf den Informatikunterricht Vor allem LehrerInnen werden bei der Einführung von Objektorientierung sehr gefordert sein, gilt es doch eine Vielzahl mächtiger Begriffe so einzuführen, dass SchülerInnen sie nicht nur verstehen, sondern auch in einer Programmierumgebung umsetzen können. Das wird sich meiner Meinung nach auch deshalb schwierig gestalten, als dass einige LehrerInnen nur ein verschwommenes Bild von Objektorientierung haben, sei es nun wegen mangelnder fachli-cher Qualifikation (z.B.: Musiklehrer unterrichtet Informatik), mangelnder Fortbildung oder eines zu starken Einflusses des jahrelang praktizierten prozeduralen Programmierens. Im Prinzip wird der Erfolg beziehungsweise das Scheitern bei der Einführung von Objekt-orientierung meiner Meinung nach von drei Punkten abhängen:

Der Wahl der richtigen Werkzeuge sowohl für Entwurf als auch Programmie-rung [vgl. auch Ling03]

4 siehe Anhang


Der Komplexitätsreduktion der vorgestellten Konzepte Der Lern- und Lehrbereitschaft der Lehrkräfte

Auch Lingl hält eine erfolgreiche Einführung des objektorientierten Paradigmas nur unter folgenden vier Prämissen für möglich [vgl. Ling03].

das richtige Werkzeug wählen von dem verwendeten Arsenal an Werkzeugen wohl definierte kleine Teilmen-

gen auswählen in sorgfältig ausgewählten Lernschritten jeweils nur ein Konzept auf einmal neu

einführen dem Übergang vom Konkreten zum Abstrakten und zurück besondere Bedeu-

tung schenken 4. Vermittlung von Objektorientierung In diesem Abschnitt werden einige Ideen, wie die Einführung von Objektorientierung auch im Unterricht funktionieren könnte, vorgestellt. Zum besseren Verständnis werden einige prakti-sche Beispiele geboten, die zeigen sollten, was die Stärken aber auch die Schwächen der ein-zelnen Möglichkeiten sind. 4.1. Objektorientierte Modellierung lehren Für viele LehrerInnen stellt sich die Frage, wann denn nun Objektorientierung gelehrt werden soll. Gleich vorweg, die Expertenmeinungen gehen auch hier auseinander. Knapp und Fischer schlagen objektorientierte Analyse und Entwurf bereits für die Sekundarstufe I vor [vgl. Knap98]. Geht man von lernpsychologischen Erkenntnissen aus, sollte in der siebten Schul-stufe, für die die Einführung vorgeschlagen wird [vgl. Knap98], ein derartiges Abstraktions-vermögen schon bei SchülerInnen vorhanden sein.

Das Ziel von Knapp und Fischer ist es, Anwendersysteme von SchülerInnen objektorien-tiert analysieren zu lassen, um diese auf die Handhabung neuer Systeme gut vorzubereiten [vgl. Knap98]. Obwohl ihr Versuch sicher löblich ist, fürchte ich doch, dass er große Schwie-rigkeiten für SchülerInnen beinhalten könnte. Vielleicht sollte man in dieser Schulstufe nicht versuchen gleich aus etwas (meiner Meinung nach eher) Abstraktem wie Absatz, Blocksatz oder einrücken etwas noch Abstrakteres wie Klassen, Objekte, Attribute und Operationen abzuleiten. Viel mehr sollte man für den Anfang versuchen, Abstraktion, was ja enorm wich-tig in der Informatik ist, anhand von „realeren“ Beispielen wie einem Pullover (der als Illust-ration auch bei Knapp/Fischer dient), zu betreiben und dann mit Anwendungssystemen fort-fahren. Den Pullover nur als Anschauungsobjekt zu erachten und dann gleich in komplexere Anwendungssystemanalyse überzugehen, ist sicherlich für viele SchülerInnen unbewältigbar. Davon kann man sich auch in den zwei unten angeführten Beispielen, die überdies „Objekt“ falsch gebrauchen, selbst überzeugen.

Abb. 2: OOA Pullover [Knap98]

OBJEKT(?!) ATTRIBUT ATTRIBUTWERT Farbe alle Farben, farblos Material Wolle

Baumwolle Synthetik

Pullover

Größe von XS bis XXL


Abb. 3: OOA Zeichen [Knap98]

Wird bei Knapp und Fischer ein eher früheres Vertrautmachen mit objektorientierten Kon-zepten angestrebt, gibt es auch Ansätze, in denen Objektorientierung erst nach einer fundier-ten Datenbankausbildung samt Einsatz von UML eingeführt wird. Hierbei kann objektorientiertes Programmieren also schon auf ein Fundament, das sich durch ein gezieltes „Abstraktionstraining“ mit UML ergibt, aufbauen.

Der Einsatz von UML im objektorientierten Entwurf ist jedoch nicht unumstritten. Laut Broy und Siederslieben beginnen die Probleme bereits mit UML und nicht erst bei der objekt-orientierten Programmierung. Vor allem das „Fehlen einer klaren Semantik“ und eine „man-gelnde Integration verschiedener Beschreibungstechniken“ stellt für sie eine durchwegs schlechte Ausgangsbasis für weitere Schritte dar. [Broy02] Mit dieser Meinung bilden sie jedoch eher eine Ausnahme. In der Literatur wird ein Einsatz von UML durchwegs als positiv beschrieben [vgl. Ling03], da sich Klassen mit Attributen und Operationen, Klassenhie-rarchien und auch ihre Beziehungen untereinander gut (und meiner Meinung nach durchwegs ordentlich) darstellen lassen. 4.2. Die Wahl der „richtigen“ objektorientierten Sprache Neben der Wahl der „am besten geeigneten“ Modellierungssprache für Objektorientierung, ist natürlich auch die Sprache, in der schlussendlich programmiert werden sollte, von entschei-dender Bedeutung. Wenn es sich noch dazu um die „Muttersprache“ für die SchülerInnen handeln sollte, muss diese Wahl sorgsam getroffen werden. Grundsätzlich bieten sich eine Reihe objektorientierter Sprachen für den Unterricht an. Zum Glück (oder vielleicht doch eher leider) scheiden einige schon deshalb für die Schule aus, da sie käuflich erworben werden müssten (darunter C#). Aber die Wahl DER Anfängersprache fällt selbst mit den lizenzfreien Angeboten noch schwer, denn „typischerweise präferieren drei überzeugte Kollegen natürlich drei verschiedene Sprachen:

Der Fachbereichsleiter DELPHI, weil dies das zeitgemäße Werkzeug sei. Der Webexperte JAVA wegen der Client-Server-Unterstützung.

OBJEKT (?) ATTRIBUT ATTRIBUTWERT DARSTELLUNG

Schriftstil normal fett kursiv unterstrichen Kapitälchen

normal fett kursiv unterstrichen KAPITÄLCHEN

Schriftart Serifschrift serifenlos proportional nichtproportional

Serifschrift serifenlos proportional n ichtproport ional

Schriftgröße in Punkten ange-geben

6 Punkte

16 Punkte Schriftposi-tion

normal Hochstellung Tiefstellung

normal eine Hochstellung

eine Tiefstellung

Zeichen

Schriftfarbe


Der Fachseminarleiter Object-PASCAL, weil es nicht mit einem gewaltigen Overhead und unwichtigen Gimmicks (das tolle Aussehen) vom eigentlichen Kern des Unterrichts ablenkt.“ [Peno98]

Und wieder andere präferieren PYTHON [Ling03], DELPHI [Peno98], JAVA [Peno98], OBERON, MODULA-3 [Bösz01], C++, etc. Das bedeutet für den Informatikunterricht, dass es nicht DIE Programmiersprache geben kann. Die Wahl der für den Unterricht eingesetzten objektorientierten Programmiersprache (sofern dieses Paradigma überhaupt gelehrt wird) liegt also bei dem/der InformatiklehrerIn und dessen/deren Vorlieben5. Meiner Meinung nach sollten aber neben den Vorlieben der Lehrkraft auch folgende Gründe eine Rolle bei der Wahl der Programmiersprache spielen:

Die Sprache sollte eine möglichst klare Syntax und wenige Ausnahmen besitzen. [vgl. Schw01]

Sie sollte möglichst strukturierte und übersichtliche Programmierung ermöglichen. Die Handhabung der Bibliotheken sollte sich auch für Anfänger einfach gestalten.

Im Folgenden wird die objektorientierte Programmiersprache JAVA auf ihre Eignung als „Muttersprache“ für den Anfangsprogrammierunterricht in der Schule analysiert. 4.2.1. JAVA als „Muttersprache“ – nein, danke! Die Programmiersprache JAVA ist seit ihrer Entstehung 1990 nicht zuletzt wegen ihrer Por-tabiliät und des daraus resultierenden Erfolgs als „Sprache des Internets“ auch bei SchülerIn-nen sehr bekannt (aber nicht unbedingt beliebt). Ob sie sich auch als „Muttersprache“ für den Anfangsprogrammierunterricht eignet, ist jedoch fraglich. Wie Böszörmenyi in seinem Arti-kel in LOG IN 21/1 feststellt, handelt es sich bei JAVA um eine „klare und gute Sprache“ mit einigen Eigenarten [Bösz01]:

„Modul als Spezialfall von Klassen“ „Prozedur als Spezialfall von Methoden“ „Konstanten als Spezialfall von Variablen“ „Das Modulkonzept fehlt“ „Es gibt keine Records“ „Arrays sind Objekte“

Diese Punkte widersprechen deutlich den geforderten Kriterien aus Punkt 4.2.. Schwerwie-gender als diese Eigentümlichkeiten, an die man sich mit der Zeit gewöhnt, erscheinen mir jedoch Lingls Kritikpunkte bezüglich „einfacher Anfangskonstrukte“ [vgl. Ling03].

public static void main(String[] args)

Die statische Methode, die in keiner Klasse fehlen darf, besitzt sechs syntaktische Elemente, deren Erklärung jeden Anfänger heillos überfordert. Ähnliches ist auch bei

System.out.println(„Hello, world!“);

5 In HTBLAs wird die Programmiersprache derzeit noch weitestgehend vorgeschrieben


zu erwarten. Dieser anfängliche „Overhead“ kann natürlich rasch zu Frustrationen führen. Auch die großen Klassenbibliotheken lassen Anfänger schier verzweifeln. Das allergrößte Problem, warum JAVA von vielen StundentInnen und SchülerInnen nicht verstanden wird, liegt meiner Meinung nach jedoch nicht bei JAVA, sondern in der Art, wie mit dieser objektorientierten Sprache umgegangen wird. Insofern erachte ich die Aussage Böszörmenyis, dass JAVA als „erste Programmiersprache schwierig zu erlernen ist“ [Bösz01], nur dann für haltbar, wenn so wie im nachfolgenden Negativbeispiel vorgegangen wird. Negativbeispiel aus einer Einführungsvorlesung zum Thema JAVA (WS 2000/01) [vgl. Bösz00]:

− Algorithmen sollen in Fluss- bzw. Blockdiagrammen dargestellt werden − keine einzige Folie mit UML

− eine einzige „Einleitungsfolie“ mit allen mächtigen Begriffen (Klasse, Objekt, Nach-richt), die niemand verstehen kann, der noch nie programmiert hat

− „Hello, world“ − Programme mit Methoden, aber ohne Objekte − Grundanweisungen, If-Anweisung, Schleifen, Arrays − jetzt erst Klassen, Objekte (abgesehen von den Arrays), Methoden und eine Reihe un-

übersichtlicher Folien, die es einem Anfänger unmöglich machen, zu erkennen, wie diese drei zusammenhängen

− Pakete − Geheimnisprinzip − …

Mit einem solchen Vorgehen MUSS JAVA als „Muttersprache“ ausscheiden. Allerdings würde man mit einem Ausschluss JAVAs als „Muttersprache“ auch viele Möglichkeiten von JAVA verschenken. Mit BlueJ, einer meiner Meinung nach sehr ansprechenden und didak-tisch sehr gut gestalteten Entwicklungsumgebung, könnte JAVA (und damit auch die häufig gebrauchte C-Syntax) jedoch sehr gut als Muttersprache eingeführt werden. 4.2.2. JAVA als „Muttersprache“ – unbedingt! In BlueJ hat man die Möglichkeit, Klassen und ihre Objekte mittels eines UML-ähnlichen Klassendiagramms zu visualisieren. Damit erhält man einen sehr guten Überblick über die Klassenhierarchie. Klickt man auf die Klassen, wird der Code sichtbar, der gelesen oder bear-beitet werden kann. Klickt man mit der rechten Maus auf die Klasse, können auch Objekte erzeugt werden, die dann als Art Ellipse auf dem Hauptmenü (zusammen mit dem „UML-Diagramm“) aufscheinen. Mittels eines Klicks auf die Objekte werden deren Methoden und geerbte Methoden sichtbar. Auch können neue Methoden hinzugefügt werden.

Mit all diesen Methoden werden „Objektorientierung“ und schwierige Konzepte auch für den Anfänger leichter ersichtlich und nachvollziehbar, was BlueJ zu einer außergewöhnlich guten und auch der Objektorientierung treuen Entwicklungsumgebung macht.


Abb. 4 – BlueJ Oberfläche Besonders gut erscheint mir auch die von den BlueJ Befürwortern [vgl. Köll01] vorgeschla-gene Didaktik. Die Vorgehensweise mag für im prozeduralen Zeitalter geschulte Informatiker vielleicht drastisch anmuten. Ich erachte dies jedoch als einzigen Weg, objektorientierte Pro-grammierung als solches sinnvoll zu vermitteln.

„Zuerst Objekte Nicht mit einem leeren Blatt (Bildschirm) beginnen Code lesen lassen „Große“ Anschauungsprojekte verwenden Nicht mit „main“ beginnen Vergiss „Hello, world“ Zeigen der Programmstruktur Sorgsam mit dem User Interface umgehen“ [Köll01]

Von den Befürwortern von BlueJ wird der folgende Ansatz als am effektivsten für den Er-werb der objektorientierten Sprache JAVA erachtet [vgl. Köll01]:

„Learning by observing“ wird als Ausgangspunkt für jeden weiteren objektorientierten Schritt angesehen. Dieser Ansatz ist sehr konform mit entwicklungspsychologischen Ansich-ten und der Art, wie wir laut Aristoteles [vgl. Rays00] Dinge wahrnehmen und klassifizieren. Besonderer Wert wird hierbei auch auf die Experimentierfreudigkeit des Menschen gelegt. So werden SchülerInnen beziehungsweise StudentInnen dazu motiviert, mit bereitgestellten (das heißt bereits implementierten) Formen zu spielen (wodurch auch Kinder viel lernen) und die Auswirkungen ihres Handelns zu begreifen. [vgl. Köll01]

In einem nächsten Schritt, den wir „Learning by manipulating“ nennen könnten, werden die Beobachtungen in die Tat umgesetzt, indem kleine Teile des Codes (aber nur innerhalb einer Klasse) verändert werden müssen. Das ist um ein Vielfaches leichter zu bewerkstelligen als vor einem leeren „Blatt Papier“ zu sitzen und zu versuchen Klassen und Objekte zu erzeu-gen. Die Scheu und eventuelle Ängste können so leicht genommen werden. Ähnlich wie im „richtigen“ Leben, verändern wir Attribute von Objekten und im Anschluss auch deren Me-thoden. [vgl. Köll01]


Im letzten Schritt wird „Learning by doing“ praktiziert. Das heißt, es werden neue Attri-bute, neue Methoden, neue Objekte und neue Klassen hinzugefügt. Das Meisterstück stellt dann, nach einer Vertiefung der wichtigen Aspekte der Modellierung, ein eigenes, zur Gänze selbst (beziehungsweise in der Gruppe) geschriebenes Programm dar. [vgl. Köll01]

Diese Methode erscheint mir als sehr gut geeignet für den Unterricht. Ganzheitliches Ler-nen wird ermöglicht und Ängste vor leeren Blättern sowie das Gefühl des Nichtdurchschau-ens der Konzepte werden den SchülerInnen genommen. Was auch noch besonders auffällt, ist, dass SchülerInnen nicht gezwungen werden, sofort Programme selbst zu schreiben. Damit wird Überforderung und Motivationsschwund rechtzeitig vorgebeugt und das leidige Thema der expliziten Erklärung von „public static void main(String[] args)“ umgangen. 5. Conclusio Objektorientierung bietet sich aufgrund ihrer „Natürlichkeit“ im Informatikunterricht bereits in unteren Schulstufen in Form objektorientierter Analyse beziehungsweise objektorientierter Modellierung an. Aufbauend auf diesen kann in Folge auch objektorientiert programmiert werden, wobei die Wahl der Sprache und der Entwicklungsumgebung entscheidend zum Er-folg beitragen. Auch die Art der Vermittlung schwieriger, zusammenhängender Konzepte wie Klassen, Objekte und Methoden bedarf eines objektorientierten Vorgehens, das sich deutlich von einer „prozeduralen“ Vermittlung unterscheidet. Werden diese Faktoren ausreichend be-rücksichtigt, erscheint Objektorientierung durchwegs lehrbar.


Literaturverzeichnis [Bösz00] Böszörményi, László: Vorlesungsskriptum „Software I“ WS 2000/2001. Univer-

sität Klagenfurt, 2000. [Bösz01] Böszörményi, László: JAVA für Anfänger - Warum JAVA nicht meine Lieblings-

sprache für einen Anfängerkurs ist. LOG IN 21 1/2001 [Broy02] Broy, Manfred; Siedersleben, Johannes: Objektorientierte Programmierung und

Softwareentwicklung – Eine kritische Einschätzung. Informatik Spektrum 1/2002 [Crut95] Crutzen, Cecile K. M.; Hein, Hans-Werner: Objektorientiertes Denken als didakti-

sche Basis der Informatik. in Schubert, Sigrid [Hrsg.]: Innovative Konzepte für die Ausbildung, 6. CI-Fachtagung Informatik und Schule, 1995.

[Dude93] Engesser, Hermann [Hrsg.]: Duden Informatik – 2. Auflage. Mannheim, Wien, Dudenverlag. 1993

[Knap98] Knapp, Thomas; Fischer, Helmar: Objektorientierung im Informatikunterricht – Ein didaktisches Konzept zum Einstieg in den Informatik-Unterricht der Sekun-darstufe I. LOG IN 18 3/4/1998

[Köll01] Kölling, Michael; Quig, Bruce; Patterson, Andrew; Rosenberg, John: The BlueJ system and its pedagogy. 2001

http://www.cs.umu.se/~jubo/Meetings/OOPSLA01/Contributions/MKolling.pdf [Ling03] Lingl, Gregor: Objektorientierung im Informatik-Unterricht der AHS – Traditio-

nelle Probleme und neue Chancen. in Reiter, Anton et al. [Hrsg.]: Schulinformatik in Österreich – Erfahrungen und Beispiele aus dem Unterricht. Wien, Ueberreuter. 2003

[Midd03] Middendorf, Stefan; Singer, Reiner; Heid, Jörn: JAVA – Programmierhandbuch und Referenz für die JAVA-2-Plattform, Standard Edition. 3. Aufl. Heidelberg, dpunkt.verlag. 2003

[Rays00] Rayside, Derek; Campbell Gerard T.: Aristotle and Object-Oriented Programming: Why Modern Students Need Traditional Logic. 2000

[Schw01] Schwill, Andreas. Vorlesung E – Anfangsunterricht. 2001 http://www.gym1.at/schulinformatik/aus-fortbildung/fachdidaktik/vk-

01/anfangsunterricht/anfang-schwill.pdf [Peno98] Penon, Johann; Spolwig, Siegfried: Schöne visuelle Welt. LOG IN 18 5/1998. [Schw95] Schwill, Andreas: Programmierstile im Anfangsunterricht. in Schubert, Sigrid

[Hrsg.]: Innovative Konzepte für die Ausbildung, 6. CI-Fachtagung Informatik und Schule, 1995.

[Spol99] Spolwig, Siegfried: „Hello World“ in OOP. LOG IN 19 5/1999 Abbildungsverzeichnis

http://www.oszhdl.be.schule.de/gymnasium/faecher/informatik/oop/oop_1.0.htm http://www.cs.umu.se/~jubo/Meetings/OOPSLA01/Contributions/MKolling.pdf Knapp, Thomas; Fischer, Helmar: Objektorientierung im Informatikunterricht – Ein

didaktisches Konzept zum Einstieg in den Informatik-Unterricht der Sekundarstufe I. LOG IN 18 3/4/1998

Links

http://www.bluej.org (alle Links mit Stand: 14.06.2004)


Anhang A) Hello, world! (in JAVA) public class FirstProgramme{

public static void main(String [] args){ System.out.println("Hello, world!");

}//main }//class


B1) Pullover (in JAVA) public class Pullover{ private String farbe; private String material; private String groesse; //Konstruktor public Pullover(String farbe, String material, String groesse){ this.setFarbe(farbe); this.setMaterial(material); this.setGroesse(groesse); }//Pullover //nur wolle ist mit hand waschbar! ;) public boolean isWaschbarMitHand(){ return (this.material.toLowerCase().equals("wolle")); }//isWaschbar //überschreiben der toString methode von java.lang.String public String toString(){ return "********************************\n" + "Farbe: " + this.getFarbe() + "\n" + "Material: " + this.getMaterial() + "\n" + "Groesse: " + this.getGroesse() + "\n"; }//toString public void setFarbe(String farbe){ this.farbe = farbe; }//setFarbe public String getFarbe(){ return farbe; }//getFarbe public void setMaterial(String material){ this.material = material; }//setMaterial public String getMaterial(){ return material; }//getMaterial public void setGroesse(String groesse){ this.groesse = groesse; }//setGroesse public String getGroesse(){ return groesse; }//getGroesse }//class


B2) Testprogramm für Pullover (in JAVA) public class TestProgramm{ public static void main(String[] args){ Pullover p1, p2, p3; p1 = new Pullover("rot","wolle","s"); p2 = new Pullover("gruen","baumwolle","m"); p3 = new Pullover("blau","synthetik","xxl"); System.out.println(p1); System.out.println(p2); System.out.println(p3); System.out.println("p1 ist waschbar mit der Hand: " + p1.isWaschbarMitHand()); System.out.println("p3 ist waschbar mit der Hand: " + p3.isWaschbarMitHand()); }//main }//TestProgramm

Documents

„WIE SCHÜLERGERECHT IST OBJEKTORIENTIERUNG … · Katharina Fritz, 0060308 4 Fachdidaktik Seminar SS2004 imperativen Paradigma beruhen und Bestandteile einer informatischen Ausbildung