Aus : Schubert / Schwill, 2004, S. 212 - 216

 

7.2 Entwicklung und Bedeutung

 

Der Begriff "objektorientierte Programmierung (OOP)" wird in verschiedenen Bedeutung verwendet. Das führt zu ähnlichen Missverständnissen, wie sie vom Prinzip der strukturierten Programmierung ausgingen (Schubert, 1991). Wenn man den Prozess des OOM unterteilt in:

 

      objektorientierte Analyse (OOA),

      objektorientierter Entwurf (OOE),

      objektorientierte Programmierung (OOP),

 

dann meint man die Programmierung im engeren Sinne, also die Übertragung des Entwurfes in die Programmiersprache (auch Kodierung genannt). In der Fachwis­senschaft Informatik ist es üblich, mit Programmierung den gesamten Problemlösungsprozess (Analyse, Entwurf und Programmierung (Kodierung)) zu bezeichnen. In der Lehrdisziplin Informatik setzt sich zunehmend der Begriff informatische Modellierung für den fachspezifischen Problemlösungsprozess als Ganzes durch. Wir bezeichnen deshalb das Prinzip der objektorientierten Programmierung mit OOM. In den Zitaten wird OOP in diesem Sinne verwendet. Zur Bedeutung der OOM wird die Sichtweise aus dem Schülerduden Informatik übernommen:

 

"Daher lässt sich die objektorientierte Programmierung zusammen mit der strukturierten Pro­grammierung, als deren Fortsetzung sie aufgefasst werden kann, eher in die Klasse der Software-Entwicklungsmethoden als in die Klasse der programmiersprachlichen Denkschemata einordnen" (Claus/Schwill, 1997, S. 382).

 

"Programmiersprachliches Denkschema" wird im Folgenden kurz Paradigma ge­nannt. Man unterscheidet das prozedurale und deklarative (fasst funktional und prädikativ zusammen) Paradigma. In der Informatik werden nach wie vor alle Paradigmen angewendet. Für jede Aufgabenklassse steht ein spezielles Paradigma im Vordergrund.

 

"Es gibt Problemstellungen, deren Umsetzung geradezu nach objektorientierter Programmierung verlangen, z.B. im Bereich der Simulation oder bei der Entwicklung graphischer Benutzeroberflä­chen, und andere, bei denen das nicht der Fall ist. Insofern kann tatsächlich der Fall eintreten, dass objektorientierter Entwurf und Programmierung das Problem nicht löst und daher nicht 'funktio­niert'" (Claussen, 1993, S. 2-3).

 

Es besteht keine Notwendigkeit, erfolgreiche prozedurale und deklarative Informa­tiklösungen objektorientiert nachzubauen. Die Informatik besitzt eine lange Tradi­tion im Entwickeln effizienter Algorithmen. Diese Erfahrungen dürfen in der informatischen Bildung nicht fehlen. OOM sollte also dort einsetzen, wo bessere Lösungen damit erzeugt werden können.

 

OOM stützt sich heute ebenso wie das Prinzip der strukturierten Programmie­rung auf das prozedurale Paradigma, denn Operationen werden auf diese Weise realisiert. Das mag eine Zwischenstufe der Entwicklung sein, die noch überwunden wird. Es zeigt uns aber zwei wichtige Konsequenzen. Erstens ist OOM keineswegs so homogen in der Denkweise, wie behauptet wird. Zweitens gehört zur informatischen Bildung das Verständnis dafür, dass das informatische Modellieren

 

"... eine geschichtliche Entwicklung durchlaufen hat und sich noch immer weiterentwickelt. ... Die Richtung, in der die geschichtliche Entwicklung abgelaufen ist, war sicher kein Zufall" (Böszörmenyi, 2001, S. 15).

 

Für die Schüler ist es also außerordentlich wichtig, verschiedene Problemlösungs­ansätze der Informatik kennen und vergleichen zu lernen. So kann z.B. das de­klarative Paradigma mit der Software-Entwicklungsmethode des strukturierten Wachstums verbunden werden. Die Schüler erkennen, dass die Transparenz um­fangreicher Wissensbasen (aus Fakten und Regeln) bzw. komplizierter Funktio­nengeflechte unterstützt werden muss. Trace-Mechanismen und Erklärungskom­ponenten veranschaulichen die Ableitungspfade. Wir empfehlen, zwei Paradigmen im Informatikunterricht vorzustellen. Bisher liegen gute Erfahrungen zur gestaffel­ten Einführung in das prozedurale (als erstes) und prädikative (als zweites) Para­digma unter Bedingungen eines Zentralabiturs vor. Für andere Kombinationen fehlt bisher die vergleichbare Lernerfolgskontrolle. Beide Paradigmen können unterschiedlich tief angeeignet werden. Das Bildungsziel eines Sichtenwechsels steht im Vordergrund, nicht die Lösung komplexer Konstruktionsaufgaben.

