Life^3/Unterrichtsmethoden

Vorwort zu den Unterrichtsmethoden

Ein paar Hinweise zu den aufgeführten Unterrichtsmethoden

Unter der Rubrik Unterrichtsmethoden stellen wir einzelne methodische Hinweise für den Informatikunterricht vor.

Diese beziehen sich immer auf den Bereich Objektorientierung / Informatik.

Die meisten Unterrichtsmethoden können mit verschiedenen Schwerpunkten eingesetzt werden:

• Zur Einführung eines neuen Konzepts, oder einer Vorgehensweise
• Zur Anwendung, Vertiefung oder Reflexion

Wir konzentrieren uns auf Unterrichtsmethoden, die Elemente der Softwareentwicklung und des objektorientierten Modellierens für Schülerinnen und Schüler erfahrbar machen. Wir legen also einen Schwerpunkt auf Vorgehensweisen.

Die Darstellung der Unterrichtsmethoden erfolgt schematisch nach einem einheitlichen Aufbau. Wir lehnen uns hier an die Diskussion um pädagogische Muster an: Die Methoden stellen als Muster keine fertigen Rezepte dar, sondern sind Muster, die an die individuelle Situation angepasst werden müssen und sollen. Siehe: Pedagogical Patterns Project.

Die formalisierte Schreibweise soll den Leseaufwand verringern - hoffentlich sehen Sie das als hilfreich an!

Ausführlichere Beschreibungen, zusammen mit Beispielen etc. zu einzelnen methodischen Mustern finden Sie in der Kategorie Unterrichtseinheiten.

Bisher sind hier folgende Unterrichtsmethoden beschrieben:

Grundlage einer objektorientierten Modellierung ist die Analyse. CRC-Karten haben sich hier als geeignetes Arbeits- und Dokumentationswerkzeug etabliert. Die Methode CRC-Kartenanalyse im Unterricht gibt Anregungen für eine mögliche Integration der Analyse im Unterricht.

Um ein mittels CRC-Karten beschriebenes Modell auf Konsistenz zu testen, bietet sich die Methode des Objektspiels an.

Wie ein möglicher Übergang von der Analysephase zur Designphase erfolgen kann, und was dabei beachtet werden muss, wird in Vom CRC-Modell zum Klassendiagramm beschrieben.

Liegt ein fertiges, d.h. bereits implementiertes Modell vor, so beschreibt die Unterrichtsmethode Grafische Oberfläche hinzufügen, wie die Integration einer grafischen Benutzeroberfläche auf im Unterricht erstellte Modelle erreicht werden kann, und welche Schwierigkeiten dabei beachtet werden müssen.

Die Methode Einführung in Ereignisse stellt dar, wie das Thema Ereignisorientierung im Unterricht eingeführt werden kann.

Schließlich wird in Ereignisbehandlung integrieren aufgezeigt, wie die Integration der Ereignisbehandlung in eigene bzw. vorgegebene Software-Projekte erfolgen kann.

CRC-Karten-Analyse im Unterricht

Name

CRC-Karten-Analyse im Unterricht

Kurzbeschreibung

Das objektorientierte Modell einer Anwendungsdomäne hängt stark von den Anforderungen (des Auftraggebers) ab: Je nach gewünschter Funktionalität fällt das Modell unterschiedlich aus.

Die anwendungsfallgetriebene CRC-Karten-Analyse klärt die Anforderungen mit Hilfe der Definition von Anwendungsfällen und erstellt darauf aufbauend ein Analysemodell der Anwendungsdomäne.

Auch bekannt als

Modellieren mit CRC-Karten, Design, Entwurf

Problem

Nahezu alle Abläufe in einem realen System (der Anwendungsdomäne) sind durch Aktionen und Interaktionen geprägt, die oft unbemerkt und ohne scheinbare Initiierung erfolgen. In der Analysephase muss ausgewählt werden: Welche Aktionen und Interaktionen sollen erfasst werden, welchem Objekt sind sie zuzuordnen (Beispiel: Der Torwart fängt den Ball oder: Der Ball wird gefangen vom Torwart). Unwesentliches wird weggelassen, woraus die Frage resultiert: "Was gehört zum Modell, was nicht?"

Zielgruppe/Kontext

Analysephase von Softwareentwicklungsprojekten. In unserem life³-Phasenmodell: "Phase 2 / Schritt A" und in "Phase 3"

(Lern)-Schwierigkeiten

Die Systemgrenze muss gefunden werden: Was gehört zum Modell, was ist überflüssig und wird weggelassen.

Diese Frage kann nur geklärt werden, wenn der Zweck bzw. der Einsatz der späteren Software klar ist. Anfängerinnen und Anfänger neigen dazu, ihnen naheliegende Elemente direkt ins Modell abzubilden. Schwierigkeiten entstehen dann, wenn unterschiedliche Meinungen bezüglich des Offensichtlichen/Naheliegenden geäußert werden oder wenn wesentliche Aspekte in der Analysephase übersehen werden.

