Methodische Probleme mit OOP im  Anfangsunterricht

von
Siegfried Spolwig
 

Im folgenden werden drei verschiedene Ansätze für den Einstieg in die objektorientierte Programmierung hinsichtlich des informatischen Gehalts und der methodischen Implikationen untersucht:

- Visuelle Programmierung
- OOP teilweise
- OOA-OOP vollständig
- Ergebnisse

Was wir aufgegeben haben

Unsere Vorstellungen von einem Informatikunterricht, der im Bereich Modellieren und Konstruieren angesiedelt ist, sind:

• State of the art

• Konzepte stehen im Vordergrund, nicht das vollständige Beherrschen einer Programmiersprache

• Schwerpunkt auf OOA und Modellieren

• Umsetzung der gefundenen Objekte/Klassen und ihrer Semantik in die Programmiersprache weitestgehend ohne Brüche (die Sprache muss die gefundenen Bezeichner 1:1 ausdrücken können)

• Produktorientierung und Ernsthaftigkeit der Programme zur Motivation der Schüler

• Spiralcurriculum mit dem Ziel eines größeren Softwareprojektes im Kurshalbjahr 13/1

Bis ca. 1997 hatten wir ein sehr ausgefeiltes Unterrichtskonzept der Programmierung entwickelt, das sich folgendermaßen beschreiben lässt:

• OOA

• objektbasierte modulare Programmierung (jedes Objekt = 1 ADT = 1 Pascal-Unit), die nur Benutzungsbeziehungen zwischen Schichten kennt

• keine "Hauptprogramme"

•  Objektorientierung von Anfang an.

Bereits die die ersten zwei, drei Programme behandelten ein Anwendungsproblem mit einer gewissen Komplexität, und die mindestens 1-2 Units zu Realisierung benötigten [8].

Das Erlernen der Programmiersprache lief relativ problemlos nebenher, auch weil alle Notationen durchgängig in der gleichen Art und Weise erfolgten, nämlich in Units [6] unter Turbo-Pascal. Dieses Konzept hat sich bei der Beurteilung der Lernerfolge der Schüler als sehr vorteilhaft erwiesen, da alle späteren Erweiterungen, Vertiefungen usw. immer wieder auf der gleichen objektbasierten Grundstruktur und Sichtweise aufgebaut wurden.

Was wir stattdessen bekommen haben

Nach 1997 beschlossen wir, "richtige OOP" im Unterricht einzuführen als Weiterführung unseres didaktischen Konzeptes. Dabei sollten die erreichten Standards, Leitlinien und Ansprüche nicht aufgegeben werden, sondern wir versprachen uns zusätzliche Erfolge von den erweiterten Möglichkeiten.

Allerdings hatte diese Entscheidung ganz andere Folgen als wir anfangs vermutet hatten, was in erster Linie mit der Wahl des Programmierentwicklungssystems zusammenhängt.

Nach heftigen Diskussionen entschieden wir uns für DELPHI. Aus damaliger Sicht war es durchaus attraktiv, da es erstens auf der Pascal-Schiene lag und zweitens einen komfortablen GUI-Builder integriert hatte. (Im Gegensatz zu ehrenwerten Puristen haben wir nie ideologische Schwierigkeiten mit professionellen und proprietären  Entwicklungswerkzeugen gehabt.) Diese Entscheidung war jedoch nicht unproblematisch, wie es sich im Verlauf der Zeit herausgestellt hat, weil die Form des Hammers in beträchtlicher Weise über den sauberen Einschlag des Nagels entscheidet - vornehmer ausgedrückt: die Wahl des Mediums kann den Inhalt determinieren oder beeinträchtigen. "Visuelle Programmierung" hatte zunächst Hochkonjunktur, nicht nur bei uns.