Abstraktion spielt in der Fachwissenschaft eine andere Rolle als in der Lehrdis­ziplin Informatik. Im Fach vereinfacht Abstraktion die Entwicklungsprozesse von Hard- und Software. Sie muss nur einmal richtig verstanden werden. Dieses Ver­ständnis hat die Lehrdisziplin zu fördern. Gerade dabei zeigen sich große Schwie­rigkeiten. Deshalb muss der Aneignungsprozess mit sehr anschaulichen Einzelbei­spielen beginnen. Die Anforderungen an die Abstraktion dürfen nur schrittweise erhöht werden. Genau so ist auch die historische Entwicklung in der Informatik verlaufen. Ein Grund mehr, den historischen Lernansatz zu verfolgen.

Die These von der Weiterentwicklung der strukturierten Programmierung wird für die Schüler verständlich, wenn man die Vorstufen der OOM näher betrachtet. Ihre Thematisierung im Informatikunterricht entspricht einer Linie mit steigender Abstraktion und beantwortet die Frage zum Entwicklungsstand der Informatik. Zur Komplexitätsbewältigung und der damit verbundenen Fehlerreduzierung wurde die funktionale Abstraktion als Grundkonzept zur Beschreibung benutzerdefinierter Operationen entwickelt. Die Schüler lernen die Möglichkeit zur Konstruktion wieder verwendbarer Lösungsbausteine im prozeduralen Paradigma in Form von Pro­zeduren und Funktionen kennen. Bei der Anwendung treten häufig Probleme im Verständnis des Parameterkonzeptes auf. Die Entscheidung für Wert- und Refe­renzparameter erfordert ausreichendes Wissen um die damit verbundenen Konse­quenzen. Als Lernhilfe wurde z.B. das Modell eines Hauses mit verschiedenen Räumen vorgestellt, an deren Türschildern man die aktuellen Parameterbelegungen ablesen kann, die jeweils im Rauminneren erzeugt wurden. Das erwies sich bei Referenzparametern eher als Hürde im Lernprozess.

 

Da Kapselung ein wichtiges Prinzip der Informatik ist, lohnt es, den Entwick­lungsweg transparent zu machen und die Etappen zu beurteilen:

 

1.    Etappe:  Subroutinen konnten Befehlsfolgen einer maschinenorientierten Programmiersprache unter einem Namen zur Wiederverwendung bereitstel­len. Die dabei verwendeten Daten blieben jedoch ungeschützt, da sie noch nicht gekapselt werden konnten. Sie waren global verfügbar, d. h. sie exis­tierten während der gesamten Ausführungszeit des Programms. Benutzerde­finierte Datentypen waren noch unbekannt.

 

2.    Etappe: Eine Weiterentwicklung des Konzeptes führt zur funktionalen Abs­traktion. Sie wird in Form von Unterprogrammen, Funktionen oder Proze­duren, realisiert. Operationsfolgen und Daten werden gemeinsam gekapselt. Damit liegen lokale Daten vor. Lokal sichtbare Daten existieren nicht über die Ausführungszeit der Funktionen und Prozeduren hinaus. Der Datenaus­tausch erfolgt mittels Parameterkonzept über eine definierte Schnittstelle. Die formalen Parameter werden vor der Ausführungszeit vereinbart. Die ak­tuellen Parameter entstehen zur Ausführungszeit. Es fehlt die Möglichkeit, lokale Daten über die Ausführungszeit der Funktionen und Prozeduren hin­aus zur Verfügung zu stellen, ohne diese außerhalb der Kapselung aufzube­wahren.

 

3.     Etappe: Eine Datenkapsel kann als nächster Schritt zur Verbesserung des Konzeptes verstanden werden. Die benutzerdefinierte Datenstruktur, wird zusammen mit den Operationen, die auf dieser Datenstruktur ausgeführt werden sollen, gekapselt. Dabei wird festgelegt, welche Daten von außen sichtbar sein dürfen und welche verborgen werden. Die Programmiersprache Modula stellt Datenkapseln zur Verfügung. Als nachteilig erwies sich, dass nur genau ein Exemplar einer solchen Struktur beschreibbar ist. Es fehlt also ein Konzept, das den Export eines Datentyps ermöglicht.

 

4.    Etappe: Mit dem abstrakten Datentyp (ADT) wurde das möglich. Die Vor­teile bestehen darin, dass:

-  beliebig viele Exemplare (Instanzen) vom Typ ableitbar sind.

-  ein hoher Grad der Abstraktion für benutzerdefinierte Datentypen erreicht wird.

