Eduwiki - Benutzerbeiträge [de]

Lernroboter

2021-11-03T11:21:16Z

Koellner: /* Anlaufstellen */

Im Rahmen dieser Website werden unterschiedliche Unterrichtseinheiten vorgestellt bzw. interessierten Lehrkräften zur Verfügung gestellt. Übergeordnetes Ziel der Unterrichtsreihen ist eine Förderung von Computational Thinking und der Problemlösefähigkeit im Grundschulalter. Um diese Fähigkeit zu fördern, steht die Arbeit mit unterschiedlichen Lernrobotern im Mittelpunkt. Lernroboter sind meist handliche, kindlich ansprechende Roboter, die auf unterschiedliche Art und Weise von den Lernenden programmiert werden können. Im Umgang und der Arbeit mit den Lernrobotern sollen bei den Lernenden bestimmte Kompetenzen und Fähigkeiten gefördert werden. Im Lehrplan NRW der Grundschule kann die Arbeit mit Lernrobotern dem Kompetenzbereich Problemlösen und Handeln zugeordnet werden; insbesondere den Kompetenzen technische Probleme lösen und Algorithmen erkennen und formulieren.

Es gibt bereits eine Vielzahl unterschiedlicher Lernroboter. Es werden im Folgenden zwei Lernroboter kurz vorgestellt, mit denen sich die auf dieser Website vorgestellten Unterrichtseinheiten beschäftigen werden.

===Ozobot===
Den Ozobot gibt es in zwei verschiedenen Ausführungen, die sich für verschiedene Zielgruppen eignen. Zum einen der Ozobot Bit und zum anderen der Ozobot Evo. Der Lernroboter kann, in egal welcher Ausführung, durch die Ausstattung von fünf Sensoren an der Unterseite schwarze Linien abfahren. Solange der Roboter nicht programmiert ist, entscheidet er an Kreuzungen von Linien zufällig. Mithilfe der Einarbeitung von Farbcodes kann das Fahrverhalten des Roboters beeinflusst werden. Mit dem Ozobot Evo sind zwei Programmiermöglichkeiten möglich. Zum einen die einmalige, direkte Programmierung per Linien-Coding. Zum anderen ist auch eine manuelle Programmierung per App möglich. Für einen Unterricht mit dem Ozobot steht im Internet bereits eine Menge an Material zur Verfügung - nicht nur auf unserer Webseite. Auch auf YouTube sind zahlreiche Videos mit praktischen Anwendungsideen zu finden. Weitere Informationen zum Ozobot finden Sie [[Ozobot|hier]].
{| class="wikitable"
|+
![[Datei:Ozobot hinten.jpg|mini|Ozobot von hinten]]

 
! [[Datei:Ozobot unten.jpg|mini|Ozobot von unten]]

|}

===Bluebot===
Der Bluebot ist ein Roboter mit Rädern und Augen, der mithilfe von Richtungstasten auf der Oberseite programmiert werden kann. Dabei sind die Befehle Vorwärts, Rückwärts, Links- und Rechtsdrehung möglich. Kinder können eine beliebige Abfolge von Bewegungen speichern. Nach dem Speichern der Abfolge führt der Roboter die Bewegungen schrittweise aus. Ergänzend zum Roboter kann eine Programmierleiste genutzt werden, in der die Befehlskette mithilfe von Symbolen dargestellt werden kann. Genauso wie der Ozobot ist die Hülle des Lernroboters transparent, sodass ein interessanter Blick in das Innenleben des Roboters stattfinden kann.
{|
![[Datei:BlueBot vorne.jpg|mini|BlueBot von vorne]] 
![[Datei:BleuBot oben.jpg|mini|BlueBot von oben]]
|}
 

===Beschaffungsmöglichkeiten von Lernrobotern===
Oftmals sind keine schuleigenen Roboter vorhanden und die Anschaffung solcher ist, zum Beispiel aus finanziellen Gründen, nicht möglich. In solchen Fällen kann das Ausleihen von Lernrobotern für einzelne Unterrichtseinheiten eine gute Alternative darstellen. An dieser Stelle werden deshalb fortlaufend Anlaufstellen zur Ausleihe gesammelt und aufgelistete. Weitere Angebote sind gerne gesehen und können zur Ergänzung an Michael Lenke (michael.lenke@upb.de) gesendet werden.

====Anlaufstellen====

