"Von Stiften und Mäusen" oder Was heißt objektorientierte Modellierung?

- Eine kritische Betrachtung -
von
Siegfried Spolwig

1.  Einleitung

Das Unterrichtskonzept "Von Stiften und Mäusen" (SuM) [vgl.1] erschien vor ca. 10 Jahren. Die Autoren haben sich ein großes Verdienst um die Einführung der Objektorientierung in den Informatikunterricht erworben und es gebührt Ihnen die Ehre, unter den ersten gewesen zu sein, die ein schülergerechtes objektorientiertes Unterrichtskonzept entwickelt haben, das sich bis heute einer erstaunlichen Lebendigkeit und zunehmender Verbreitung erfreut. Es wird inzwischen in Rahmenlehrplänen genannt, von Bildungsservern empfohlen, in vielen Schulen und Lehrerfortbildungen eingesetzt.

Mittlerweile ist SuM nahezu in alle schulrelevanten Sprache portiert, zuletzt nach Delphi und Python. Es muss also gut sein, obwohl der Ansatz schon ein wenig angejahrt erscheint und es heute eine Reihe von didaktisch reduzierten Tools (z. B. BlueJ, Fujaba & Mr. Dobs, UMLed/Delphi) gibt, die dem Stand der Technik entsprechen.

Erstaunlicherweise findet man praktisch nirgends ein Wort der Kritik. Das zumindest erscheint verdächtig. Es stellt sich die Frage, ob SuM immer noch geeignet ist, die Ziele eines zeitgemäßen Informatikunterrichts, der Modellierung und geeignete Modellierungstechniken in den Mittelpunkt stellt, zu erreichen.

SuM war zunächst für den Anfangsunterricht entwickelt worden; fleißige Programmierer haben inzwischen Programme und Klassen vorgestellt, die dieses Niveau weit hinter sich lassen und damit den Anspruch demonstrieren, mit SuM könne man viel mehr machen. Hier wird soll der 'SuM-Kern' und seine Eignung für den Einführungsunterricht in die objektorientierten Programmierung untersucht werden.

2.  Das informatische Konzept

Der Kern von SuM ist eine sprachenunabhängige Klassenbibliothek (Bildschirm, Maus, Tastatur, Stift, Anwendung), die einen PC beschreibt [2]. Die Dokumentation verbirgt die Attribute der Objekte und stellt sich wie ein abstrakter Datentyp dar, der nur Funktionen anbietet. Die Klassen sind erweiterbar. Mit diesem Angebot lassen sich nur Aufgaben bestimmter Problemklassen lösen (Persistenz z. B. ist nicht vorgesehen). Des Weiteren ist impliziert, dass sich die erzeugten Objekte selbst auf dem Bildschirm darstellen (i. d. R. mit einem Attribut Stift gezeichnet werden).
Diese Entwurfsentscheidung hat zur Folge, dass neuere Konzepte, die die Trennung von Daten und ihrer Repräsentation vorsehen (z. B. MVC), nicht möglich sind.

Modellierung ist seit einiger Zeit das neue Zauberwort der Informatik-Didaktik. Professorale Arbeiten und kluge Dissertationen haben es eben auch nicht eben leichter und klarer für den amtierenden Lehrer gemacht. Die objektorientierte Programmierung ist angetreten mit dem Anspruch und Versprechen, Objekte und Ausschnitte der Realwelt so abzubilden wie sie sind. Jedes Analyseobjekt hat seine Entsprechung in der natürlichen realen Welt und übernimmt dessen Identität im Modell. Meyer, einer der Väter der Objektorientierung, hat es so formuliert:

"Deshalb verbringen objektorientierte Entwerfer normalerweise ihre Zeit nicht mit akademischen Diskussionen darüber, wie Objekte zu finden sind: In der physikalischen und abstrakten Wirklichkeit sind die Objekte modelliert und warten nur darauf, aufgelesen zu werden." [3]

Diesem Anspruch genügt SuM in der jetzt vorliegenden Entwicklung und einer verbreiteten Praxis nicht.
 

3.  Didaktische Analyse

Das Konzept folgt zunächst richtigen Überlegungen.

"Die Bereitstellung einer sehr kleinen, aber dennoch schon recht leistungsfähigen Bibliothek fertiger Klassen, ist ein wesentliches Prinzip des hier vorgestellten didaktischen Konzepts. Und auch deren Überschaubarkeit ist für den Anfangsunterricht äußerst wichtig.
Einerseits wird dadurch die Verwendung fertiger Bausteine auf der Grundlage einer Dokumentation geübt, andererseits wird frühzeitig die eigene Erweiterung einer bestehenden Klassenbibliothek angeregt." [4]
 

