Didaktik der Software Entwicklung

1

Humboldt-Universität zu Berlin Institut für Informatik Informatik in Bildung und Gesellschaft Dr. Jochen Koubek

1. Didaktik der Software-Entwicklung In diesem Text werden grundlegende Anmerkungen zur einer Didaktik der Objektorientierten Modellierung (OOM) beschrieben. OOM umfasst dabei die Analyse (OOA), den Entwurf (OOE) und die Programmierung (OOP). Doch zunächst einige wichtige didaktische Grundbegriffe, auf die im Folgenden Bezug genommen wird.1 Auf die Terminologie der OOM wird an dieser Stelle nicht näher eingegangen, ein umfassendes Glossar wurde kürzlich in der Zeitschrift LOGIN veröffentlicht.2 Definitionen Didaktik ist die Theorie und Praxis vom Lernen und Lehren. Sie kümmert sich um die Fragen, wer was wann mit wem wo wie womit warum und wozu lernen soll. Schüler sind Menschen, die sich von einem Lehrer beim Lernen helfen lassen. Lehrer sind Menschen, die Schülern beim Lernen helfen. Unterricht ist die Inszenierung von Lernprozessen. Inszenierung ist die Umsetzung eines Handlungsplans in einen Handlungsablauf.

Didaktisches Handeln besteht einerseits in der Transformation von Inhalten in Unterrichtsgegenstände (Inhaltsaspekt), andererseits in der auf bestimmte Lerngruppen ausgerichteten Vermittlung der transformierten Inhalte (Vermittlungsaspekt). In der Regel ist das Ziel des didaktischen Handelns, Lernprozesse für Schüler möglichst einfach zu gestalten. Didaktische Planung bezieht sich also darauf, den Unterrichtsverlauf in Hinblick auf den Inhalts- und Vermittlungsaspekts zu optimieren. Unterricht ist für den Lehrer daher oft mit erheblichem Planungs- und Vorbereitungsaufwand verbunden. Dabei sollten die von der Didaktik erarbeiteten Prinzipien berücksichtig werden. 1 2

Vgl. Kaiser/Kaiser: Studienbuch Pädagogik; Meyer: Schulpädagogik Login Heft 128, Online unter: http://log-in.fachdid.fu-berlin.de/

Didaktik der Software Entwicklung

2

1.1. Didaktische Prinzipien Die Didaktik hat einige Grundprinzipien aufgestellt, die für die didaktische Transformation gelten. Diese sollte:      

Situationsbezogen Handlungsorientiert Wissenschaftsorientiert Beispielorientiert Strukturiert Reduzierend, d.h. auf das Wesentliche beschränkt sein

Ähnliche Prinzipien wurden für die Vermittlung des Lehrmaterials formuliert. Hier gelten die Forderungen nach     

Anschaulichkeit Verfremdung zur Durchbrechung eingefahrener Sichtweisen Vergleich Tätigkeitsorientierung, um zum Lernen mit Kopf, Herz und Hand zu animieren Terminologischer Konsequenz

Vor allem den letzten Punkt möchte ich noch kurz ausführen: Methodisch sollte starker Wert auf das Verständnis des objektorientierten Vokabulars gelegt werden, sowohl aktiv als auch passiv. Dazu gehören Klasse, Objekt, abstrakte Klasse, Instanz, Attribut, Eigenschaft, Methode, Vererbung, Objektbeziehung, Aggregation etc.  

Passives Vokabular bedeutet, dass die Grundbegriffe bekannt sind und somit angebotene Erklärungen und Lösungen verstanden werden. Aktives Vokabular bedeutet, dass die Studenten in der Lage sind, Probleme, Ansätze und Lösungen terminologisch richtig zu beschreiben.

Aktives umfasst passives Verständnis, wer etwas ausdrücken kann, kann es auch verstehen. Wer aber eine Erklärung verstehen kann, ist nicht unbedingt in der Lage, sie auch weiterzugeben. Als Ergebnis des Java-Pilotprojekts im Sommersemester 2004, aber auch auf der Grundlage anderer Lernprozesse, gibt es Gründe zu folgenden Thesen: 



  