*[https://www.kmz-paderborn.de/medienzentrum/digitales-klassenzimmer/lernen-mit-medien.php Kreismedienzentrum]
*[https://bibliothek.live/Angebote/Digitale-Angebote/Digital-Kids Stadtbibliothek Paderborn]
*Universität Paderborn

[[Kategorie:Definition]]
[[Kategorie:Glossar]]

Big Data

2021-11-03T11:10:32Z

Koellner: Seite nicht mehr finden

@linked to [[Data Science]]

Content following

__NICHT_INDEXIEREN__

Lernroboter

2021-11-03T10:58:36Z

Koellner:

Life^3/Unterrichtsmethoden

2021-11-02T15:05:23Z

Koellner: Ergänzung - 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:
{| class="wikitable"
|objektName : Klassenname
|-
|Attributname = wert

...

...

...
|}
CRC-Karte der Klasse Feld und Objektkarte des Feldes Otto:
{| class="wikitable"
| colspan="2" |Feld
|-
|nimmt Einsatz auf

gibt Einsatz abt

behalte Einsatz ein

kennt setzenden Spieler

kennt nächstes Feld

kennt seine Nummer
|Feld

Spieler
|}
{| class="wikitable"
|otto : Feld
|-
|Einsatz = 0

Nummer = 1

setzenderSpieler = ulli

naechstesFeld = marc
|}

=== Referenzen ===
[http://csis.pace.edu/~bergin/patterns/objectgame.html Peter Bergin: The Object Game]

Life^3/Didaktisches Konzept

2021-11-02T14:52:50Z

Koellner: Ergänzung - Lerntheoretischer Hintergrund

=='''Überblick Didaktisches Konzept'''==
Im Bereich Didaktik finden Sie Informationen zum didaktischen Hintergrund, zum Beispiel erklären wir hier das life³-Phasenmodell und den Ansatz der systemorientierten Didaktik.

Das didaktische Konzept des life³-Projekts lehnt sich an den in Paderborn vertretenen Ansatz der Systemorientierten Didaktik der Informatik an. Informationen hierzu finden Sie im Bereich Systemorientierte Didaktik.

Mit dem life³-Phasenmodell wird der mögliche Aufbau einer Unterrichtssequenz zum Einstieg in die Objektorientierung in der Jahrgangsstufe 11/1 beschrieben. Das Phasenmodell wurde an zwei Paderborner Schulen erprobt und unter Einsatz von Befragungen, Tests und videogestützter Unterrichtsbeobachtung evaluiert. Einzelheiten hierzu und zur konkreten Umsetzung des Phasenmodells werden in der Rubrik Unterrichtseinheiten beschrieben.

Hier in dieser Rubrik hingegen finden Sie - wie oben bereits angedeutet - abstraktere Darlegungen zu Aufbau und Konzeption des life³-Phasenmodells. Vielleicht kann dies dazu dienen, unser Vorgehen zu erhellen. Vielleicht werden Sie zu eigenen Ideen angeregt, oder Sie finden Verbesserungsmöglichkeiten, oder Ihnen kommen konkrete Ideen für eigene Unterrichtseinheiten orientiert am life³-Phasenmodell.

==='''Das life³-Phasenmodell'''===

====Phasenmodell für den Einstieg in grundlegende Konzepte und Sichtweisen der Objektorientierung.====
Objektorientierung ist ein spannendes und aktuelles Themengebiet sowohl in der Informatik, speziell der Softwaretechnik, als auch im Informatikunterricht.

Insbesondere das objektorientierte Modellieren als der planende und gestaltende Teil der Softwareentwicklung kann in vielfältiger Weise zur informatischen Bildung beitragen:

*Notationen und Techniken zum Strukturieren von Informationen kennen lernen
*Grundkenntnisse über Struktur und Funktionsweise objektorientierter Software erwerben
*Einblick in den Erstellungsprozess von Software bekommen
*Softwareentwicklung als einen ingenieursmäßigen, technischen Konstruktionsprozess aber auch als einen kreativen Gestaltungsprozess kennen lernen
*Problemlösetechniken und die Arbeit im Team üben
*...

Um diese Ziele im Unterricht zu erreichen, ist ein Verständnis der Grundkonzepte der Objektorientierung eine wesentliche Vorbedingung. Leider sind diese Grundkonzepte erstens sehr zahlreich, zweitens stark miteinander verwoben und drittens oft erst verständlich, wenn man komplexere objektorientierte Programme untersucht oder entwickelt.

Das Phasenmodell verhindert, dass die Schülerinnen und Schüler aufgrund der Komplexität und Vielzahl der objektorientierten Technologien sozusagen "den Wald vor lauter Bäumen nicht mehr erkennen können". Anstelle einzelner, ausgewählter Konzepte stellt es die Grundidee der Objektorientierung in den Mittelpunkt des Unterrichts: Objektstrukturen und deren Interaktion. Damit wird eine auf Zusammenhänge ausgerichtete Perspektive auf die Thematik eingenommen, aus der heraus im Unterricht die notwendigen Konzepte, Notationen, Werkzeuge und Techniken erschlossen werden können.

Der Unterricht orientiert am life³-Phasenmodell wird in drei aufeinander aufbauende Phasen eingeteilt. Jede Phase legt die Grundlagen für die nächste. Die Phasierung erleichtert die Unterrichtsplanung und das Erlernen, da jeweils nur einige ausgewählte Aspekte im Mittelpunkt stehen. In der jeweils folgenden Phase werden diese Elemente für den weiteren Fortschritt genutzt und vertieft.

'''AN DIESER STELLE FEHLT EIN BILD...'''

In der ersten Phase werden die Leitideen, die Notationen und die Benutzung der Werkzeuge vermittelt. Es wird ein kleines objektorientiertes Modell untersucht und verändert. Im Mittelpunkt stehen die beiden Leitideen: Objektstrukturen und Kollaborative Methoden.

In der zweiten Phase wird das Gelernte gefestigt. Es wird gezeigt, wie auf das objektorientierte Modell eine grafische Oberfläche aufgesetzt wird, und wie mittels Ereignisbehandlung mit dem Modell interagiert werden kann. In dieser Phase gibt es verstärkt Übungen zu einzelnen Konzepten.

Die dritte Phase regt die Schüler zur eigenständigen Anwendung und Vertiefung des Erlernten an. Dabei sollen Lernziele auf den Ebenen Bewertung und Reflexion einbezogen werden.

Insgesamt orientiert sich das life³-Phasenmodell am Modell des Cognitive Apprenticeship, dessen Lernwirksamkeit empirisch gut abgesichert ist.
 

=====Phase 1=====
Grundbegriffe und Grundstrukturen
{| class="wikitable"
|+
!
!Schritt A

Anwendungsgebiet erkunden
!Schritt B

Informales Modell erkunden
!Schritt C

Formales Modell erkunden

(Klassenebene)
!Schritt D

Formales Modell erkunden

(Methodenebene)
|-
|Ziele
|Vertraut werden bzw. ins Gedächtnis rufen der Abläufe und Strukturen der Anwendungsdomäne
|Vertraut werden mit objektorientierter Sichtweise der Anwendungsdomäne; Objektstrukturen und Collaborative Methoden kennen lernen
|Vertraut werden mit formaler Notation und der Funktionsweise einer OO-Anwendung und der IDE
|Vertraut werden mit formaler Notation von Aktivitätsdiagrammen, kennen lernen von Kontrollstrukturen
|-
|Medien
|Je nach Domäne, z.B.: Spielmaterial
|CRC- und Objektkarten
|Anwendung, Entwicklungsumgebung mit Debugger, visuell orientiert
|Anwendung, Entwicklungsumgebung mit Debugger, visuell orientiert
|-
|Konzepte
|Entsprechend der Anwendungsdomäne, z.B.:Spieler, Spielzeug, Begriffe für die einzelnen Materialien
|Klasse, Objekt, Verantwortlichkeit, Beziehung, Zustand, Objektspiel, Anwendungsfall
|Klasse, Objekt, Beziehung, Kardinalität, Übersetzen, Methodenaufruf, Parameter, UML
|Story-Diagramme, Bedingte Anweisungen, Schleifen, Parameter
|}
'''Dauer:''' 10 Unterrichtsstunden

'''Lernziele:''' Heranführung der Schüler an eine objektorientierte Sichtweise, die Einführung der Begriffe Klasse, Objekt, Assoziation, Methode, Attribut sowie Interaktionen von Objekten. Desweiteren Metaphern der Objektorientierung als Verständnishilfe für die Grundideen der Objektorientierung, UML-, Klassen- und Objektdiagramme, Benutzen der Werkzeuge Fujaba und des darin integrierten grafischen Debuggers Dobs sowie CRC-Karten und Objektspiel als Analyse- bzw. Modellierungstechniken.

'''Werkzeuge:''' CRC-Karten, Objektspiel, Fujaba und das darin integrierte Dobs (mit Lehreranleitung)

'''Ablauf:''' In ''Schritt A'' sollen sich die Schülerinnen und Schüler mit der Anwendungsdomäne vertraut machen. Werden als Anwendungsdomäne wie in den aufgezeigten Beispielen Spiele gewählt, so können in diesem Schritt die Schülerinnen und Schüler diese praktisch durchführen und sich mit den Spielregeln befassen. Dadurch kann sich in den folgenden Schritten und Phasen die Konzentration auf die objektorientierten Konzepte richten, die an dieser Stelle aber noch keine Rolle spielen sollen. Ein bis zwei Unterrichtsstunden sollten daher für diesen ersten Schritt ausreichend sein.

In ''Schritt B'' wird erstmals eine objektorientierte Sichtweise eingeführt. Mit Hilfe von CRC-Karten als Notationstechnik für Objektorientierte Analyse wird ein Modell für ein Beispiel aus der jeweiligen Anwendungsdomäne (z.B. ein Spiel) erstellt. Die Schülerinnen und Schüler erlernen das Objektspiel: Hierbei sollen sie selbst Objekte spielen, d.h. deren Rolle übernehmen. Sie erhalten CRC-Karten aus dem Modell und dürfen beim Spiel nur die Eigenschaften der Objekte benutzen. Das Objektspiel soll dazu dienen, ein Verständnis für objektorientierte Sichtweisen auszubilden. Die Beispiele sollten dabei so gewählt sein, dass es CRC-Karten (Klassen) gibt, aus denen mehrere Objekte gebildet werden, die sich durch ihre Zustände, die auf Objektkarten festgehalten werden, unterscheiden. Dies soll dazu beitragen, den Unterschied zwischen Klassen und Objekten zu verstehen. Für weitere Informationen siehe: Objektspiel.

In ''Schritt C'' wird eine fertige Implementation (zunächst auf Klassenebene) des zuvor selbst erstellen CRC-Modells mit Hilfe einer IDE am Rechner untersucht. An dieser Stelle erlernen die Schülerinnen und Schüler die formale Notation eines Modells mit Hilfe einer graphischen oder auch textuellen Programmiersprache und den Umgang mit der Entwicklungsumgebung, die im weiteren Verlauf der Unterrichtseinheit eingesetzt werden soll. Wird wie im dargestellten Beispiel eine grafische Notation verwendet, so sollte sich diese an UML orientieren. In diesem Fall müssten in dieser Phase auch bereits UML-spezifische Begriffe wie Kardinalität und Assoziationen erläutert werden. Eventuell aufkommende Begriffe wie Datentypen, Parameter und Kontrollstrukturen werden - soweit nötig - ebenfalls erläutert.

In ''Schritt D'' schließlich rückt die Implementation der Methoden in den Mittelpunkt. Die realisierten Methoden des bereits implementierten Beispiels sollten an dieser Stelle zunächst analysiert werden. Übungsaufgaben können helfen, die Syntax der Programmiersprache bzw. die grafische Notation der Aktivitätsdiagramme zu erlernen und praktische Erfahrung bei der Implementation von Methoden zu erlangen.

=====Phase 2=====
{| class="wikitable"
|+
!
!Schritt A

Schritte aus Phase 1 selbst durchführen,

in richtiger Reihenfolge
!Schritt B

Grafische Oberflächen kennenlernen
!Schritt C

Ereignisbehandlung kennenlernen
|-
|Ziele
|vertraut werden mit Modellierungs- und Softwareentwicklungsprozess, Vertiefen der Kenntnisse und Begriffe, Übertragen auf ein neues Beispiel
|Bibliotheknutzung und Konzept der GUI-Bibliothek verstehen
|Verknüpfung von Modell und grafischer Oberfläche (View), Konzept der Ereignisbehandlung verstehen
|-
|Medien
|CRC-IDE, Bibliothek, Beispiel-Anwendung
|
|IDE, Beispiel-Anwendung
|-
|Konzepte
|Analyse, Design, Test, Fehlersuche, Syntax und Semantik, Schleifen, lokale Variable, Verzweigung, primitive Datentypen
|Bibliothek, bidirektionale/unidirektionale Beziehungen, Bibliotheksklassen
|
Ereignisse, Vererbung, Schnittstellen (Interface), Model-View-(Control)-Konzept MV(C)
|}'''Dauer:''' ca. 30 Unterrichtsstunden

'''Lernziele:''' Verdeutlichung der Rolle und des zeitlichen Ablaufs verschiedener Schritte der Softwareentwicklung, Ereignisbehandlung und Benutzeroberflächen, Algorithmen, Bedeutung und Benutzung von Klassenbibliotheken, Vererbung und Interfaces, Umgang mit Fehlern

'''Werkzeuge:''' Fujaba, Dobs, CRC-Karten, Objektspiel (mit Hilfen des Lehrers)

'''Ablauf:''' Die Schülerinnen und Schüler sollen in dieser zweiten Phase analog zu den Erkundungsschritten der ersten Phase entscheidende Schritte der Softwareentwicklung unter Anleitung der Lehrperson an einem neuen Beispiel weitgehend selbständig durchführen. Das Kennenlernen Grafischer Oberflächen, ihrer Elemente und Strukturen und damit verbunden das Benutzen einer Klassenbibliothek schließt sich in einem weiteren Schritt an. Um Oberfläche und implementiertes Modell sinnvoll miteinander zu verknüpfen, steht im dritten Schritt dieser Phase das Konzept der Ereignisbehandlung im Mittelpunkt.

Die Schritte dieser Phase im Einzelnen:

In ''Schritt A'' sollen - wie bereits angedeutet - die Schülerinnen und Schüler analog zu den Erkundungsschritten der ersten Phase die entscheidenden Softwareentwicklungsschritte bis zur Erstellung eines lauffähigen Modells weitgehend selbständig in Gruppen durchführen. Das beinhaltet wie in der ersten Phase das Erkunden der Anwendungsdomäne, die Erstellung eines informalen Modells mittels CRC-Karten (also eine objektorientierte Analyse), dessen Weiterentwicklung zu einem formalen Modell in UML-Notation (objektorientierter Entwurf bzw. Designschritt) und schließlich die Implementierung der Methoden. Beginnen wird also dieser erste Schritt mit der Einführung eines neuen Beispiels als Anwendungsdomäne. (Im Falle unseres Projekts war dies ein weiteres Spiel: Schatzsuche.) Indem die Schülerinnen und Schüler versuchen, einen Softwareentwicklungsprozess durchzuführen, werden sie einerseits vertrauter mit dem Modellierungs- und Softwareentwicklungsprozess, vertiefen die in Phase 1 erlernten Begriffe, Sichtweisen und Kenntnisse und erwerben andererseits praktische Fähigkeiten im Hinblick auf die CRC-Kartentechnik als Mittel zur Analyse sowie die Benutzung einer IDE als Design- und Implementierungswerkzeug.

Die Anleitung durch die Lehrperson wird hier insbesondere auch darin zu sehen sein, dass sie im Falle von Problemen und Verständnisschwierigkeiten diese für den ganzen Kurs thematisiert, abgeschlossene Softwareentwicklungsschritte reflektieren lässt, und in notwendige neue Begrifflichkeit (z.B. Schleifen, lokale Variablen, Verzweigung, Datentypen, usw.) geeignet einführt. Ein wichtiger Punkt hierbei ist das Thematisieren der Fehlersuche und das Erarbeiten bzw. das Nahelegen von systematischen Vorgehensweisen bei der Fehlerbeseitigung. In regelmäßigen Abständen sollten jeweils eine oder zwei Gruppen dem gesamten Kurs ihre Arbeit und ihr Vorgehen vorstellen und mit den anderen diskutieren.

Sobald die Modelle in den Gruppen weitgehend implementiert sind, führt die Lehrperson in das Thema 'Grafische Oberflächen' ein und beginnt damit ''Schritt B'' dieser Phase. Die Einführung könnte beispielsweise darin bestehen, dass eine einfache Anwendung (z.B. Ampelschaltung) vorgestellt und von den Schülern erkundet wird. Sie werden dabei auf die Benutzung einer grafischen Bibliothek stoßen, welche Elemente bereitstellt, aus denen die grafische Oberfläche der Anwendung aufgebaut ist. (Im Projekt haben wir uns der eigens dafür konzipierten vereinfachten grafischen Bibliothek FGrafik bedient.) Mit den Schülerinnen und Schülern sollte nun der Aufbau dieser Bibliothek studiert werden und an einfachen Beispielen deren Verwendung eingeübt werden. Zu thematisieren ist dabei insbesondere das Konzept Klassenbibliothek an sich als Bereitstellung fertiger Klassen, deren Funktionalität man sich für eigene Anwendungen bedienen kann. Außerdem wird man an dieser Stelle spätestens nicht mehr umhin kommen, das objektorientierte Vererbungskonzept einzuführen, da sich nahezu jede Bibliothek dieses Prinzips mehr oder minder in ihrer Struktur und auch in ihrer Benutzung bedient. (Das Vererbungskonzept umfasst hierbei im Übrigen das Schnittstellenkonzept.) Als Abschluss dieses Schrittes und um die Erstellung einer Benutzungsoberfläche in den Softwareentwicklungsprozess einzubetten, sollen die Schülerinnen und Schüler schließlich für ihr im ersten Schritt erstelltes Modell eine Oberfläche entwerfen und implementieren.

In ''Schritt C'' steht anschließend die Frage im Mittelpunkt, wie sich Modell und Oberfläche nun zu einer bedienbaren Software verknüpfen lassen: Das Konzept der Ereignisbehandlung muss thematisiert werden. Auch hier bietet sich eine einfache Beispielanwendung (z.B. die bereits erwähnte Ampelschaltung) als Anschauungs- und Übungsbeispiel an. Wichtig ist in diesem Zusammenhang, dass die Schülerinnen und Schülern ein Verständnis für Sinn und die unterschiedlichen Rollen von Ereignisempfängern, Ereignisquellen und den Ereignissen selbst erlangen. Nähere Beschreibungen für die Einführung in Ereignisse und zum Integrieren der Ereignisbehandlung in eigene Anwendungen befinden sich in der Kategorie Unterrichtsmethoden. 

=====Phase 3=====
{| class="wikitable"
|+
!
!Projekt in Gruppenarbeit

Vollständigen Softwareentwicklungsprozess möglichst eigenständig durchführen, Kooperation und Wettbewerb zwischen den Gruppen
|-
|Ziele
|Vertiefung und Anwendung des in Phase 1 und Phase 2 Erlernten; Reflexion von Vorgehensweise und eigenen Design-Ideen
|-
|Medien
|CRC-Karten, IDE, Bibliothek
|-
|Konzepte
|Objektorientierte Analyse, objektorientiertes Design, Beurteilungskriterien (Verständlichkeit, Einfachheit, Korrektheit, "Erweiterbarkeit", "Aufgabenangemessenheit"), Anwendungsfälle aus Entwickler- und Nutzersicht
|}

'''Dauer:''' ca 20 Unterrichtsstunden

'''Lernziele:''' Erlernen von Zusammenhängen einzelner Schritte objektorientierter Softwareentwicklung, Kommunikationsfähigkeit, Evaluation von Software und Gestaltungsmöglichkeiten

'''Werkzeuge:''' Fujaba, Dobs, CRC-Karten, Objektspiel (jetzt ohne Lehreranleitung)

'''Ablauf:''' Die Lehreperson hat ähnlich zum Beginn der Phase 2 eine neue Anwendungsdomäne vorbereitet und tritt nun in dieser Phase in der Rolle eines Auftraggebers auf, der von den Schülerinnen und Schülern bzw. von den einzelnen Gruppen die Erstellung einer Softwareanwendung für diese Anwendungsdomäne verlangt. Sie sollen also in dieser Phase projektartig in Gruppen und dabei so eigenständig wie möglich die Phasen eines Softwareentwicklungsprozess durchlaufen. Die Anwendungsdomäne bzw. das Anwendungsbeispiel sollte dabei von der Lehrperson so gewählt sein, dass es sich strukturell und in seiner Komplexität von den Schülerinnen und Schülern bewältigen lässt (in Phase 3 des life³-Projektunterrichts war dies das Spiel Memory). Dabei können ihnen dann natürlich die Kenntnisse und Unterlagen der beiden vorangegangenen Phasen von Nutzen sein. Neben der Rolle als Auftraggeber, der sich ständig über den Projektstand einer jeden Gruppe erkundigt, kommt der Lehrperson in dieser Phase mehr noch als in Phase 2 die Rolle einer Beraters zu. Er gibt u.a. Hinweise zu Abstimmung und Arbeitsteilung in den Gruppen, steht bei Problemen als Ansprechpartner zur Verfügung.

Wichtig ist auch in dieser Phase, dass einzelne Gruppen in regelmäßigen Abständen ihren Projektstand und ihr Vorgehen dem ganzen Kurs vorstellen und ihre Realisierungen im Plenum diskutiert werden. Dabei erhalten andere Gruppen Anregungen, können eigenen Erfahrungen einfließen lassen und (Modellierungs-)Fehler wie auch sonstige Sackgassensituationen vermeiden. Bei all dem sollte die Lehrperson wie schon in den beiden vorangegangenen Phasen auf begrifflich präzise Artikulation und Argumentation seitens der Schülerinnen und Schüler achten und diese auch einfordern.

Die Phase endet mit einer abschließenden Projektpräsentation durch die einzelnen Gruppen und einer Reflexion über das Vorgehen, die Bedeutung wichtiger Konzepte wie z.B. der Ereignisbehandlung, usw.

==='''Systemorientierte Didaktik'''===
Eine ''Systemorientierte Didaktik der Informatik'' zielt darauf, informatische und allgemeinbildende Aspekte im Informatikunterricht integrativ zu behandeln und zu thematisieren.

Dem ''(soziotechnischen) Informatiksystem'' als zentraler Begriff kommt hierbei eine entscheidende Rolle zu.

Der Begriff ''Informatiksystem'' wird in der Informatik sowohl in fachwissenschaftlichen als auch in didaktischen Diskussionszusammenhängen verwendet. Allerdings bleiben vor allem im didaktischen Diskurs, die theoretischen Dimensionen des Begriffs oft unklar. Der Beitrag Informatiksystem und Dekonstruktion als didaktische Kategorien versucht daher, den Begriff des Informatiksystems als sozio-technisches Handlungssystem hinsichtlich seiner didaktischen Relevanz zu analysieren. Der aus diesen Überlegungen resultierende Begriff eines Informatiksystems wird zunächst daraufhin untersucht, welche seiner Aspekte und ihm impliziten fachwissenschaftlichen Methoden in einem Informatikunterricht mit allgemeinbildendem Anspruch thematisiert werden sollten. Dies geschieht vor allem anhand des für die systemorientierte Didaktik zentralen wissenschaftstheoretischen Konzepts der ''Dekonstruktion''. Als Resultat des Beitrags werden die Konturen eines systemorientierten fachdidaktischen Zugangs zum Informatikunterricht deutlich, die zugleich Aufgabenfelder für künftige fachdidaktische Forschung beschreiben.

Für das Konzept der ''Dekonstruktion von Informatiksystemen'' wird schließlich ein Sieben Schritte Schema zur unterrichtlichen Durchführung vorgeschlagen. Das Vorgehen wird an einem Beispiel erläutert.

Objektorientierung ist nur ein mögliches Paradigma für den Informatikunterricht. Informationen zum Zusammenhang von Objektorientierung und Systemorientierter Didaktik finden Sie daher in der Unterkategorie Didaktik und Objektorientierung.

==='''Lerntheoretischer Hintergrund'''===

===='''Zum Bild des Lehrens und Lernens'''====
'''Kurze Einführung in das didaktische Konzept, Begründung des Phasenmodells, Darstellung der Bezüge zum Cognitive Apprenticeship'''

Lehr-lerntheoretische Bezüge: Zur Orientierung am Modell des Cognitive Apprenticeship

Die einzelnen Elemente des Phasenmodells, die Unterrichtsmethoden und die bevorzugten Lern-Werkzeuge ergeben zusammen die life-Lernumgebung für den Einstieg in die Objektorientierung. Wir orientieren uns dabei an folgendem

====Bild des Lernens und Lehrens:====

#Lernen ist ein aktiver und individueller Aneignungs- und Konstruktionsprozess; ausgehend vom Vorwissen, der Motivation und dem Engagement des Lernenden.
#Konzepte werden effektiver erlernt und verstanden, wenn sie zusammeen mit ihrer Anwendung gelehrt werden. So wird deutlich, wo der Nutzen, aber auch die Grenzen des Konzepts liegen. Die Anwendung bettet das (theoretische) Konzept in einen (praktischen) Kontext ein. Zudem wird die Gefahr 'trägen Wissens' vermieden.
#Anspruchsvollere Aufgaben sind lernwirksamer als einfache Übungsaufgaben nach dem Drill&Practice-Schema.

Diese Annahmen gründen auf neuere

====Informatikdidaktische Ansätze und Ergebnisse der Lehr-Lernforschung====

*Systemorientierte Didaktik:
**"Für handlungsorientierte Lernprozesse mit Informatiksystemen im Unterricht verdient als vorläufiges Resümee der Diskussion festgehalten zu werden, dass Lernprozesse als Balanceakt zwischen Instruktion und Konstruktion organisiert werden sollten. Lernen erfordert zum einen Anleitung, Orientierung, Zielvorgaben und Hilfen - als Elemente traditioneller Unterrichtsorganisation. Zum anderen aber auch Motivation, Interesse und entdeckende Eigenaktivität des Lernenden - Elemente eines selbst organisierten, Lerner gesteuerten Prozesses kognitiver Strukturbildung, die vor allem auch in individuellen Lernsituationen mit computerunterstützten Lernumgebungen zu erreichen sind." (Zitat aus: Hampel, Thorsten; Magenheim, Johannes; Schulte, Carsten: Dekonstruktion von Informatiksystemen als Unterrichtsmethode In: Schwill, Andreas [Hrsg.]: Informatik und Schule. Berlin [u.a.] 1999, 153)
*Informationszentrierter Ansatz: Verweis u.a. auf Mandl
*Fundamentale Ideen: orientieren sich am Konzept von J. S. Bruner, entdeckendes Lernen: Eigene Forscheraktivität der Lernenden; Spiraliges Vorgehen mit zunehmender Präzisierung von Begriffen

===== Die Perspektive der Erziehungswissenschaft: =====
Sigrid Blömeke (Blömeke 2000, dort finden sich auch die Quellenangaben) stellt fest:

''"Blickt man nun auf den Prozess des Wissenserwerbs stellen konstruktivistische Ansätze den derzeit angemessensten theoretischen Rahmen dar."''

und:

''"Mittlerweile sind auf der Basis des konstruktivistischen Ansatzes international zahlreiche Unterrichtseinheiten entwickelt und empirisch geprüft worden, die zu ähnlichen pädagogischen Schlussfolgerungen kommen, so dass man davon ausgehen kann, dass «eine theoretisch begründete, empirisch unterfütterte Empfehlung für die pädagogische Praxis gegeben [ist; S. B.], die sich variabel, kreativ und kontextsensitiv nutzen lässt» (Weinert 1998, S. 208). Konstruktion durch das Herstellen individueller Bedeutungen, Rekonstruktion durch die Einnahme unterschiedlicher Perspektiven und Dekonstruktion durch das Zweifeln an eigenen Positionen stellen drei Leitprinzipien hierfür dar (vgl. Reich 2000, S. 119ff.). Gefördert werden kann der Wissenserwerb in diesem Sinne durch verschiedene Konzepte des situierten Lernens: situated cognition, anchored instruction, cognitive flexibility und cognitive apprenticeship (vgl. Gerstenmaier / Mandl 1995, S. 882, und Siebert 1999, S. 97f.). Konkret bedeutet dies, dass durch ein Ausgehen von authentischen Aufgaben, die Einbeziehung authentischer Kontexte, die Einnahme multipler Perspektiven und Modelllernen der Wissenserwerb optimiert werden kann."''

Die Ergebnisse der MARKUS-Studie zur Qualität des Mathematik-Unterrichts(die zum Teil sicherlich auf den Informatik-Unterricht übertragbar sind):

''"Leistungsstarke Klassen sind durch drei charakteristische Merkmale gekennzeichnet. [..]''

''1) Zum einen ist die Klassenführung in diesen Klassen überdurchschnittlich effizient, d.h. es besteht Klarheit über die Regeln, die Lehrkraft ist jederzeit über das Geschehen in der Klasse im Bilde; Störungen kommen selten vor, und es herrscht eine konzentrierte Arbeitsatmosphäre. Dieses Ergebnis unterstreicht den durch viele Untersuchungsergebnisse gestützten Sachverhalt, dass eine effiziente Klassenführung eine notwendige, allerdings alleine nicht hinreichende Voraussetzung für den Unterrichtserfolg ist.''

''2) Hinzu kommen muss eine hohe Unterrichtsqualität, durch die sich die erfolgreichen Klassen ebenfalls charakterisieren lassen: Der Mathematiklehrer / die Mathematiklehrerin erklärt verständlich, begeistert die Schüler für neue Themen, betont die Notwendigkeit von Anstrengung, erwartet hohe Leistungen und nimmt sich für Sorgen und Fragen einzelner Schüler Zeit.''

''3) Anspruchsvolle Formen des Übens kommen bei den leistungsstarken Klassen / Kursen etwas ? wenn auch nur in geringem Maße ? häufiger vor. Anspruchsvolles Üben bedeutet, dass die Übung nicht vorwiegend auf die Beherrschung von Fertigkeiten und Routinen abzielt, sondern dass verstärkt''