3.1  SuM als Turtle

Die Unterrichtssequenz SuM beginnt mit dem übenden Gebrauch von gegebenen Objekten. Ein typisches erstes Programm (Klasse) zeigt ein "Haus vom Nikolaus" [5] :

public class Nikolaus1

/* verwendete Objekte */
private Bildschirm meinBildschirm;
private Stift meinStift;

public void fuehreAus()
{
/* Aufbau der Objekte */

  meinBildschirm=new Bildschirm();
  meinStift=new Stift();

/* Nachrichtenteil */
  meinStift.bewegeBis(100,100);
  meinStift.runter();
  meinStift.bewegeBis(140,100);
  meinStift.bewegeBis(100,60);
  meinStift.dreheBis(60);
  meinStift.bewegeUm(40);
  meinStift.dreheUm(-120);
  meinStift.bewegeUm(40);
  meinStift.bewegeBis(100,60);
  meinStift.bewegeBis(100,100);
  meinStift.bewegeBis(140,60);
  meinStift.bewegeBis(140,100);

/* Abbau der Objekte */
  meinStift.gibFrei();
  //meinBildschirm.gibFrei();
}
}

Bereits hier sieht man, dass es sich nicht um die Abbildung eines Objekts ‚Haus’ handelt, sondern um eine Strichzeichnung, die der Stift auf den Bildschirm schreibt, quasi ein anweisungsgesteuertes Malprogramm. Es werden zwar die Objekte Bildschirm und Stift benutzt, jedoch hat das Produkt abgesehen von der OO-Notation mit Objektorientierung noch nicht viel zu tun. Das ging mit LOGO und Turtle im Prinzip genauso. Diese und ähnliche Beispiele können gut zum Lernen von Sequenzen und Kontrollstrukturen dienen. Ein weiterer positiver Aspekt ist die Visualisierung der Ergebnisse, die dem Schüler die unmittelbare Überprüfbarkeit seiner Arbeit gewährleistet.

3.2  Entwicklung und Erweiterung eigener Klassen

Das Konzept sieht aus nahe liegenden Gründen Entwicklung und Erweiterung eigener Klassen vor:

"Die zwar griffige Bezeichnung »Stifte und Mäuse« für die hier vorgestellte Konzeption wird bei oberflächlicher Betrachtung häufig missverstanden. So gibt es immer wieder Betrachter, die glauben mit diesem Konzept gehe die Reduktion auf eine Verwendung der vier Basisklassen einher.
Das ist falsch!
Vielmehr gehört die Erweiterung zu einer kurseigenen Klassenbibliothek wesentlich zum didaktischen Konzept." [4].

Leider beginnt hier die Krux. Der Zwang, wegen der Darstellung und eventuell anderer Manipulationen auf die Kern-Klassen zurückzugreifen, schafft Objekte und Klassen von eigenartiger Konsistenz. Einige Beispiele mögen das verdeutlichen.

Beispiel 1: Billardkugel

Es soll eine Billardkugel auf dem Bildschirm simuliert werden, die an der Bande zurückprallt.
 

In einer konsequent objektorientierten Umsetzung würde man unter SuM eine Klasse mit diesen Attributen und ähnlichen Methoden erwarten. Weit gefehlt!

In der SuM-Implementierung findet man

unit mKugel;
interface
uses mSuM;

type Kugel = class
       hatStift: Stift;            // die Kugel hat einen Stift, um sich zu zeichnen
       kenntBildschirm: Bildschirm;//die Kugel kennt einen  Bildschirm als Begrenzung
                                  
       zRadius : GanzeZahl;
       constructor init(pAnfangH, pAnfangV: GanzeZahl; pGeschwindigkeit: Zahl;
                                                                   pRichtung: Zahl);
       procedure   Zeichne;
       procedure   Loesche;
       procedure   Bewege;
       function    hPosition: Zahl;
       function    vPosition: Zahl;
       function    Richtung: Zahl;
       procedure   setzeRichtung(pWinkel: Zahl);
       procedure   merke(pBildschirm: Bildschirm);
       destructor  gibFrei;
     end; 
     ... [6]

