Entwicklung von Komponenten eines Lehr-Lern-Konzeptes zum objektorientierten
Modellieren
Torsten Brinda
Didaktik der Informatik und multimediale Lehr-Lern-Systeme
Universität Siegen
D-57068 Siegen
Email: brinda@informatik.uni-siegen.de
URL: http://www.didaktik-der-informatik.de
Hinweis zu diesem Dokument: Der hier vorliegende
Text entspricht in großen Teilen der Publikation [Br01]
des Autors. Er wurde um Folien aus einem Vortrag des Autors, der im Rahmen
der Fachtagung
Informatik und
Schule 2001 (INFOS2001) in Paderborn gehalten wurde, damit verbundene
Erläuterungen, sowie um Verweise und Kommentare das Thema betreffender
multimedialer Lern- und Lehrmaterialien ergänzt. Im Text wird an geeigneten
Stellen über das Kürzel Folie
auf diese verwiesen. Diese Folien können über die Navigationsschaltflächen
(zur ersten Folie) |
(eine Folie zurück) |
(eine Folie vorwärts) |
(zur letzten Folie) |
auch unabhängig vom Text durchlaufen werden. |
Zusammenfassung:
Im Rahmen dieses Beitrags werden zunächst Argumente dafür geliefert,
dass objektorientiertes Modellieren (OOM) als Problemlösungsmethode
dazu geeignet ist, Ziele allgemein bildenden Informatikunterrichts zu realisieren.
Aufgrund des Mangels an Lehr-Lern-Materialien zum OOM in der Fachdidaktik,
werden vorhandene Lehrstrategien und Lehr-Lern-Materialien in der Fachwissenschaft
untersucht mit dem Ziel der Entwicklung von Strategien für die Gestaltung
entsprechender Elemente für den Informatikunterricht. Kriterien und
Vorgehensweisen zur Auswahl, Strukturierung und Repräsentation der
kognitiven Beziehungen von Lerninhalten und Kompetenzen, sowie zur Konstruktion
von Übungsaufgaben zu OOM aus Aufgabenklassen werden entwickelt, um
die Planung und Ausgestaltung von Informatikunterricht zu OOM zu erleichtern,
dessen Vergleichbarkeit zu erhöhen und Qualitätsstandards zu
etablieren.
Abstract:
In this contribution arguments are given, that object-oriented modelling
(OOM) as a problem solving method is suitable to achieve the objectives
of general secondary education in informatics. Because of a lack of learning
and teaching material on OOM within didactics of informatics, available
teaching strategies as well as learning and teaching material of the university
subject are analyzed to develop strategies for the design of corresponding
elements for secondary education in informatics. Criteria and methods for
selecting, structuring and representing cognitive relationships of learning
content and competences, as well as for constructing exercises on OOM by
the use of exercise classes are developed in order to simplify the planning
and arrangement of secondary informatics education on OOM and to raise
its comparability and to establish quality standards.
1 Motivation
In der Arbeitsgruppe "Didaktik
der Informatik" der Universität
Dortmund (ab Ende 2002 an der Universität
Siegen) wird seit 2000 ein Lehr-Lern-Konzept für objektorientiertes
Modellieren (OOM) im Informatikunterricht entwickelt [Br00a],
[Br00b].
Die Entwicklung ist eine Reaktion auf sich vom imperativen Problemlösen
mit starker Betonung der Programmierung hin zum informatischen Modellieren
verändernde Schwerpunkte bei den durch Informatikunterricht zu vermittelnden
Kompetenzen (vgl. Ansatz Hubwieser[Hu00]),
den hohen Bedarf für Konzepte zur Umsetzung didaktischer Theorien
bei Informatiklehrenden und die Tatsache, dass objektorientierte Modellierung
zu einem fundamentalen Gegenstandsbereich der Fachwissenschaft im Sinne
der fundamentalen Ideen der Informatik nach Schwill[Sc93]
geworden ist und damit intensiver als bislang im Informatikunterricht berücksichtigt
werden sollte.
Da OOM bislang nicht verbreitet im Informatikunterricht thematisiert
wird, existiert noch kein Konsens darüber, welche objektorientierten
Basiskonzepte, Modellierungstechniken und -strategien, sowie welche Grundzüge
einer objektorientierten Programmiersprache von den Schülerinnen und
Schülern erlernt werden sollen, damit sie die für die Realisierung
der Ziele modernen, allgemein bildenden Informatikunterrichts [GI00],
wie das Durchdringen von "Wirkprinzipien von Informatiksystemen" und das
Erlangen von Gestaltungskompetenz im Sinne des "informatischen Modellierens",
erforderlichen Fach- und Methodenkompetenzen erwerben können. Im World
Wide Web und in Fachzeitschriften, wie LOG
IN, publizierte Unterrichtsbeispiele zur Objektorientierung zeigen
weiterhin eine starke Orientierung hin auf die Programmierung. Die Diskussion
von Programmiersprachen in bezug auf ihre Unterrichtseignung dominiert
dabei konzeptuelle Überlegungen.
Um die Planung und Ausgestaltung von Informatikunterricht zu OOM zu
erleichtern, dessen Vergleichbarkeit zu erhöhen und Qualitätsstandards
zu etablieren, werden im Rahmen dieses Beitrags Kriterien und Vorgehensweisen
zur Strukturierung und Repräsentation der Beziehungen von Kompetenzen
und objektorientierten Konzepten, sowie zur Konstruktion von Übungsaufgaben
zum objektorientierten Modellieren aus Aufgabenklassen entwickelt. Es handelt
sind dabei um wesentliche Bestandteile eines didaktischen Systems zu OOM
(vgl. [BS01]).
Die Kernaussagen der Motivation fasst diese Folie
zusammen.
2 Entwicklung von Kompetenzen im Informatikunterricht
der Sekundarstufe II
Schülerinnen und Schülern werden in ihrem Alltag und späteren,
beruflichen Werdegang auf vielfältige Weisen mit komplexen Informatiksystemen
konfrontiert, sei es als Anwender, Betroffener, Entscheider, Planer, Entwickler
oder als Administrator. Zur Vorbereitung auf die sich durch komplexe Informatiksysteme
zunehmend verändernde Arbeits- und Lebensweise von Menschen heißt
es in den "Empfehlungen
für ein Gesamtkonzept zur informatischen Bildung an allgemein bildenden
Schulen" der Gesellschaft für Informatik [GI00]:
"Der Umgang mit digital dargestellter Information und die Beherrschung
von Informatiksystemen stellen folglich unverzichtbare Ergänzungen
der traditionellen Kulturtechniken Lesen, Schreiben und Rechnen dar.".
Die im Rahmen der Empfehlungen charakterisierte Bildung orientiert sich
an vier Leitlinien, von denen hier die Linien "Wirkprinzipien von Informatiksystemen"
und "informatische Modellierung" von besonderer Bedeutung sind. Um Informatiksysteme
beherrschen und deren prinzipielle Möglichkeiten und Grenzen für
einen gegebenen Zweck beurteilen zu können, ist ein Grundverständnis
der Wirkprinzipien erforderlich, das nur durch Fach- und Methodenkompetenz
zur Analyse und Modellierung von Systembausteinen im Informatikunterricht
erworben werden kann und wofür deren Anwendung allein nicht ausreichend
ist (vgl. hierzu auch folgende Folie).
Neben der Tatsache, dass das objektorientierte Modellieren zu einem
fundamentalen Gegenstandsbereich der Informatik geworden ist und damit
in wissenschaftspropädeutischem Informatikunterricht der Sek. II thematisiert
werden muss, besteht die begründete Vermutung, dass der objektorientierte
Ansatz aufgrund zahlreicher Entwicklungen systematischer Vorgehensweisen
und anschaulicher Darstellungsformen in der Fachwissenschaft gut dazu geeignet
ist, die oben genannten Ziele modernen Informatikunterrichts zu realisieren.
Die Arbeiten verschiedener Fachdidaktiker liefern hierzu eine Reihe von
Indizien. Füller hat darauf hingewiesen, dass "ein objektorientierter
Ansatz verwendet werden kann, um Anwendersysteme zu analysieren und neutral
zu vergleichen" [Fü99, S. 190]. Mit
der "Dekonstruktion von Informatiksystemen als Unterrichtsmethode" (Magenheim
u. a. [MSH99]) liegt ein Zugang zu objektorientierten
Sichtweisen im Informatikunterricht vor, bei dem die Analyse objektorientiert
gestalteter Informatiksysteme zum durchgängigen Prinzip wird. Hubwieser
hat im Rahmen seines "informationszentrierten Ansatzes" allgemein bildenden
Informatikunterricht mit Modellierung als inhaltlichem Kern begründet.
Er merkt an [Hu00, S.85], dass unterrichtliche Betrachtungen
des Modellierungsvorgangs oft zu rein philosophischen, wenig schülergemäßen
Exkursen gerieten, da man bis vor wenigen Jahren nicht über geeignete
geistige Techniken verfügte, diesen systematisch und in angemessener
Tiefe im Unterricht umzusetzen. Er weist in diesem Zusammenhang auf die
Arbeiten zu objektorientierten Modellierungstechniken und Vorgehensweisen
von Rumbaugh, Booch und Jacobson (s. z. B. [BRJ98])
hin, von denen er einige für geeignet hält, diese methodische
Lücke zu schließen.
Die genannten informatischen Bildungsziele können aber auch mit
dem objektorientierten Ansatz nur dann erreicht werden, wenn dabei der
konzeptionelle Wandel vom Programmieren zum informatischen Modellieren
vollzogen wird (vgl. Folie).
Zu starke Betonung der Programmierung bewirkt, dass Lernende zunächst
sehr viel Faktenwissen zu einer Programmiersprache erwerben müssen,
bevor sie die angestrebte Gestaltungskompetenz erlangen. Aufgrund des Mangels
an Lernhilfen und Unterrichtsmaterialien zum Modellieren, lässt sich
in der Schulpraxis weiterhin verbreitet die Betonung der Programmierung
beobachten, allerdings zunehmend bei Verwendung objektorientierter Programmiersprachen.
Zur Beseitigung dieses Mangels will die hier vorgestellte Arbeit beitragen.
Für den Bereich der Wirkprinzipien von Informatiksystemen wurde
in der Fachgruppe "Didaktik der Informatik" an der Universität Dortmund
bereits im Rahmen einer Diplomarbeit [St99] ein Konzept
entwickelt (vgl. Abbildung 1) und exemplarisch erprobt, das einen explorativen
Zugang zu Fachinhalten (im Beispiel aus dem Fachgebiet "Rechnernetze und
verteilte Systeme") ermöglicht.
Abbildung 1: Erkundungsbaustein für das Anfordern einer
Webseite
In Rahmen der Forschungsarbeit des Autors werden prozess- und ergebnisorientierte
Lernhilfen für den Bereich des objektorientierten Modellierens konzipiert,
entwickelt und in einem Einsatzkonzept verknüpft.
3 Fachwissenschaftliche Erkenntnisse zum objektorientierten
Modellieren
Für die Suche nach Lehr-Lern-Materialien zum OOM in der Fachdidaktik
steht ein großer Reichtum an Lehrbüchern, Lernhilfen, Übungsaufgaben
und Werkzeugen in der Fachwissenschaft zur Verfügung. Obwohl sich
diese Materialien an Informatikstudierende und Software-Entwickler und
damit an völlig andere Zielgruppen als Lernende im Informatikunterricht
richten, so verbindet alle dennoch, dass sie Anfänger beim objektorientierten
Modellieren sind. Aus diesem Grund werden vorhandene Lehrstrategien und
Lehr-Lern-Materialien in der Fachwissenschaft untersucht mit dem Ziel der
Entwicklung von Strategien für die Gestaltung entsprechender Elemente
für Informatikunterricht zu OOM.
3.1 Begriffsbildung
Objektorientierte Basiskonzepte, wie Objekt, Klasse, Assoziation oder Vererbung,
sind erforderlich, um objektorientierte Modellierungstechniken und die
Lösung von Problemen durch ein Geflecht kooperierender Objekte verstehen
zu können. Deshalb stehen sie zumeist am Anfang entsprechender Ausbildungsabschnitte.
In Lehrbüchern zu OOM (analysiert wurden hier Publikationen von Wirfs-Brock
u. a. [WWW90, S. 17-28], Jacobson u. a. [Ja93,
S. 44-68], Rumbaugh u. a. [Ru93, S. 27-59], Booch
[Bo94,
S. 109-186] und Meyer [Me97]) werden diese Basiskonzepte
oft über Metaphern eingeführt, indem ein Bezug zu Begriffen der
Lebenswelt hergestellt wird. Wirfs-Brock u. a. veranschaulichen den Klassenbegriff
als Schablone für eine spezielle Art von Objekten und als Fabrik,
die Objekte produziert [WWW90, S. 22]. Ein Objekt
sehen sie als "Black Box" mit öffentlicher Schnittstelle und geheimem
Inhalt [WWW90, S. 18]. Jacobson u. a. führen
die Klasse als Bauplan für den internen Aufbau strukturgleicher Objekte
ein [Ja93, S. 50]. Booch beschreibt eine Beziehung
zwischen zwei Objekten als Pfad, über den Nachrichten versendet werden
können [Bo94, S. 129] und Aggregatobjekte als
Container
[Bo94, S. 166].
Bei der Reihenfolge der Erarbeitung der Grundbegriffe lassen sich in
der Fachliteratur folgende Varianten erkennen:
-
Objekt, Nachrichtenaustausch und Beziehungen zwischen Objekten, Klasse,
Beziehungen zwischen Klassen (Wirfs-Brock u. a., Jacobson u. a., Booch),
-
Objekt, Klasse, Beziehungen zwischen Objekten und Klassen (Rumbaugh u.
a.),
-
Klasse, Objekt, Beziehungen zwischen Objekten und Klassen (Meyer).
Während die ersten beiden Varianten keine Vorkenntnisse aus dem imperativen
Paradigma erfordern und mit einem lebensweltlichen Objektbegriff beginnen,
setzt die dritte Variante auf den Begriff des abstrakten Datentyps (ADT)
auf und entwickelt diesen zum Klassenbegriff weiter. Die Grundbegriffe
werden i. d. R. schrittweise und systematisch entwickelt. Zuerst eingeführte
Begriffe werden verwendet, um nachfolgende daraus abzuleiten bzw. darauf
aufzubauen. Teilweise werden Begriffe bereits verwendet, bevor sie formal
eingeführt worden sind. Vorwissen aus anderen Paradigmen wird dazu
verwendet, um Lerninhalte der Objektorientierung daran anzuknüpfen.
Die Erarbeitung des Klassenbegriffs aus dem ADT ist ein Beispiel hierfür.
Bei Meyer [Me97, S. 215] finden sich auch Ansatzpunkte
für einen Bezug zum funktionalen Ansatz. Beim funktionalen Ansatz
kann z. B. eine von zwei Variablen abhängige Funktion f(x,y) überführt
werden in eine Funktion höherer Ordnung (g(x))(y)=f(x,y). Dies wird
als "currying" bezeichnet. Beim objektorientierten Ansatz gibt es einen
analogen Zusammenhang. So kann die Funktion f hier transformiert werden
in x.g(y) bzw. y.g'(x) (vgl. Folie).
Fachkonzepte werden hier also schrittweise und systematisch entwickelt.
Dabei werden Wissen über die Lebenswelt und Vorkenntnisse zu anderen
Problemlösungsmethoden benutzt, um die neuen Konzepte zu veranschaulichen.
3.2 Statische und dynamische Aspekte
Bei der objektorientierten Analyse und Konstruktion von Informatiksystemen
lassen sich statische und dynamische Modelle unterscheiden. Während
es das Ziel des statischen Modells ist, einen Überblick über
den Aufbau bzw. die Architektur des Systems, z. B. in einem oder mehreren
Klassendiagrammen, zu geben, zielt das dynamische Modell darauf ab, einen
Überblick über zeitliche Systemabläufe, wie Objekterzeugung,
Objektzustandsveränderung durch Nachrichtenaustausch mit anderen Objekten
oder Objektzerstörung, z. B. in Interaktionsdiagrammen, zu geben.
Beide Aspekte sind gleichermaßen bedeutend, untrennbar mit jedem
nichttrivialen Informatiksystem verbunden und beeinflussen einander wechselseitig.
Objektorientierte Modellierungstechniken stellen eine Reihe von Darstellungsmitteln
zur Konstruktion solcher Modelle bereit. Objektorientierte Vorgehensweisen
geben Hinweise zur systematischen Erstellung von statischem und dynamischem
Modell (z. B. [Ba99, S.119ff]) und betonen, dass beide
aufgrund der Abhängigkeit parallel entwickelt werden sollten. Die
Einführung in die verschiedenen Techniken erfolgt in der Literatur,
ähnlich wie bei den Basiskonzepten, streng systematisch. Praktische
Übungsbeispiele zum OOM (s. z. B. [Ru93]) zeigen
allerdings, wie objektorientierte Basiskonzepte, Modellierungstechniken
und Vorgehensweisen erst einzeln, dann kombiniert eingeübt werden
können.
In der Fachgruppe "Didaktik der Informatik" wurden 2001 interaktive
Animationen zur Visualisierung objektorientierter Grundkonzepte (Hinweis:
die Animationen können nur in Ihrem Webbrowser angezeigt werden, wenn
Ihr Browser Flash-Animationen unterstützt oder Sie ein entsprechendes
Plugin installiert haben!) mit Macromedia Flash entwickelt. Ziele waren
es, die Eignung solcher Animationen für den Lernprozess, den Produktionsaufwand
und die Darstellungs- und Interaktionsmöglichkeiten des Werkzeugs
Flash zu erkunden. Der Einsatz der Animationen im Rahmen eines E-Learning-Praktikums
der Schupperuni des Fachbereichs Informatik für Oberstufenschülerinnen
führte zu überwiegend positiver Resonanz.
Aus Sicht der Informatik ist es erforderlich, dass Anfänger nicht
nur die prinzipielle, sondern aus ökonomischen Gründen die Konstruktion
guter, objektorientierter Modelle erlernen im Sinne von Kriterien, wie
z. B. Wiederverwendbarkeit und Wartbarkeit. Fowler weist darauf hin, dass
bestimmte Modellierungstechniken diesbezügliche Mängel schnell
ersichtlich machen. So z. B. kann in Interaktionsdiagrammen anhand des
Nachrichtenaustauschs zwischen Objekten schnell erkannt werden, ob Aufgaben
gleichmäßig zwischen Objekten verteilt sind oder ob der Entwurf
zu stark zentralisiert ist [FS97, S. 8]. Die Verwendung
graphischer Modellierungstechniken kann also dazu beitragen, dass bestimmte
Fehlerklassen und strukturelle Mängel schneller entdeckt werden können,
als dies z. B. auf Quelltextebene möglich ist. Der ursprünglich
aus der Architektur stammende Ansatz der Entwurfsmuster hat seit 1995 im
Rahmen der objektorientierten Software-Entwicklung weite Verbreitung gefunden
(vgl. z. B. [Ga96]). Entwurfsmuster stellen Kombinationen
von Objekten und Klassen als Lösungen für wiederkehrende abstrakte
Entwurfsprobleme bereit und fördern somit das Lernen aus Beispielen.
Durch die Verwendung erprobter Lösungen für Teilprobleme wird
die Qualität der Modelle, die Muster verwenden, in der Regel verbessert.
4 Fachdidaktische Konzepte zum objektorientierten
Modellieren
4.1 Wissen strukturieren
Da im Informatikunterricht die Entwicklung von Kompetenzen im Vordergrund
steht, ist die sachlogische Struktur der Fachwissenschaft allein ungeeignet
zur Strukturierung des Unterrichts. Aufgrund der Struktur der Fachkonzepte
wird aber deutlich, welche Elemente als Vorkenntnisse für andere Elemente
erforderlich oder hilfreich sind. Verschiedene Fachkonzepte lassen sich
mit einer "ist-erforderlich-für-" bzw. einer "ist-hilfreich-für-Relation"
verknüpfen. Da es alternative Möglichkeiten gibt, resultiert
daraus eine Vielzahl von Varianten, Wissen und Können schrittweise
zu entwickeln. Probleme können dabei z. B. auftreten, wenn es in der
Struktur zu Sprüngen im Abstraktionsniveau kommt, wie z. B. bei der
Konstruktion von Klassenhierarchien zu in Aufgabenstellungen beschriebenen
Realitätsausschnitten zu beobachten (s.a. Folie).
Ein zentrales didaktisches Problem vieler hierzu publizierter Methoden
und damit eine große, potentielle Fehlerquelle stellt der Übergang
von der objektorientierten Sicht auf einen Realitätsausschnitt hin
zur klassenorientierten Sicht des Klassendiagramms dar. In einem Realitätsausschnitt
werden zumeist sofort potentielle Klassenkandidaten gesucht, anstatt zunächst
problemrelevante Objekte zu identifizieren. Für Fortgeschrittene ist
das eine leichte Aufgabe. Für Anfänger wird an dieser Stelle
die Formalisierung eines Realitätsausschnitts durch Objekte und damit
ein Abstraktionsschritt übersprungen. Um nicht zu frühzeitig
zu formalisieren, werden im Informatikunterricht teilweise CRC-Karten [BC89]
als Vorstufe zu Klassendiagrammen eingesetzt. Da eine einzelne Karte eine
informell beschriebene Klasse repräsentiert, wird dadurch das oben
genannte Problem nicht gelöst. Der Abstraktionsschritt von der Beschreibung
eines Realitätsausschnitts hin zur Strukturierung von Klassen in einem
Klassendiagramm kann vereinfacht werden, wenn Objektdiagramme (s. z. B.
[Ru93,
S. 29]) verwendet werden (s. Abb. 2 u. Folie).
Abbildung 2: Vom Realitätsausschnitt zum Klassendiagramm
Diese stellen eine Momentaufnahme eines Objektgeflechts zu einem bestimmten
Zeitpunkt mit den aktuellen Attributwerten und Beziehungen zwischen Objekten
dar. Da im Objektdiagramm bereits Notationen verwendet werden, die auch
im Klassendiagramm verwendet werden, stellen diese eine gute Vorbereitung
dar. Für die Transformation eines Objektdiagramms in ein Klassendiagramm
(vgl. Folie)
können später Regeln formuliert werden, die diesen Prozess unterstützen.
Ein ähnliches Vorgehen wird von Balzert [Ba99, S.
132 u. S. 142] vorgeschlagen. Für jede typische Interaktion eines
Benutzers mit einem System (Anwendungsfall) soll ein Objektdiagramm und
ein lokales Klassendiagramm konstruiert werden. Die einzelnen Klassendiagramme
werden anschließend zusammengeführt. Bei diesem Vorgehen wird
ein großer Teil der gestalterischen Kreativität bereits bei
der Konstruktion der Objektdiagramme gefordert. Um Brainstorming-Prozesse
an dieser Stelle zu fördern, können die Objektdiagramme zunächst
auf einer informellen Ebene entwickelt werden, etwa unter Verwendung eines
Objekt-Analogons zu CRC-Karten. Iteriert man das beschriebene Vorgehen
für alle Anwendungsfälle eines Informatiksystems, so erhält
man ein statisches, objektorientiertes Analysemodell. Bei [Ba99,
S. 170ff] finden sich weitere Hinweise, wie ausgehend von Anwendungsfällen
und einem statischen Analysemodell über Szenarios eine Folge von Sequenzdiagrammen
entwickelt und damit das dynamische Modell schrittweise und systematisch
konstruiert werden kann.
Da OOM für Lehrende ein neues Basiskonzept ist, soll ein übersichtlicher
und kompakter Überblick in grafischer Form darüber gegeben werden,
in welchen Beziehungen Teile zu einander stehen, in welcher Reihenfolge
sie sinnvoll angeeignet werden können und wo aufgrund des Vorwissens
von Lernenden fortgesetzt werden kann, um so eine bessere Orientierung
im Lernstoff zu ermöglichen. Lernenden kann die grafische Struktur
für die Organisation von Selbststudienphasen bzw. zur Wiederholung
und Nachbereitung von Unterricht dienlich sein (s.a. Folie).
An Darstellungsformen für diesen Zweck ergeben sich eine Reihe von
Anforderungen (vgl. Folie).
Insbesondere müssen sie ausdrucksstark, selbsterklärend und leicht
verständlich sein. Weiterhin müssen sie es von ihrer Topologie
her ermöglichen, nicht nur einen festen Lehr-Lern-Pfad, sondern ein
hohes Maß an Flexibilität für individuelle Lehr-Lern-Pfade
zu eröffnen. Sequentielle Darstellungsformen, wie Listen, sind dazu
ungeeignet. Baumbasierte Darstellungsformen mit beliebigem und variablem
Knotenausgrad ermöglichen es, Fachkonzepte hierarchisch anzuordnen
und so die Anforderungen an die Vorkenntnisse darzustellen, indem diese
jeweils als Kinder eines Knotens dargestellt werden. Da alle Kinderknoten
gleichberechtigt sind, bleibt die Reihenfolge der Aneignung der mit ihnen
verbundenen Fachkonzepte offen. Reine Baumdarstellungen des Vorkenntnisgeflechts
erweisen sich als nachteilig, wenn Fachkonzepte dieselben Vorkenntnisse
benötigen. Der, die gemeinsamen Vorkenntnisse repräsentierende,
Teilbaum wird dann so oft in den Gesamtbaum übernommen, wie es Elemente
gibt, die diese Vorkenntnisse erfordern. Dadurch wird die Darstellung schnell
unhandhabbar. Zyklenfreie, gerichtete Graphen vermeiden dieses Problem
und bieten ferner den Vorteil, verschiedene Relationen zwischen Knoten
darzustellen. Fachkonzepte können darin durch eine "ist-erforderlich-für-"
oder eine "ist-hilfreich-für-Relation" strukturiert werden. Weiterhin
muss die Darstellungsform hinreichend ausdrucksstark sein, um z. B. boolesche
Verknüpfungen zwischen über Relationen verbundenen Knoten zu
realisieren. Es muss sich ausdrücken lassen, dass verschiedene Elemente
gemeinsam als Vorkenntnisse für andere benötigt werden oder dass
aus einer Menge von Elementen wenigstens eines als Vorkenntnis benötigt
wird. Bei alledem bietet die Verwendung von standardisierten Darstellungsformen
in der Regel den Vorteil, dass bereits Editoren existieren, auf die zurückgegriffen
werden kann.
Unter Berücksichtigung der gegebenen Anforderungen erweisen sich
folgende, standardisierten Darstellungsformen für den gegebenen Zweck
prinzipiell als geeignet: Und-Oder-Bäume, Begriffsnetze (concept maps)
und semantische Netze. Begriffsnetze ermöglichen zwar beliebige Relationen,
die boolesche Verknüpfung ist aber nicht darstellbar. Semantische
Netze eröffnen den größten Darstellungsspielraum, allerdings
stark zu Lasten der Übersichtlichkeit. Die Erweiterung von Und-Oder-Bäumen
zu azyklischen Und-Oder-Graphen stellt den besten Kompromiss bzgl. der
gegebenen Anforderungen dar (vgl. [Br00a],
[BS01]).
Lerninhalte von OOM wurden mit dieser Darstellungsform erfolgreich vom
Autor strukturiert (vgl. Beispiele in Abb. 3 und Folie).
Abbildung 3: Strukturierung und Repräsentation von Fachkonzepten
von OOM im Und-Oder-Graph
4.2 Aufgabenklassen
Die inhaltliche Schwerpunktverschiebung vom Programmieren hin zum Modellieren
muss im gesamten Informatikunterricht umgesetzt werden. Damit werden neue
Aufgabenklassen erforderlich, anhand derer sich die neuen Fachkonzepte
erlernen lassen. In der Fachdidaktik findet sich ein großer Reichtum
an publizierten Programmieraufgaben und -lösungen, Beispiele zur Modellierung
sind noch selten. In Lehrbüchern zu OOM findet man einen reichen Vorrat
an Aufgabenstellungen zur objektorientierten Modellierung, die wegen ihres
einführenden Charakters auch für den Informatikunterricht herangezogen
werden können (z. B. [Ru93], [Ba99]).
Da es sich bei den Adressaten dieser Lehrbücher aber nicht um Schülerinnen
und Schüler handelt, werden Kriterien formuliert, anhand derer Aufgabenstellungen
für den Informatikunterricht ausgewählt bzw. transformiert werden
können (vgl. auch [Br00b]):
-
Fachkonzepte: Es werden nur diejenigen Aufgaben ausgewählt,
die sich auf die für den Informatikunterricht ausgewählten Fachkonzepte
beziehen.
-
Betonung der Modellierung: Da es hier um neue Aufgabenklassen zu
OOM geht, ist die Betonung der Modellierung zentral.
-
Sprachenunabhängigkeit: Die Formulierung der Aufgabe soll so
gewählt sein, dass keine spezielle Modellierungs- oder Programmiersprache
zur Bearbeitung erforderlich ist. Damit wird gewährleistet, dass die
Aufgabe an die im Unterricht verwendeten Sprachen angepasst werden kann.
-
Komplexität: Es werden Aufgaben sehr unterschiedlicher Komplexität
benötigt, um sowohl einzelne Modellierungsschritte als auch die selbstständige
Konstruktion komplexer Modelle erlernen zu können. Zu komplexe Aufgabenstellungen
führen zur Überforderung und binden zu viel Unterrichtszeit.
Dadurch verursachte Misserfolgserlebnisse führen meist zum Verlust
der Motivation bei Lernenden.
Analysiert man Übungsaufgaben zu OOM, so lassen sich diese i. d. R.
in verschiedene Arbeitsaufträge und einen Beispielkontext trennen.
Klassen neuer Übungsaufgaben lassen sich dadurch identifizieren, dass
die nach den zuvor genannten Kriterien ausgewählten Aufgabenstellungen
von ihren jeweiligen Beispielkontexten getrennt und somit zu strukturierten
"Aufgabengerüsten" reduziert werden (s. Folie).
Für jede Aufgabenklasse wird angegeben, welche Materialien zur Verfügung
stehen bzw. welche Information gegeben ist und worin der Auftrag besteht
bzw. welche Information gesucht ist, wie z. B. in folgender Aufgabenklasse:
Gegeben: |
Liste von Klassen-, Attribut- und Operationsnamen mit kurzer Beschreibung |
Gesucht: |
Zuordnung von Attributen und Operationen zu Klassen |
Weitere Beispiele zeigt diese Folie.
Eine Sequenz n unabhängiger Teilaufgaben zum selben Beispielkontext
führt zu n verschiedenen Aufgabenklassen. Durch n aufeinander aufbauende
Teilaufgaben zum selben Beispielkontext wird der Lösungsweg einer
komplexeren Aufgabenstellung vorstrukturiert. Jede dieser Teilaufgaben
kann als eigene Aufgabenklasse aufgefasst werden, für die dann das
zu ihrer Bearbeitung erforderliche Wissen entweder direkt im Aufgabentext
bereitgestellt oder durch vorgelagerte Aufgabenstellungen erarbeitet werden
muss. Durch Kombination dieser elementaren Aufgabenklassen lassen sich
komplexere Aufgabenklassen konstruieren, bspw. dadurch, dass für den
Lösungsweg erforderliche Zwischenergebnisse nicht in eigenen Teilaufgaben
erarbeitet werden, sondern durch den Lernenden selbst gefunden werden müssen.
Die Aufgabenklassen werden so strukturiert und in einer Baumstruktur
angeordnet, dass Aufgabenklassen, die sich auf eine spezielle Modellierungstechnik
oder ein spezielles Modelldetail beziehen, die Blätter bilden. Innere
Knoten bilden Aufgabenklassen, die verschiedene Aspekte kombinieren. Diese
haben zugleich auch Sicherungscharakter für in der Hierarchie tiefer
befindliche Knoten. Die selbst- und vollständige Modellierung eines
Informatiksystems bildet in dieser Struktur den Wurzelknoten. In [Br00b]
wurden Aufgabenstellungen zur Konstruktion eines statischen Systemmodells
auf die beschriebene Weise analysiert und dokumentiert und dabei die in
Abb. 4 dargestellte Hierarchie von Aufgabenklassen konstruiert. Ziel dieser
Strukturierung ist es nicht, kreative Prozesse der Unterrichtsgestaltung
durch schematische Darstellungen einzuengen. Vielmehr soll dazu beigetragen
werden, geeignete Fachkonzepte fachdidaktisch leichter zugänglich
zu machen, ihre Verbreitung zu fördern und damit Informatikunterricht
zu verbessern. Diese Folie
zeigt den erwarteten Gewinn durch Aufgabenklassen für Lernende und
Lehrende.
Abbildung 4: Aufgabenklassen bei der Konstruktion eines statischen
Systemmodells
Um Übungsaufgaben für Informatikunterricht zu OOM zu konstruieren,
sind neben abstrakten Aufgabenklassen auch konkrete und geeignete, motivierende
Beispielkontexte erforderlich. Dieser Beispielkontext liefert dann den
inhaltlichen Rahmen für die jeweilige Aufgabenstellung. Aufgrund der
Analyse solcher Beispielkontexte wurden folgende Kriterien für die
Auswahl von Beispielkontexten abgeleitet:
-
Eignung für OOM: Nicht jeder Beispielkontext legt ein objektorientiertes
Vorgehen gleichermaßen nahe (s. z.B. [Fü99]).
Keinesfalls sollte dies durch Lehrende erzwungen werden. Eine Ausnahme
hiervon kann lediglich ein Vergleich der Eignung verschiedener Programmierparadigmen
zur Lösung derselben Problemstellung sein.
-
Lebensweltbezug: Der Beispielkontext sollte aus der Lebenswelt der
Lernenden stammen. Diese sollten die vielfältigen Zusammenhänge
des Realitätsausschnittes aufgrund eigener Erfahrung kennen oder hinreichend
viel Information darüber recherchieren können. Ein unbekannter
Kontext erfordert zunächst eine zeitaufwendige Auseinandersetzung
damit. Die Aufmerksamkeit kann dann nicht auf das Ziel, Modellierung zu
erlernen, konzentriert werden.
-
Motivation: Ein Beispielkontext muss motivierend sein, um die Aufmerksamkeit
der Lernenden zu binden und ihr Interesse für weitere Beschäftigung
mit den Inhalten zu wecken. Dies kann z. B. durch Kontexte geschehen, die
den Lernenden aufgrund eigener Interessen Freude bereiten, oder die ihnen
einen gewissen Nutzen für sich oder ihr Umfeld versprechen. Von besonderer
Bedeutung sind Beispielkontexte zum Erlernen neuer Inhalte. In Verbindung
mit den Aufgabengerüsten sollte ein solcher Beispielkontext Spannung
aufbauen und aufrecht erhalten. Der Reiz des Neuen soll dazu genutzt werden,
die Beschäftigung mit einer Problemstellung zu motivieren.
-
Leichte Änderbarkeit und Erweiterbarkeit: Strukturierungstechniken,
wie Klassenhierarchien, abstrakte Klassen, etc. zeigen ihre Qualität
erst, wenn bestehende Strukturen verändert bzw. erweitert werden.
Das setzt einen entsprechend offenen Beispielkontext voraus, in dem Erweiterungen
und Modifikationen der Struktur möglich und sinnvoll sind. In diesem
Zusammenhang kann zwischen größeren Projekten und einer Verkettung
kleinerer Beispiele unterschieden werden. Ein größeres Projekt
kann von vornherein so gewählt werden, dass die Anwendung der o. g.
Strukturierungstechniken Vorteile bringt. Die Erstellung einer Gesamtlösung
kann aber je nach Projektgröße sehr zeitintensiv sein und damit
zum Motivationsverlust bei den Lernenden führen. Bei einer Verkettung
aufeinander aufbauender kleinerer Beispiele kann das Ende flexibler gewählt
werden. Ferner können bspw. verschiedene Klassenstrukturen erstellt
und modifiziert werden und die Qualität der Techniken dadurch bewertet
werden. Erweiterbare Kontexte, die auch Verknüpfungen fachlicher Zusammenhänge
ermöglichen, fördern eine angemessene Binnendifferenzierung.
Einen Ausschnitt aus einer Modellierungsaufgabe zeigt diese Folie.
Das Szenario (auf dem hier gezeigten Niveau) ist den Lernenden i.d.R. bekannt.
Mögliche Aufgaben sind hier, je nach Bildungsstand:
-
Beschreibung des Diagramms mit eigenen Worten,
-
Zuordnung von gegebenen Attributen und Methoden zu den Klassen (Unterscheidung
nach einfacher und mehrfacher Zuordnung möglich),
-
Benennung der Relationen und Spezifikation der Multiplizitäten,
-
inhaltliche Modifikation / Ergänzung des Klassendiagramms,
-
Restrukturierung des Klassendiagramms unter Verwendung von Vererbungsbeziehungen,
-
Konstruktion eines Objektdiagramms zu einer textuell beschriebenen Situation,
-
...
4.3 Einsatzszenario
Die Repräsentation der Wissensstrukturen dient dazu, Lernenden und
Lehrenden eine bessere Orientierung bei der Kompetenzentwicklung zu ermöglichen,
indem gezeigt wird, wie einfache Wissenselemente zur Kompetenz eines komplexeren
Konzeptverständnisses verbunden werden. Es wird gezeigt, welche einfachen
Konzepte von Lernenden verstanden werden müssen, welches Vorwissen
sie haben müssen, um ein komplexeres Konzept zu durchdringen. Es handelt
sich bei dieser Repräsentation um ein mögliches Modell des angestrebten
fachlichen Lernfortschrittes, das schrittweise aufgrund von Unterrichtserfahrungen
um Kompetenzbilder anzureichern ist. Dadurch gelingt es, den Lehr-Lern-Prozess
besser am Vorwissen der Lerngruppe zu orientieren. Die Anwendung von höherwertigen
Konzepten oder Methoden im Sinne vorwegnehmenden Lernens soll hierdurch
keineswegs in Frage gestellt werden - zum Durchdringen des komplexeren
Konzeptes ist aber das Vorwissen erforderlich, das für die Anwendung
u. U. keine Rolle spielt.. Die Strukturen können zur Gewinnung von
Kriterien für Lernerfolgskontrollen eingesetzt werden, da ersichtlich
wird, welches die zentralen Bestandteile eines Konzeptes sind, die ein
Lernender im Rahmen einer Prüfungssituation diskutieren und anwenden
können muss. Sie dienen damit Lehrenden und Lernenden zur Evaluation
des fachlichen Lernfortschrittes. Weiterhin können die Wissensstrukturen
von Lehrenden dazu verwendet werden, Empfehlungen für die Sequenzierung
von Kursreihen zu erhalten, indem die Auswahl von Übungsaufgaben dem
in den Wissensstrukturen vorgeschlagenen Aufbau der Kompetenzen folgt.
Für die Ausgestaltung kommunikativer Lehr-Lern-Situationen steht mit
den vorgeschlagenen Aufgaben- und Kontextklassen eine fachdidaktische Vorgehensweise
zur Verfügung, mit der sich vielfältige, unterschiedlich komplexe
Problemstellungen für den Informatikunterricht zu OOM einfach durch
Lehrende konstruieren lassen. Dabei ist es immer möglich, die vorgeschlagenen
Aufgabenklassen durch Variantenbildung, Vereinfachung oder Kombination
so zu modifizieren, dass sie für die gegebene Unterrichtssituation
geeignet sind und dazu beitragen, vorhandene Lernbarrieren zu überwinden.
5 Software-Entwicklungswerkzeuge als Lernhilfen?
Informatikunterricht der Vergangenheit setzte auf die Entwicklung von kleinen
Programmen, um daraus Erkenntnisse über Anwendungen in der Lebenswelt
abzuleiten. Das funktionierte, solange beiden, den Unterrichtsbeispielen
und den professionellen Lösungen, die gleichen Prinzipien und Methoden
zugrunde lagen. Lernende handelten nach der gleichen Strategie wie Experten,
allerdings mit Gegenständen von stark reduzierter Komplexität.
Inzwischen sind Algorithmen, Datenstrukturen und Methoden der Software-Entwicklung,
die großen Informatiksysteme zugrunde liegen, prinzipiell andere,
so dass der Transfer vom "Programmieren im Kleinen" auf das "Programmieren
im Großen" [Ap98] nicht empfohlen wird.
Die Tätigkeiten der Lernenden im Informatikunterricht reduzieren
sich häufig auf Anwenden von Standardsoftware und Problemlösen
in einer Programmiersprache. Aufgrund veränderter Bildungsziele werden
objektorientierte Programmiersprachen erlernt. Lernende bevorzugen die
Sprache Java wegen ihrer Bedeutung im professionellen Bereich. Diesem Wusch
geben Lehrende nach. Die Modellierungssprache "Unified Modeling Language
(UML)" und die damit verbundene Werkzeuge für Analyse und Entwurf
kommen im Informatikunterricht zum Einsatz. Diese Werkzeuge werden als
wenig geeignet für das informatische Modellieren im Informatikunterricht
bewertet, da die Komplexität ihrer Benutzungsoberflächen viel
Unterrichtszeit bindet. Das ist aber lediglich ein Symptom der originären
Zielsetzung von Software-Entwicklungswerkzeugen, nämlich professionelle
Software-Entwickler bei der effizienten und möglichst fehlerfreien
Erstellung von Software-Produkten zu unterstützen.
Software-Entwicklungswerkzeuge müssen Funktionalitäten bereitstellen,
die sich im Erkenntnisprozess von Lernenden als Barrieren erweisen, z.
B. Fehlerbegrenzung durch Handlungsverbot. Die für die Vermeidung
bestimmter Fehlerklassen sehr sinnvolle Fehlerbegrenzung durch Handlungsverbot
(z.B. Auswahl des Rückgabetyps einer Methode aus einer Liste von Datentypen)
ist als ständig präsente Funktionalität aus fachdidaktischer
Sicht kritisch zu bewerten, da Lernende auf diese Weise vom System vor
bestimmten Fehlerklassen bewahrt werden und ein Lernen aus diesen Fehlern
somit verhindert wird. Beim Arbeiten ohne ein Software-Entwicklungswerkzeug
oder mit einem, das diese Funktionalität nicht bietet, wird der Anwender
mit solchen Fehlern konfrontiert, ohne eine entsprechende Problemlösungsstrategie
erlernt zu haben. Aus Gründen der Gestaltungsflexibilität bieten
viele Systeme die Möglichkeit, vorbereitete Auswahlfelder um eigene
Freitexteingaben zu ergänzen. Damit wird dieser Punkt zum Teil relativiert
(vgl.Folie).
Im Hinblick auf den Lehr-Lern-Prozess besteht das Hauptproblem darin, dass
die fundamentalen Ideen des Arbeitsgegenstandes, hier also des Erstellens
objektorientierter Modelle, vorausgesetzt werden. Diese Systeme richten
sich an Anwender mit Vorwissen zur Gestaltung objektorientierter Problemlösungen
und helfen diesen, alles Wesentliche bei der Modellierung zu berücksichtigen,
bestimmte Routineaufgaben zu automatisieren und die Qualität der Lösung,
wo möglich, zu erhöhen. Für die Aneignung von Modellierungskonzepten
sind diese Systeme nicht konzipiert und nicht geeignet. Produktentwicklung
und die Ausbildung von Software-Entwicklern sind keine Ziele des Informatikunterrichts.
Es ist ein anderes Ziel, Lernende im Erkenntnisprozess zu unterstützen.
In der Fachgruppe "Didaktik der Informatik" entwickelt eine studentische
Projektgruppe im WS 2001/02 und im SS 2002 unter Mitbetreuung des Autors
eine Lernumgebung für
objektorientiertes Modellieren im Informatikunterricht (vgl. Folie),
die Lernenden einen handlungsorientierten, explorativen Zugang zum objektorientierten
Modellieren eröffnen soll.
6 Schlussfolgerungen und Ausblick
Im Rahmen dieser Arbeit wurde begründet, dass die unterrichtliche
Behandlung von OOM als Problemlösungsmethode dazu geeignet ist, Ziele
allgemein bildenden Informatikunterrichts umzusetzen. Ferner wurde gezeigt,
dass fachwissenschaftliche Erkenntnisse zum OOM dazu genutzt werden können,
den Mangel an Lehr-Lern-Materialien in der Fachdidaktik zu beseitigen.
Im Weiteren werden diese Arbeiten nun verfeinert. Schwerpunkte werden dabei
Besonderheiten von Modellierungstechniken und Vorgehensweisen, sowie die
bessere Berücksichtigung von Alternativen bei der Strukturierung der
Fachkonzepte einerseits und die Erweiterung der Aufgabenklassen um dynamische
Aspekte und deren Verzahnung mit den statischen andererseits sein. Das
Zusammenwirken der Komponenten des Konzepts zeigt diese Folie.
Die Entwicklungsstufen des Konzeptes werden prozessbegleitend erprobt und
evaluiert ab 2001, um parallel dazu sowohl Konzept als auch Entwurfsmethodik
verbessern zu können.
Literaturverzeichnis
[Ap98] |
Appelrath,
H.-J.; Boles, D.; Claus, V.; Wegener, I.: Starthilfe Informatik. B.G. Teubner,
Stuttgart, 1998. |
[Ba99] |
Balzert,
H.: Lehrbuch der Objektmodellierung. Spektrum Akademischer Verlag, Heidelberg,
1999. |
[BC89] |
Beck, K.; Cunningham,
H.: A laboratory for teaching object-oriented thinking. In: Proceedings
of OOPSLA 1989, SIGPLAN notices (ACM) vol. 24, New Orleans, 10/1989. |
[Bo94] |
Booch, G.: Objektorientierte Analyse und Design. Addison-Wesley, Bonn,
1994. |
[BRJ98] |
Booch, G.; Rumbaugh, J.; Jacobson, I.: The Unified Modeling Language
User Guide. Addison-Wesley, Reading, Massachusetts, 1998. |
[Br00a] |
Brinda,
T.: Didaktische Systeme für objektorientiertes Modellieren (OOM) im
Informatikunterricht. In (Gesellschaft für Informatik Hrsg.): Informatiktage
2000. Konradin, Leinfelden-Echterdingen, 2000, S. 282-285. |
[Br00b] |
Brinda,
T.: Sammlung und Strukturierung von Übungsaufgaben zum objektorientierten
Modellieren im Informatikunterricht. In: Log In 20 (2000) 5, S. 39-49. |
[Br01] |
Brinda,
T.: Einfluss fachwissenschaftlicher Erkenntnisse zum objektorientierten
Modellieren auf die Gestaltung von Konzepten in der Didaktik der Informatik.
In: Magenheim, J.; Keil-Slawik, R. (Hrsg.): Informatikunterricht und Medienbildung.
Köllen, Bonn, 2001. |
[BS01] |
Brinda,
T.; Schubert, S.: Didaktisches System für objektorientiertes Modellieren.
Forschungsbericht Nr. 752, Fachbereich Informatik, Universität Dortmund,
2001. |
[FS97] |
Fowler, M.; Scott, K.: UML distilled. Applying the standard object
modeling language. Addison Wesley Longman, Inc., 1997. |
[Fü99] |
Füller, K.: Objektorientiertes Programmieren in der Schulpraxis.
In (Schwill, A. Hrsg.): Informatik und Schule. Fachspezifische und fachübergreifende
didaktische Konzepte. Springer, Berlin, 1999, S. 190-201. |
[Ga96] |
Gamma,
E.; Helm, R.; Johnson, R.; Vlissides, J.: Entwurfsmuster. Addison-Wesley,
Bonn, 1996.<â meModified=2002/11/11 11:24:10=2002/11/11>âmeModified
|
Benutzer: gast
Besitzer: schwill
Last modified:
|
|
|
|