Erst mit der konsequenten Einführung der Trennung von Fachkonzept und GUI (M-V-C) ist das angepeilte Ziel erreicht worden, jedoch nicht ohne Opfer [4]. Diese "hard core oop" gelingt nur mit guten und sehr guten Schülern problemlos, schwache sind völlig überfordert, was zu einer Zwei-Klassen-Gesellschaft im Unterricht und zu entsprechenden Ausfällen führt.  Dazu muss aber gesagt werden, dass aufgrund unserer Schulform der Informatikunterricht in der 11. Klasse Pflichtunterricht ist, durch den alle, also auch die schwachen und uninteressierten, hindurch müssen. Diese starke Differenzierung war früher nie so deutlich.

Der Erfolg oder Misserfolg objektorientierter Programmierung im Schulunterricht hängt jedoch nicht davon ab, ob dieser Ansatz zu schwierig sei, mit einem zu großen Overhead bei kleinen Programmen daherkommt usw., sondern wird wesentlich dadurch bestimmt, welche Werkzeuge man für die Realisierung (Programmiersprache) einsetzt und in einem noch viel stärkeren Maße von sehr genau geplanten didaktischen Entscheidungen und dem methodischen Vorgehen im Unterricht [vgl. 4]  Mit anderen Worten: schon die ersten fünf Stunden sind mitentscheidend dafür, ob später ein Softwareprojekt gelingen wird oder nicht.

In seinem Vortrag "Objektorientiertes Programmieren in der Schulpraxis" berichtet Klaus Füller,

" ..., dass die Schüler nicht abstrakt objektorientiert entwerfen und den fertigen Entwurf dann in einer Sprache umsetzen, wobei ein einfaches Konzept vielleicht kompliziert ausgedrückt werden muss. Sie denken vielmehr in der Zielsprache..." [2]

Das wird Gründe haben. Vermutlich hat Füller den Schülern zunächst gründlich JAVA beigebracht und danach die objektorientierten Ansätze. Unsere Erfahrungen sind eher gegenteiliger Natur. Die Schüler lernen in Klassen und Objekten zu denken, haben aber teilweise erhebliche Schwierigkeiten bei der Umsetzung in die Programmiersprache, weil dieser Teil viel Übung braucht und aus Zeitgründen immer zu kurz kommt. Ich denke, das haben wir eindrucksvoll gezeigt mit den Ergebnissen bei den "Web-gestützen Software-Projekten", die in LOG IN ausführlich vorgestellt und die mit dem 1. Preis im Informatikwettbewerb ausgezeichnet wurden.
Dem sei noch hinzuzufügen, dass das Denken in Programmiersprache bei Projekten von einigermaßen ernst zu nehmender Größe kaum zu Erfolgen führt, sondern, dass andere Methoden der strukturierten Zerlegung erforderlich sind.
Diese Entscheidungen sind methodischer und medialer Art und haben nicht viel damit zu tun, ob die Sprache A, B oder X dieses oder jenes Feature besitzt. So sind Hinweise, dass der Code selbst kein Objekt sei und keine Iteratoren oder closures erlaubt, ziemlich sophisticated und für den Schulunterricht völlig irrelevant [vgl. 2]. Sie lassen eher Mängel in der didaktisch-methodischen Aufbereitung vermuten.

Wo die Probleme sind

Die Schwierigkeiten des objektorientierten Ansatzes im Anfangsunterricht liegen also weniger in der Komplexität des zu bearbeitenden - mehr oder weniger kleinen - Anwendungsproblems, sondern in der Komplexität der Anforderungen an die kognitive Beanspruchung der Schüler, die sich aus dem gesamten Set ergibt. Es sind vielfältige Abstraktionsleistungen unterschiedlichen Niveaus gleichzeitig zu erbringen, die auf völlig unterschiedlichen, unübersichtlich verschränkten Ebenen angesiedelt sind und die zu einem wohlgestalteten Ganzen führen sollen.

1. PASCAL lernen (das ist nicht Delphi) als formale Fremdsprache, vulgo "der Pascal-Kurs". Hier steht man vor der Entscheidung, einen systematischen Sprachkurs mit allen seinen Vorteilen zu organisieren oder eher eklektizistisch und unsystematisch die Bröckchen zu verteilen, die gerade benötigt werden.
   
   