Eine Billardkugel hat in der Realität natürlich keine Eigenschaften Stift und Bildschirm. Aus der Klassendeklaration geht auch nicht hervor, auf welche Attribute die Funktionen hPosition, vPosition und  Richtung zugreifen.
Das ist einfach schlecht modelliert und implementiert.

Ein ähnlicher Entwurf [6a] aggregiert ebenfalls einen Buntstift und Bildschirm als Attribute:

Beispiel 2: Ampel

Über Ampeln lässt sich trefflich streiten, denn Abstraktion ist immer  ein zielgerichteter Prozeß unter dem Blickwinkel auf einen bestimmten Zweck. Deshalb gibt es auch Ampelprogramme wie Sand am Meer. Ein Elektroniker, der eine Steuerung entwickelt, würde vermutlich eine Ampel als abstrakte Einheit sehen, deren Merkmale lediglich Zustände sind und zu einer Fachklasse kommen, die keinerlei Bezüge zur physischen Realisation  enthält. Hier soll es jedoch nur um die Art Ampeln gehen, die gern im Anfangsunterricht programmiert werden und auf dem Bildschirm zu sehen sind, aber auch richtig funktionieren.

Es ist allgemein bekannt, wie eine Ampel aussieht und im Prinzip aufgebaut ist: ein dunkelgrauer Kasten mit drei Lampen drin, die abwechselnd an und ausgehen.

Das lässt sich mit geeigneten Mitteln und diesen verständlichen Bezeichnern leicht realisieren, wohl nicht unter SuM.

Zum Vergleich ein SuM-Klassendiagramm (aus dem nebenstehenden Quelltext gezeichnet):

Spätestens hier wird das Dilemma mit SuM in voller Schärfe sichtbar: Eine ordentliche Modellierung scheint nicht möglich, weil das Ausgangskonzeptes offensichtlich zu solchen Lösungen auffordert und die Sicht auf andere verstellt. Diese Ampel hat anstelle von drei Lampen, die man ein- und ausschalten kann, also als Objekte ansprechen kann, eine Tastatur und einen Buntstift, der etwas auf den Bildschirm malt.

Dieses Beispiel ist nicht etwa ein ausgesucht schlechtes, sondern es steht exemplarisch für den Charakter der SuM-Objekte, wie sie in den Schulen gebaut werden. 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.
In dem verbreiteten Zug-Projekt werden von einer Oberklasse Waggon (mit der SuM-typischen Struktur) die Unterklassen Lok, Güterwagen usw. abgeleitet. 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.

SuM bewirkt auf dieser Ebene durch die Restriktionen, dass jedes Objekt prinzipiell Attribute aus der Kern-Bibliothek haben muss, ein eigenartiges Abbild der gefundenen Objekte. Überspitz könnte man auch sagen, wer als einziges Werkzeug einen Stift hat, für den besteht die ganze Welt aus Strichen. 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.

Es steht heute nichts mehr dem im Wege, auch in der Schule ein objektorientiertes Konzept aus einem  Guss in den Unterricht zu bringen. Das heißt, eine saubere OOA, die notwendigen softwaretechnischen Erweiterungen in OOD durch Hinzufügen erforderlicher Objekte und Klassen und am Ende zur Realisierung eine objektorientierte Sprache, die es erlaubt, das gefundene Modell 1:1 auszudrücken.

Zusammengefasst kann man feststellen dass das SuM-Konzept zwar alle wichtigen Merkmale von OOP darstellen, aber lediglich die objektorientierte Programmiertechnik aufzeigen kann, jedoch OOA und OOD im Anfangsunterricht nicht richtig unterstützt und so nicht empfohlen werden kann.

Es sollte nicht die prägende Kraft des ersten Eindrucks bei Schülern und Lehrern unterschätzt werden. Daher scheint es bedenklich, wenn ganzen Generationen von Lehrern SuM als erster Kontakt zu OOP in dieser Weise beigebracht wird. Otto Normallehrer wird mit hoher Wahrscheinlichkeit es nicht als Anstoß verstehen, andere Konzepte zu erarbeiten, sondern dabei bleiben, zumal es ja so schöne Vorlagen und Materialien gibt. Die Zählebigkeit von SuM und das daraus entstandene Eigenleben scheinen diese Vermutung zu bestätigen. Es dient eben inzwischen nicht mehr nur dem Einführungsunterricht, sondern als Basis-Tool für fast alles, was man so in der Schule programmieren kann. Die Liste der SuM-Derivate für die Klassenstufen 11-13 reicht von 'Abzählreim' bis 'Zahlsuche-Backtracking'. [8]
 