Studenten mit chronischen Verständnisproblemen sind weder in der Lage, ihre Probleme in Worte zu fassen noch verstehen sie angebotene Lösungen. Sie beherrschen das Fachvokabular weder passiv noch aktiv. Es gilt der Umkehrschluss: Wer das Vokabular wirklich versteht, kann zwar mit konkreten Aufgaben Probleme haben, ist aber grundsätzlich in der Lage, objektorientiert zu denken. Verstehensprobleme lassen sich immer an unverstandenen Wörtern erkennen. Durch die handlungsorientierte (s. u.) Arbeit an wenig- oder unverstandenen Begriffen klären sich individuelle Probleme. Allgemeiner gesagt ist die Sprache der beste Hinweis für Verständnis.

Didaktik der Software Entwicklung 

3

Begriffe lernt man in Handlungszusammenhängen. Glossare und Lexika helfen zwar, Begriffe zu präzisieren, ersetzen aber nicht die aktive Bemühung um Begriffsbildung. Glossare sollten erst hinzu gezogen werden, wenn im Rahmen von Handlungen Beschreibungsbedarf auftaucht.

Ein Beispiel mag den letzten Punkt verdeutlichen: Klappt der Kfz-technisch unbelastete Mensch die Motorhaube auf, so sieht er darunter den Motor. Klappt er die Motorhaube wieder zu, bleibt das diffuse Bild einer Einheit als Erinnerungsbild. Die Kabel, Schläuche, Rohre, Deckel und größere Blöcke werden begrifflich nicht differenziert. Weder genauere Beschreibungen noch Fehlerdiagnosen sind mit diesem Verständnis möglich. Eines Tages bemerkt er einen merkwürdigen Geruch im Auto und fragt einen Freund um Hilfe. Dieser fragt ihn, ob er den Ölstand kontrolliert habe. Es ergibt sich folgender Dialog: Freund: Hast Du den Ölstand kontrolliert Mensch: Den was? Freund: Den Ölstand. Hast Du genug Öl? Mensch: Nein. Keine Ahnung. Freund: Wann hast Du denn das letzte Mal Öl nachgefüllt? Mensch: Ich war letzte Woche an der Tankstelle. Freund: Und hast Du da Öl nachgefüllt oder nur getankt? Mensch: Ist das nicht dasselbe? Freund: Nein. Das eine ist Öl, das andere Benzin. Mensch: Aber Benzin ist doch Öl. Wenn die Ölpreise steigen, wird das Tanken teurer. Freund: Ja Benzin wird ja auch aus Öl gemacht. Im Auto aber ist es etwas anderes. Da gibt es Benzin und Öl. Mensch: Aha. Freund: Also kein Öl nachgefüllt. Mensch: Na ja, getankt halt. Freund: Na gut, dann schauen wir mal nach Deinem Ölstand. Der Freund zeigt ihm, den Ölstand zu kontrollieren, welche Handgriffe dafür nötig sind, worauf er achten muss. Er lernt Worte wie Öleinfüllfdeckel, vielleicht auch Ölwanne, Ölfilter, Öldruckventil oder Ölablassschraube Im Motor erkennt unser Mensch nun den Ölstandanzeiger als eigenständigen Gegenstand, er versteht den Begriff, hat aber u. U. noch kein eigenes Wort dafür. Hier hilft ein Wörterbuch, um sein neues Wissen anschlussfähig zu machen. Auf der anderen Seite kann ihm dieses Buch auch mittels neuer Worte auf neue Gegenstände und Handlungen aufmerksam machen, z.B. auf Kühlmittel, Batterie oder Scheibenwascherdüse. Als didaktisches Grundprinzip bei allen Lernvorgängen gilt daher: Bewusstes Lernen erfolgt über bewusstes Arbeiten an der Sprache Bewusstes Arbeiten an der Sprache erfolgt über bewusstes Handeln Beim Umgang mit Wissen unterscheidet man zwischen implizitem und explizitem Wissen. Etwas verstehen bedeutet nicht zwangsläufig, es auch erklären zu können. Jeder