2. DELPHI lernen (das ist nicht Pascal), also die Bedienung und verständige Handhabung eines professionellen Programmiersystems gegen das sich Turbo-Pascal wie ein Kinderspiel ausnahm. Erschwerend kommt hinzu, dass die proprietären  Delphi-Objekte (syntaktisch) anders zu programmieren sind, als in der klassischen OOP-Notation, die wiederum nicht Standard-Pascal ist. Hier kann man die Delphi-Benutzungsoberfläche selbst, die Komponenten (und den Orkus der Klassen darunter) einer objektorientierten Analyse unterziehen und das System als objektorientiert verstehen oder nur als Lieferant einer bestimmten Syntax, die nur richtig bedient werden will.
   
   

3. OOA- und OOD-Prinzipien im Ansatz kennen lernen.
   
   

4. ANWENDUNGSPROBLEME  analysieren (mit OOA, UML)  und in a + b + c umsetzen.

Und das alles gleichzeitig - wenn man einen vollständigen Ansatz wählt. Es entsteht die Frage, ob man diese Teile nicht besser losgelöst und z. B. nach einander im Unterricht behandelt sollte. Dazu gibt es sehr unterschiedliche Meinungen.

An drei Beispielen, die jeweils exemplarisch für einen anderen Ansatz stehen, soll gezeigt werden, wo die Möglichkeiten und Hürden im Einzelnen liegen, welche Konsequenzen sich aus unterschiedlichen Ansätzen ergeben und welche didaktisch-methodischen Entscheidungen erforderlich sind, das Ganze zu einem guten Ende zu bringen. Die drei Ansätze werden auf die oben genannten Ziele überprüft.
(Ein vierter Ansatz, der im Anfangsunterricht ausschließlich mit Delphi-Komponenten hantiert, wird wegen seiner Abwegigkeit nicht weiter behandelt.)

Die Beispiele beziehen sich auf den Anfangsunterricht (das 1. selbst erstellte Programm) im sog. "Kontext der Anwendung - Modellieren und Konstruieren" [vgl. 10]

Begriffsbestimmung

• Programmieren: Umsetzung einer Spezifikation im weitesten Sinne in eine Programmiersprache (Codierung)

• Visuelle Programmierung: Strukturierte Programmierung unter Zuhilfenahme eines GUI-Builder, keine Fachklassen

• OOP: Programmieren unter Zuhilfenahme (Benutzen) von Fachklassen/Objekten

• OOA-OOP: vollständige Software-Entwicklung mit Fachklassen, MVC

Werkzeug : Delphi V.

Typische OO-Notationen wie z. B. Lampe.Create, Lampe.Einschalten, Lampe.SetFarbe (Gelb) und andere Syntax, die OO Konstrukte erkennen lässt, sind fett gedruckt.

Beispiel 1: Programm ZahlRaten, "Visuelle Programmierung"

Spielalgorithmus wird erarbeitet und programmiert.

unit uFenster;
// Version     : 1.0 - Zahlenraten - "Visuelle Programmierung"

interface
// =======================================================================
uses
   Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
   StdCtrls, ExtCtrls;

type
  TFensterFrm = class(TForm)
    EingabeLbl    : TLabel;
    EingabeEdt    : TEdit;
    EndeBtn       : TButton;
    MeldePnl      : TPanel;
    HilfeBtn      : TButton;
    ZaehlerGrpBox : TGroupBox;
    ZaehlerLbl    : TLabel;

    procedure FormCreate(Sender: TObject);
    procedure EndeBtnClick(Sender: TObject);
    procedure Raten(Sender: TObject; var Key: Char);
    procedure HilfeBtnClick(Sender: TObject);

  private
    Geheimzahl : integer;
    Ratezahl   : integer;
    Zaehler    : integer;
    procedure Init;
  end;

var
 FensterFrm : TFensterFrm;