4.  uGrafik - eine Alternative

Viele Betriebssysteme und Programmierumgebungen bieten eine Grafikebene (meist Canvas genannt) an, die Methoden zum Zeichnen von Linien, Rechtecken usw. hat. Um die oben geschilderten Probleme zu umgehen und durchgängig objektorientiert zu arbeiten, wurde am OSZ Handel, Berlin, einer Anregung Monika Seifferts folgend, eine Grafikbibliothek entwickelt, die entsprechende Klassen enthält[9].

Es liegen Portierungen in Delphi, Java, Python vor, die in einigen Schulen eingesetzt werden. Die Klassen sind erweiterbar. Weitere Klassen wie Listen kamen hinzu. Die Objekte stellen sich selbst auf dem Bildschirm dar und haben alle nötigen Attribute und Methoden. Sie können mit der Maus angeklickt und verschoben werden. Kapselung und Geheimnisprinzip sind eingehalten.

Das Paket kann zum gleichen didaktischen Ansatz im Anfangsunterricht verwendet werden wie SuM, nämlich

- Kennen lernen der Programmierumgebung,
- objektorientierte Denkweise und Notation,
- zum Benutzen von fertigen Klassen
- bei  der Entwicklung eigener Klassen.

Mit einem entscheidenden Unterschied: Die Schüler arbeiten vom ersten Tage an durchgängig mit Objekten, die erzeugt und manipuliert werden. Unterrichtssequenzen sind verfügbar[10].

4.1  Billardkugel und Ampel unter uGrafik

Zum Vergleich mit SuM die Billard- und Ampelklassen mit uGrafik:

Beispiel 1: Billard (s.o.)

UNIT uKugel ;
INTERFACE
(* ==================================================================== *)
USES uGrafik;
    
  type
   TKugel = class (TKreis)
              XRichtung,
              YRichtung : integer;
              procedure SetLink(Tisch : TZeichenblatt);
              procedure SetXRichtung (xR : integer);
              procedure SetYRichtung (yR : integer);
              procedure PosVersetzen;
              procedure BandePruefen;
              procedure Bewegen;
            end;
...

TKugel ist eine Unterklasse von TKreis, welcher Radius, Farbe, Position und die dazugehörigen Zugriffsmethoden vererbt, sowie Methoden zum Darstellen/Löschen auf dem Bildschirm.

Im FensterFormular wird das Billard gesteuert und dargestellt. Das Programm (Ausschnitt) erklärt sich selbst.

Beispiel 2: Ampeln

Zur Demonstration der Programmierung mit uGrafik sei hier das gesamte Programm abgedruckt.

UNIT uLampe;
(* ******************************************************************** *)
(* K L A S S E : TLampe                                                 *)
(* -------------------------------------------------------------------- *)
(* Version     : 0.9                                                    *)
(* Autor       : S. Spolwig, OSZ Handel                                 *)
(* Beschreibung: Die Klasse bildet eine Lampe für beliebige Anwendungen *)
(*               ab.                                           		*)
(* Compiler    : Delphi 5.0                                             *)
(* Aenderungen : 0.9	11-MAY-01                                       *)
(* ******************************************************************** *)

INTERFACE
// ======================================================================
uses uGrafik;

type
  TLampe   = class(TKreis)
   public
    constructor Create; 
    procedure Ein;
    procedure Aus;
  end;

IMPLEMENTATION
// ======================================================================

constructor TLampe.Create;
// --------------------------------------------------------------------
begin
  inherited Create;
  SetRadius(12);
end;

procedure TLampe.Ein;
// --------------------------------------------------------------------
begin
  Zeigen;
end;

procedure TLampe.Aus;
// --------------------------------------------------------------------
begin
  Loeschen;
end;

END.

UNIT uAmpel;
(* ******************************************************************** *)
(* K L A S S E : TAmpel                                                 *)
(* -------------------------------------------------------------------- *)
(* Version     : 0.9                                                    *)
(* Autor       : S. Spolwig, OSZ Handel                                 *)
(* Beschreibung: Die Klasse bildet eine dumme Ampel mit diskreten       *)
(*               Lampen ab.					        *)
(* Compiler    : Delphi 5.0                                             *)
(* Aenderungen : 0.9	11-MAY-01                                       *)
(* ******************************************************************** *)

INTERFACE
// ======================================================================
uses uGrafik, graphics, uLampe;

