Bachelorarbeit-Bericht Nr. 4

Sie lesen einen älteren Blogeintrag. Bitte beachten Sie, dass die hierin enthaltenen Informationen technologisch veraltet sein können. Dieser Text spiegelt nicht unbedingt meine aktuellen Meinungen oder Fähigkeiten wider.

Dies ist die originale deutsche Version dieses Textes. Er ist auch als englische Übersetzung verfügbar.

10. August 2010

Diese Woche möchte ich den ersten Versuch unternehmen, eine aktualisierte Teachlet-Definition aufzustellen. Das Endergebnis des heutigen Eintrags soll der erste Versuch einer aktualisierten Definition sein, was auch bedeutet, dass ich um dein Feedback bitte (jedenfalls sofern du Teachlet-Erfahrung hast oder dich aus anderen Gründen angesprochen fühlst).

Aber vorher noch mal die „historische” Definition:

Ein Teachlet ist eine interaktive Lehreinheit, in der ein lauffähiges Stück Software um eine klar definierte Funktionalität erweitert werden soll, um ein Entwurfsmuster oder ein Programmiersprachkonzept zu veranschaulichen. Ein Moderator motiviert mit Hilfe eines Rechners und eines Beamers das Ausgangssystem sowie die vorzunehmende Erweiterung und lässt sich dann von den Teilnehmern anleiten, die dazu notwendigen Änderungen am Quelltext vorzunehmen.

Aus den Ergebnissen von letzter Woche haben wir die Liste der zentralen Aspekte für Teachlets (statisch) und Teachlet-Einheiten (dynamisch).

Teachlet

Teachlet-Einheit

Ich fange einfach mal so an, dass ich die bisherige Definition Satz für Satz versuche zu aktualisieren und dabei die Begriffen im Hinterkopf zu haben. Auf zum ersten Satz:

Ein Teachlet ist eine interaktive Lehreinheit, in der ein lauffähiges Stück Software um eine klar definierte Funktionalität erweitert werden soll, um ein Entwurfsmuster oder ein Programmiersprachkonzept zu veranschaulichen.

Was passt an diesem Satz nicht?

Ich würde zunächst die Interaktivität gerne mehr unterstreichen, da Teachlets unstreitbar in hohem Maße interaktiv sind und das eins der definierenden Elemente ist. Wenn einfach nur „interaktiv“ da steht, gibt das einen großen Interpretationsspielraum (manch einer würde evtl. Vorlesungen als interaktiv beschreiben, wenn Fragen gestellt werden können).

Der Begriff der lauffähigen Software ist in dieser Form sinnvoll.

Statt der Erweiterung der Funktionalität würde ich mir eine größere Flexibilität für die Aufgabenstellung wünschen. Eine Erweiterung der Funktionalität ist zwar der Normalfall, sollte jedoch nicht vorgeschrieben werden (denkbar wäre etwa auch ein großes Refactoring).

Die Formulierung „ein Entwurfsmuster oder ein Programmiersprachkonzept“ ist ebenfalls recht restriktiv und sollte im Hinblick auf andere mögliche Lernziele (bestimmte Algorithmen, Refactorings o.Ä.) verallgemeinert werden.

Mein Versuch eines neuen ersten Satzes, den ich dabei jedoch aus Stilgründen zweiteile:

Ein Teachlet ist eine höchst interaktive Lehreinheit, in der ein lauffähiges Stück Software so verändert wird, dass es eine bestimmte Aufgabenstellung erfüllt. Diese ist so gewählt, dass dadurch ein ganz bestimmtes Lernziel erreicht werden kann.

Kommen wir zum zweiten Satz:

Ein Moderator motiviert mit Hilfe eines Rechners und eines Beamers das Ausgangssystem sowie die vorzunehmende Erweiterung und lässt sich dann von den Teilnehmern anleiten, die dazu notwendigen Änderungen am Quelltext vorzunehmen.

Gut ist hier, dass der Moderator und die Teilnehmer erwähnt werden. Weniger gut ist die Einschränkung auf Rechner und Beamer, die (so der Konsens der Teachlet-Runde) besser auf eine „gemeinsame Sicht“ verallgemeinert werden sollte. So wären etwa auch Teachlets denkbar, bei denen sich Teilnehmer und Moderator nicht im selben physischen Raum aufhalten (z.B. Teleconferencing, Teachlets per Internet).