Didaktik der Software Entwicklung

4

beherrscht die Grammatik seiner Muttersprache, ohne sie erklären zu können. „Das ist halt so!“ ist das gängige Erklärungsmuster bei implizitem Wissen. Ein Ziel der didaktischen Analyse ist es, das implizite Wissen des Lehrers in explizites umzuwandeln, was bedeutet, die richtigen Fachbegriffe anwenden zu können. Ein Lehrer-Team muss besonders auf einheitliche Terminologie achten. Sollten sich terminologische Unschärfen und Fehler ergeben, ist es für einen Lehrer nicht mit Autoritätsverlust verbunden, wenn er sich bereitwillig korrigiert bzw. korrigieren lässt. Das zeigt, dass ihm die Sache wichtiger als das Wunschbild des fehlerlosen Lehrers ist. Auf der anderen Seite sollte der Lehrer die Schüler für korrekte Verwendung der Terminologie sensibilisieren. Dazu gibt es mehrere Möglichkeiten:  Korrigieren einer unrichtigen Verwendung  Den Schüler auf den Lapsus aufmerksam machen und fragend erarbeiten  Beantworten einer Schülerfrage  Fragen an die Klasse zurück geben  Die Geschichte und Etymologie eines Wortes erklären, sofern er sie kennt  Zum Gebrauch eines Glossars oder Wörterbuchs auffordern

1.2. Didaktik der OOM – Inhaltsaspekt Aus didaktischen Gründen wird der OOM-Unterricht anhand des Wasserfall-Modells empfohlen. Das Modell besticht durch klare Gliederung und trennscharfe Projektphasen. Dabei sollte im Unterricht darauf hingewiesen werden, dass dieses Modell lediglich eine Idealisierung darstellt und bei realen Projekten außerhalb des Unterrichts erhebliche Umsetzungs-Probleme hat, weil es ihren Verlauf nicht adäquat abbildet. Ein idealisierter Projektverlauf, wie er im Wasserfallmodell dargestellt wird, kann aber im Unterricht mit entsprechendem didaktischen Aufwand gewährleistet werden, wodurch die Klarheit und Stringenz des Modell zum Tragen kommt. Es erfüllt vor allem die Prinzipien der Wissenschaftsorientierung, der Strukturiertheit und der Reduktion auf das Wesentliche.

Die Phasen im Einzelnen:

Didaktik der Software Entwicklung

5

Initialisierung Das Projekt wird vorgestellt, die Fragestellung formuliert. Da Projektarbeit bei OOM als bevorzugte Unterrichtsmethode gilt, ist es möglich, die Lerngruppe über das konkrete Projekt entscheiden zu lassen. Da vor allem im Anfangsunterricht die mögliche Komplexität von Software-Projekten von Schülern nur schwer einzuschätzen ist, liegt es in der Verantwortung des Lehrers, die Auswahl eines im Rahmen des Unterrichts zu bewältigendes Projekt zu steuern.

Analyse (Spezifikation, OOA) Die Aufgabenstellung soll mit eigenen Worten formuliert werden. Dabei können Metaphern verwendet werden (Maschine, Motor, Personengruppe) Die Aufgabe wird in möglichst kleine Teilaufgaben zerlegt:     

Ideensammlung mit Karteikarten, Magnete und Stiften Die Karteikarten zu Teilproblemen zusammenfassen Substantive als Klassen identifizieren Zeitplan für die Umsetzung angeben Verbale Präsentation der Ergebnisse

Ergebnis der OOA: Klassen

Entwurf (Design, OOD) Die Spezifikation der OOA wird in Klassenbeziehungen übersetzt. Dabei werden abstrakte und nicht-abstrakte Klassen bestimmt und deren Beziehung (keine, ist-Teil, ist) festgelegt.  Verben als Methoden identifizieren,  Adjektive bzw. Eigenschaftswörter in Attributen modellieren. Adjektive sind Werte von Attributen.  Signaturen bestimmen (Übergabe und Ergebnisparameter mit Datentypen)  UML-Diagramme zur Visualisierung einführen Ergebnis der OOD: Darstellung des Problems in UML-Diagrammen