type
  TAmpel = class(TObject)
   private
    Kasten : TRechteck;
    RoteLampe,
    GelbeLampe,
    GrueneLampe : TLampe;
    XPosition,
    YPosition : integer;      // wo sie steht
   public
    constructor Create;       // herstellen
    procedure RotSchalten;
    procedure GelbSchalten;
    procedure GruenSchalten;

    procedure SetPosition(xp, yp: integer);
    procedure Zeigen;
    procedure Abschalten;
  end;

IMPLEMENTATION
// ======================================================================

constructor TAmpel.Create;
// --------------------------------------------------------------------
begin
  inherited create;
  Kasten := TRechteck.Create;
  Kasten.SetFuellFarbe(clGray);

  RoteLampe   := TLampe.Create;
  GelbeLampe  := TLampe.Create;
  GrueneLampe := TLampe.Create;

  RoteLampe.SetFuellFarbe(clRed);
  GelbeLampe.SetFuellFarbe(clYellow);
  GrueneLampe.SetFuellFarbe(clLime);
end;

procedure TAmpel.RotSchalten;
// --------------------------------------------------------------------
begin
   RoteLampe.Ein;
   GelbeLampe.Aus;
   GrueneLampe.Aus
end;

procedure TAmpel.GelbSchalten;
// --------------------------------------------------------------------
begin
  RoteLampe.Aus;
  GelbeLampe.Ein;
  GrueneLampe.Aus;
end;

procedure TAmpel.GruenSchalten;
// --------------------------------------------------------------------
begin
  RoteLampe.Aus;
  GelbeLampe.Aus;
  GrueneLampe.Ein;
end;

procedure TAmpel.Zeigen;
// --------------------------------------------------------------------
begin
  Kasten.Zeigen;
  RoteLampe.Zeigen;
  GelbeLampe.Zeigen;
  GrueneLampe.Zeigen;
end;

procedure TAmpel.Abschalten;
// --------------------------------------------------------------------
begin
  RoteLampe.Aus;
  GelbeLampe.Aus;
  GrueneLampe.Aus;
end;

procedure TAmpel.SetPosition(xp, yp: integer);
// --------------------------------------------------------------------
begin
  XPosition := xp;
  YPosition := yp;
  Kasten.SetPos(XPosition,YPosition,XPosition + 30,YPosition + 80);
  RoteLampe.SetPos((XPosition + 15 ),(YPosition + 15));
  GelbeLampe.SetPos((XPosition + 15 ),(YPosition + 40));
  GrueneLampe.SetPos((XPosition + 15 ),(YPosition + 65));
end;

END.

unit uFenster;
(* ******************************************************************** *)
(* K L A S S E : 							*)
(* -------------------------------------------------------------------- *)
(* Version     : 2.0                                                    *)
(* Autor       : S. Spolwig,                                            *)
(* Beschreibung: Die Klasse steuert die Anzeige zweier dummer Ampeln im *)
(*               Wechsel an einer Baustelle.                            *)
(* Zweck       : Algorithmen üben bis der Doktor kommt ...              *)
(* Compiler    : Delphi 5.0                                             *)
(* Aenderungen : 0.9	11-MAY-01                                       *)
(* ******************************************************************** *)
INTERFACE
// ======================================================================

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  StdCtrls, ExtCtrls,
  uGrafik, uZeit, uAmpel;

type
  TFensterFrm = class(TForm)
    SteuerPnl     : TPanel;
    EndeBtn	  : TButton;
    BildImg	  : TImage;
    TestBtn       : TButton;
    AbschaltenBtn : TButton;

    procedure FormCreate(Sender: TObject);
    procedure TestBtnClick(Sender: TObject);
    procedure AbschaltenBtnClick(Sender: TObject);
    procedure EndeBtnClick(Sender: TObject);
  end;

var
  FensterFrm    : TFensterFrm;
  Ampel_1,
  Ampel_2       : TAmpel;
 
IMPLEMENTATION
{$R *.DFM}
// ======================================================================
var  Zeichenblatt  : TZeichenblatt;

procedure TFensterFrm.FormCreate(Sender: TObject);
begin
  Zeichenblatt := TZeichenblatt.Create;
  Zeichenblatt.SetLink(BildImg);
  Ampel_1 := TAmpel.Create;
  Ampel_2 := TAmpel.Create;
  Ampel_1.SetPosition(100,100);
  Ampel_2.SetPosition(300,100);
  Ampel_1.Zeigen;
  Ampel_2.Zeigen;
end;