implementation
// =======================================================================
{$R *.DFM}

procedure TFensterFrm.FormCreate(Sender: TObject);
// -----------------------------------------------------------------------
begin
  Init;
end;

procedure TFensterFrm.Raten (Sender: TObject; var Key: Char);
// -----------------------------------------------------------------------
var antwort : integer;
begin
  if key = chr(13)
  then
   begin
    Ratezahl := strtoint(EingabeEdt.Text);
    Zaehler  := Zaehler + 1;
    ZaehlerLbl.Caption := inttostr(Zaehler);

    if Ratezahl = Geheimzahl
    then
     begin
     MeldePnl.Caption := (' Gratuliere! Richtig geraten! ');
     antwort := Application.Messagebox('Wollen Sie weiterspielen?',
                                        'Systemmeldung',MB_OKCANCEL);
     case antwort of
      IDOK     : Init;
      IDCANCEL : Close;
     end;
    end
  else
    if Ratezahl < Geheimzahl
    then MeldePnl.Caption := (' Ratezahl zu niedrig ... ')
    else MeldePnl.Caption := (' Ratezahl zu hoch ... ');
  end;
end;

procedure TFensterFrm.HilfeBtnClick(Sender: TObject);
// -----------------------------------------------------------------------
begin
  Showmessage('Eine Zahl von 1..100 mit möglichst wenigen Versuchen raten.'
                + #13 + 'Tip im Editfeld eingeben!');
end;

procedure TFensterFrm.EndeBtnClick(Sender: TObject);
// -----------------------------------------------------------------------
begin
  Close
end;

procedure TFensterFrm.Init;
// -----------------------------------------------------------------------
begin
  EingabeEdt.Text   := '';
  ZaehlerLbl.Caption:= inttostr(0);
  MeldePnl.Caption  := 'Neues Spiel - neues Glück';
  Ratezahl          := 0;
  Zaehler           := 0;
  randomize;
  Geheimzahl        := random(100)+1;
end;

END. // --------- Unit -------

FensterFrm und alle Komponenten sind zwar Objekte, aber die klassischen OO-Konstrukte sind in Delphi nicht sichtbar und für Anfänger erkennbar. Das gesamte Programm (in jeder beliebigen Länge) wird innerhalb des Fensterformulars implementiert. Diese Art zu programmieren hat mit Objektorientierung nichts zu tun.

Beispiel 2: Teilweise objektorientiert

Mit den Schülern wird eine OOA der Fachklassen und der benötigten GUI-Objekte durchgeführt. Die Fachklassen werden vom Lehrer codiert und den Schülern fertig mit der Spezifikation zur Benutzung gegeben. Die Schüler programmieren innerhalb des Fensterformulars und wenden die Klassen an.. Das Beispiel benutzt ein Paket von Grafikobjekten zur Darstellung eines Meteoriten, der über den Himmel zieht, dabei seine Farbe ändert und dann "explodiert".

unit uFenster;
// Aufgabe     : Darstellung eines Meteoriteneinschlages

interface
// ======================================================================
uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  StdCtrls, ExtCtrls,uGrafik, uZeit;

type
  TFensterFrm = class(TForm)
    BildImg     : TImage;
    SteuerPnl   : TPanel;
    StartBtn	: TButton;
    Ende        : TButton;

    procedure FormCreate(Sender: TObject);
    procedure StartBtnClick(Sender: TObject);
    procedure EndeClick(Sender: TObject);
   private
    procedure MeteorInit;
  end;

var
  FensterFrm   : TFensterFrm;
  Meteor       : TKreis;      // oder auch mehrere Exemplare!

implementation
{$R *.DFM}
// ======================================================================

procedure TFensterFrm.FormCreate(Sender: TObject);
// ----------------------------------------------------------------------
begin
  Zeichenblatt := TZeichenblatt.Create;    
  Zeichenblatt.SetLink (BildImg);
  Zeichenblatt.SetFuellFarbe(clBlue); 	   // der Himmel
  Zeichenblatt.Zeigen;
  Meteor := TKreis.Create;
end;

procedure TFensterFrm.StartBtnClick(Sender: TObject);
// ----------------------------------------------------------------------
var entfernung : integer;

begin
  MeteorInit;
  entfernung := 0;
  while (Meteor.GetXpos < Zeichenblatt.GetBreite) do
  begin
    Meteor.Zeigen;
    Zeit.SetPause(10);
    Meteor.Loeschen;
    Meteor.PosVersetzenUm(2,1);
    entfernung := entfernung + 2;

    if (Meteor.GetXpos > 50) and (entfernung < 255)
    then
      begin
        Meteor.SetFuellFarbe(RGB(200,entfernung,entfernung));
        Meteor.SetFarbe(RGB(200,100,100));
      end;
    if (Meteor.GetXpos > 350) and (Meteor.GetXpos < 400)
    then Meteor.SetRadius(Meteor.GetRadius + 10);
    if (Meteor.GetXpos > 400)
    then Meteor.SetRadius(2);
  end;
end;

procedure TFensterFrm.EndeClick(Sender: TObject);
// ----------------------------------------------------------------------
begin
  Close;
end;

procedure TFensterFrm.MeteorInit;
// ----------------------------------------------------------------------
begin
  Meteor.SetPos(-10,30);
  Meteor.SetRadius(5);
  Meteor.SetFarbe(clBlack);
  Meteor.SetFuellFarbe(clBlack);
end;

END. // --------- UNIT -----------------

An diesem Beispiel wird der Bruch in der Notation deutlich: Delphi-Objekte erfordern eine andere Art der Codierung als klassische Objekte der Fachklassen. Die Komponenten müssen nicht mit Create erzeugt  werden, Set- und Getmethoden sind unbekannt,  der Zugriff auf Attribute erfolgt über Zuweisungen statt mit Methoden. Insofern wird der Lernprozess durch Delphi massiv behindert.

Beispiel 3: OOA-OOP - Das gleiche Programm ZahlRaten

Die gesamte OOA für GUI und Fachklasse wird durchgeführt, Trennung von Benutzungsoberfläche und Fachkonzept (Spielklasse), die gesamte Implementierung machen die Schüler.

unit uFensterFrm;
// Aufgabe     : GUI fuer das Ratespiel Zahlenraten, 
                 1 Fachklasse (uRatespiel)

interface
// =======================================================================
uses
   Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
   StdCtrls, ExtCtrls, uRatespiel;

type
  TFensterFrm = class(TForm)
    EingabeLbl    : TLabel;
    EingabeEdt    : TEdit;
    EndeBtn       : TButton;
    MeldePnl      : TPanel;
    HilfeBtn      : TButton;
    ZaehlerGrpBox : TGroupBox;
    ZaehlerLbl    : TLabel;

    procedure FormCreate(Sender: TObject);
    procedure EndeBtnClick(Sender: TObject);
    procedure RatezahlAnnehmen(Sender: TObject; var Key: Char);
    procedure HilfeBtnClick(Sender: TObject);

  private
   procedure Init;
   procedure DatenAktualisieren;
   procedure FensterAktualisieren;
  end;

var
 FensterFrm : TFensterFrm;
 Ratespiel  : TRatespiel;  // hier wird das aktuelle Objekt deklariert

implementation
// =======================================================================
{$R *.DFM}
            

procedure TFensterFrm.FormCreate(Sender: TObject);
// -----------------------------------------------------------------------
begin
  Ratespiel := TRatespiel.Create;  // Objekt erzeugen
  Init;
end;

procedure TFensterFrm.EndeBtnClick(Sender: TObject);
// -----------------------------------------------------------------------
begin
  Close
end;

procedure TFensterFrm.RatezahlAnnehmen (Sender: TObject; var Key: Char);
// -----------------------------------------------------------------------
var antwort : integer;

begin
  if key = chr(13)
  then
   begin
    DatenAktualisieren;
    FensterAktualisieren;
  end;

  if Ratespiel.IstFertig
  then
   begin
     antwort := Application.Messagebox('Wollen Sie weiterspielen?',
                                        'Systemmeldung',MB_OKCANCEL);
     case antwort of
      IDOK     : Init;
      IDCANCEL : Close;
     end;
   end
end;
            

procedure TFensterFrm.HilfeBtnClick(Sender: TObject);
// -----------------------------------------------------------------------
begin
  Showmessage('Eine Zahl von 1..100 mit möglichst wenigen Versuchen raten.'
                + #13 + 'Tip im Editfeld eingeben!');
end;

procedure TFensterFrm.Init;
// -----------------------------------------------------------------------
begin
  Ratespiel.Init;
  EingabeEdt.Text := '';
  ZaehlerLbl.Caption := inttostr(0);
  MeldePnl.Caption := 'Neues Spiel - neues Glück';
end;

procedure TFensterFrm.DatenAktualisieren;
// -----------------------------------------------------------------------
begin
  Ratespiel.SetRatezahl(strToInt(EingabeEdt.Text));
  Ratespiel.ZaehlerErhoehen;
end;

procedure TFensterFrm.FensterAktualisieren;
// -----------------------------------------------------------------------
begin
  MeldePnl.Caption  := Ratespiel.GetStatusMeldung;
  ZaehlerLbl.Caption:= intToStr(RateSpiel.GetZaehler);
end;

END. // --------- Unit -------

Hier ist nur das FensterFrm dargestellt. Die Spielklasse ist typische OOP. Zur Notation gilt das oben gesagte. Hinzukommen die Methoden, die die Verbindung zwischen Fach- und GUI-Klasse herstellen. Das Anwendungsproblem wird ausschließlich in der Fachklasse abgearbeitet. Das Fenster dient nur als echtes GUI und codiert kein Probleme, die in die Fachklasse gehören.

Bei diesem Ansatz wird die volle Dosis verabreicht. Es braucht offensichtlich besondere Schüler und auch besondere Lehrer, um diesen Weg zu gehen. Das Beispiel selbst gibt inhaltlich zu wenig her als dass es über Wochen künstlich am Leben gehalten werden kann, um dabei die Bedienung von DELPHI, die Pascal-Sprachkonstrukte als auch wesentliche Grundlagen von Objektorientierung zu erarbeiten. In diesem Halbjahr hatte ich eine  überwiegend schwache Gruppe und bin deshalb mit diesem Ansatz zum ersten Mal trotz sorgfältiger Vorbereitung grandios gescheitert, weil die Schüler völlig überfordert waren..

Fasst man die Beispiele zusammen, so ergibt sich folgender Überblick über die Lernpotenziale.

Was daraus folgen könnte

• Ansatz 1 ist hervorragend geeignet, strukturierte Programmierung zu lernen und den "Pascalkurs" zu veranstalten, in dem das Wort OOP nie fallen wird.
  
  

• Ansatz 2 ist erprobt. Es lässt sich eine natürliche Sicht auf Objekte erarbeiten und er hat motivationale Aspekte. In NRW wird so etwas ähnliches mit "Stiften und Mäusen" versucht, leider als eine Art objektorientierte Fortsetzung des alten Turtle-Konzeptes. Die Lampen oder Ampeln dort haben einen Buntstift als Attribut oder Aggregation, was man nicht erwartet und ein falsches Bild von Modellierung vermittelt [10]. Unsere Ampeln kommen ohne Stifte und Mäuse aus. Der Vorteil liegt im Übungscharakter, der unmittelbaren optischen Überprüfbarkeit der Ergebnisse und im Umgang mit Schnittstellen.
  Des weiteren lassen sich hervorragend Kontrollstrukturen an bewegten Objekten einführen und üben.
  
  

• Ansatz 3 ist etwas unrealistisch (s.o.), weil zu ehrgeizig oder nur mit guten und sehr guten Schülern zu machen.
  
  

• Die Ansätze 1 - 3 stellen könnten so etwas wie ein kleines Curriculum darstellen und nach einander durchlaufen werden.
  Ob man Ansatz 1 als Vorspann zum Erlernen des Handwerkzeugs durchführen sollte, um dann auf OOP zu erweitern, ist fraglich und zweischneidig. Warum sollte man überhaupt noch umsteigen, wenn das alles so schön funktioniert und auch noch gut aussieht?
  
  

• Delphi ist das falsche Werkzeug? Neben den genannten Schwächen verbirgt Delphi große Teile des Codes. Das hat Vor- und Nachteile. In JAVA und PYTHON erscheinen die GUI-Komponenten im Quelltext und sind auch von Hand zu programmieren. Das erleichtert am Anfang das Verständnis, ist bei Fortschritten jedoch sehr lästig. Dann kann Delphi seine volle Stärke ausspielen. Die Ergebnisse von Softwareprojekten mit fortgeschrittenen Schülern zeigen das.
  
  

• Nach dem fertigen OOA/OOD-Modell wird das Programm mit einem Code-Generator erzeugt?
  Das kann eine Erleichterung bei den Standard-Methoden sein, darf aber aus guten Gründen das Programmieren nicht überflüssig machen. Modellierungstechniken als Kern eines Informatikunterrichts kann auch nicht bedeuten, z. B. den gesamten UML-Umfang abzuarbeiten und sich den Teufel um die Codierung zu kümmern.
  
  

• Was hier für Delphi untersucht wurde, dürfte ähnlich für andere Programmiersprachen und Umgebungen in mehr oder weniger verschärfter Form auch zutreffen.

Was daraus sicher folgt oder Bestand hat

• Ein objektorientierter Einstieg im Anfangsunterricht ist immer noch die erste Wahl.

• OOA ist im Hinblick auf Modellierung im Informatikunterricht das gebotene Verfahren.

• Auf die Realisierung des beschriebenen Modells kann nicht verzichtet werden.

• Syntax und Semantik der Programmiersprache müssen so eng wie möglich das gefundene Modell ausdrücken können. Leicht verständlich formulierte Modelle dürfen nicht durch komplizierte oder kryptische Syntax vernebelt werden.

• Es ist jedoch ein sehr präzise geplantes methodisches Vorgehen mit vorausschauenden Bögen erforderlich, um auch durchschnittlichen Schülern Erfolgserlebnisse zu geben.

Literatur

[1] Eberle, F.: Didaktik der Informatik bzw. einer informations- und kommunikationstechnischen Bildung
      auf der Sekundarstufe II, Aarau, 1996.
[2] Füller, K.: Objektorientiertes Programmieren in der Schulpraxis,
     http://www.he.schule.de/~klausf/Infos99/Objektorientierung/
[3] Hubwieser, P.: Didaktik der Informatik. Berlin, Heidelberg, 2000.
[4] Penon, J. u. Spolwig, S: Schöne visuelle Welt? Objektorientierte Programmierung mit DELPHI und JAVA.
     IN: LOG IN, 18 (1998) Heft 5
[5] Schwill, A.: Programmierstile im Anfangsunterricht.
      http://didaktik.cs.uni-potsdam.de/didaktik/Forschung/INFOS95.pdf
[6] Spolwig, S.: Objektorientierung im Informatikunterricht.  Ferd. Dümmlers Verlag, Bonn 1997.
[7] Spolwig, S.: "Web-gestützte Softwareprojekte" (Teil1) IN: LOG IN, 20 (2000) Heft 6:
[8] Spolwig, S.: Objektbasierte Programmierung im Anfangsunterricht. IN: LOG IN, 15 (1995) Heft 3
[9] Spolwig, S: PAT 95. Dateiverwaltung in objektbasiertem Software Design. Landesbildstelle Berlin, 1995.
[10] MSWWF: Sekundarstufe II, Gymnasium/Gesamtschule, Richtlinien und Lehrpläne, Aufgabenbeispiele,
     Informatik, 1999.