Lösung

CRC-Analyse kann sehr gut wie eine Brainstorming-Sitzung in Gruppen von etwa vier Schülerinnen und Schülern durchgeführt werden.

Ausgangspunkt ist das Identifizieren/Finden von Objekten, die auf Karteikarten, den sog. CRC-Karten, notiert werden: Oben wird der Klassenname notiert, in zwei Spalten darunter die Verantwortlichkeiten und Beteiligte.

HIER FEHLT NOCH EIN BILD...

Zum Verfeinern des Modells zieht man Anwendungsfälle hinzu: das sind von einem Benutzer (Akteur) 'angestoßene' bzw. 'angefragte' Verantwortlichkeiten, die ihm meist ein Ergebnis zurückmelden.

Die Anwendungsfälle werden gesondert auf einer Liste notiert. Sie bekommen einen Namen und eine kurze Erläuterung. Mit Hilfe des Objektspiels können die einzelnen Anwendungsfälle getestet werden. Anschließend werden die Gruppenergebnisse in der Gesamtgruppe zu einem Modell zusammengeführt und nochmals getestet, zumindest jedoch sollten sie besprochen werden, um Alternativen aufzuzeigen sowie um Vor- und Nachteile einzelner Varianten anzusprechen.

Ergebnis

Zusammen mit den Anwendungsfällen zeigt das CRC-Modell die wesentlichen Elemente des noch zu designenden Fachklassenmodells und seine Zielsetzung auf (Was soll der spätere Benutzer machen können?). Die CRC-Karten können anschließend in ein solches Fachklassenmodell überführt werden.

Die Anwendungsfälle sind im Übrigen noch von Bedeutung, sie können später immer wieder zum Testen des weiterentwickelten Modells herangezogen werden. Außerdem unterstützen sie die Anbindung einer grafischen Oberfläche sowie damit verbunden die Integration der Ereignisorientierung, da sie Start- und Endpunkte von Benutzerinteraktionen festhalten.

Diskussion/Konsequenzen

Schon früh erfahren die Schüler, dass es nicht nur eine Lösung gibt. Hier liegt zunächst - allerdings nur scheinbar - eine Schwäche dieser Methode, da sie zu langwierigen, oft als lästig empfundenen Diskussionen führen kann. Doch mit wachsender Fachkompetenz der Schülerinnen und Schüler ergeben sich hier Möglichkeiten, alternative Lösungswege zu entwickeln, und die Güte von Lösungen anhand ihrer Konsequenzen abzuschätzen.

Anwendungsfälle werden schnell als lästiges Übel empfunden, sie können in der Gesamtgruppe jedoch als Maßstab genutzt werden, um die einzelnen Lösungen zu vergleichen: Sind die Anwendungsfälle vollständig? Sind sie vollständig vom Modell unterstützt? Hat das Modell zusätzliche, evtl. überflüssige Eigenschaften?

Es kann vorkommen, dass die Gruppen lieber direkt ein UML-Klassendiagramm erstellen wollen und die Analyse überspringen, insbesondere wenn die Anwendungsdomäne bekannt ist. Hierbei sollte auf die Bedeutung einer sorgfältigen Analyse aufmerksam gemacht werden und Konsequenzen erörtert werden.

Objektspiel

Name

Objektspiel

Kurzbeschreibung

Schülerinnen und Schüler müssen die internen Abläufe objektorientierter Programme verstehen. Dazu spielen sie in einer Art Rollenspiel die Objekte eines Programms.

Auch bekannt als

Object Game; Rollenspiel; Simulation Game

Problem

Um ein objektorientiertes Programm zu verstehen, müssen statische Beschreibungen (Klassen und Objekte) und dynamische Beschreibungen (Sequenzen) als Einheit betrachtet werden. Die vielen formalen und syntaktischen Einzelheiten der jeweiligen Darstellungen/Notationen erschweren dieses Verständnis jedoch.

Zielgruppe/Kontext

Schülerinnen und Schüler im Anfangsunterricht benötigen einen Überblick, was Objektorientierung ausmacht. Beim Erstellen kleinerer Modellierungen kann das Objektspiel eine bereits erfolgte Modellierung für den ganzen Kurs anschaulich werden lassen und als Methode zur Überprüfung des Modells benutzt werden. Das Objektspiel kann auch zur Einführung von CRC-Karten benutzt werden. Ebenso kann es genutzt werden, um unterschiedliche Modelle zu vergleichen.

(Lern)-Schwierigkeiten