''solche Aufgaben eingesetzt werden, die eine Anwendung des Gelernten auf neue Gebiete erfordern, die mathematisches Verständnis prüfen und die zeigen, ob das Wesentliche verstanden wurde. Der Bereich des anspruchsvollen Übens bietet vielversprechende Ansatzpunkte für die Verbesserung des Mathematikunterrichts: durch verstärkten Einsatz von unterschiedlichen Formen intelligenten, verständnis- und damit auch leistungsförderlichen Übens, die das herkömmliche Festigen und Sichern von Fertigkeiten, Rechenverfahren und Routineprozeduren ergänzen, aber nicht ersetzen."''

Folgerungen für das Phasenmodell:

====Orientierung am Cognitive Apprenticeship====
Eigenschaften idealer Lernumgebungen:

*Die Perspektive auf die Lern-Inhalte: Diese sollen überblicksartig ("Bereichswissen") zusammen mit Vorgehensweisen zur Problemlösung und Aufgabenbearbeitung ("heuritische Strategien"), "Kontrollstrategien" zur Einschätzung des Vorgehens und mit bereichsbezogenen sowie allgemeinen Lernstrategien vermittelt werden. Es geht insgesamt darum, das eigenständige Lernen zu fördern, indem die Anfänger schnell mit dem Lerngebiet vertraut werden.
*Ein wesentliches Mittel dabei ist die Reihenfolge der Vermittlung, die Lern-Sequenz: Zuerst sollen globale Fähigkeiten vermittelt werden, die dann durch speziellere ausdifferenziert werden. Die Komplexität und Vielfalt der Aufgaben soll ansteigen
*Daneben sind sozialen Bedingungen zu beachten: Das Lerngebiet sollte authentisch und situiert im Unterricht behandelt werden. Die Motivation der Lernenden und ihre Interaktion untereinander sind weiter wichtige Faktoren