Realisierung (Implementierung, Programmierung, OOP) Pseudocode eignet sich als Vorstufe zur eigentlichen Implementierung. Vor allem bei Schülern mit Vorkenntnissen muss erläutert werden, wieso nicht sofort zum Quellcode übergegangen wird. Um den Überblick zu erleichtern wird ein Java-Glossar bereit gestellt.

Einführung, Nutzung Zu beiden Phasen liegen noch keine Beobachtungen vor.

Didaktik der Software Entwicklung

6

1.3. Didaktik der OOM – Vermittlungsaspekt In diesem Abschnitt wird von dem zeitlichen Horizont einer Lehrveranstaltung mit 2SWS für die Dauer eines Semesters ausgegangen. Außerhalb der Präsenzzeit werden von den Schülern Hausaufgaben bzw. Arbeitsaufträge bzw. Übungsblätter bearbeitet. Grundsätzlich ist die Arbeit an einem konkreten Projekt die empfohlene Unterrichtsmethode. Die Projektdauer kann dabei das gesamte Semester umfassen. Die didaktische Planung bezieht sich im Schwerpunkt auf die inhaltliche Gestaltung und die Koordination von Präsenzzeit und Übungen. Zwei Modelle bieten sich an: 1. Ein gemeinsames Projekt der gesamten Lerngruppe. Die Inhalte, die für die Bearbeitung des Projekts notwendig sind, werden in der Präsenzzeit erarbeitet, die Arbeitsaufträge bestehen in der Vervollständigung und Dokumentation der Ergebnisse. Der Arbeitsaufwand lässt sich in diesem Fall auf die gesamte Gruppe verteilen, bei hinreichender Planung sogar zu Semesterbeginn. 2. Individuelle Projekte. Während der Präsenzzeit wird von den Schülern ein Musterprojekt bearbeitet, die Arbeitsaufträge bestehen darin, die Ergebnisse auf ihre eigenen Projekte zu übertragen. Der Arbeitsaufwand ist für alle Beteiligten deutlich größer, die Entfremdung vom Projekt allerdings geringer. In Folgenden stehen eine Reihe unsortierter Anmerkungen, die sich auf die konkrete Durchführung des OOM-Unterricht beziehen.  Musterlösungen: OOM lernt man nicht nur durch Programmieren sondern auch durch Analyse guter Projekte. Es wird daher empfohlen, einen Pool an Lösungen bereitstellen und darauf in Übungen explizit Bezug zu nehmen. Solche Musterlösungen können z.B. erfolgreich abgeschlossene Projekte vergangener Semester sein.  Objects First: Der Unterrichts-Ablauf sollte Top-Down geplant werden. Hierbei gibt es den problematischen Übergang von der Konzeption zur Realisierung in Algorithmen einer konkreten Sprache. Zur Gewöhnung sollte man daher TopDown mit Bottom-Up mischen und regelmäßig kleine Übungen zum algorithmischen Denken einschieben.  Problemklassen: Als Aufgaben nicht nur nach Lösungen suchen lassen sondern die Schüler/Stundenten auch ähnliche Probleme formulieren lassen. Damit werden Problemklassen identifiziert und Transferleistungen erleichtert.  Pseudocode: Der Übergang vom Entwurf zur Realisierung sollte zunächst in Pseudocode erfolgen, d.h. in einer umgangssprachlichen Formulierung, die im Anschluss in konkreten Code verfeinert wird.  Glossar: Um die Arbeit an korrekter Terminologie zu erleichtern, kann auf ein Java-Glossar verwiesen werden. Ein solches Glossar wurde im letzten Semester erstellt und steht auf dem Fachdidaktik-WIKI zur Verfügung.

Didaktik der Software Entwicklung

7