procedure TFensterFrm.TestBtnClick(Sender: TObject);
// --------------------------------------------------------------------
begin
  Ampel_1.Zeigen;
  Ampel_2.Zeigen;
  Ampel_1.RotSchalten;
  Ampel_2.GruenSchalten;
  Zeit.SetPause(1000);
  Ampel_1.GelbSchalten;
  Ampel_2.Gelbschalten;
  Zeit.SetPause(1000);
  Ampel_1.GruenSchalten;
  Ampel_2.RotSchalten;
end;

procedure TFensterFrm.AbschaltenBtnClick(Sender: TObject);
// --------------------------------------------------------------------
begin
  Ampel_1.Abschalten;
  Ampel_2.Abschalten;
end;

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

end.

An diesen einfachen Beispielen wird deutlich, dass der Schwerpunkt des Unterrichts auf Modellierung und Konfigurieren liegt, während die Zeit fressende Fummelarbeit der Grafikprogrammierung auf der niedrigen Ebene entfällt. Durch eine sorgfältige Analyse erreicht man eine hohe semantische Klarheit der Klassen und ihrer Hierarchie und daraus folgend i. d. R. eine überraschend einfache Implementierung. Anders ausgedrückt ist eine saubere OOA das sichere Halteseil beim Gang durch die nach oben offene Richter-Skala der Komplexität.

4.2  Ein Stift unter uGrafik

Wenn man einmal wirklich einen Stift zum Zeichnen brauchte, ist der sehr leicht unter uGrafik zu realisieren:

Das ist alles. Der Stift erbt alles von TLinie und bekommt nur der der schönen Bezeichner wegen eine (eigentlich überflüssige) Methode 'StrichZiehen'.

4.3  Fachklassen mit Animation

Darüber hinaus können die Grafikobjekte auch zur Darstellung und Simulation von Anwendungen eingesetzt werden, die ein ordentliches Fachkonzept aufweisen, z. B. Geld, Noten, Münzen in einem Geldwechselautomaten, sofern sich die Objekte selbst auf dem Bildschirm darstellen sollen. Ansonsten ist die Trennung von Daten und ihrer Repräsentation zu präferieren.

Animierter Geldwechselautomat

type
  TMuenze = class (TBargeld)
   protected
    Form     : TKreis;
    Radius   : integer;
    Praegung : TText;
    Farbe    : TColor; (* clYellow, Clwhite *)

   public
    constructor Create; override;
    function IstEcht : boolean; override;
    ...
end;

Aus der Oberklasse TBargeld erbt TMuenze das Attribut Wert mit den dazugehörigen Zugriffsmethoden.
TMuenze ist Oberklasse für Mark, Groschen, Pfennig usw., die Methoden sind polymorph. Daneben hat eine Münze die natürlichen Attribute Form und Prägung zur Darstellung, wobei es schon ein erheblicher Unterschied ist, ob sie als solche konkretisiert sind oder stattdessen eine technisch erzwungene Kombination Stift/Bildschirm auftaucht.

Beispiele zur objektorientierten Modellierung mit/ohne uGrafik stehen stehen unter
http://www.oszhandel.de/gymnasium/faecher/informatik/modellierung/uml.htm

___________________

Literatur und Links

[1]   Ludger Humbert: Objektorientierung im Informatikunterricht der Sekundarstufe II
       http://region.Hagen.de/OOP/welcome.html
[2]   http://www.learn-line.nrw.de/angebote/oop/medio/sum/kern/index.html
[3]   B. Meyer: Objektorientierte Softwareentwicklung. München Wien London, 1990.
[4]   http://www.learn-line.nrw.de/angebote/oop/medio/didaktik/bibliothek/index.html
[5]   G. Dick: Stifte und Mäuse mit JAVA
       http://www.avg-wesel.de/fb/inf/lfb/sumjava/kap5/erstesprogramm.htm
[6]   Hannah-Arendt-Gymnasium : Doku Info Lk 12
       http://www.kubitz-online.de/oop/uebersicht.html
[6a] http://www.krumwiede.de/Informatik/SumJava/start.html
[7]   Hannah-Arendt-Gymnasium : Doku Info Lk 12
[8]   http://www.mg-werl.de/faecher/Informatik/Java/index.html
[9]   Siegfried Spolwig: 'Hello World' in OOP. IN: LOG IN 19 (1999) Heft 5.
[10] Unterrichtssequenzen mit uGrafik.
       http://www.oszhandel.de/gymnasium/faecher/informatik/u-sequenzen/index.htm