Das Zusammenspiel der Objekte macht die Funktionalität eines objektorientierten Programms aus. Im Quelltext sieht man jedoch nur die Beschreibungen der Klassen. Und auch Klassendiagramme lassen lediglich eine solche statische Sicht zu.

Um Handlungssequenzen und Sequenzdiagramme zu verstehen, benötigt man Grundwissen über Objekte (hier sind zu nennen die Begriffe 'Identität', ' Zustand'). Anfänger aber kennen viele dieser Konzepte nicht. Zudem kennen sie die Syntax objektorientierter Sprachen nicht.

Um nun aber OO-Konzepte angemessen zu verstehen, benötigt man eine generelle Idee, was Objekte sind und was sie machen.

Lösung

Schülerinnen und Schüler, die die Rolle eines Objektes übernehmen, erhalten eine Klassenkarte (CRC-Karte) mit der Beschreibung der Klasse (Verantwortlichkeiten, Beteiligte) des Objektes sowie zusätzlich eine Objektkarte, auf denen das notwendige Wissen des Objekts zu jedem Zeitpunkt notiert werden kann ('Zustand').

Unter Anleitung des Lehrers spielen die Schüler einzelne Abläufe durch. Jedes Objekt wird von einem Schüler gespielt. Die Schüler dürfen dabei nur die Aufgaben verrichten, die auf ihren Klassenkarten notiert sind. Hierzu dürfen sie die neben den einzelnen Aufgaben notierten Objekte zur Mitarbeit auffordern. Weiterhin dürfen sie nur von dem Wissen Gebrauch machen, das auf ihren Objektkarten festgehalten ist. Die Impulse, die von außen (einem Akteur) gegeben werden müssen, entsprechen den Anwendungsfällen und können als solche thematisiert werden. Die weiteren Regeln des Objektspiels sind:

• nur verbale Kontaktaufnahmen zu anderen Objekten sind erlaubt,
• nur mit den Begriffen der Verantwortlichkeiten arbeiten ( "reden" ),
• nur mit den Beteiligten Kontakt aufnehmen,
• ausschließlich auf der Objektkarte notwendige Zustände notieren ( "keine Gedächtnisleistung des Rolleninhabers").

Ergebnis

Je nach Verwendungsart des Objektspiels haben die Schülerinnen und Schüler entweder ihre Modellierung überprüft, oder grundlegende Einsichten über Objekte gesammelt:

• Objekte haben eine Identität (Peter und Susanne hatten beide dieselben CRC-Karten, waren aber dennoch verschiedene Objekte),
• einen Zustand (haben sich verschiedene Dinge gemerkt),
• können nur die Aufgaben erledigen, die auf ihrer Karte vermerkt sind,
• können ihre Aufgaben durch Zusammenarbeit mit anderen Objekten erledigen;
• wie sie ihre Aufgaben erledigen, hängt auch von ihrem Zustand ab;
• verschiedene Objekte können dieselbe CRC-Karte benutzen, sie gehören dann zur selben Klasse (Peter und Susanne gehörten zur Klasse X).

Diskussion/Konsequenzen

Das Objektspiel wird von einigen Schülern als zu wenig ernsthaft angesehen. Bei einfachen Modellen z.B. sind den Schülern die Abläufe so klar, dass sie sich nicht an die Angaben auf den Karten halten. Hier muss ihnen deutlich gemacht werden, wie wichtig es ist, dass beim Objektspiel dennoch die Regeln eingehalten werden: Bei späteren Test von eigenen Modellen mit dem Objektspiel ist dies nämlich Voraussetzung, um Aufschluss über die Gültigkeit bzw. Konsistenz des eigenen Modells zu erhalten.

Bemerkungen

Es gibt in dieser ersten Phase der Modellierung und bei diesem Stand der Softwareentwicklung keine grundsätzlich festzulegende Abfolge von Tätigkeiten, sondern es ist ein Wechselspiel zwischen dem genauen 'Hinsehen', 'Erkunden' der Realität, dem Finden von Objekten und Aktivitäten, dem Finden und Verfeinern von Anwendungsfällen und dem Erstellen von CRC-Karten. In diesem Rahmen bietet das Objektspiel die Möglichkeit, ohne "syntaktischen Aufwand" die Modellierung zu verbessern.

Objektkarten ermöglichen es Objekte zu identifizieren und ihren Zustand festzuhalten:

objektName : Klassenname

Attributname = wert ... ... ...

CRC-Karte der Klasse Feld und Objektkarte des Feldes Otto:

Feld
nimmt Einsatz auf gibt Einsatz abt behalte Einsatz ein kennt setzenden Spieler kennt nächstes Feld kennt seine Nummer	Feld Spieler

otto : Feld

Einsatz = 0 Nummer = 1 setzenderSpieler = ulli naechstesFeld = marc

Referenzen

Peter Bergin: The Object Game