==== Die Adaption des CA im Rahmen des life-Projekts / Bezüge zu den einzelnen Elementen ====
{| class="wikitable"
! colspan="2" |Lernumgebungen im CA
!Das Phasenmodell mit Unterrichtsmethoden
|-
| rowspan="4" |Lern-Inhalte
|Bereichswissen
|Objektstrukturen
|-
|Heuristische Strategien ("tricks of the trade")
|Vorgehensweisen, Unterrichtsmethoden
|-
|Kontroll-Strategien
|Fehlersuche, Objektspiel als Test
|-
|Lern-Strategien
|
|-
| rowspan="6" |Lehr-Methoden
|Modelling
|Objektspiel
|-
|Coaching
|Erklären des Objektspiels, Hilfestellungen des Lehrens
|-
|Scaffolding and fading
|Durch das Phasenmodell
|-
|Artikulation
|Auf die Begrifflichkeit achten, Schülerarbeiten erklären lassen: Z. B.: Vorstellung der Ergebnisse der Gruppenarbeitsphasen
|-
|Reflektion
|Arvbeitsphasen besprechen: War das Vorgehen in der Gruppe erfolgreich?

In Phase 3 durch Arbeit in parallelen Gruppen: Die einzelnen Gruppen stellen vor der Klasse den Stand dar. Ihr Vorgehen, ihre Modellier-Ideen und Probleme ? Die Klasse unterstützt, fragt nach,..
|-
|Exploration
|Vorliegende Beispiele erkunden
|-
| rowspan="3" |Lern-Sequenz
|Ansteigende Komplexität
|Durch das Phasenmodell: Ansteigende Selbstständigkeit
|-
|Ansteigende Vielfalt
|Durch das Phasenmodell: Modell-> Modell+ gui-> Modell+ gui+ Ereignisbehandlung
|-
|Globale Kenntnisse und Fähigkeiten vor lokalen
|Denken in Objektstrukturen zuerst, Vorgehensweisen, dann schrittweise Implementationsdetails, Werkzeuge wie Fujaba verdecken viele Details durch grafische Programmierung und automatische Codeerzeugung
|-
| rowspan="5" |Soziale Bedingungen
|Situiertheit
|Konzepte der Objektorientierung werden im Zusammenhang mit Softwareentwicklung eingeführt
|-
|Expertenpraxis
|Elemente aus der Expertenpraxis werden übertragen: Vorgehensweisen
|-
|Intrinsische Motivation
|Die eigenständige Aktivität wird von Anfang an gefördert, die Schüler können recht schnell ein kleines Projekt erstellen: Diese Erfolge sollen die Motivation stärken
|-
|Kooperation der Lernenden nutzen
|Durch Gruppenarbeit und Partnerarbeit am Rechner
|-
|Wettbewerb der Lernenden nutzen
|Die Gruppen arbeiten parallel am selben Projekt: In der Unterrichtsbesprechung wird der eigene Stand mit dem der anderen Gruppen verglichen
|}

Life^3/Didaktisches Konzept