Das Ausgangssystem zu erwähnen ist ebenfalls sinnvoll. Statt einer Erweiterung sollte im o.g. Sinne eher von einer Veränderung gesprochen werden.

Letztlich ist zu diskutieren, inwieweit Teachlets auf die Veränderung von Quelltext festgelegt sein sollten, wo es doch auch z.B. visuelle Programmierung und sicher noch weitere Paradigmen der Softwareentwicklung gibt, in denen der Begriff des Quelltextes zugunsten anderer Implementationsmechanismen wegfällt.

Mal sehen, was wir daraus machen können:

Ein Moderator motiviert das Ausgangssystem sowie die vorzunehmende Veränderung in einer mit den Teilnehmern gemeinsamen Sicht (etwa am Beamer) und lässt sich dann von den Teilnehmern anleiten, die dazu notwendigen Änderungen an der Software vorzunehmen.

Zeit für eine kleine Bestandsaufnahme. Die folgenden Begriffe aus den obigen Listen sind noch nicht untergebracht: Lösungsraum, Implementation, Architektur, Zielsystem, Dokumentation; Rechner, Standard-Ablauf, Zwischenergebnisse festhalten, Entwurfsdiskussion.

Zwei davon würde ich gerne begründet ausklammern: Rechner weil das Vorhandensein eines Rechners durch die Veränderung lauffähiger Software implizit ist, und Standard-Ablauf weil dieser gerade durch die Definition dargestellt werden soll.

Um ein paar der restlichen Aspekte einzubringen, versuche ich jetzt, ein paar neue Sätze zu formulieren:

Für die Lösung der Aufgabe soll ein Lösungsraum mit mehreren möglichen Varianten hinsichtlich der Architektur existieren, um eine Entwurfsdiskussion zu ermöglichen. Der Moderator hat dabei die Aufgabe, die Diskussion zu lenken und Zwischenergebnisse festzuhalten. Nach der gemeinsamen Implementierungsphase ist das Ergebnis die veränderte Software.

Dann ist wohl noch etwas für das Drumherum nötig:

Zum Teachlet gehört weiterhin eine Dokumentation, die für die Vorbereitung relevante Unterlagen wie eine detaillierte Choreographie oder ein ausimplementiertes Zielsystem enthält.

Ich konnte nicht widerstehen, die Choreographie mit aufzunehmen, wenn wir schon das Zielsystem drin haben wollen. Trotzdem zweifle ich noch, ob dieser Satz mit zur elementaren Definition gehören sollte.

Hier ist also der Entwurf 1 der aktualisierten Teachlet-Definition:

Ein Teachlet ist eine höchst interaktive Lehreinheit, in der ein lauffähiges Stück Software so verändert wird, dass es eine bestimmte Aufgabenstellung erfüllt. Diese ist so gewählt, dass dadurch ein ganz bestimmtes Lernziel erreicht werden kann. Ein Moderator motiviert das Ausgangssystem sowie die vorzunehmende Veränderung in einer mit den Teilnehmern gemeinsamen Sicht (etwa am Beamer) und lässt sich dann von den Teilnehmern anleiten, die dazu notwendigen Änderungen an der Software vorzunehmen. Für die Lösung der Aufgabe soll ein Lösungsraum mit mehreren möglichen Varianten hinsichtlich der Architektur existieren, um eine Entwurfsdiskussion zu ermöglichen. Der Moderator hat dabei die Aufgabe, die Diskussion zu lenken und Zwischenergebnisse festzuhalten. Nach der gemeinsamen Implementierungsphase ist das Ergebnis die veränderte Software. Zum Teachlet gehört weiterhin eine Dokumentation, die für die Vorbereitung relevante Unterlagen wie eine detaillierte Choreographie oder ein ausimplementiertes Zielsystem enthält.

Puh, das ist etwas länger ausgefallen als die alte Definition, deckt allerdings auch deutlich mehr ab. Ich hoffe, dass der Ablauf klarer herausgestellt ist.

Ich wiederhole noch mal meine Bitte um Feedback zu diesem Entwurf. Idealerweise soll diese Definition mindestens so lange halten wie die vorherige, daher würde ich mögliche Probleme gerne jetzt schon identifizieren.

Wenn rechtzeitig etwas Feedback kommt, werde ich es bis nächste Woche in den Entwurf einpflegen. Ansonsten werde ich mir bis dahin mal ein paar Gedanken um den Leitfaden für meine Interviews machen. Bis dahin!