Es bleibt der Nachteil, dass keine Ableitungen von Typen aus einem Basis­typ möglich sind.

 

5.    Etappe: Die Fortsetzung des Konzeptes führte vom ADT zur Objektorientie­rung. Eine Klasse entspricht einem ADT. Jedes Objekt entsteht durch Inkar­nation aus einer Klasse (Bauplan für eine Objektart). Eine Klasse beschreibt Instanzvariablen (gekapselte Datenstruktur in den Objekten) und die über den Variablen definierten Operationen. OOM bietet mit der Vererbung die Möglichkeit, aus einem Basistyp neue Typen abzuleiten. Schnittstelle und Funktionalität des Basistyps gehen auf den abgeleiteten Typ über. Es besteht die Möglichkeit zur Modifikation des abgeleiteten Typs.

Die Schüler verstehen OOM nun als eine Entwicklungsstufe des informatischen Modellierens, die nicht zufällig entstand, die aber auch keinen Abschluss bilden kann, denn Vererbung verstößt gegen das Geheimnisprinzip.

 

Im Informatikunterricht der Sekundarstufe II erwies sich das Konzept des ADT als erlernbar. Solange keine Informatikvorkenntnisse aus der Sekundarstufe I vor­lagen, sahen die Lehrpläne vieler Bundesländer genau ein Paradigma der Informa­tik, das prozedurale Paradigma, vor. In diesem wurde das erforderliche Abstrakti­onsniveau systematisch bis zu ADT und dynamischen Datenstrukturen über die möglichen Kurse entwickelt. Bei der Euphorie über das hohe fachliche Niveau in einem Teilgebiet der Informatik wurde übersehen, dass zunehmend weniger Schü­ler bereit waren, ein Fach zu wählen, in dem es sehr schwer ist, Spitzenleistungen zu erzielen. Die Überlegungen der Schüler zu ihrer Abiturstrategie zeigten, dass Informatik im Wettbewerb mit anderen Fächern bestehen muss. Bei der Suche nach neuen, attraktiven Konzepten bot sich OOM an. Außerdem versprachen Fachwissenschaftler große Erleichterung in der Software-Entwicklung durch An­wendung der OOM. Hier kann es leicht zu Fehleinschätzungen des Lernaufwandes für OOM gekommen sein. Inzwischen wird OOM in den Lehrplänen einiger Bun­desländer empfohlen. Die Ablösung des prozeduralen Paradigmas durch OOM wurde gefordert (Czischke, 1997). Die notwendige Fähigkeit, Operationen mit prozeduralen Strukturen zu gestalten, eignen sich die Schüler bei dieser unterricht­lichen Vorgehensweise im Kontext der OOM an. Wenn man die folgende These als korrekt annimmt, dann wird OOM keineswegs leichter erlernbar sein, als das Basiskonzept ADT.

 

"Objektorientierter Entwurf ist die Entwicklung von Softwaresystemen als strukturierte Sammlung von Implementierungen abstrakter Datentypen" (Claussen, 1993, S. 15).

 

Die beschriebene bessere Motivationslage der Schüler kann durchaus andere Ursa­chen haben. So kann die Begeisterung der Lehrer für OOM einen wichtigen Einfluss auf ihren Unterricht ausüben. Eine Evaluierung der Lernprozesse zu alternati­ven Vorgehensweisen beim informatischen Modellieren steht noch aus. Sie wird erschwert durch die geringen Schülerzahlen im Informatikunterricht. Ob die ob­jektorientierten Denkweisen den lehrmethodisch günstigsten Zugang zum Ver­ständnis der Informatik bilden, bleibt vorerst offen. Es gibt deutliche Gegenstim­men:

 

"Dabei wird übersehen, dass Objektorientierung kaum für den Einstieg in die Informatik geeignet ist (Hartmann/Nievergelt, 2002, S. 467).

 

Wir empfehlen, unterschiedliche Arten der informatischen Modellierung zum Lerngegenstand zu machen. Jeder Eindruck eines universellen Problemlöseansat­zes ist zu vermeiden. Ein ausgewogenes Verständnis der Informatik muss Vorrang vor sehr speziellen Bildungszielen bekommen (Humbert, 2003). Insgesamt darf das informatische Modellieren nicht den Informatikunterricht ausfüllen. Es besteht keine Notwendigkeit, große Informatiksysteme im Unterricht mit Schülern zu entwickeln, um deren Wirkprinzipien und Architektur als Lerngegenstand zu ges­talten. Die Lernzeit für die Analyse von anwendungstauglichen Informatiksyste­men wird häufig unterschätzt. Wir empfehlen deshalb, Strukturmodelle im Unter­richt einzusetzen, um Entwurf und Funktionalität von Informatiksystemen zu vermitteln (vgl. Kapitel 9).