2021-11-02T14:48:42Z

Koellner: Ergänzung - Systemorientierte Didaktik

=='''Überblick Didaktisches Konzept'''==
Im Bereich Didaktik finden Sie Informationen zum didaktischen Hintergrund, zum Beispiel erklären wir hier das life³-Phasenmodell und den Ansatz der systemorientierten Didaktik.

Das didaktische Konzept des life³-Projekts lehnt sich an den in Paderborn vertretenen Ansatz der Systemorientierten Didaktik der Informatik an. Informationen hierzu finden Sie im Bereich Systemorientierte Didaktik.

Mit dem life³-Phasenmodell wird der mögliche Aufbau einer Unterrichtssequenz zum Einstieg in die Objektorientierung in der Jahrgangsstufe 11/1 beschrieben. Das Phasenmodell wurde an zwei Paderborner Schulen erprobt und unter Einsatz von Befragungen, Tests und videogestützter Unterrichtsbeobachtung evaluiert. Einzelheiten hierzu und zur konkreten Umsetzung des Phasenmodells werden in der Rubrik Unterrichtseinheiten beschrieben.

Hier in dieser Rubrik hingegen finden Sie - wie oben bereits angedeutet - abstraktere Darlegungen zu Aufbau und Konzeption des life³-Phasenmodells. Vielleicht kann dies dazu dienen, unser Vorgehen zu erhellen. Vielleicht werden Sie zu eigenen Ideen angeregt, oder Sie finden Verbesserungsmöglichkeiten, oder Ihnen kommen konkrete Ideen für eigene Unterrichtseinheiten orientiert am life³-Phasenmodell.

==='''Das life³-Phasenmodell'''===

====Phasenmodell für den Einstieg in grundlegende Konzepte und Sichtweisen der Objektorientierung.====
Objektorientierung ist ein spannendes und aktuelles Themengebiet sowohl in der Informatik, speziell der Softwaretechnik, als auch im Informatikunterricht.

Insbesondere das objektorientierte Modellieren als der planende und gestaltende Teil der Softwareentwicklung kann in vielfältiger Weise zur informatischen Bildung beitragen:

*Notationen und Techniken zum Strukturieren von Informationen kennen lernen
*Grundkenntnisse über Struktur und Funktionsweise objektorientierter Software erwerben
*Einblick in den Erstellungsprozess von Software bekommen
*Softwareentwicklung als einen ingenieursmäßigen, technischen Konstruktionsprozess aber auch als einen kreativen Gestaltungsprozess kennen lernen
*Problemlösetechniken und die Arbeit im Team üben
*...

Um diese Ziele im Unterricht zu erreichen, ist ein Verständnis der Grundkonzepte der Objektorientierung eine wesentliche Vorbedingung. Leider sind diese Grundkonzepte erstens sehr zahlreich, zweitens stark miteinander verwoben und drittens oft erst verständlich, wenn man komplexere objektorientierte Programme untersucht oder entwickelt.

Das Phasenmodell verhindert, dass die Schülerinnen und Schüler aufgrund der Komplexität und Vielzahl der objektorientierten Technologien sozusagen "den Wald vor lauter Bäumen nicht mehr erkennen können". Anstelle einzelner, ausgewählter Konzepte stellt es die Grundidee der Objektorientierung in den Mittelpunkt des Unterrichts: Objektstrukturen und deren Interaktion. Damit wird eine auf Zusammenhänge ausgerichtete Perspektive auf die Thematik eingenommen, aus der heraus im Unterricht die notwendigen Konzepte, Notationen, Werkzeuge und Techniken erschlossen werden können.

Der Unterricht orientiert am life³-Phasenmodell wird in drei aufeinander aufbauende Phasen eingeteilt. Jede Phase legt die Grundlagen für die nächste. Die Phasierung erleichtert die Unterrichtsplanung und das Erlernen, da jeweils nur einige ausgewählte Aspekte im Mittelpunkt stehen. In der jeweils folgenden Phase werden diese Elemente für den weiteren Fortschritt genutzt und vertieft.

'''AN DIESER STELLE FEHLT EIN BILD...'''

In der ersten Phase werden die Leitideen, die Notationen und die Benutzung der Werkzeuge vermittelt. Es wird ein kleines objektorientiertes Modell untersucht und verändert. Im Mittelpunkt stehen die beiden Leitideen: Objektstrukturen und Kollaborative Methoden.

In der zweiten Phase wird das Gelernte gefestigt. Es wird gezeigt, wie auf das objektorientierte Modell eine grafische Oberfläche aufgesetzt wird, und wie mittels Ereignisbehandlung mit dem Modell interagiert werden kann. In dieser Phase gibt es verstärkt Übungen zu einzelnen Konzepten.

Die dritte Phase regt die Schüler zur eigenständigen Anwendung und Vertiefung des Erlernten an. Dabei sollen Lernziele auf den Ebenen Bewertung und Reflexion einbezogen werden.

Insgesamt orientiert sich das life³-Phasenmodell am Modell des Cognitive Apprenticeship, dessen Lernwirksamkeit empirisch gut abgesichert ist.
 

=====Phase 1=====
Grundbegriffe und Grundstrukturen
{| class="wikitable"
|+
!
!Schritt A

Anwendungsgebiet erkunden
!Schritt B

Informales Modell erkunden
!Schritt C

Formales Modell erkunden

(Klassenebene)
!Schritt D

Formales Modell erkunden

(Methodenebene)
|-
|Ziele
|Vertraut werden bzw. ins Gedächtnis rufen der Abläufe und Strukturen der Anwendungsdomäne
|Vertraut werden mit objektorientierter Sichtweise der Anwendungsdomäne; Objektstrukturen und Collaborative Methoden kennen lernen
|Vertraut werden mit formaler Notation und der Funktionsweise einer OO-Anwendung und der IDE
|Vertraut werden mit formaler Notation von Aktivitätsdiagrammen, kennen lernen von Kontrollstrukturen
|-
|Medien
|Je nach Domäne, z.B.: Spielmaterial
|CRC- und Objektkarten
|Anwendung, Entwicklungsumgebung mit Debugger, visuell orientiert
|Anwendung, Entwicklungsumgebung mit Debugger, visuell orientiert
|-
|Konzepte
|Entsprechend der Anwendungsdomäne, z.B.:Spieler, Spielzeug, Begriffe für die einzelnen Materialien
|Klasse, Objekt, Verantwortlichkeit, Beziehung, Zustand, Objektspiel, Anwendungsfall
|Klasse, Objekt, Beziehung, Kardinalität, Übersetzen, Methodenaufruf, Parameter, UML
|Story-Diagramme, Bedingte Anweisungen, Schleifen, Parameter
|}
'''Dauer:''' 10 Unterrichtsstunden

'''Lernziele:''' Heranführung der Schüler an eine objektorientierte Sichtweise, die Einführung der Begriffe Klasse, Objekt, Assoziation, Methode, Attribut sowie Interaktionen von Objekten. Desweiteren Metaphern der Objektorientierung als Verständnishilfe für die Grundideen der Objektorientierung, UML-, Klassen- und Objektdiagramme, Benutzen der Werkzeuge Fujaba und des darin integrierten grafischen Debuggers Dobs sowie CRC-Karten und Objektspiel als Analyse- bzw. Modellierungstechniken.

'''Werkzeuge:''' CRC-Karten, Objektspiel, Fujaba und das darin integrierte Dobs (mit Lehreranleitung)

'''Ablauf:''' In ''Schritt A'' sollen sich die Schülerinnen und Schüler mit der Anwendungsdomäne vertraut machen. Werden als Anwendungsdomäne wie in den aufgezeigten Beispielen Spiele gewählt, so können in diesem Schritt die Schülerinnen und Schüler diese praktisch durchführen und sich mit den Spielregeln befassen. Dadurch kann sich in den folgenden Schritten und Phasen die Konzentration auf die objektorientierten Konzepte richten, die an dieser Stelle aber noch keine Rolle spielen sollen. Ein bis zwei Unterrichtsstunden sollten daher für diesen ersten Schritt ausreichend sein.

In ''Schritt B'' wird erstmals eine objektorientierte Sichtweise eingeführt. Mit Hilfe von CRC-Karten als Notationstechnik für Objektorientierte Analyse wird ein Modell für ein Beispiel aus der jeweiligen Anwendungsdomäne (z.B. ein Spiel) erstellt. Die Schülerinnen und Schüler erlernen das Objektspiel: Hierbei sollen sie selbst Objekte spielen, d.h. deren Rolle übernehmen. Sie erhalten CRC-Karten aus dem Modell und dürfen beim Spiel nur die Eigenschaften der Objekte benutzen. Das Objektspiel soll dazu dienen, ein Verständnis für objektorientierte Sichtweisen auszubilden. Die Beispiele sollten dabei so gewählt sein, dass es CRC-Karten (Klassen) gibt, aus denen mehrere Objekte gebildet werden, die sich durch ihre Zustände, die auf Objektkarten festgehalten werden, unterscheiden. Dies soll dazu beitragen, den Unterschied zwischen Klassen und Objekten zu verstehen. Für weitere Informationen siehe: Objektspiel.

In ''Schritt C'' wird eine fertige Implementation (zunächst auf Klassenebene) des zuvor selbst erstellen CRC-Modells mit Hilfe einer IDE am Rechner untersucht. An dieser Stelle erlernen die Schülerinnen und Schüler die formale Notation eines Modells mit Hilfe einer graphischen oder auch textuellen Programmiersprache und den Umgang mit der Entwicklungsumgebung, die im weiteren Verlauf der Unterrichtseinheit eingesetzt werden soll. Wird wie im dargestellten Beispiel eine grafische Notation verwendet, so sollte sich diese an UML orientieren. In diesem Fall müssten in dieser Phase auch bereits UML-spezifische Begriffe wie Kardinalität und Assoziationen erläutert werden. Eventuell aufkommende Begriffe wie Datentypen, Parameter und Kontrollstrukturen werden - soweit nötig - ebenfalls erläutert.