1.4. Planungsfragen Bei der Planung sollten zumindest folgende Fragen beachtet werden. Die vorgeschlagen Antworten können dabei als Diskussionsgrundlage dienen. 1. Wie soll Algorithmik eingeführt werden? a. Kleine algorithmische Bei-Spiele als Anfangs- oder Endsequenz in jeder Stunde bereiten den Übergang zur Implementierung vor. Solche Spiele müssen i. Leicht verständlich sein ii. kurz und bündig bearbeitbar sein iii. Ohne viel Vorbereitung durchführbar sein iv. Ohne exotisches Lehrmaterial auskommen v. Auf Kontrollstrukturen und Algorithmen hinarbeiten vi. Unterhaltsam sein Bsp.: Zugrangieren, Turm von Hanoi etc. Beim Algorithmusspiel muss zwischen Erstellung und Ausführung unterschieden werden, d.h. die Gruppe, die einen Handlungsablauf erstellt, darf ihn nicht vorführen. Dieses Vorgehen ist vor allem an Schüler der Sek I und Sek II orientiert und wird im Seminar ausprobiert. Ziel des Seminars ist es u. a., unterrichtstaugliche Spiele für die verschiedenen Sprachkonstrukte zu entwickeln und zu testen. b. Der Einsatz von IDEs (Integrated Development Environment) verspricht rasche Erfolgserlebnisse bei der Implementierung kleiner Algorithmen, da ein GUI die Erstellung von Ein-/Ausgabeschnittstellen erleichtert. Der Nachteil ist die nicht unerhebliche Einarbeitungszeit in die IDE. Sollte der Einsatz einer solchen Entwicklungsumbebung aber vorgesehen sein, spricht nichts gegen eine Einarbeitung an überschaubaren Beispiele, während die Konzentration auf OOA/OOE liegt. c. Als Alternative bietet sich an, die Beispiele syntaxfrei zu halten und konkreten Code später kennen zu lernen, was günstig für den Anfangsunterricht ohne Vorkenntnisse sein kann. d. Bei strengem Top-Down, kann der Unterricht durch geschickte Planung allmählich über Pseudocode zu Kontrollstrukturen vordringen. 2. Wann sollten die Grundbegriffe des OOM erarbeitet werden? a. Vor dem Projekt oder als Teil des Projekts? Objekt- oder klassenorientiert? Losgelöst vom Projekt erscheint handhabbar Aber: b. Beispielorientiert vorgehen denn c. Objects first heißt zurecht nicht classes first d. Projekte stärker auf den Unterhaltungswert ausrichten, z.B. Spiele (s. o.) 3. Welche Tools sollen eingesetzt werden? a. Open-Source-Software bzw. Freeware ist unbedingt einzusetzen und zwar in der gleichen Form, die auch von Schülern bezogen werden kann. Hervorzuheben sind BlueJ und Fujaba.

Didaktik der Software Entwicklung

8

1.5. Offene Fragen Folgende didaktischen Fragen sind im letzten Semester offen geblieben:  Als Hauptproblem stellte sich die Frage, wann und wie konkrete Sprachkonstrukte eingeführt werden sollen, also Verzweigungen, Schleifen, Operatoren etc. Wenngleich einige Antworten formuliert worden sind (s. o.), fehlt es an einem rundum überzeugenden Ansatz.  Ebenso problematisch ist die Einführung von Variablen. Hier sollte nicht zu wenig Zeit eingeplant werden, ohne allerdings den OOM-Rahmen zu vernachlässigen.  Das Denken in Objekten ist problematischer als es zunächst erscheint. o Man kann es nicht oft genug wiederholen: Der Lehrer muss auf einheitliche Terminologie achten! o Oberklassen werden häufig mit Aggregationen verwechselt. Als Oberklasse der Klasse Baum wird häufig Wald genannt und nicht (z. B.) Pflanze. o Attribute werden mit Eigenschaften verwechselt: „Der Baum ist klein“ anstatt „Der Baum hat das Attribut Größe und den Wert klein. Beispiel für bewährte Unterrichtspraxis, die viele der hier angesprochenen Punkte berücksichtigt, finden sich unter: http://www.oszhdl.be.schule.de/gymnasium/faecher/informatik/ooa-ood/ooa_1.1.htm und den damit verbundenen Seiten.