In ''Schritt D'' schließlich rückt die Implementation der Methoden in den Mittelpunkt. Die realisierten Methoden des bereits implementierten Beispiels sollten an dieser Stelle zunächst analysiert werden. Übungsaufgaben können helfen, die Syntax der Programmiersprache bzw. die grafische Notation der Aktivitätsdiagramme zu erlernen und praktische Erfahrung bei der Implementation von Methoden zu erlangen.

=====Phase 2=====
{| class="wikitable"
|+
!
!Schritt A

Schritte aus Phase 1 selbst durchführen,

in richtiger Reihenfolge
!Schritt B

Grafische Oberflächen kennenlernen
!Schritt C

Ereignisbehandlung kennenlernen
|-
|Ziele
|vertraut werden mit Modellierungs- und Softwareentwicklungsprozess, Vertiefen der Kenntnisse und Begriffe, Übertragen auf ein neues Beispiel
|Bibliotheknutzung und Konzept der GUI-Bibliothek verstehen
|Verknüpfung von Modell und grafischer Oberfläche (View), Konzept der Ereignisbehandlung verstehen
|-
|Medien
|CRC-IDE, Bibliothek, Beispiel-Anwendung
|
|IDE, Beispiel-Anwendung
|-
|Konzepte
|Analyse, Design, Test, Fehlersuche, Syntax und Semantik, Schleifen, lokale Variable, Verzweigung, primitive Datentypen
|Bibliothek, bidirektionale/unidirektionale Beziehungen, Bibliotheksklassen
|
Ereignisse, Vererbung, Schnittstellen (Interface), Model-View-(Control)-Konzept MV(C)
|}'''Dauer:''' ca. 30 Unterrichtsstunden

'''Lernziele:''' Verdeutlichung der Rolle und des zeitlichen Ablaufs verschiedener Schritte der Softwareentwicklung, Ereignisbehandlung und Benutzeroberflächen, Algorithmen, Bedeutung und Benutzung von Klassenbibliotheken, Vererbung und Interfaces, Umgang mit Fehlern

'''Werkzeuge:''' Fujaba, Dobs, CRC-Karten, Objektspiel (mit Hilfen des Lehrers)

'''Ablauf:''' Die Schülerinnen und Schüler sollen in dieser zweiten Phase analog zu den Erkundungsschritten der ersten Phase entscheidende Schritte der Softwareentwicklung unter Anleitung der Lehrperson an einem neuen Beispiel weitgehend selbständig durchführen. Das Kennenlernen Grafischer Oberflächen, ihrer Elemente und Strukturen und damit verbunden das Benutzen einer Klassenbibliothek schließt sich in einem weiteren Schritt an. Um Oberfläche und implementiertes Modell sinnvoll miteinander zu verknüpfen, steht im dritten Schritt dieser Phase das Konzept der Ereignisbehandlung im Mittelpunkt.

Die Schritte dieser Phase im Einzelnen:

In ''Schritt A'' sollen - wie bereits angedeutet - die Schülerinnen und Schüler analog zu den Erkundungsschritten der ersten Phase die entscheidenden Softwareentwicklungsschritte bis zur Erstellung eines lauffähigen Modells weitgehend selbständig in Gruppen durchführen. Das beinhaltet wie in der ersten Phase das Erkunden der Anwendungsdomäne, die Erstellung eines informalen Modells mittels CRC-Karten (also eine objektorientierte Analyse), dessen Weiterentwicklung zu einem formalen Modell in UML-Notation (objektorientierter Entwurf bzw. Designschritt) und schließlich die Implementierung der Methoden. Beginnen wird also dieser erste Schritt mit der Einführung eines neuen Beispiels als Anwendungsdomäne. (Im Falle unseres Projekts war dies ein weiteres Spiel: Schatzsuche.) Indem die Schülerinnen und Schüler versuchen, einen Softwareentwicklungsprozess durchzuführen, werden sie einerseits vertrauter mit dem Modellierungs- und Softwareentwicklungsprozess, vertiefen die in Phase 1 erlernten Begriffe, Sichtweisen und Kenntnisse und erwerben andererseits praktische Fähigkeiten im Hinblick auf die CRC-Kartentechnik als Mittel zur Analyse sowie die Benutzung einer IDE als Design- und Implementierungswerkzeug.

Die Anleitung durch die Lehrperson wird hier insbesondere auch darin zu sehen sein, dass sie im Falle von Problemen und Verständnisschwierigkeiten diese für den ganzen Kurs thematisiert, abgeschlossene Softwareentwicklungsschritte reflektieren lässt, und in notwendige neue Begrifflichkeit (z.B. Schleifen, lokale Variablen, Verzweigung, Datentypen, usw.) geeignet einführt. Ein wichtiger Punkt hierbei ist das Thematisieren der Fehlersuche und das Erarbeiten bzw. das Nahelegen von systematischen Vorgehensweisen bei der Fehlerbeseitigung. In regelmäßigen Abständen sollten jeweils eine oder zwei Gruppen dem gesamten Kurs ihre Arbeit und ihr Vorgehen vorstellen und mit den anderen diskutieren.

Sobald die Modelle in den Gruppen weitgehend implementiert sind, führt die Lehrperson in das Thema 'Grafische Oberflächen' ein und beginnt damit ''Schritt B'' dieser Phase. Die Einführung könnte beispielsweise darin bestehen, dass eine einfache Anwendung (z.B. Ampelschaltung) vorgestellt und von den Schülern erkundet wird. Sie werden dabei auf die Benutzung einer grafischen Bibliothek stoßen, welche Elemente bereitstellt, aus denen die grafische Oberfläche der Anwendung aufgebaut ist. (Im Projekt haben wir uns der eigens dafür konzipierten vereinfachten grafischen Bibliothek FGrafik bedient.) Mit den Schülerinnen und Schülern sollte nun der Aufbau dieser Bibliothek studiert werden und an einfachen Beispielen deren Verwendung eingeübt werden. Zu thematisieren ist dabei insbesondere das Konzept Klassenbibliothek an sich als Bereitstellung fertiger Klassen, deren Funktionalität man sich für eigene Anwendungen bedienen kann. Außerdem wird man an dieser Stelle spätestens nicht mehr umhin kommen, das objektorientierte Vererbungskonzept einzuführen, da sich nahezu jede Bibliothek dieses Prinzips mehr oder minder in ihrer Struktur und auch in ihrer Benutzung bedient. (Das Vererbungskonzept umfasst hierbei im Übrigen das Schnittstellenkonzept.) Als Abschluss dieses Schrittes und um die Erstellung einer Benutzungsoberfläche in den Softwareentwicklungsprozess einzubetten, sollen die Schülerinnen und Schüler schließlich für ihr im ersten Schritt erstelltes Modell eine Oberfläche entwerfen und implementieren.

In ''Schritt C'' steht anschließend die Frage im Mittelpunkt, wie sich Modell und Oberfläche nun zu einer bedienbaren Software verknüpfen lassen: Das Konzept der Ereignisbehandlung muss thematisiert werden. Auch hier bietet sich eine einfache Beispielanwendung (z.B. die bereits erwähnte Ampelschaltung) als Anschauungs- und Übungsbeispiel an. Wichtig ist in diesem Zusammenhang, dass die Schülerinnen und Schülern ein Verständnis für Sinn und die unterschiedlichen Rollen von Ereignisempfängern, Ereignisquellen und den Ereignissen selbst erlangen. Nähere Beschreibungen für die Einführung in Ereignisse und zum Integrieren der Ereignisbehandlung in eigene Anwendungen befinden sich in der Kategorie Unterrichtsmethoden. 

=====Phase 3=====
{| class="wikitable"
|+
!
!Projekt in Gruppenarbeit

Vollständigen Softwareentwicklungsprozess möglichst eigenständig durchführen, Kooperation und Wettbewerb zwischen den Gruppen
|-
|Ziele
|Vertiefung und Anwendung des in Phase 1 und Phase 2 Erlernten; Reflexion von Vorgehensweise und eigenen Design-Ideen
|-
|Medien
|CRC-Karten, IDE, Bibliothek
|-
|Konzepte
|Objektorientierte Analyse, objektorientiertes Design, Beurteilungskriterien (Verständlichkeit, Einfachheit, Korrektheit, "Erweiterbarkeit", "Aufgabenangemessenheit"), Anwendungsfälle aus Entwickler- und Nutzersicht
|}

'''Dauer:''' ca 20 Unterrichtsstunden

'''Lernziele:''' Erlernen von Zusammenhängen einzelner Schritte objektorientierter Softwareentwicklung, Kommunikationsfähigkeit, Evaluation von Software und Gestaltungsmöglichkeiten

'''Werkzeuge:''' Fujaba, Dobs, CRC-Karten, Objektspiel (jetzt ohne Lehreranleitung)

'''Ablauf:''' Die Lehreperson hat ähnlich zum Beginn der Phase 2 eine neue Anwendungsdomäne vorbereitet und tritt nun in dieser Phase in der Rolle eines Auftraggebers auf, der von den Schülerinnen und Schülern bzw. von den einzelnen Gruppen die Erstellung einer Softwareanwendung für diese Anwendungsdomäne verlangt. Sie sollen also in dieser Phase projektartig in Gruppen und dabei so eigenständig wie möglich die Phasen eines Softwareentwicklungsprozess durchlaufen. Die Anwendungsdomäne bzw. das Anwendungsbeispiel sollte dabei von der Lehrperson so gewählt sein, dass es sich strukturell und in seiner Komplexität von den Schülerinnen und Schülern bewältigen lässt (in Phase 3 des life³-Projektunterrichts war dies das Spiel Memory). Dabei können ihnen dann natürlich die Kenntnisse und Unterlagen der beiden vorangegangenen Phasen von Nutzen sein. Neben der Rolle als Auftraggeber, der sich ständig über den Projektstand einer jeden Gruppe erkundigt, kommt der Lehrperson in dieser Phase mehr noch als in Phase 2 die Rolle einer Beraters zu. Er gibt u.a. Hinweise zu Abstimmung und Arbeitsteilung in den Gruppen, steht bei Problemen als Ansprechpartner zur Verfügung.

Wichtig ist auch in dieser Phase, dass einzelne Gruppen in regelmäßigen Abständen ihren Projektstand und ihr Vorgehen dem ganzen Kurs vorstellen und ihre Realisierungen im Plenum diskutiert werden. Dabei erhalten andere Gruppen Anregungen, können eigenen Erfahrungen einfließen lassen und (Modellierungs-)Fehler wie auch sonstige Sackgassensituationen vermeiden. Bei all dem sollte die Lehrperson wie schon in den beiden vorangegangenen Phasen auf begrifflich präzise Artikulation und Argumentation seitens der Schülerinnen und Schüler achten und diese auch einfordern.

Die Phase endet mit einer abschließenden Projektpräsentation durch die einzelnen Gruppen und einer Reflexion über das Vorgehen, die Bedeutung wichtiger Konzepte wie z.B. der Ereignisbehandlung, usw.

==='''Systemorientierte Didaktik'''===
Eine ''Systemorientierte Didaktik der Informatik'' zielt darauf, informatische und allgemeinbildende Aspekte im Informatikunterricht integrativ zu behandeln und zu thematisieren.

Dem ''(soziotechnischen) Informatiksystem'' als zentraler Begriff kommt hierbei eine entscheidende Rolle zu.

Der Begriff ''Informatiksystem'' wird in der Informatik sowohl in fachwissenschaftlichen als auch in didaktischen Diskussionszusammenhängen verwendet. Allerdings bleiben vor allem im didaktischen Diskurs, die theoretischen Dimensionen des Begriffs oft unklar. Der Beitrag Informatiksystem und Dekonstruktion als didaktische Kategorien versucht daher, den Begriff des Informatiksystems als sozio-technisches Handlungssystem hinsichtlich seiner didaktischen Relevanz zu analysieren. Der aus diesen Überlegungen resultierende Begriff eines Informatiksystems wird zunächst daraufhin untersucht, welche seiner Aspekte und ihm impliziten fachwissenschaftlichen Methoden in einem Informatikunterricht mit allgemeinbildendem Anspruch thematisiert werden sollten. Dies geschieht vor allem anhand des für die systemorientierte Didaktik zentralen wissenschaftstheoretischen Konzepts der ''Dekonstruktion''. Als Resultat des Beitrags werden die Konturen eines systemorientierten fachdidaktischen Zugangs zum Informatikunterricht deutlich, die zugleich Aufgabenfelder für künftige fachdidaktische Forschung beschreiben.

Für das Konzept der ''Dekonstruktion von Informatiksystemen'' wird schließlich ein Sieben Schritte Schema zur unterrichtlichen Durchführung vorgeschlagen. Das Vorgehen wird an einem Beispiel erläutert.

Objektorientierung ist nur ein mögliches Paradigma für den Informatikunterricht. Informationen zum Zusammenhang von Objektorientierung und Systemorientierter Didaktik finden Sie daher in der Unterkategorie Didaktik und Objektorientierung.

==='''Lerntheoretischer Hintergrund'''===

==== '''Zum Bild des Lehrens und Lernens''' ====
'''Kurze Einführung in das didaktische Konzept, Begründung des Phasenmodells, Darstellung der Bezüge zum Cognitive Apprenticeship'''

Lehr-lerntheoretische Bezüge: Zur Orientierung am Modell des Cognitive Apprenticeship

Die einzelnen Elemente des Phasenmodells, die Unterrichtsmethoden und die bevorzugten Lern-Werkzeuge ergeben zusammen die life-Lernumgebung für den Einstieg in die Objektorientierung. Wir orientieren uns dabei an folgendem

==== Bild des Lernens und Lehrens: ====

# Lernen ist ein aktiver und individueller Aneignungs- und Konstruktionsprozess; ausgehend vom Vorwissen, der Motivation und dem Engagement des Lernenden.
# Konzepte werden effektiver erlernt und verstanden, wenn sie zusammeen mit ihrer Anwendung gelehrt werden. So wird deutlich, wo der Nutzen, aber auch die Grenzen des Konzepts liegen. Die Anwendung bettet das (theoretische) Konzept in einen (praktischen) Kontext ein. Zudem wird die Gefahr 'trägen Wissens' vermieden.
# Anspruchsvollere Aufgaben sind lernwirksamer als einfache Übungsaufgaben nach dem Drill&Practice-Schema.

Diese Annahmen gründen auf neuere

==== Informatikdidaktische Ansätze und Ergebnisse der Lehr-Lernforschung ====

* Systemorientierte Didaktik:
** "Für handlungsorientierte Lernprozesse mit Informatiksystemen im Unterricht verdient als vorläufiges Resümee der Diskussion festgehalten zu werden, dass Lernprozesse als Balanceakt zwischen Instruktion und Konstruktion organisiert werden sollten. Lernen erfordert zum einen Anleitung, Orientierung, Zielvorgaben und Hilfen - als Elemente traditioneller Unterrichtsorganisation. Zum anderen aber auch Motivation, Interesse und entdeckende Eigenaktivität des Lernenden - Elemente eines selbst organisierten, Lerner gesteuerten Prozesses kognitiver Strukturbildung, die vor allem auch in individuellen Lernsituationen mit computerunterstützten Lernumgebungen zu erreichen sind." (Zitat aus: Hampel, Thorsten; Magenheim, Johannes; Schulte, Carsten: Dekonstruktion von Informatiksystemen als Unterrichtsmethode In: Schwill, Andreas [Hrsg.]: Informatik und Schule. Berlin [u.a.] 1999, 153)
* Informationszentrierter Ansatz: Verweis u.a. auf Mandl
* Fundamentale Ideen: orientieren sich am Konzept von J. S. Bruner, entdeckendes Lernen: Eigene Forscheraktivität der Lernenden; Spiraliges Vorgehen mit zunehmender Präzisierung von Begriffen

 

===== Die Perspektive der Erziehungswissenschaft: =====
Sigrid Blömeke (Blömeke 2000, dort finden sich auch die Quellenangaben) stellt fest:

''"Blickt man nun auf den Prozess des Wissenserwerbs stellen konstruktivistische Ansätze den derzeit angemessensten theoretischen Rahmen dar."''

und:

''"Mittlerweile sind auf der Basis des konstruktivistischen Ansatzes international zahlreiche Unterrichtseinheiten entwickelt und empirisch geprüft worden, die zu ähnlichen pädagogischen Schlussfolgerungen kommen, so dass man davon ausgehen kann, dass «eine theoretisch begründete, empirisch unterfütterte Empfehlung für die pädagogische Praxis gegeben [ist; S. B.], die sich variabel, kreativ und kontextsensitiv nutzen lässt» (Weinert 1998, S. 208). Konstruktion durch das Herstellen individueller Bedeutungen, Rekonstruktion durch die Einnahme unterschiedlicher Perspektiven und Dekonstruktion durch das Zweifeln an eigenen Positionen stellen drei Leitprinzipien hierfür dar (vgl. Reich 2000, S. 119ff.). Gefördert werden kann der Wissenserwerb in diesem Sinne durch verschiedene Konzepte des situierten Lernens: situated cognition, anchored instruction, cognitive flexibility und cognitive apprenticeship (vgl. Gerstenmaier / Mandl 1995, S. 882, und Siebert 1999, S. 97f.). Konkret bedeutet dies, dass durch ein Ausgehen von authentischen Aufgaben, die Einbeziehung authentischer Kontexte, die Einnahme multipler Perspektiven und Modelllernen der Wissenserwerb optimiert werden kann."''

Die Ergebnisse der MARKUS-Studie zur Qualität des Mathematik-Unterrichts(die zum Teil sicherlich auf den Informatik-Unterricht übertragbar sind):

''"Leistungsstarke Klassen sind durch drei charakteristische Merkmale gekennzeichnet. [..]''

''1) Zum einen ist die Klassenführung in diesen Klassen überdurchschnittlich effizient, d.h. es besteht Klarheit über die Regeln, die Lehrkraft ist jederzeit über das Geschehen in der Klasse im Bilde; Störungen kommen selten vor, und es herrscht eine konzentrierte Arbeitsatmosphäre. Dieses Ergebnis unterstreicht den durch viele Untersuchungsergebnisse gestützten Sachverhalt, dass eine effiziente Klassenführung eine notwendige, allerdings alleine nicht hinreichende Voraussetzung für den Unterrichtserfolg ist.''

''2) Hinzu kommen muss eine hohe Unterrichtsqualität, durch die sich die erfolgreichen Klassen ebenfalls charakterisieren lassen: Der Mathematiklehrer / die Mathematiklehrerin erklärt verständlich, begeistert die Schüler für neue Themen, betont die Notwendigkeit von Anstrengung, erwartet hohe Leistungen und nimmt sich für Sorgen und Fragen einzelner Schüler Zeit.''

''3) Anspruchsvolle Formen des Übens kommen bei den leistungsstarken Klassen / Kursen etwas ? wenn auch nur in geringem Maße ? häufiger vor. Anspruchsvolles Üben bedeutet, dass die Übung nicht vorwiegend auf die Beherrschung von Fertigkeiten und Routinen abzielt, sondern dass verstärkt''

''solche Aufgaben eingesetzt werden, die eine Anwendung des Gelernten auf neue Gebiete erfordern, die mathematisches Verständnis prüfen und die zeigen, ob das Wesentliche verstanden wurde. Der Bereich des anspruchsvollen Übens bietet vielversprechende Ansatzpunkte für die Verbesserung des Mathematikunterrichts: durch verstärkten Einsatz von unterschiedlichen Formen intelligenten, verständnis- und damit auch leistungsförderlichen Übens, die das herkömmliche Festigen und Sichern von Fertigkeiten, Rechenverfahren und Routineprozeduren ergänzen, aber nicht ersetzen."''

Folgerungen für das Phasenmodell:

===== Orientierung am Cognitive Apprenticeship =====
Eigenschaften idealer Lernumgebungen:

* Die Perspektive auf die Lern-Inhalte: Diese sollen überblicksartig ("Bereichswissen") zusammen mit Vorgehensweisen zur Problemlösung und Aufgabenbearbeitung ("heuritische Strategien"), "Kontrollstrategien" zur Einschätzung des Vorgehens und mit bereichsbezogenen sowie allgemeinen Lernstrategien vermittelt werden. Es geht insgesamt darum, das eigenständige Lernen zu fördern, indem die Anfänger schnell mit dem Lerngebiet vertraut werden.
* Ein wesentliches Mittel dabei ist die Reihenfolge der Vermittlung, die Lern-Sequenz: Zuerst sollen globale Fähigkeiten vermittelt werden, die dann durch speziellere ausdifferenziert werden. Die Komplexität und Vielfalt der Aufgaben soll ansteigen
* Daneben sind sozialen Bedingungen zu beachten: Das Lerngebiet sollte authentisch und situiert im Unterricht behandelt werden. Die Motivation der Lernenden und ihre Interaktion untereinander sind weiter wichtige Faktoren

 

===== Die Adaption des CA im Rahmen des life-Projekts / Bezüge zu den einzelnen Elementen =====
{| class="wikitable"
! colspan="2" |Lernumgebungen im CA
!Das Phasenmodell mit Unterrichtsmethoden
|-
| rowspan="4" |Lern-Inhalte
|Bereichswissen
|Objektstrukturen
|-
|Heuristische Strategien ("tricks of the trade")
|Vorgehensweisen, Unterrichtsmethoden
|-
|Kontroll-Strategien
|Fehlersuche, Objektspiel als Test
|-
|Lern-Strategien
|
|-
| rowspan="6" |Lehr-Methoden
|Modelling
|Objektspiel
|-
|Coaching
|Erklären des Objektspiels, Hilfestellungen des Lehrens
|-
|Scaffolding and fading
|Durch das Phasenmodell
|-
|Artikulation
|Auf die Begrifflichkeit achten, Schülerarbeiten erklären lassen: Z. B.: Vorstellung der Ergebnisse der Gruppenarbeitsphasen
|-
|Reflektion
|Arvbeitsphasen besprechen: War das Vorgehen in der Gruppe erfolgreich?

In Phase 3 durch Arbeit in parallelen Gruppen: Die einzelnen Gruppen stellen vor der Klasse den Stand dar. Ihr Vorgehen, ihre Modellier-Ideen und Probleme ? Die Klasse unterstützt, fragt nach,..
|-
|Exploration
|Vorliegende Beispiele erkunden
|-
| rowspan="3" |Lern-Sequenz
|Ansteigende Komplexität
|Durch das Phasenmodell: Ansteigende Selbstständigkeit
|-
|Ansteigende Vielfalt
|Durch das Phasenmodell: Modell-> Modell+ gui-> Modell+ gui+ Ereignisbehandlung
|-
|Globale Kenntnisse und Fähigkeiten vor lokalen
|Denken in Objektstrukturen zuerst, Vorgehensweisen, dann schrittweise Implementationsdetails, Werkzeuge wie Fujaba verdecken viele Details durch grafische Programmierung und automatische Codeerzeugung
|-
| rowspan="5" |Soziale Bedingungen
|Situiertheit
|Konzepte der Objektorientierung werden im Zusammenhang mit Softwareentwicklung eingeführt
|-
|Expertenpraxis
|Elemente aus der Expertenpraxis werden übertragen: Vorgehensweisen
|-
|Intrinsische Motivation
|Die eigenständige Aktivität wird von Anfang an gefördert, die Schüler können recht schnell ein kleines Projekt erstellen: Diese Erfolge sollen die Motivation stärken
|-
|Kooperation der Lernenden nutzen
|Durch Gruppenarbeit und Partnerarbeit am Rechner
|-
|Wettbewerb der Lernenden nutzen
|Die Gruppen arbeiten parallel am selben Projekt: In der Unterrichtsbesprechung wird der eigene Stand mit dem der anderen Gruppen verglichen
|}

Life^3/Didaktisches Konzept

2021-11-02T14:24:57Z

Koellner:

2021-08-04T12:16:05Z

Koellner: Erstellung einer Life^3 Unterseite

Lorem Ipsum...

Life^3/Unterrichtsmethoden

2021-08-04T12:14:13Z

Koellner: Erstellung einer Life^3 Unterseite

Life^3

2021-08-04T12:08:24Z

Koellner:

=='''Was eigentlich bedeutet life³?'''==
Die Abkürzung life³ steht für '''L'''ernwerkzeuge für den '''I'''n'''f'''ormatikunterricht: '''E'''insetzen, '''E'''valuieren und (Weiter)'''E'''ntwickeln.

Das Projekt wird vom Universitätsverbund MultiMedia NRW (UVM) gefördert

==='''Was steckt dahinter?'''===
Das Projekt life³ greift auf die Erfahrungen aus der Hochschulausbildung und die dort eingesetzten Materialien und Werkzeuge zurück, um eine Lernwerkstatt zum Thema 'Objektorientiertes Modellieren' aufzubauen. Hier können sie Informationen über die Gestaltung von Informatikunterricht finden.

=='''Was finde ich auf den Seiten?'''==
Von didaktischer Konzeption und Techniken zur Unterrichtsmethodik finden sie ganze Unterrichtseinheiten, abgestimmte Übungsaufgaben und Beschreibungen von verschiedenen Werkzeugen zur Verwendung im Unterricht, sowie vorgefertigte Projektdateien für das von uns benutzte und ebenfalls an der Universität Paderborn entwickelte Modellierungspaket Fujaba.

Weitere Seiten des Projekts life³

* [[Didaktisches Konzept]]
* Unterrichtsmethoden
* Unterrichtseinheiten
* Werkzeuge
* Software-Projekte
* Aufgaben
* Softwaretechnik
* Glossar
* Über life³

 
==='''Was werden sonst noch für Informationen angeboten?'''===
Weiterhin bieten wir im Bereich Softwaretechnik Informationen zur Ereignisbehandlung an. Unter anderem wird hier die Nutzung der Grafikbibliothek FGrafik sowohl in Fujaba, als auch im Quelltext erläutert.

Life^3

2021-08-04T11:38:09Z

Koellner:

== '''Was eigentlich bedeutet life³?''' ==
Die Abkürzung life³ steht für '''L'''ernwerkzeuge für den '''I'''n'''f'''ormatikunterricht: '''E'''insetzen, '''E'''valuieren und (Weiter)'''E'''ntwickeln.

Das Projekt wird vom Universitätsverbund MultiMedia NRW (UVM) gefördert

=== '''Was steckt dahinter?''' ===
Das Projekt life³ greift auf die Erfahrungen aus der Hochschulausbildung und die dort eingesetzten Materialien und Werkzeuge zurück, um eine Lernwerkstatt zum Thema 'Objektorientiertes Modellieren' aufzubauen. Hier können sie Informationen über die Gestaltung von Informatikunterricht finden.

== '''Was finde ich auf den Seiten?''' ==
Von didaktischer Konzeption und Techniken zur Unterrichtsmethodik finden sie ganze Unterrichtseinheiten, abgestimmte Übungsaufgaben und Beschreibungen von verschiedenen Werkzeugen zur Verwendung im Unterricht, sowie vorgefertigte Projektdateien für das von uns benutzte und ebenfalls an der Universität Paderborn entwickelte Modellierungspaket Fujaba.

=== '''Was werden sonst noch für Informationen angeboten?''' ===
Weiterhin bieten wir im Bereich Softwaretechnik Informationen zur Ereignisbehandlung an. Unter anderem wird hier die Nutzung der Grafikbibliothek FGrafik sowohl in Fujaba, als auch im Quelltext erläutert.

Life^3/Didaktisches Konzept

2021-08-04T11:37:19Z

Koellner:

Life^3/Didaktisches Konzept

2021-08-04T11:04:08Z

Koellner: Erstellung einer Life^3 Unterseite

'''Überblick Didaktisches Konzept'''

Im Bereich Didaktik finden Sie Informationen zum didaktischen Hintergrund, zum Beispiel erklären wir hier das life³-Phasenmodell und den Ansatz der systemorientierten Didaktik.

Das didaktische Konzept des life³-Projekts lehnt sich an den in Paderborn vertretenen Ansatz der Systemorientierten Didaktik der Informatik an. Informationen hierzu finden Sie im Bereich Systemorientierte Didaktik.

Mit dem life³-Phasenmodell wird der mögliche Aufbau einer Unterrichtssequenz zum Einstieg in die Objektorientierung in der Jahrgangsstufe 11/1 beschrieben. Das Phasenmodell wurde an zwei Paderborner Schulen erprobt und unter Einsatz von Befragungen, Tests und videogestützter Unterrichtsbeobachtung evaluiert. Einzelheiten hierzu und zur konkreten Umsetzung des Phasenmodells werden in der Rubrik Unterrichtseinheiten beschrieben.

Hier in dieser Rubrik hingegen finden Sie - wie oben bereits angedeutet - abstraktere Darlegungen zu Aufbau und Konzeption des life³-Phasenmodells. Vielleicht kann dies dazu dienen, unser Vorgehen zu erhellen. Vielleicht werden Sie zu eigenen Ideen angeregt, oder Sie finden Verbesserungsmöglichkeiten, oder Ihnen kommen konkrete Ideen für eigene Unterrichtseinheiten orientiert am life³-Phasenmodell.

'''Das life³-Phasenmodell'''

Lorem Ipsum...

'''Systemorientierte Didaktik'''

Lorem Ipsum...

'''Lerntheoretischer Hintergrund'''

Lorem Ipsum...

Life^3

2021-08-04T10:52:32Z

2021-07-07T13:58:56Z

Koellner: