Wissenschaftliche Hausarbeit zur Ersten Staatsprüfung für

Transcrição

Wissenschaftliche Hausarbeit zur Ersten
Staatsprüfung für das Lehramt am
Gymnasium
im Fach:
Informatik
Thema:
Entwicklung einer Simulationsumgebung zur
explorativen Lösungsfindung grundlegender
Probleme in Verteilten Systemen.
vorgelegt von:
Meißner, Gabor
Name, Vorname
09.11.1983
geb. am
Rudolstadt
Geburtsort
INHALTSVERZEICHNIS
I
Inhaltsverzeichnis
Abbildungsverzeichnis
1
2
3
Einleitung
1
1.1
Verteilte Systeme in der Schule . . . . . . . . . . . . . . . . . . . .
1
1.2
Von der (fundamentalen) Idee zur Lernsoftware . . . . . . . . . . .
4
1.3
Motivation und Aufbau . . . . . . . . . . . . . . . . . . . . . . . .
6
Anforderungsanalyse und Rahmenbedingung
7
2.1
Technische Anforderungen . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Inhaltliche Anforderungen . . . . . . . . . . . . . . . . . . . . . .
7
2.3
Pädagogische und psychologische Anforderungen . . . . . . . . . .
8
2.4
Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . 11
Stand der Forschung
14
3.1
Merkmale und Einordnung von Lernsoftware . . . . . . . . . . . . 14
3.2
Lernsoftware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3
4
IV
3.2.1
Simulation zum Thema Internetworking: F ILIUS . . . . . . 16
3.2.2
Lernsoftware zur Automatentheorie und mehr: G ANIMAL . 19
Digitale Lernspiele . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1
Forschung über digitale Lernspiele . . . . . . . . . . . . . . 21
3.3.2
c . . . . . . . . . . . 25
Wo in der Welt ist Carmen Sandiego?
3.3.3
Fountain of Wisdom . . . . . . . . . . . . . . . . . . . . . 27
3.3.4
Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Konzeption
4.1
32
Inhaltliche Konzeption . . . . . . . . . . . . . . . . . . . . . . . . 32
INHALTSVERZEICHNIS
5
6
II
4.1.1
Die Spielwelt . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.2
Punktesystem . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.3
Auswahl von zentralen Problemen in Verteilten Systemen . 34
4.1.4
Auswahl und Beschreibung von Lösungswegen . . . . . . . 38
4.2
Prototypentwicklung und grafische Oberfläche . . . . . . . . . . . . 47
4.3
Unterteilung in Rahmenwerk und Plugins . . . . . . . . . . . . . . 50
4.4
Einordnung des Projekts . . . . . . . . . . . . . . . . . . . . . . . 51
Realisierung
53
5.1
Programmiersprache und verwendete Technologien . . . . . . . . . 53
5.2
Das Rahmenwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3
Die Problem-Plugins . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.1
Nachrichtenverlust . . . . . . . . . . . . . . . . . . . . . . 58
5.3.2
Unterschiedliche Nachrichtenreihenfolgen . . . . . . . . . . 60
5.3.3
Fälschen von Nachrichten . . . . . . . . . . . . . . . . . . 62
5.3.4
Inkonsistent-Werden einer gemeinsamen Ressource . . . . . 64
5.3.5
Mitlesen von Nachrichten . . . . . . . . . . . . . . . . . . 66
Evaluation
6.1
69
Schulversuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.1.1
Vorbemerkungen . . . . . . . . . . . . . . . . . . . . . . . 69
6.1.2
Fragebogenentwicklung . . . . . . . . . . . . . . . . . . . 70
6.1.3
Ergebniserfassung und Auswertung . . . . . . . . . . . . . 75
6.1.4
Schlussfolgerung aus den Ergebnissen . . . . . . . . . . . . 82
6.2
Schwächen der Lösung . . . . . . . . . . . . . . . . . . . . . . . . 84
6.3
Stärken der Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.4
Anwendungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . 86
INHALTSVERZEICHNIS
6.5
7
III
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Zusammenfassung
88
Literaturverzeichnis
89
Erklärung
95
A Technische Dokumentation
96
A.1 Beschreibung der Systempakete . . . . . . . . . . . . . . . . . . . 96
A.1.1 Der Systemkern: systemcontrol
. . . . . . . . . . . . . . . 96
A.1.2 Das systemcontrol.runtime-Unterpaket . . . . . . . . . . . . 98
A.1.3 Das systemcontrol.runtime.simulation-Unterpaket . . . . . . 99
A.1.4 Systemwerkzeuge: util.xmlhandling . . . . . . . . . . . . . 99
A.1.5 Die Problemsimulation: problem . . . . . . . . . . . . . . . 100
A.1.6 Die Problem-Schnittstellen: problem.ressourcemodell . . . . 100
A.1.7 Die Problem-Verwaltung: problem.runtime . . . . . . . . . 102
A.1.8 Das Kommunikationsunterpaket: problem.simulationmodel . 105
A.1.9 Die grafische Benutzeroberfläche: gui . . . . . . . . . . . . 107
A.1.10 Vorgabe zur Struktur von Plugins . . . . . . . . . . . . . . 110
A.1.11 Pluginbeschreibung in XML-Dateien . . . . . . . . . . . . 111
A.2 Beschreibung der Plugins . . . . . . . . . . . . . . . . . . . . . . . 112
A.2.1 Verlorene Nachrichten . . . . . . . . . . . . . . . . . . . . 112
A.2.2 Falsche Nachrichtenreihenfolge . . . . . . . . . . . . . . . 114
A.2.3 Inkonsistentes Nutzen gemeinsamer Ressourcen . . . . . . 116
A.2.4 Lauschangriff . . . . . . . . . . . . . . . . . . . . . . . . . 119
A.2.5 Verfälschte Nachrichten . . . . . . . . . . . . . . . . . . . 120
ABBILDUNGSVERZEICHNIS
IV
Abbildungsverzeichnis
1
Filius: Hauptfenster . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2
Filius: Simulation einer Peer-to-Peer-Anwendung . . . . . . . . . . 17
3
Ganimal: Zwei Möglichkeiten zur Erstellung eines Rot-SchwarzBaums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4
c Tutorien . . . . . . . . . . . . 22
NEED FOR SPEED: CARBON :
5
c Parasoziale Charaktäre . . . . . . . . . . . 23
CALL OF DUTY 4 :
6
c
Titelbild: Wo auf der Welt ist Carmen Sandiego?von
2001 . . . . 25
7
c
Wo auf der Welt ist Carmen Sandiego?Spielszene
. . . . . . . . . 26
8
Fountain of Wisdom: Spielszene . . . . . . . . . . . . . . . . . . . 28
9
Fountain of Wisdom: Bewertungssystem . . . . . . . . . . . . . . . 29
10
Uhren mit unterschiedlichen Geschwindigkeiten . . . . . . . . . . . 40
11
Uhren mit unterschiedlichen Geschwindigkeiten und Lamport . . . 42
12
Beispiel für ein Lese- und Scheibquorum . . . . . . . . . . . . . . 43
13
Kombinierter Einsatz von Verschlüsselung und Signierung mit Hilfe eines asymmertrischen Verschlüsselungsverfahrens1 . . . . . . . 45
14
Der Einsatz und die Verschlüsselung von Nachrichten-Digests2 . . . 47
15
Programmoberfläche von Gimp . . . . . . . . . . . . . . . . . . . . 48
16
Programmoberfläche des ersten Prototyps . . . . . . . . . . . . . . 49
17
Programmoberfläche des zweiten Prototyps . . . . . . . . . . . . . 50
18
Der Bürgermeister begrüßt den Benutzer . . . . . . . . . . . . . . . 55
19
Die Programmoberfläche . . . . . . . . . . . . . . . . . . . . . . . 55
20
Der Ereignis-Tab: Verknüpfung von Werkzeugen mit Ereignissen . . 56
21
Der Nachrichtentypen-Tab: Auswahl von Nachrichten-Optionen . . 57
22
Grafische Darstellung einer verlorenen Nachricht . . . . . . . . . . 59
23
Die Werkzeuge des Problems „Verlorene Nachrichten“ . . . . . . . 59
ABBILDUNGSVERZEICHNIS
V
24
Optionen des Typs „Nachrichtenbestätigung“ . . . . . . . . . . . . 60
25
Nachrichten haben bei den Agenten unterschiedliche Kombinationen 61
26
Werkzeuge zur Nachrichtensortierung . . . . . . . . . . . . . . . . 62
27
Gefälschte Nachricht werden über unterschiedliche Orte dargestellt . 63
28
Eine echte Nachricht: Identische Orte bei Sender und Empfänger . . 63
29
Werkzeuge für das Problem der gefälschten Nachrichten . . . . . . 63
30
Animation des Problems der gemeinsamen Ressourcen . . . . . . . 64
31
Aktuelle und nicht-aktuelle Ressourcen . . . . . . . . . . . . . . . 65
32
Werkzeuge des Problems der gemeinsamen Ressourcen . . . . . . . 65
33
Quoreneinstellungen des Problems der gemeinsamen Ressourcen . . 66
34
Ein dritter Agent liest Nachrichten mit . . . . . . . . . . . . . . . . 67
35
Werkzeuge zur Nachrichtenver- und entschlüsselung . . . . . . . . 67
36
Zwei Fragezeichen: Die Nachrichten werden verschlüsselt, aber nicht
entschlüsselt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
37
Ergebnisse des ersten Teils. Mittelpunkt der Linien sind die Durchschnittswerte, die Linien stellen die Standardabweichung dar. . . . . 77
38
Lernerfolg der Schülerinnen und Schüler . . . . . . . . . . . . . . . 79
39
Herstellen eines Praxisbezugs zum Problem . . . . . . . . . . . . . 79
40
UML-Diagramm 1: Systemübersicht . . . . . . . . . . . . . . . . . 96
41
UML-Diagramm 2: Systemsteuerung und -verwaltung . . . . . . . 97
42
UML-Diagramm 3: Laufzeitkomponenten zur Systemverwaltung . . 99
43
UML-Diagramm 4: Systemwerkzeuge . . . . . . . . . . . . . . . . 100
44
UML-Diagramm 5: das Problempaket . . . . . . . . . . . . . . . . 101
45
UML-Diagramm 6: die Problemschnittstellen . . . . . . . . . . . . 103
46
UML-Diagramm 7: Paket zur Problemverwaltung . . . . . . . . . . 104
47
UML-Diagramm 8: Nicht-generische Kommunikationskomponenten 106
48
UML-Diagramm 9: Das GUI-Paket . . . . . . . . . . . . . . . . . 110
1
EINLEITUNG
1
1
Einleitung
In den 1940er Jahren begann das moderne Computerzeitalter. Mit fortschreitender Technik bildeten sich einige Tendenzen der Entwicklung heraus, die den Umgang mit Computern für große Teile der Bevölkerung alltäglich werden ließ. Aus
fast allen Bereichen von Wirtschaft, Gesellschaft und auch aus dem Privatleben
sind Rechner nicht mehr wegzudenken. Daruntern zählen die Miniaturisierung, der
Leistungszuwachs, die Vernetzung und Einbettung von Computern, die mittlerweile über Local oder Wide Area Networks bishin zum Internet Kommunikation über
weite Distanzen mit Geschwindigkeiten bis zu mehreren Gigabit pro Sekunde erlauben. Verteilte Systemen nehmen in dieser Entwicklung eine besondere Rolle ein.
Nach Tannnenbaum sind Verteilte Systeme „eine Menge voneinander unabhängiger Computer, die dem Benutzer wie ein einzelnes, kohärentes System erscheinen“[TS03, S. 18].
Dabei sind zwei Aspekte entscheidend: Ein verteiltes System besteht aus mehreren
autonomen Maschinen und aus Benutzersicht ist die Zusammensetzung des Systems unbekannt, es erscheint als eine einzelne Maschine. Andere Definitionen charakterisieren diese Systeme über unabhängige Funktionseinheiten, die miteinander
kommunizieren und dabei Aufgaben bewältigen[Ben04, S. 5]. Je nachdem wie eng
oder weit die unterschiedlichen Definition ausgelegt werden, kann die Kommunikation in einem Verteilten System auf den Austausch von Nachrichten beschränkt
werden. Diese Annahme oder Definition soll der Arbeit zu Grunde liegen.
1.1
Verteilte Systeme in der Schule
„Es sieht so aus, als hätten wir in der Computertechnologie die Grenzen des
Möglichen erreicht, auch wenn man mit solchen Aussagen vorsichtig sein sollte sie neigen dazu, fünf Jahre später ziemlich dumm zu klingen.“
John von Neumann, 1949
1
EINLEITUNG
2
Mit dem Fortschritt der Technologie geht auch ein Bedeutungszuwachs der Informationstechnologie in der Gesellschaft und der Wirtschaft einher, der zwangsläufig
auch Einfluss auf die Schule und andere Bildungseinrichtungen hat. Der klassische
Informatikunterricht, zum Teil als Wahlfach, oder die Thematisierung von Informationstechnologie in anderen Schulfächern begann in den 1970er Jahren. Die Themen
und Perspektiven des Fachs haben sich natürlich in den letzten 40 Jahren verändert.
Die Schwerpunkte verlagerten sich von hardware- zu algorithmenorientiertem Informatikunterricht [SS04, S. 23f.].
Als Tendenz für die Zukunft werden die Einbettung der Informatik in übergeordnete
Begriffe und der Ansatz der fundamentalen Ideen von Schubert und Schwill herausgestellt. Die in der Informatik behandeltenden Themen wurden quantitativ mit der
Entwicklung des Fachs immer größer. Während zu Zeiten des hardwareorientierten Ansatzs die Maschine im Vordergrund stand, wurden zahlreiche Themen durch
die Algorithmenorientierung ergänzt. Dazu zählen etwa der Softwareentwurf oder
Fragen der theoretischen Informatik wie die Komplexität von Algorithmen. Mit der
Öffnung des Unterrichtsfachs und der Schwerpunktlegung auf fundamentale Ideen der Wissenschaft Informatik, finden sich auch Ansätze zur Thematisierung von
Verteilten Systemen wieder, auch wenn sie von Schubert und Schwill nicht explizit
genannt werden[SS04, S. 95ff]. Im Gegensatz dazu nennen eine Reihe von bayrischen Didaktikern in ihrem Konzept „Informatik und Schule“ Verteilte Systeme als
Thema für die Oberstufe ausdrücklich[BGH+ 00, S. 25ff.].
Um eine fundamentale Idee einer Wissenschaft zu werden, muss eine Idee fünf
Kriterien[SS04, S. 85] erfüllen, damit sie „ebenso einfach wie durchschlagend sind“
[Bru60, S. 26]. Das Hochizontalkriterium besagt, dass die Idee in verschiedenen
Gebieten vielfältig anwendbar und erkennbar sein muss. Verteilte Systeme könnten natürlich als eigenständiges Thema behandelt werden, darüberhinaus aber auch
in Verbindung mit den (Thüringer) Lehrplanthemen Internetworking, der Analyse von komplexeren Informatiksystemen oder nachrichtenbasierter Kommunikation
(Sicherheit von Informatiksystemen) [LP99, S. 14].
1
EINLEITUNG
3
Das zweite Kriterium ist das Vertikalkriterium, das besagt, dass eine Idee auf jedem intellektuellen Niveau unterrichtet werden muss.3 Als Beispiel soll ein konkretes Beispiel aus dem Thema Verteilte Systeme genannt werden. Der Austausch
von Nachrichten kann zu Beginn über eine einfache Unterscheidung zwischen einer
Netzwerk- und einer Softwareebene des Nachrichtenprotokolls dargestellt werden.
Zu einem späteren Zeitpunkt könnte man dann das komplette ISO-OSI- Schichtenmodell [Tan03] einführen und alle sieben Ebenen berücksichtigen. Weiterhin könnte
man das ISO/OSI-Modell und TCP oder IP[Hol03, S. 17f und S. 33f] vergleichen
und diskutiert werden.
Drittes Kriterium ist das Zielkriterium und besagt, dass die Idee einer idealisierten
Zielvorstellung dient, die aber eigentlich nicht realisierbar ist. Die Ziele von Verteilten Systemen lassen sich mit wünschenswerten Transparenzeigenschaften[TS03, S.
21-24], einer wirklich zuverläßiger Kommunikation und einfachen Nutzung der verteilter Ressourcen beschreiben.
Das vierte Kriterium ist das Zeitkriterium. Eine Idee muss historisch wahrnehmbar
und längerfristig relevant sein. Die historische Bedeutsamkeit Verteilter Systeme ist
durch die ständige Zunahme derartiger Systeme gegeben. Das Sinnkriterium ist das
letzte Kriterium für eine Idee um als fundamental zu gelten. Es besagt, dass die Idee
einen Bezug zur Sprache und zum Denken des Alltags haben muss. Verteilte Systeme sollten für einen „normalen“ Endanwender transparent sein, also unbemerkt
bleiben. Der Nachrichtenaustausch zwischen Computern zur kooperativen Arbeit an
gemeinsamen Ressourcen gehört aber zur täglichen Lebenswelt von Jugendlichen
und hat natürlich auch Bedeutung für die spätere Arbeitswelt und soziale Interaktionen. Die Schule hat an dieser Stelle die Aufgabe, über den intuitien Umgang hinaus
Wissen über das bedienende System bereitzustellen.
3
Vgl. dazu auch das „Spiralprinzip“[SS04, S. 45 u.a.]
1
EINLEITUNG
1.2
4
Von der (fundamentalen) Idee zur Lernsoftware
„Durch spielerisches Experimentieren kamen vermutlich ebenso viele Durchblicke
zustande wie durch planmäßiges Abarbeiten vorgegebener Programme.“ [Win04,
S. 179]
Werner Winkler
Verteilte Systeme könnten in Zukunft eine wichtigere Rolle als Thema im Informatikunterricht spielen. Gleiches könnte für Lernsoftware gelten. Der Begriff Lernsoftware ist sehr weit gefasst. So sind Entwicklungsumgebungen für Programmiersprachen oder auch Office-Anwendungen, wenn sie dem Lernen dienen, Lernsoftware. Auch Programme, die Lehrmaterialien erzeugen, Lernspiele oder Lernplattformen fallen unter diesen Begriff. Die in dieser Arbeit beschriebene Software unterstützt das Lernen jedoch durch eine vereinfachte Abbildung zentraler Eigenschaften der Realität auf eine Simulation. Simulation zeichnen sich dadurch aus, dass sie
reale Vorgänge sichtbar und manipulierbar machen um damit Strukturen und Funktionsweisen zu unterstreichen[Bi007].
Die Simulation soll den Benutzern eine Möglichkeit eröffnen, hinter die „Welt der
Zeichen“ zu blicken und zu verstehen, wie Verteilte Systeme arbeiten, auch wenn
eine Simulation „nur“ die Realität abstrakt abbilden kann. Die Simulation ist kein
Beitrag zur Beherrschung eines Werkzeugs wie einem Chats, das auf einem verteilten System basiert. Sie soll systematisch und explizit die Vorgänge hinter der
Oberfläche beleuchten und zugänglich machen. Die Simulation soll also das Funktionieren des Werkzeugs aufzeigen[Ber07].
Ein zweites Element der Software ist die Spielorientierung. Um die Simulation
möglichst spannend und ansprechend zu gestalten, werden die Benutzer in eine
fiktive Spielwelt eingeführt. Der vielzitierte Johan Huizinga beschreibt das Spiel
als „eine freiwillige Handlung [...], die innerhalb festgesetzter Grenzen von Zeit
und Raum nach freiwillig angenommenen, aber unbedingt bindenden Regeln ver-
1
EINLEITUNG
5
richtet wird, ihr Ziel in sich selber hat und begleitet wird von einem Gefühl der
Spannung und Freude und einem Bewusstsein des ’Andersseins’ als das ’gewöhnliche Leben’“[Hui87, S. 37]. Diese klassische Definition des Spielens widerspricht
natürlich dem Begriff „Lernspiel“, da sie davon ausgeht, dass ein Spiel nur dem
Selbstzweck dient und damit nicht dem Lernen dienen kann. Auch die Freiwilligkeit einer Lernsoftware muss im Projektzusammenhang sicher bezweifelt werden.
Interessant sind aber andere Attribute des Spielens nach Huizinga. Darunter fallen
die festgesetzten Grenzen, die bindenden Regeln, die positiven Emotionen, die mit
einem Spiel verbunden sein sollen, sowie das Ausbrechen aus dem Alltag. All diese
Eigenschaften machen den Entwurf eines Lernspiel sehr interessant.
Dass Spielen und Lernen aber trotzdem einen engen Zusammenhang aufweisen,
zeigen andere Arbeiten[Win04, S. 170] und ist zudem auch offensichtlich. Bopp
zeigt beispielsweise auf, wie Lernen in Computerspielen stattfindet und wie diese
Analyse für Lernspiele genutzt werden kann. Spiele werden immer komplexer und
gleichzeitig haben Spieler wenig Lust vor Beginn eines Spiels ein Handbuch zu studieren. Komplexere Regeln bauen stattdessen auf bekannten Regeln auf und werden
in Form von aufwendig entwickelten Methoden dem Spieler näher gebracht. „Games that trigger learning and thus allow players to do new interesting things are
games that people like to play.“[Bop06, S. 9] Diese einfache Formel soll möglichst
auch für Lernspiele, also auch im vorliegenden Projekt gelten. Es kommt also auf
die Methoden an und die sollen möglichst wenig an klassisches Lernen errinnern.
Um den Ehrgeiz des Benutzers zu wecken, wurde ein Bewertungssystem entwickelt,
das das Spielergebnis vergleichbar mit den von anderen Spielern macht.
Die Software versteht sich dabei als „Explorationsmodul“. Nach Kerres sind diese
Module Software, die Lernaktivitäten beim Lernenden initiieren, die von ihm ausgehen. „Exploratives Lernen in solchen Lernumgebungen schließt aus, dass z. B. Ziele
und/ oder Wege des Lernens von außen vorgegeben werden. Es kann ein Angebot
gemacht werden, das so gestaltet ist, dass die Person motiviert ist sich eigenständig
mit einem Gegenstand auseinanderzusetzen“[Ker01, S. 217f].
1
1.3
EINLEITUNG
6
Motivation und Aufbau
Die mediale Diskussion über Computerspiele ist unüberschau groß. Dabei geht es
meist darum, wie Computerspiele Jugendlichen schaden. Manchmal wird aber auch
darüber diskutiert, ob und wie elektronische Spiele einen Nutzen haben könnten
[Kri08].s Die Arbeit soll ein Beispiel dafür sein, dass komplexe Lernvorgänge in
Spielen stattfinden können, dass Lernen mit Computerspielen angstfrei sein kann
und den Lernern vielleicht auch etwas Spass bereitet.
Ausgehend von diesen Grundannahmen wurde eine explorative Simulation Verteilter Systeme konzipiert, implementiert und getestet. In dieser Arbeit soll zunächst
untersucht werden, welche Anforderungen erstellt wurden und daraus ableitend
welche Voraussetzungen für die Entwicklung der Software bestanden. In einem
zweiten Schritt werden ähnliche Projekte vorgestellt. Im vierten Abschnitt der Arbeit wird die inhaltliche, didaktische und technische Konzeption der Simulation
näher erläutert. Anschließend wird die Realisierung diskutiert und das Ergebnis der
Arbeit hauptsächlich anhand empirischer Untersuchungen in verschiedenen Informatikkursen evaluiert. Zudem werden in diesem Abschnitt Schlussfolgerungen für
eine Weiterentwicklung der Simulation vorgestellt. Im siebten Kapitel werden ableitend aus den Hypothesen und den Ergebnissen der Evaluation Einsatzmöglichkeiten
der Software skizziert. Abschließend folgt ein Ausblick.
2
2
ANFORDERUNGSANALYSE UND RAHMENBEDINGUNG
7
Anforderungsanalyse und Rahmenbedingung
Die Simulation ist eine Lernsoftware, die Lernende dabei unterstützt, zentrale Probleme Verteiler Systeme zu kennen und mit einfachen, aber authentischen Mitteln Lösungen für diese Probleme bereitzustellen. Im folgenden Kapitel werden die
technischen, inhaltlichen und erziehungswissenschaftlichen Anforderungen an das
Projekt sowie die vorausgesetzten Rahmenbedingungen dargestellt.
2.1
Technische Anforderungen
Die Simulation soll plattformunabhängig und ressourcenschonend realisiert werden. Dies begrenzt natürlich die Wahl der Programmiersprachen. Das Programm
soll zudem in einen Haupt- und in mehrere Problemteile abgegrenzt werden. Im
Rahmen der Arbeit werden verschiedene Probleme implementiert. Die Software
soll so entworfen werden, dass auf einfache Art weitere Probleme in die Simulation
integriert werden können. Die Software soll über eine grafische Benutzerschnittc
stelle verfügen und mit Bedienelementen ausgestattet sein, die aus Windowsund
anderen modernen Betriebssystemen sowie Webapplikationen bekannt sind. Natürlich ist die Oberfläche aufgeräumt und möglichst einfach zu gestalten. Eine weitere
Funktionalität ist das Speichern und Laden von Systemzuständen, damit das Programm abgebrochen und fortgesetzt werden kann.
2.2
Inhaltliche Anforderungen
Um Schülerinnen, Schülern und anderen Lernenden die Thematik Verteilte Systeme
näher zu bringen, ist es notwendig ihnen zu verdeutlichen, welche Ziele derartige
Systeme haben. Sie sollten zum Beispiel erkennen, dass es sinnvoll ist, Nutzern Verteilter Systeme über weite Strecke den Zugang zu Ressourcen zu ermöglichen[TS03,
S. 20]. Diese Ziele kann die Simulation aber nur bedingt vermitteln und muss die
2
8
Aufgabe des begleiteten Unterrichts sein, in den die Software eingebettet sein sollte. Weiterhin spielen Transparenzen in Verteilten Systemen eine wichtige Rolle,
etwa dass es sich überhaupt um ein Verteiltes System handelt. So sollen verschiedene Mechanismen hinter dem System dem Benutzern verborgen bleiben[TS03, S.
22ff.]. Dies kann im Rahmen der Simulation nur begrenzt dargestellt werden, soll
aber versucht werden.
Verteilte Systeme sollen auch offen, also erweiterbar, und skalierbar sein. Damit
sollen zusätzliche Funktionalitäten und Mechanismen in einem Verteilten System
ergänzt oder auch entfernt werden können[TS03, S. 24-33]. Auch diese Ziele können nur begrenzt Gegenstand der Software sein, sollten aber zumindest ansatzweise
vermittelt werden. Hier bieten sich gute Möglichkeiten für den Unterricht, Informationen und Wissen zu ergänzen.
Das Hauptziel der Simulation ist aber die Darstellung von zentralen Problemen Verteilter Systeme. Es soll gezeigt werden, dass ein einfaches System in der Realität
oft fehleranfällig ist und zahlreiche Funktionalitäten ergänzt werden müssen um es
stabil und robust zumachen. Nur dies würde garantieren, dass Benutzer die Vorzüge
von Software, die auf verteilten Ressourcen basiert, eher vertrauen als anderen Methoden. Sicher ist es ein Vorteil, wenn man zu jeder Uhrzeit eine Onlineüberweisung
durchführen kann und nicht zur Bank gehen muss. Ein möglicher Nachteil, dass das
System aber nicht sicher ist und wichtige Informationen an Dritte geraten könnten,
würden diesen Vorteil aber zunichte machen.
2.3
Pädagogische und psychologische Anforderungen
Zur Klärung der pädagogischen Anforderungen an die Simulation ist ein grundsätzliches Verständnis von drei Lerntheorien von Bedeutung:4
Kognitivismus
4
Auswahl begründet durch [HS07, S. 30]
2
9
Unter Kognitivismus versteht man eine Lerntheorie, die die Kognition in den Mittelpunkt des Lernen stellt und davon ausgeht, dass die „inneren“ Prozesse, „durch die
ein Organismus Kenntnis von seiner Umwelt erlangt“, für den Wissenserwerb verantwortlich sind. Darunter fallen vor allem „Wahrnehmung, Vorstellung, Denken,
Urteilen [und] Sprache“[Ede96, S. 8]. Für eine Lernsimulation ist der Kognitivismus deshalb von Bedeutung, weil eine Lösungsfindung auf der Basis von kognitiven
Vorgängen stattfinden sollte um nachhaltig zu sein.
Behaviorismus
Nach dem Behaviorismus, einer Gegenströmung zum Kognitivismus, ist Verhalten das wichtigste Merkmal des Menschseins. Außerdem wird davon ausgegangen,
dass das Verhalten veränderbar ist. Deshalb spielt die Umwelt eine entscheidende Rolle in der Analyse des menschlichen Verhaltens. Von besonderer Bedeutung
ist das Beschreiben der gewünschten Verhaltensänderung des Lernenden, um sog.
„Verstärkermechanismen“ auswählen zu können. Zwischen Verhalten und einem
Umweltereignis gibt es demnach funktionale Zusammenhänge[Sun06, S. 64f]. Für
eine Simulation, die nach Lafrancois Lernen als Verhaltsänderung ausgelöst von
Erfahrungen versteht[Lef06, S. 3], spielt diese Analyseform eine besondere Rolle.
Konstruktivismus
Für das Lernen durch Simulationen ist nach Heptner und Schnarrenberger der Konstruktivismus von besonderer Bedeutung [HS07, S. 33], da Manipulationen als konstruktivistische Vorgänge an einem realen System u.a. zu kompliziert sein können
[Bi007]. Unter Konstruktivismus wird dabei verstanden, dass Wissen nur in den
Köpfen der Lernenden aktiv konstruiert werden kann. Durch die aktive, lernerorientierte Auseinandersetzung mit der Umwelt, z.B. in Form der Manipulation von
Objekten mit Hilfe einer Simulation, finden Lernprozesse statt [KW06, S.70f].
L ERNTHEORIE
M ERKMALE DER S OFTWARE
B EISPIEL
Behaviorismus
Instruktionsparadigma: Frage-Antwort-Schema Vokabeltrainer
Kognitivismus
Problemlöseparadigma: vorgegebenes Problem
Simulationen
2
Konstruktivismus Problemlöseparadigma: offenes Problem
10
Simulationen
Tabelle 1: Lerntheorien und ihre Beziehung zu Lernsoftware
[WR02, S. 17]
Neben dem grundlegenden Verständnis der Lerntheorien ist eine Zuordnung der
Software zu einem Lernprogrammtyp notwendig um weitere pädagogische Anforderungen an das Projekt benennen zu können. Prinzipiell sind dabei Programme zu
unterscheiden, die dem behavioristischen Lernmodell nahe stehen und einen starren Ablauf verfolgen (Information - Frage - Antwort - Auswertung). Die Auswertung besteht dabei meist nur aus „richtig“ oder „falsch“[Sun06, S. 74ff]. Im Gegensatz gibt es Lernsoftware, die Lernenden zutraut, ihr Wissen selbst zu konstruieren.
Solche Software muss natürlich offener angelegt werden als Software vom ersten
Typ[Sun06, S. 77ff]. Das vorliegende Projekt soll dem konstruktivistischer Lernsoftware zuzuordnen (Vgl. S. 10, Tabelle 1).
Nach der Typologie von Baumgart und Payr[BP99, S. 142] gibt es weiterhin die
Gruppe der Simulationen und Spiele, die einem Lerner vor die Aufgabe stellt durch
gezielte Manipulation ein bestimmtes Ergebnis zu bewirken. In komplexeren Simulationen haben solche veränderten Parameter auch Auswirkungen auf andere Parameter und es entsteht ein komplexes Netz von Wechselwirkungen [BP99, S. 161].
Dabei besteht eine Verwandtschaft zwischen dem Spielen, dem Lernen und dem
Begriff der Simulation: „The relationship between games and simulations has been
close, even when virtual reality systems were being pioneered the power of immersive environments for learning was recognised“[Fre06, S. 10].
Neben Simulationen gibt es auch noch Experten- und Modellbildungssysteme. Diese stellen „Wissen“, etwa in Form von Werkzeugen, bereit um damit konkrete Probleme lösen zu können. Hierbei sollen erfolgreiche und nicht erfolgreiche Lösungswege in einem konkreten Fall zu kognitiven Lernerfahrungen und zu wünschenswerten Generalisierungen führen [AP94, S. 39-59]. Trotz der offensichtlichen Ähn-
2
11
lichkeiten der beiden Typen, gibt es einen zentralen Unterschied. Simulationen sollen bestimmte Verhaltensmuster einüben und Modellbildungssysteme theoretische
Überlegungen über strukturelle Gegebenheiten initiieren[HS07, S. 33]. Eine weitere Anforderung an die Lernsoftware ist es also, nicht nur Verhaltensweisen zu
trainieren, sondern generalisierbares Wissen zu erzeugen. Die Software soll also,
eingebettet in einen entsprechenden Unterricht, die Voraussetzungen schaffen, alle
drei Anforderungsbereiche der Einheitlichen Prüfungsanforderungen im Fach Informatik in den Aufgabenkontext einzubinden. So sollen bekannte Sachverhalte,
Verfahren und Arbeitstechniken die Grundlage zur Lösung der gestellten Probleme
sein (z.B. die Bedienung des Programms und die Verwendung verschiedener Datentypen). Diese bekannten Techniken sollen in dem neuen Zusammenhang (Verteilte Systeme) angewendet (Anforderungsbereich II) und schließlich bewusst und
selbstständig zur Lösung einer komplexeren Aufgabe verwendet werden (Anforderungsbereich III)[Ku003, S. 11f].
2.4
Rahmenbedingungen
Der Entwicklung der Simulation gehen verschiedene Annahmen der aktuellen Forschung zu E-Learning-Produkten voraus. So richtet sich die Software vordergründig
an ein eingebettes Unterrichtskonzept, dass neben Phasen der individuellen Arbeit
von Schülerinnen und Schüler mit der Simulation auch Elemente klassischer Unterrichtsgestaltung beinhaltet. Diese Voraussetzung basiert auch auf aktuellen wissenschaftlichen Erkenntnissen, die einen kombinierten, eingebetteten Einsatz von
Lernsoftware als sinnvoll herausstellen [Ker03]. Lehrende müssen das Konzept Verteilter Systeme trotz der Software den Lernenden nahe bringen, die Simulation hat
nicht den Anspruch Unterricht zu ersetzen[KSJ06, S. 10]. Stattdessen wird die „Arbeit mit einem Explorationsmodul [...] aus dem Wunsch des Schülers [motiviert]
mit Elementen zu agieren, die auf Grund ihrer Abstraktion oder Komplexität mit
anderen Lernmaterialien schwer erfassbar oder schwerer darstellbar sind“[SS04, S.
142].
2
12
Weitere Voraussetzungen, die Anforderungen an die Simulation sind, lassen sich in
einigen Punkten zusammenfassen[KSJ06, S. 25-29]. So sollen die technischen Voraussetzungen zur Nutzung der Software gegeben sein. Dies legt die Verwendung
einer möglichst kostenlosen und plattformübergreifenden Programmiersprache nahe. Außerdem sollte beim Einsatz der Software darauf geachtet werden, dass Hilfe
bei technischen Problemen angeboten werden kann. Dies kann etwa durch OnlineHilfen oder gut geschulte Lehrende realisiert werden. Es wäre weiterhin denkbar,
einen virtuellen Raum aufzubauen, wo sich Entwickler und Nutzer der Software austauschen können. Ein zweiter Anforderungskomplex sind Vorkenntnisse der
Lehrenden. Da die Software für den Informatikunterricht konzipiert wurde, ist davon auszugehen, dass die Lehrerinnen und Lehrer über das nötige Fachwissen im
Umgang mit der Simulation verfügen und sich schnell und problemlos in die Thematik Verteilte Systeme einarbeiten können.
Es gibt auch Voraussetzungen an die Lernenden, wenn der Einsatz der Simulation
erfolgreich sein soll. So müssen sie grundlegende Kenntnisse über die Bedienung
von Computer haben und mit einer modernen, grafischen Oberfläche umgehen können. Sie sollten weiterhin einfache Datentypen kennen und sich mit Algorithmen
auskennen. Auch dies kann von Schülerinnen und Schülern erwartet werden, die
schon einige Zeit den Informatikunterricht besucht haben. Der Zeitaufwand für die
Vorbereitung, die Verwendung der Simulation und die Nachbereitung der Thematik
sollte sich ebenfalls im Rahmen halten. Hier ist angedacht, dass alle drei Schritte in einer Doppelstunde durchgeführt werden können. Diese Annahme soll in der
Evaluation überprüft werden.
Unter „Instruktionsdesign für E-Learning“5 wird eine weitere Gruppe Anforderungen zusammengefasst. Dabei soll der Lernende aktiv sein und sein Wissen selbst
mit Unterstützung der Software und bezogen auf einen konkreten Kontext konstru5
Die Auswahl der relevanten Punkte für die Software entspricht nicht allen Qualitätskriterien, die
von Kristöfl u.a. aufgestellt, da sich viele Punkte auf ein konkretes Unterrichtsmodell beziehen und
nicht auf die Simulation an sich. Im Kapitel „Anwendungsmöglichkeiten“ wird auf andere Punkte
genauer eingegangen.
2
13
ieren. Die Schüleraktivität wird über die Bedingung des Software sichergestellt. Die
Lösungsfindung in der Simulation entspricht der Wissenskonstruktion und der Kontext ist die von der Simulation bereitgestellte „Lernwelt“. Die Lernaktivität wird
über Selbstständigkeit, den Rückgriff auf implizites Wissen, die Einbindung konkreter Probleme in komplexe Denkprozesse und die Anwendung auf eine konkrete
Problemsituation sichergestellt. Für Hilfestellungen wird eine breite, mediale Unterstützung in Form einer Dokumentation und Anwendungshilfe sowie dem Verweis
auf verschiedene (Online-)Quellen angeboten. Weiterhin ist der Lerninhalt aktuell
und authentisch, auch wenn er sich auf ein fiktives, spielerisches Szenario bezieht.
Die Rahmenbedingungen, die dieser Arbeit zu Grunde liegen, sind also:
• Explorativität
• niedrige technische Anforderungen und technische Unterstützung am Lernort
• inhaltliche Unterstützung am Lernort
• geringe Voraussetzungen an die Vorkenntnisse der Lernenden
• Schüleraktivität6
• realitätsbezogene Lösungsfindung
• aktuelle und authenische Lerninhalte
6
Unter Schüleraktivität ist zu verstehen, dass Schülerinnen und Schüler durch aktives, selbsttäti-
ges Handeln lernen und nicht passiv durch Zuhören, Abschreiben oder Nachvollziehen.
3
3
STAND DER FORSCHUNG
14
Stand der Forschung
Dem Projektinhalt entsprechend soll in diesem Kapitel der Stand der Forschung
analysiert werden. Dazu wird zunächst eine Einordnung des Projekt anhand verschiedener Typologien vorgenommen. Anschließend geht es um exploratives Lernen im Allgemeinen und im Informatikunterricht. Das vorliegende Projekt kann dabei am besten mit F ILIUS verglichen werden, einer Software zum Thema Internetworking der Universität Siegen. Da das vorliegende Projekt ein digitales Lernspiel
ist, sollen Beispiele aus der aktuellen Forschung über spiel-basiertes E-Learning
diskutiert werden.
3.1
Merkmale und Einordnung von Lernsoftware
Um die vorzustellenden Projekte einordnen zu können, werden an dieser Stelle noch
einige Merkmale definiert. Der Gegenstand der Software ist das Thema, über das etwas gelernt werden soll. Die Nutzerzahl unterscheidet, ob das Programm von mehreren Nutzern gleichzeitig verwendet werden kann. Die unterschiedlichen Softwaretypen wurden bereits angeführt. Mit Spielorientierung ist gemeint, ob das Lernen
in einer Spielwelt stattfinden.
Der Begriff Explorativität wurde bereits definiert. Die Erweiterbarkeit meint, ob
sich durch angemessenen Aufwand weitere Lerninhalte zur Software hinzufügen
lassen. Mit Einbettung in andere Lernformen soll festgelegt werden, ob die Software
allein genutzt werden kann oder ob es sinnvoller ist sie in einen Unterrichtskontext
zu stellen.
Als vorletztes Merkmal wird der „Lerngegenstandstyp“ definiert, das hinter einer
Lernsoftware steckt. Dieser Typ zeichnet den Zugang zum Verständnis des Mediums aus. Hier sind generell zu unterscheiden, ob das Bedienen und Beherrschen
eines Werkzeugs, das vom Computer mittels einer grafischen Benutzeroberfläche
bereitgestellt wird [Maa94, S. 5], („werkzeugorientiert“) oder das Verstehen des
3
STAND DER FORSCHUNG
15
Funktionierens der Werkzeuge („systemorientiert“) im Vordergrund stehen. Außerdem soll die Methodik des Lernens unterschieden werden, die von den Programmen
verwendet werden. Sind die Methoden unabhängig vom Lerngegenstand, werden
sie als „offen“ bezeichnet. Orientieren sich die Methoden am Funktionieren des zu
untersuchenden Objekts, werden sie „problembezogen“ genannt.
Daraus ergibt sich folgendes Schema für Vergleichsmerkmale von E-Learningprodukten:
• Gegenstand
• Nutzerzahl
• Softwaretyp
• Spielorientierung
• Explorativität
• Erweiterbarkeit
• Einbettung in andere Lernformen
• Lerngegenstandstyp
• Problembezug
• Art des Wissens7
3.2
Lernsoftware
Das vorliegende Projekt versteht sich wie bereits ausgeführt als exploratives Modul.
Solche Module gibt es viele. Exemplarisch sollen die Projekte F ILIUS und G ANI MAL
in diesem Abschnitt kurz vorgestellt werden. F ILIUS weist eine thematische
Nähe zum vorliegenden Projekt auf und hat ebenfalls moderne Erkenntnisse der
7
Hier könnten zahlreiche Arten unterschieden werden. Es soll aber nur zwischen zwei Arten in
dieser Arbeit differenziert werden: Sachwissen und Handlungswissen.
3
STAND DER FORSCHUNG
16
Abbildung 1: Hauptfenster von Filius.8
Lernsoftwareforschung berücksichtigt. Letzteres gilt auch für G ANIMAL, welches
sich u.a. mit Fragen der Automatentheorie beschäftigt.
3.2.1
Simulation zum Thema Internetworking: F ILIUS
F ILIUS ist ein Projekt, das an der Universität Siegen von der Fachgruppe Didaktik
der Informatik und E-Learning entwickelt wurde. F ILIUS bedeutet soviel wie „Freie
Interaktive Lernumgebung für Internetworking der Universität Siegen“. Die Haupttätigkeiten, die Benutzer mit F ILIUS vornehmen können, sind das Konstruieren und
Konfigurieren von Netzwerken sowie die Interaktion mit dem System. Die Software
bietet daneben die Möglichkeit, alle Vorgänge auf unterschiedlichen Netzschichten
zu beobachten [ABD+ 07a, S. 1ff]. Darstellbar sind mit der Simulation verschiedene
Typen von Rechnern sowie weitere Komponenten, die im Internet eine Rolle spielen. Dazu zählen Kabel, Switch, Router, Personal Computer, Laptops und Modems
[ABD+ 07a, S. 16]. Im Zentrum der Software stehen jedoch die Modelle und Dienste, die zum Verständnis des Internets grundlegend notwendig sind. Darunter zählen
das Client-Server-Modell, das World Wide Web, Routing, Peer-to-peer und E-Mail
[ABD+ 07a, S. 6-13 und 30-41].
Die Untersuchung der Vorgänge auf verschiedenen Netzwerkschichten [ABD+ 07a,
8
Asschoff,
André
u.a.,
<http://www.die.informatik.uni-siegen.de/pg\
textsc{Filius}/pic/MainFrame.png> am 08.03.08.
3
STAND DER FORSCHUNG
17
Abbildung 2: Simulation einer Peer-to-Peer-Anwendung.9
S. 52-60] sind dabei die interessanteste Eigenschaft, denn sie bieten die Möglichkeit
hinter die Internet-“Werkzeuge“ zu schauen und nicht nur ihre Bedienung nachvollziehbar zu machen, sondern auch ihre eigentliche Funktionsweise. Den gleichen
Anspruch hat auch die vorliegende Simulation, der einen entscheidenden Mehrwert
für den Unterricht erbringen kann. F ILIUS hat ebenfalls den Anspruch eine explorative Lernsoftware zu sein, die konstruktives Lernen ermöglicht [ABD+ 07a, S. 2f].
Das Siegener Projekt soll also ebenfalls nicht isoliert betrachtet werden, sondern in
einen klassischen Unterrichtskontext begleitet von einem Lehrer eingebunden werden und gleichzeitig den Schülerinnen und Schülern den Wissenserwerb auf Basis
konstruktiver Tätigkeiten ermöglichen.
Der Aufbau der Software hat viele Paralellen zum vorliegenden Projekt. Unter einem Projekt wird ein konfiguriertes Netzwerk verstanden. Dies kann neu angelegt,
geladen und gespeichert werden. Ein solches Projekt ist vergleichbar mit den „Spielständen“ im vorliegenden Projekt. Weiterhin werden zwei Modi unterschieden: Im
Entwurfsmodus wird ein Netzwerk zusammengefügt. Im Simulationsmodus kann
das Netzwerk dann auf Funktionstüchtigkeit überprüft und anhand eines vorgegebenen Szenario getestet werden [ABD+ 07b, S. 3f und S. 6-9]. Auch diese funktionelle
Unterscheidung ist eine Gemeinsamkeit der beiden Projekte.
9
Asschoff,
André
u.a.,
<http://www.die.informatik.uni-siegen.de/pg\
3
STAND DER FORSCHUNG
18
F ILIUS ist ebenfalls erweiterbar. Dazu gibt es einen Software-Assistenten, der eingebunden in die F ILIUS-Oberfläche Client- oder Server-Anwendungen dabei hilft,
neue Funktionalitäten hinzuzufügen [ABD+ 07b, S. 4].
Die Unterschiede liegen natürlich zunächst in der Thematik. Das vorliegende Projekt beschäftigt sich mit Verteilten Systemen und nicht mit dem Internet und seinen
Diensten. Auch die Hardware hinter dem Netzwerk sowie Fragen der Konfiguration sind für das Projekt uninteressant, da sie als vorgegeben vorausgesetzt werden.
Die verschiedenen Szenarien in F ILIUS sind zwar mit den zentralen Problemen vergleichbar, aber nicht das Hauptaugenmerk der Simulation. Ein zentraler, pädagogischer Unterschied ist die Spielorientierung. Das vorliegende Projekt hat einen
ausgeprägten Spielcharakter und lässt sich der Gruppe der Lernspiele zurechnen,
F ILIUS kann man eher als reine Lernsoftware bezeichnen. Das vorliegende Projekt soll außerdem das Erstellen von Algorithmen ermöglichen. In F ILIUS werden
hingegen Konfigurationen von Maschinen erstellt.
M ERKMAL
F ILIUS
Gegenstand
Internetworking
Nutzerzahl
Einzelnutzer
Softwaretyp
Simulation
Spielorientierung
nicht spielorientiert
Explorativität
explorativ
Erweiterbarkeit
erweiterbar
Einbettung in andere Lernformen eingebettet
Lerngegenstandstyp
systemnah
Problembezug
problembezogen
Art des Wissens
Handlungswissen
Tabelle 2: Einordung von Filius
textsc{Filius}/pic/P2PSuche.png> am 08.03.08.
3
STAND DER FORSCHUNG
19
Abbildung 3: Ganimal: Zwei Möglichkeiten zur Erstellung eines Rot-SchwarzBaums[GanoJ]
3.2.2
Lernsoftware zur Automatentheorie und mehr: G ANIMAL
Das Projekt G ANIMAL wurde an der Universität des Saarlandes mit Unterstützung
der Deutschen Forschungsgemeinschaft entwickelt und beschäftigt sich mit endlichen Automaten, Bäumen u.a.10 . Das System basiert auf HTML und JAVA und kann
on- und offline genutzt werden. Außerdem wird die Systematik des Wissensaufbaus
des Projekts hervorgehoben. Darunter wird verstanden, dass ein Lernender zunächst
einen Text lesen kann und anschließend mit Informationen aus dem Text einen Prozess spezifiziert. Aus diesem vom Nutzer erstellten Prozess generiert die Software
dann eine Grafik. Der Lernende hatte damit die Möglichkeit zu interagieren und
steuert das Lernen selbst [Ker03, S. 2f].
Auch G ANIMAL ist ein Einzelnutzersystem und simuliert den Lerngegenstand. Durch
das Paradigma der Generativität ist G ANIMAL auch erweiterbar, wobei die Erweiterbarkeit sich auf Werkzeuge u.ä. bezieht und das Rahmenwerk damit dem
Plugin-Entwickler möglichst viel (vor allem konzeptionelle) Arbeit abnimmt [Ker03,
S. 4ff].
10
Weitere Anwendungsmöglichkeiten sind unter [GanoJ] nachzulesen.
3
STAND DER FORSCHUNG
20
Die Unterschiede zum vorliegenden Projekte liegen im Lernleitbild und natürlich
im Thema. Auch bei G ANIMAL steht das Verständnis des Verstehens des Lerngegenstands im Vordergrund, allerdings sind Handlungen, die der Lernende auszuführen relativ unabhängig davon. Aufgrund der weiten Thematik hätte man ein solches
System sicher kaum anders entwerfen können.
M ERKMAL
G ANIMAL
Gegenstand
Theoretische Informatik
Nutzerzahl
Einzelnutzer
Softwaretyp
Simulation
Spielorientierung
nicht spielorientiert
Explorativität
explorativ
Erweiterbarkeit
erweiterbar
Einbettung in andere Lernformen nicht eingebettet
Lerngegenstandstyp
systemnah
Problembezug
problembezogen
Art des Wissens
Handlungswissen
Tabelle 3: Einordnung von Ganimal
3
STAND DER FORSCHUNG
3.3
21
Digitale Lernspiele
Das vorliegende Projekt ist ein digitales Lernspiel. Darunter zu verstehen ist Software, die als Zweck die Erfüllung von Lernzielen hat und die das mit spielerischen
Elementen umzusetzen versucht. Der folgende Abschnitt beschäftigt sich schwerpunktmäßig mit dem Forschungsstand in diesem Sektor.
3.3.1
Forschung über digitale Lernspiele
Die Forschung beschäftigt sich auf unterschiedlichste Weise mit digitalen Lernspielen. Angelehnt an Brezinka[Bre95] gibt es drei Hauptgruppen von Forschungsschwerpunkten, die dabei gesetzt werden können. Das sind
• die pädagogische Analyse von Computerspielen (Lernspiele und Unterhaltungsspiele),
• der pädagogischer Umgang mit Computerspielen und
• die methodologisch-technische Forschung zur pädagogischen Gestaltung von
digitalen Lernspielen.
Für das vorliegende Projekt ist in erster Linie der dritte Punkt interessant. Dazu
kann zunächst festgestellt werden, dass in Videospielen im Allgemeinen gelernt
wird, auch wenn dies nicht intendiert ist oder die Lernziele einen direkten Bezug
zur Bedienung des Spiels haben. Diese Ansicht wird u.a. von James Paul Gee von
der University of Wisconsin vertreten:
„Um ein Computerspiel spielen zu können, muss man es lernen. Und Computerspiele werden immer komplizierter. Darum ist es für den kommerziellen Erfolg
eines Games zentral, dass es auf gute Lernprinzipien zurückgreift. Die Funktionsweisen guter Computerspiele, die Schüler heute spielen, sind oft besser als
die in den Schulen, die sie besuchen.“[Kri08]
3
STAND DER FORSCHUNG
22
Abbildung 4: Schnelle Einführung in die Spielewelt durch eine Filmsequenz.11
Demnach lernen Schülerinnen und Schüler in Computerspielen „angst- und risikofrei“. Wenn sie Fehler machen, können sie einfach einen alten Spielstand neuladen.
In der Schule ist das nicht so. Außerdem passen sich gute Computerspiele an die
Fähigkeiten der Spieler an und machen es schwerer, wenn jemand sehr gut ist. Ist
jemand schlecht, wird das Spiel einfacher gestaltet - ein Paradebeispiel für Differenzierung im Lernprozess.[Kri08]
Bopp benennt für Computerspiele drei mögliche Lerndimensionen[Bop06, S. 11]:
• situative Dimension
• temporäre Dimension
• soziale Dimension
Unter der situativen Dimension versteht man geplantes oder nicht-geplantes Lernen
der Spieler. Der Planende ist dabei der Spielentwickler. Er arrangiert Spielsituationen, in denen der Spieler Wissen aufbauen kann, das zum Lösen von Problemen
notwendig ist. Dies kann auf verschiedene Weise geschehen. Klassisch sind das
Texte, Gespräche und Illustrationen[Bop06, S. 13-15], die in unterschiedlichen Formen präsentiert werden.
11
c
c <http://www.onlinekosten.
Szene aus NEED FOR SPEED: CARBON von
EA,
de/news/bilder/nfs_filmsequenz.jpg> am 18.03.08.
3
STAND DER FORSCHUNG
23
c Parasoziale Charaktäre sollen motivieren.12
Abbildung 5: Call of Duty 4 :
Moderne Spiele verzichten dabei auf klassische Hilfetexte, die „außerhalb“ der
Spielewelt stehen. Sie bringen Informationen in PDAs, Telefongesprächen, Fernsehsendungen oder in (Handy-) Kurznachrichten unter. Die Kommunikationspartner können zum Beispiel Freunde, erfahrene Charaktäre, Auftraggeber oder Vorgesetzte sein. Weiterhin kann dem Spieler ein bestimmtes Verhalten demonstriert
werden, das er dann nachahmen muss um ein Problem oder eine bestimmte Klasse
von Problemen zu lösen [Bop06, S. 15]. Bopp nennt weiterhin das „stealth teaching“
- das versteckte Lehren. Damit gemeint sind Situationen, in denen der Spieler etwas machen muss ohne zu bemerken, dass er damit auf eine komplexere Situation
verbreitet wird [Bop06, S. 16f]. Es gibt auch Hervorhebungen, die bestimmte Wege
kennzeichnen oder Verengungen, die diese Wege vorgeben können.
Die zeitliche Dimension zeichnet sich dadurch aus, dass komplexere Lernziele nicht
in wenigen Sekunden, in einem Schritt und mit einer Methode gelernt werden können. Stattdessen ist es von großer Bedeutung, dass Wissen auf bereits vorhandenes Wissen aufbauen kann. Dieser Wissensstand muss von Spielentwicklern beachtet werden, damit keine unüberwindbaren Herausforderungen den Spielfluss stören
können [Bop06, S. 22-26].
Die soziale Dimension des Lernens scheint für das vorliegende Projekt keine Rolle
zu spielen, da es ein Einzelspielerprogramm ist. Nach Bopp kann es aber „parasoci12
c <http://media.teamxbox.com/games/ss/1719/1194292285.
Infity Ward,
jpg> am 18.03.08.
3
STAND DER FORSCHUNG
24
al learning“ geben, was soviel bedeutet, dass der Nutzer mit virtuellen Charakteren
lernt. Das parasoziale Lernen nimmt damit den motivierenden Charakter sozialer
Lernprozesse auf. Weiterhin ist die Beziehung zu dem Charakter von Bedeutung.
Emotionale Beziehungen und damit tiefgehendere Charaktäre haben ein größeres
Potenzial für Lernerfolge zu sorgen als flache virtuelle Mitspieler. Bopp fasst zusammen:
„The importance of parasocial phenomena for didatic methods lies in its potential to create motivating learning situations, among others. [...] Parasocial didactics
can be seen as a development of several traditional classroom methods; for example, the teaching story, a method sometimes used to make history alive by
telling it from perspective of real or made up persons from the past[...]“[Bop06,
S. 28].
Die Kriterien angelehnt Bopp u.a., an denen digitale Lernspiele in dieser Arbeit
gemessen werden, sind
• situatives Lernen,
• komplexe, zusammengesetzte Lernvorgänge,
• soziale Lernprozesse,
• parasoziale Lernprozesse und
• einer ansprechenden Oberfläche.
Im Folgenden sollen verschiedene dieser Lernspiele mit Bopps Kriterien und der
entwickelten Typologie verglichen werden. Die Auswahl beschränkt sich auf drei
Lernspiele, wobei es natürlich noch viele weitere gibt. Die Spiele wurden deshalb
ausgewählt, weil sie zahlreiche Gemeinsamkeiten mit dem vorliegenden Projekt
aufweisen und auch einige wichtige Unterschiede, die helfen sollen, das Spielkonzept zu begründen.
3
STAND DER FORSCHUNG
25
c
Abbildung 6: Titelbild: Wo auf der Welt ist Carmen Sandiego?von
200113
3.3.2
c
Wo in der Welt ist Carmen Sandiego?
Die Spielereihe „Wo in der Welt is Carmen Sandiego?“ von Brøderbund Software,
Inc. weisst von der Spielweltkonzeption eine Gemeinsamkeit mit dem vorliegenden
Projekt auf. Es geht um die Jagd nach der Diebin Carmen Sandiego, die überall auf
der Welt Schätze stiehlt. Das Spiel wurde in verschiedenen Versionen veröffentlicht
sowie als Fernsehserie und als Gameshow ausgestrahlt, die teils auch in Deutschland ausgestrahlt wurden und sich vor allem in den USA großer Beliebtheit erfreuen
[BeioJ].
Das Lernspiel ist eine kommerzielle Anwendung, die eher auf den Spiel- als auf
den Lernfaktor setzt, was wohl den Erfolg der Reihe erklärt. Trotzdem kann sich der
(jüngere) Spieler viel Wissen über Geographie und nebenbei auch über das kulturelle Erbe der Menschheit aneignen, denn die Abenteuer finden an vielen Orten rund
13
c
Wo auf der Welt ist Carmen Sandiego?von
2001: <http://ecx.images-amazon.
com/images/I/51TYCA6RJHL._SS400_.jpg> am 01.04.08
3
STAND DER FORSCHUNG
26
c
Abbildung 7: Wo auf der Welt ist Carmen Sandiego?Infos
über Korea14
um die Welt statt. Der Spieler rückt dabei in die Rolle eines Interpol-Detektiven,
der sich auf die Jagd nach der Mafia und ihrer Chefin Carmen Sandiego begibt. Als
Motivation kann der Nutzer verschiedene Dienstgrade erlangen, wenn er Erfolge
verzeichnet hat. Außerdem gibt es Motivation in Form von parasozialen Kontakten wie dem Interpol-Chef, der sich über Erfolge freut bzw. sauer wird, wenn der
Spieler Mißerfolge zu verzeichnen hat. [BeioJ]
Die Oberfläche des Spiels hat sich natürlich seit dem Jahr der ersten Version, 1985,
ständig verändert, ist aber in vielen Punkten sehr ansprechend und auf der Höhe
der Zeit geblieben. Auch in weiteren Punkten, die von Bopp angesprochen wurden,
entspricht die Software einem guten Lernprodukt (themenbezogene Texte, Illustrationen und Gespräche, komplexere Lernvorgänge). Das Lernen steht insgesamt aber
nicht im Vordergrund, was Vor- und Nachteile hat. So wird nebenbei gelernt und die
Motivation steigt. Allerdings lernt man eher Fakten statt Kompetenzen, die im Kontext der Spielbedienung stehen als sich am Lerngegenstand orientieren.
M ERKMAL
14
c
C ARMEN S ANDIEGO
Wo auf der Welt ist Carmen Sandiego? Deluxe Edition von 1990: Zeigt einen In-
fobildschirm über Korea: <http://www.lauppert.ws/screen1/carmen_sandiego_
deluxe.png> am 01.04.08
3
STAND DER FORSCHUNG
27
Gegenstand
Geographie u.a.
Nutzerzahl
Einzelnutzer
Softwaretyp
Adventure
Spielorientierung
spielorientiert
Explorativität
nicht explorativ
Erweiterbarkeit
nicht erweiterbar
Einbettung in andere Lernformen nicht eingebettet
Lerngegenstandstyp
offen
Problembezug
nicht problembezogen
Art des Wissens
Faktenwissen
situatives Lernen
Texte, Illustrationen, Gespräche
komplexes Lernen
schwach vorhanden
soziale Lernprozesse
nicht vorhanden
parasoziale Lernprozesse
vorhanden
Oberfläche
moderne Grafiken
Tabelle 4: Einordnung der Carmen-Sandiego-Reihe
3.3.3
Fountain of Wisdom
FOW (kurz: FOW, zu deutsch „Brunnen der Weisheit“) ist ein Lernspiel, das an
der FernUniversität Hagen im Lehrgebiet Verteilte Systeme für kooperative Lern/Arbeitsumgebungen entwickelt wurde. Es basiert auf der Plattform „C URE“ (Collaborative Universal Remote Education), welches eine Internet-Lernplattform ist,
die den studentischen Wissensaustausch fördern soll. C URE benutzt dazu virtuelle Räume, die gemeinsame Arbeitsbereiche für Gruppen darstellen [CURoJ]. Die
Anbindung eines Projekts an C URE erfolgt über eine Beschreibungssprache. Diese
Erweiterungsfunktion nutzt auch FOW.
16
[oAoJ, S. 6]
3
STAND DER FORSCHUNG
28
Abbildung 8: Fountain of Wisdom: Drei Mitspieler, eine Quelle (links) und eine
Senke (rechts)16
FOW ist eine Plattform, die auf fast alle Themengebiete angewendet werden kann.
Zunächst bestimmt ein Spielleiter das Thema und entwickelt zugehörige Fragen.
Fragen werden als Quellen dargestellt und Antworten befinden sich in Senken. Ein
Spieler holt immer eine Frage ab und begibt sich dann auf die Suche nach der Antwort oder den Antworten, denn einer Fragen können mehrere Antwortteile zugeordnet werden. Ist eine Frage richtig beantwortet, wird sie aus dem Spiel entfernt und
der Spieler erhält dafür Punkte. Ist sie falsch beantwortet, gibt es Punktabzüge und
die Frage verbleibt im Spiel. Daneben gibt es noch Geister, die gut und böse sein
können. Gute Geister helfen dem Spieler mit Hinweisen, böse klauen Fragen. Die
Attribute der Spieler können über Gimmicks wie schnellere Bewegungen verbessert werden. Ein Gimmick kann von erworbenen Punkten gekauft werden [oAoJ, S.
8-16].
FOW ist für viele Benutzer ausgelegt, die gemeinsam Fragen beantworten können. Wird ein Mehrbenutzerspiel gewählt, werden die Nutzer in zwei gegnerische
Teams aufgeteilt, was den Wettbewerbsgedanken fördern soll. Die Zusammenarbeit
wird über verschiedene Formen des Chats („Marktplatz“ - offener Chat in der gesamten FOW-Welt; „Spielchat“ - für alle Teilnehmer des Spiels, „Team-Chat“ - für
alle Teammitglieder und „Face-to-Face-Chat“ zwischen zwei Spielern) und über die
3
STAND DER FORSCHUNG
29
Abbildung 9: Fountain of Wisdom: Das Bewertungssystem17
Komplettierungsmöglichkeit einer nicht-vollständig beantworteten Frage durch ein
anderes Teammitglied sichergestellt [oAoJ, S. 3].
Bei FOW handelt es sich um ein Abfrageprogramm, welches bereits vorhandenes
Wissen überprüft, es ist also keine Simulation. Wissen wird durch die Software
zwar gefestigt, aber nicht aufgebaut. Die Aufgabenlösungen haben keinen Bezug
zu einem bestimmten Thema, sind also offen. Die Software ist erweiterbar und
nicht-explorativ, ist aber in einem explorativen Kontext denkbar, da durch das Spiel
eigentlich kein Wissen geschaffen werden kann. Obwohl FOW eine durchaus aufwendige, wenn auch nicht aktuelle 3D-Oberfläche zu bieten hat, hat das Projekt einige Schwächen. Es verwendet keine lernbezogenen Tutorials, Vorführungen, kein
verstecktes Lernen und keine parasozialen Charaktäre. Positv sind das Nutzen von
themenbezogenen Gesprächen mit den Geistern und die komplexe Lösungsfindung
durch aufgeteilte Antwortmöglichkeiten. Lernen findet zwar nur sehr begrenzt parasozial, dafür aber sozial statt. Damit ist das Lernen fast nur auf den Austausch mit
anderen Teilnehmern beschränkt.
17
M ERKMAL
F OUNTAIN OF W ISDOM
Gegenstand
offen
[oAoJ, S. 10]
3
STAND DER FORSCHUNG
30
Nutzerzahl
Mehrnutzer
Softwaretyp
Testsoftware
Spielorientierung
spielorientiert
Explorativität
nicht explorativ
Erweiterbarkeit
erweiterbar
Lerngegenstandstyp
Problembezug
nicht problembezogen
Art des Wissensaufbaus
kein Wissensaufbau
Tutorials
nicht-vorhanden
Informationsvermittlung
Geister
Vorführungen
keine Vorführungen
komplexes Lernen
(vorhanden)
vorhanden
(nicht vorhanden)
Oberfläche
3D-Grafik
Tabelle 5: Einordnung von Fountain of Wisdom
3.3.4
Auswertung
Aktuelle Lernsoftware-Lösungen, nicht nur die vorgestellten Projekte, haben die
Erkenntnisse von Bopp u.a. noch nicht realisiert. Lernsoftware wirkt im Vergleich
zu den modernen 3D-Welten aktueller Videospiele eher rückständig, die soziale Dimension beschränkt sich meist auf einen tutor-ähnlichen Gefährten, der sehr flach
gehalten ist. Es gibt meist keinen Mehrspieler-Modus und auch keine Einführungslevels [Bop06, S. 32ff]. Auch das methodisch-didaktische Design der Spiele entspricht nicht den Erkenntnissen von Bopp u.a. So sind viele Spiele eher einem multimedialen Lehrbuch zu vergleichen und die Handlungsfreiheit des Nutzers ist sehr
3
STAND DER FORSCHUNG
31
eingeschränkt.
„This dominance of traditional learning and teaching in educational games may
caused by a lack of knowledge about the didactic design of non educational games or a lack of financial resources necessary to use them. Or maybe it is difficult
to actually use these didactic methods to support academi learning content and
not just entertaining learning content.“[Bop06, S. 35]18
18
Das vorliegende Projekt kann auf Grund von beschränkten Ressourcen nicht alle Forderungen
von Bopp wie eine ansprechende, aktuelle Grafikengine oder eine komplexe Story erfüllen. Trotzdem
wird an den verschiedendsten Stellen versucht, diese Erkenntnisse zu nutzen, soweit dies möglich
ist.
4
KONZEPTION
4
32
Konzeption
In diesem Kapitel wird die Konzeption des vorliegenden Projekts beschrieben. Dabei wird entsprechend der bisherigen Vorgehensweise die Konzeption in zwei Bereiche aufgeteilt (inhaltliche und technische Konzeption).
4.1
Inhaltliche Konzeption
Entsprechend der Anforderungen sind die Inhalte der Lernsoftware bereits vorbestimmt: Es sollen innerhalb einer Spielwelt fünf Probleme modelliert werden, die
von den Benutzerinnen und Benutzer gelöst werden können. Die Auswahl der Probleme richtet sich danach, ob das Problem für Lernende einfach zu verstehen und
auch die Notwendigkeit der Problemlösung einfach nachvollziehbar ist. Außerdem
sollten die Probleme möglichst einen Bezug zur Alltagswelt aufweisen und sich auf
unterschiedliche Weise, also textuell und grafisch, in verschiedenen Zuständen darstellen lassen. Die Anzahl der Probleme soll auf fünf beschränkt werden, damit sich
die Simulation zeitlich in ungefähr einer Stunde lösen lässt, wenn die Lernenden
keine oder wenige Vorkenntnisse über Verteilte Systeme haben.
4.1.1
Die Spielwelt
Der Nutzer der Simulation wird in eine fiktive Stadt entführt, die in einigen Punkten
an Jena angelehnt ist. Der „Kontaktmann“, der eine parasoziale Kommunikation mit
der Spielwelt ermöglichen soll, ist der Bürgermeister der Stadt. An diesem fiktiven
Ort blühen die Wirtschaft und die Wissenschaft. Die Bewohner sind sehr zufrieden
und erhoffen sich, dass das so bleibt. Durch den wachsenden Wohlstand werden
allerdings Spione aus fremden Ländern angelockt, die sich über die Technologien
informieren wollen. Die Bewohner der Stadt, insbesondere die Industriellen, haben
sich mit der Situation weitestgehend abgefunden. Der Klau von Informationen kann
meist verhindert werden und es wird kein schlimmer Schaden angerichtet.
4
KONZEPTION
33
Gleichzeitig kommt aber ein neues Problem auf. Die Spione sind nicht unbedingt
positiv zueinander eingestellt und geraten immer öfter in Konflikte. Der Bürgermeister und die Wirtschaft der Stadt haben die begründete Angst, dass diese Konflikte schnell größer werden und die öffentliche Sicherheit in der Stadt gefährten.
Deswegen spricht er mit jedem einzelnen Agenten und findet heraus, dass ihre Konflikte oft nur auf Missverständnissen in der Kommunikation beruhen.
Um diese Probleme soll sich ein Techniker kümmern. Der Spieler rückt in die Rolle
dieses Technikers und wird vom Bürgermeister um Hilfe gebeten. Schnell treten
erste Probleme in der Kommunikation auf, die der Nutzer lösen soll.
4.1.2
Punktesystem
Die Spielergebnisse sollten laut den Anforderungen vergleichbar gemacht werden
um den Ehrgeiz der Nutzerinnen und Nutzer zu wecken. Vergleichbar heißt, dass
zwei Nutzer direkt vergleichen können, wer in dem Spiel besser abgeschnitten hat.
Dazu wurde ein Punktestand eingeführt, der die Leistung messen und den Nutzern
ein Feedback geben soll.
Dabei geht die Simulation wie folgt vor. Ein Spieler erhält dann Punkte, wenn
ein Problem als gelöst gilt. Die Leistung des Spielers wird danach berechnet, wie
schnell er das Problem gelöst hat. Die Standardvariante ist die, dass ein Schüler
3600 Punkte abzüglich der benötigten Sekunden zur Problemlösung Punkte gutgeschrieben bekommt. Wer schneller ist, bekommt also mehr Punkte.
Ein Plugin kann diese Einstellungen natürlich ändern und individuell Punkte verteilten. So ist angedacht, dass es für komplexere Probleme mehr Punkte gibt als für
einfachere und gleichzeitig weniger abgezogen werden. Sind nun in einem Spiel alle
Probleme gelöst, wird ein Endpunktestand ermittelt, der es den Nutzern ermöglicht,
ihre Leistungen direkt miteinander zu vergleichen.
4
KONZEPTION
4.1.3
34
Auswahl von zentralen Problemen in Verteilten Systemen
Wie bereits ausführlich geschildert, werden in Verteilten Systemen Nachrichten
zwischen unterschiedlichsten und oftmals gleichwertigen Kommunikationspartnern,
über deren Zustand vielleicht gar nichts ausgesagt werden kann, ausgetauscht.19
Diese sehr weite Beschreibung führt natürlich zwangsläufig zu Problemen, die beispielsweise in homogenen Systemen einfacher in den Griff zu bekommen wären.
Im Folgenden soll für die Auswahl der zu Grunde liegenden Probleme in der Simulation ein kurzer Überblick gegeben werden. Der Entscheidung für oder gegen eine
Aufgabenstellung liegen die folgenden Kriterien zu Grunde:
• das Problem hat eine wichtige Stellung in Verteilten Systemen,
• es lässt sich in geigneter Form innerhalb der Spielewelt modellieren,
• das Problem, die Lösung und die Teilschritte lassen sich grafisch und textuell
gut beschreiben,
• die Lösungen sind „authentisch“20 und haben eine geeignete Komplexität für
Schülerinnen und Schüler.
Nachrichtenverlust und -duplizität
Nachrichten können z.B. auf Grund von Übertragungsfehlern verloren gehen und
nicht beim Gegenüber ankommen. Gleichzeitig kann eine Nachricht doppelt gesendet werden und zu Missverständnissen führen. Auch der Verlust einer Nachricht
kann unerwünschte Folgen haben und eine Aktion auf der Empfängerseite nicht
auslösen, die gewünscht war. Der Verlust von Nachrichten wird in der Simulation
19
Wie bereits angedeutet, muss die Kommunikation in Verteilten Systemen nicht Nachrichten in
den Mittelpunkt stellen, auch wenn sich Nachrichten meist hinter anderen Möglichkeiten verbergen.
Der Aufruf entfernten Prozeduren (z.B. Remote Procedure Call, kurz RPC) und weitere Paradigmen
werden in dieser Arbeit aber nicht behandelt [TS03, S. 77-160].
20
Die Lösungen sollen der Realität entsprechen, keine falschen Tatsachen zur Vereinfachung der
Lösung verwenden[SS04, S. 45 u.a.].
4
KONZEPTION
35
berücksichtigt, wobei sich das Problem einfach modellieren lässt und gut für jüngere Nutzer nachvollziehbar ist.
Für die Agenten bedeutet das, dass sie sauer werden, wenn eine gewünschte Reaktion ausbleibt, da eine Nachricht verloren gegangen ist. Sie glauben nicht daran,
wie bei den anderen Problemen auch, dass es sich um ein technisches Problem handelt, sondern gehen von bösen Absichten ihres Kommunikationspartners aus. Damit würde sich der Unmut zwischen den Agenten erhöhen, was der Nutzer natürlich
verhindern soll.
Synchronisierung
Aspekte der Synchronisation treten dann in den Mittelpunkt, wenn Prozesse tatsächlich auch miteinander arbeiten müssen. Das kann etwa bedeuten, dass sie eine
gemeinsam genutzte Ressource manipulieren oder dass es wichtig ist, in welcher
Reihefolge Prozesse abgearbeitet werden. Diese beiden Aspekte fließen als zentrale
Probleme in die Arbeit ein, die Synchronisation einer physikalischen Uhr oder Wahl
eines Koordinators werden hingegen nicht behandelt[TS03, S. 280]. Ersteres ist in
vielen Situationen gar nicht notwendig, da es reicht, das Problem auf eine logische
Uhr zu reduzieren, für die nur die Reihenfolge von Ereignissen eine Rolle spielt.
Ein Wahlalgorithmus ist deshalb nicht in dieser Arbeit berücksichtigt, da es ähnlich
wie das Namenproblem recht komplex ist und sich bisher auch nicht ansprechend
in der Spielewelt modellieren ließ.
Falsche Nachrichtenreihenfolge
Auf den ersten Blick ist es für viele Belange nicht von Relevanz, in welcher Reihenfolge Nachrichten ausgetauscht werden. Doch schon ein Blick in den Alltag macht
deutlich, dass dies durchaus zu Irritationen führt:
„Treffen wir uns an der Mensa?“ - „Nein. Das wird heute nichts.“
„Wir könnten auch heute Abend ins Kino gehen“ - „Ja, gerne.“
Werden die Antworten vertauscht, kommt es zu einem Missverständnis:
4
KONZEPTION
36
„Treffen wir uns an der Mensa?“ - „Ja, gerne.“
„Wir könnten auch heute Abend ins Kino gehen“ - „Nein. Das wird heute nichts.“
Analog dazu könnten auch zwei Maschinen Missverstände in der Kommunikation
haben. Für die Agenten der Simulation ist die Nachrichtenreihenfolge deshalb von
Bedeutung, da sie Kodierungen austauschen wollen, damit die anderen Agenten geheime Botschaften erhalten können. Dabei ist in der Spielewelt die absolute Reihenfolge im Gegensatz zum obrigen Beispiel aus der Alltagswelt nicht von Bedeutung.
Der Code der Agenten ist verteilt auf zwei Agenten mit jeweils zwei Bestandteilen. Die Agenten versenden ihre zwei Bestandteile immer in richtiger Reihenfolge,
aber es kann nicht garantiert werden, dass alle vier Bestandteile in richtiger Reihenfolge ankommen. Wichtig ist, dass am Ende der Übertragung jeder Agent den
gleichen Code hat. Hat ein Spion nicht die gleiche Kodierung erhalten, ist er von
der Kommunikation ausgeschlossen.
Inkonsistent-Werden einer gemeinsamen Ressource und Replikation
Unter Replikation versteht man das Anlegen von Kopien von Ressourcen um performanter und zuverläßiger in Verteilten Systemen zu arbeiten. Die große Herausfordung, die bei replizierten Objekten besteht, ist diese Objekte konsistent zu halten.
Wird eine Kopie aktualisiert, müssten auch andere Kopien angepasst werden[TS03,
S. 405f].
Ein typisches Problem in Verteilten Systemen ist, dass Prozesse eine gemeinsame
Ressource bearbeiten. Ein klassisches Beispiel ist ein Konto, das über einen Kontostand verfügt. Bucht ein Prozess einen Betrag vom Konto ab, wird der Kontostand
aktualisiert. Problematisch wird dies erst, wenn zwei Prozesse gleichzeitig versuchen, auf das Konto zuzugreifen. Sie lesen beiden den gleichen Kontostand ein,
Prozess 1 zieht dann einen Betrag ab und Prozess 2 zahlt einen Betrag ein. Wenn
Prozess 1 zuerst beendet ist, kann es bei einem unkoordinierten Zugriff dazu führen,
dass diese Transaktion gar nicht berücksichtigt wird und nur die Erhöhung von Prozess 2 in der Bilanz auftaucht. Was für den Kontoinhaber gut sein mag, ist natürlich
4
KONZEPTION
37
ein Problem, welches schon innerhalb einer Maschine gelöst werden muss. Analog
dazu, nur mit erhöhtem Koordinationsaufwand und damit um einiges komplizierter
sieht es aus, wenn mehrere Maschinen dieses Problem lösen wollen. Ist das Problem
gelöst, spricht man davon, dass die Ressource in einem konsistenten Zustand ist.
Das Problem ist deshalb von zentraler Bedeutung, weil es in vielfältiger Form auftreten kann. Die Lösung des Problems ist zwar nicht einfach, es kann aber ansprechend innerhalb der Spielwelt modelliert werden. Hier haben die Agenten sich nämlich zusammengeschlossen und für kurze Zeit ihre Konflikte bei Seite gelegt. Sie
wollen die Warenein- und ausfuhr der Stadt abschätzen und positionieren sich dafür an zentralen Punkten. Sie haben sich überlegt, dass sie einfach den aktuellen
Wert der Waren in der Stadt als zentrale Ressource verwenden. Wird etwas exportiert, sinkt der Wert, wird etwas importiert, erhöht er sich. Natürlich trauen sich
die Agenten nicht gegenseitig und überprüfen genau, ob es ein anderer Spion etwas macht, was nicht abgesprochen war. Schnell entdecken sie, dass etwas nicht
stimmen kann. Doch kein Agent hat die anderen betrügen wollen. Es liegt also ein
technisches Problem vor. So schreiben die Agenten unkoordiniert auf die Ressource
und es kommt zu Inkonsistenzen.
Mithören und Fälschen von Nachrichten
Das Thema Sicherheit ist ein wichtiger Aspekt in Verteilten Systemen. Dabei wird
unter Sicherheit eine ganze Sammlung von Systemeigenschaften verstanden, die
grob in zwei Kategorien eingeteilt werden können. Zum einen wird ein sicherer Kanal für die Kommunikation zwischen zwei Maschinen benötigt, damit Nachrichten
nicht gefälscht, verändert oder mitgelesen werden können. Außerdem muss sichergestellt sein, dass der Empfänger sich sicher kann, dass die Nachricht tatsächlich
vom vorgegebenen Absender stammt (Authentifizierung). Die zweite Kategorie ist
die Autorisierung, also wer auf welche Ressourcen tatsächlich zugreifen darf. Auf
diesen Aspekt soll in der Arbeit allerdings nicht eingegangen werden, da er eher
einen Nebenaspekt in Verteilten Systemen darstellt[TS03, S. 467f].
4
KONZEPTION
38
In dem Projekt sollen Probleme der ersten Kategorie untersucht und behandelt werden, da auf diese Weise den Nutzern wichtige Sicherheitsaspekte näher gebracht
werden können und diese Klasse von Problemen sehr gut ins Thema der Agenten
passt, die natürlich Interesse an der Kommunikation der anderen Agenten haben.
Auf folgende Sicherheitsgefährdungen soll im vorliegenden Projekt näher eingegangen werden:
• Mitlesen von Nachrichten durch einen anderen Agenten,
• Erzeugung einer Nachricht unter einer fremden Identität und
• Modifikation von Nachrichten durch Dritte.
Aus dieser Sammlung sollen zwei Probleme abgeleitet werden. Zum einen sind
Nachrichten nicht abhörrestitent werden und zum anderen ist nicht sichergestellt,
dass eine Nachricht auch tatsächlich genauso wie sie beim Empfänger ankam vom
Absender verschickt wurde. Damit wäre nämlich nicht gesichert werden, dass sich
auf die Information in der Nachricht tatsächlich verlassen werden kann.
4.1.4
Auswahl und Beschreibung von Lösungswegen
Entsprechend der vier Kriterien zur Auswahl der Probleme, die in dem Projekt
dargestellt werden sollen, wird auch eine Liste von Kritierien entwickelt, welche
Lösungswege oder Klassen von möglichen Lösungen für die Probleme bevorzugt
werden. Generell sollte es so sein, dass nicht eine bestimmte Konstellation von Systemeinstellungen als Problemlösung akzeptiert wird, sondern Werkzeuge bereitgestellt werden, die zur Lösung eines Problems notwendig sind. Vielmehr könnte es
einen Überwacher-Prozess geben, der anhand bestimmter Kriterien überprüft, ob
ein Problem gelöst ist, damit hier eine Unabhängigkeit von konkreten Lösungsvorgaben entsteht. Allerdings stehen dem Entwickler eines Plugins beide Wege offen.
Trotzdem wird der Nutzer durch die Auswahl von Werkzeugen auf bestimmte Lösungswege beschränkt. Diese sollen im Folgenden vorgestellt und mit den nicht
4
KONZEPTION
39
gewählten Wegen verglichen werden. Die Kriterien für die Auswahl einer Strategie
sind dabei:
• Qualität der Strategie und Anerkennung als gängiger Lösungsweg nach Stand
der Forschung,
• grafische und textuelle Beschreibbarkeit der Lösungswerkzeuge und
• geeignete Komplexität der Werkzeugkonstellation und Lösungsstrategien.
Als vereinfachendes Schema für den Nutzer, nach dem sich der Entwickler auch
richtet, werden Werkzeuge als Komponenten definiert, die auf Grundlage einer konkreten Nachricht eine Aktion ausführen. Ausgelöst wird eine Komponente von einem Ereignis. Ereignisse können dabei das Senden oder das Empfangen einer Nachricht sein. Die Reihenfolge der Ausführung der Werkzeuge wird dabei berücksichtigt. Außerdem soll der Anwender Nachrichtentypen manipulieren können um die
Kommunikation zu vereinfachen können.
Verlorene Nachrichten: Sendungswiederholung und Nachrichtenbestätigung
Gehen Nachrichten verloren, führt dies zu Missstimmungen zwischen den Agenten. Sie glauben, ihr Gegenüber ignoriert sie oder sind sauer, weil sie keine Antwort
erhalten haben. Dieses recht einfache Problem wird zunächst über eine Nachrichtenbestätigung gelöst. Versendet ein Agent eine Nachricht, wird das Ankommen
dieser vom Empfänger quittiert. Sollte keine Bestätigung eintreffen, kann davon
ausgegangen werden, dass auch die Ursprungsnachricht nicht ankam. Dann muss
das Senden dieser Nachricht wiederholt werden. Die Wiederholung sollte dann abbrechen, wenn eine Bestätigung eingetroffen ist. Damit die Nachrichten und ihre
Bestätigungen einander zugeordnet werden können, erhalten Nachrichten eine ID.
Eine Nachrichtenbestätigung hat einen anderen Nachrichtentyp als eine Standardnachricht. Sie wird aus der Ursprungsnachricht generiert und trägt im Empfängerfeld den Absender ein.
4
KONZEPTION
40
Abbildung 10: Uhren mit unterschiedlichen Geschwindigkeiten: Falsche Nachrichtenreihenfolge22
Falsche Nachrichtensortierung: Logischer Zeitstempel, Empfangsbestätigung und
Sortierung beim Empfänger
Um zu verhindern, dass Nachrichten bei den Empfängern in unterschiedlicher Reihenfolge ankommen, muss den Nachrichten zunächst eine logische Uhr zugeordnet
werden. Eine logische Uhr ist im Gegensatz zu einer physikalischen keine genaue
Uhrzeit, sondern nur eine Nummer. Von Interesse ist dann nur, ob ein Ereignis a vor
oder nach einem Ereignis b stattgefunden hat. Der Lösungsweg der Simulation ist
an Lamport angelehnt. Lamport definierte diese Passiert-vor-Beziehung (a → b).
Das Senden der Nachricht findet immer vor dem Empfangen statt. Wenn jedoch
zwei Prozesse nicht miteinander kommunizieren und auch nicht indirekt in einen
Nachrichtaustausch einbezogen werden, dann gilt weder a → b noch b → a. Diese
Beziehung ist auch nicht von Interesse für die logische Sortierung [TS03, S. 289].
Weiterhin muss gelten, dass der logische Zeitpunkt C eines Ereignisses a, welches
vor einem Ereignis b stattgefunden hat, kleiner ist als der Zeitpunkt C des Ereig22
Grafik entnommen aus [TS03, S. 290]
4
KONZEPTION
41
nisses b (C(a) < C(b)). Außerdem dürfen Uhren nur vorwärts zählen und Aktualisierungsoperationen dürfen nur Additionen positiver Zahlen sein [TS03, S. 289].
Lamport schlägt nun vor, dass jeder Systemteilnehmer eine eigene Uhr führt, die
zum Startzeitpunkt auf null gesetzt ist und bei jedem Ereignis (Senden und Empfangen einer Nachricht) um eins erhöht wird. Beim Empfang einer Nachricht gilt
zudem: neuerLamportstempel = max (Sendezeit, alterLamportstempel) + 1.
Zusammenfassend müssen drei Fälle betrachtet werden, um einen korrekten LamportZeitstempel zu erzeugen:
1. Wenn a vor b im gleichen Prozess auftritt, gilt: C(a) < C(b)
2. Wenn a ein Sendeereignis ist und b das zugeordnete Empfangsereignis, gilt:
C(a) < C(b)
3. Sonst gilt: C(a) 6= C(b)
Interessant ist vor allem der Fall, wenn ein Teilnehmer mit einem höheren Zeitstempel eine Nachricht an einen Teilnehmer mit niedrigeren Zeitstempel schickt. Dieser
schickt eine Nachricht an den dritten Teilnehmer, dessen Zeitstempel noch kleiner
ist (Vgl. Abb. 6, S.25). Wird nicht nach Lamport sortiert, wäre die Nachrichtenreihenfolge logisch vertauscht. Mit dem Lamport-Algorithmus haben die Nachrichten
einen korrekten Zeitstempel(Vgl. Abb. 11, S.42) [TS03, S. 291].
Bevor die Nachrichten sortiert und ausgegeben werden können, muss jeder Agent
den Empfang einer Nachricht an alle Teilnehmer bestätigen und ebenfalls die empfangene Nachricht mit einem Zeitstempel versehen. Sind nun von jedem Agent die
Bestätigungen zu einer Nachricht eingetroffen, kann sie aus der Warteschlange entfernt und ausgegeben werden. In der Simulation bleibt die Nachricht jedoch sichtbar
bis alle Nachrichten empfangen wurden.
Weiterhin müssen die Nachrichten eventuell noch umsortiert werden. Dies kann
über einen beliebigen Sortieralgorithmus anhand der Zeitstempel geschehen.
24
4
KONZEPTION
42
Abbildung 11: Uhren mit unterschiedlichen Geschwindigkeiten und Lamport: Korrekte Nachrichtenreihefolgen24
Der Lamport-Algorithmus wurde auf Grund seiner Einfachheit ausgewählt, das Problem wurde auf den Algorithmus angepasst. Um das Problem komplett zu lösen,
wurde ein vollständig sortiertes Multicast verwendet, was sich als gängige Lösung
in Verteilten Systemen auszeichnet.
Inkonsistent-Werden einer gemeinsamen Ressource: Quorum-basierte Konsistenz
Für die Sicherung der Konsistenz einer Ressource gibt es eine ganze Reihe von Vorgehensweisen, die zunächst klassifiziert werden sollen. Da für die Projektbelange
ein erhöhter Mehraufwand und eine höhere Komplexität auszuschließen ist, entfallen Strategien, die die Bestimmung eines Koordinators voraussetzen [TS03, S.
384ff]. Bei einem vollständig migrierenden Modell, bei dem eine Ressource nicht
repliziert wird, ist das Ausfallrisiko der Ressource recht hoch. Gleiches gilt für
einen Protokolltypus, bei dem eine Ressource immer zu dem letzten, schreibenden
Prozess wechselt [TS03, S. 386f]. Bei Ansätzen, bei denen tatsächliche Replikate
einer Ressource hergestellt werden, erfordert ein Schreibprozess einen komplexeren
Koordinationsaufwand, der in diesem Zusammenhang durchaus wünschenswert ist.
4
KONZEPTION
43
Abbildung 12: Beispiel für ein Lese- und Scheibquorum: Links Schreibquorum mit
NW = 4 und rechts Lesequorum mit NR = 3
Ein Quorum-basiertes Protokoll realisiert den Repliziertes-Schreiben-Ansatz, was
bedeutet, dass Operationen auf mehreren Repliken ausgeführt werden. Zu unterscheiden sind dabei mehrheits- und einheitsbasierte Protokolle, wobei einheitsbasierte für häufige Schreiboperationen ineffektiv arbeiten und bei Ausfall von Ressourcen anfälliger sind als die mehrheitsbasierenden Varianten. Die Quorenbasierung drückt dabei aus, dass nicht alle Repliken aktuell gehalten werden müssen,
sondern nur die Mehrheit der Teilnehmer einem Schreibvorgang zuzustimmen haben. Um den aktuellen Wert der Ressource zu erhalten, ist dann aber ein größerer
Aufwand notwendig, denn es müssen so viele Teilnehmer ihren Wert zurückgeben,
dass die Anzahl der nötigen Agenten für ein Schreibquorum plus die Anzahl für
Lesequorum größer sein als die Gesamtzahl der Teilnehmer. Die aktuelle Version
in einem wird zudem über eine Versionsnummer identifizierbar gemacht [TS03, S.
S.388-392].
Nach Gifford werden Lese-Schreib- (1) und Schreib-Lese-Konflikte (2)25 vermie25
N ist die Gesamtzahl der Teilnehmer, NR die Zahl der Teilnehmer, die für ein Lesequorum
benötigt werden und NW die Anzahl für ein Schreibquorum
4
KONZEPTION
44
den, wenn
1. NR + NW > N und
2. NW > N/2
gelten (Vgl. Abb 12, S. 43).
Für die Lösung der Aufgabe in der Simulation wird vorausgesetzt, dass die Agenten ein Abstimmungssystem aufgebaut haben, welches auf Schreiben und Lesen
basiert, aber einfach per Broadcast-Prinzip an alle Teilnehmer eine Aktualisierung
senden und als aktuellen Wert ihren eigenen annehmen. Dem Nutzer wird schnell
deutlich, dass dieses System sehr anfällig ist und die Ressource zunächst geschützt
werden muss. Nur wenn ein Prozess aktuell nicht an einem Lese- oder Schreibvorgang teilnimmt, darf er seine Ressource sperren und eine Lese- oder Schreibbestätigung versenden. Wurde ein Quorum erfüllt, kann der anfordernde Teilnehmer seine
Operation ausführen und im Schreibfall eine Aktualisierung des Wertes versenden,
die dann zur Entsperrung der Ressource führen würde.
Grafisch wird das Problem dargestellt indem, wie in der Problemauswahl beschrieben, ein nummerischer Wert neben den Agenten angezeigt wird. Ein wirklich konsistentes Replikat wird grün und ein nicht-konsistes rot dargestellt. Die unterschiedlichen Nachrichtentypen erhalten wie im Beispiel der verlorenen Nachrichten ebenfalls unterschiedliche Farben. Die Sperrung einer Ressource wird mit einem aus
Browsern und anderen Anwendungen bekannten Schlosssymbol angezeigt. Ist es
offen, ist die Ressource nicht gesperrt und umgekehrt.
Lauschangriff: Verschlüsselung und Signierung mit öffentlichen Schlüssel
Es gibt zahlreiche Methoden, Nachrichten zu verschlüsseln und somit sicherzustellen, dass nur der Empfänger der Nachricht in der Lage ist, diese zu lesen. Dabei wird
ein Klartext (P ) in einen Chiffretext (C) mit Hilfe eines Schlüssels (K) übersetzt. In
den meisten Fällen wird dann mit dem gleichen Schlüssel die Operation (E für Verschlüsseln, D für Entschlüsseln) umgekehrt, sodass der Empfänger der Nachricht
4
KONZEPTION
45
Abbildung 13: Kombinierter Einsatz von Verschlüsselung und Signierung mit Hilfe
eines asymmertrischen Verschlüsselungsverfahrens27
den Text wieder lesen kann. Diese Operationen klassifiziert man als symmetrische
Verschlüsselungsverfahren (Vgl. Formel 1 und 2) [TS03, S. 479-484].
C = EK (P )
(1)
P = DK (C)
(2)
Für das vorliegende Projekt wurde sich jedoch für ein asymmetrisches Verschlüsselungsverfahren [RSA78]. Hierbei wird ein Nachrichtentext nicht mit dem gleichen
Schlüssel ver- und entschlüsselt, stattdessens werden zwei Schlüssel dafür verwendet. Ein öffentlicher Schlüssel (öffentlicher Schlüssel von A: KA+ ) wird publiziert
und ist generell jedem zugänglich. Einen geheimen Schlüssel (KA− ) sollte jeder Nutzer für sich behalten. Je nachdem, ob man sicherstellen will, dass eine Nachricht
nicht mitgelesen werden kann oder dass eine Nachricht tatsächlich vom Absender
stammt, werden für die Ver- und Entschlüsselung unterschiedliche Schlüssel verwendet.
Zur Nachrichtenverschlüsselung wird der Text mit dem öffentlichen Schlüssel des
Empfängers verschlüsselt. Zur Entschlüsselung muss nun der geheime Schlüssel
des Empfängers genutzt werden. Damit ist sichergestellt, dass nur der Empfänger
die Nachricht tatsächlich lesen kann. Zur Nachrichtensignierung hingegen wird der
geheime Schlüssel des Absenders verwendet. Da nur dieser den geheimen Schlüssel
27
4
KONZEPTION
46
besitzt, ist sichergestellt, dass er auch tatsächlich der Absender der Nachricht ist
(Vgl. S. 45, Abb. 13).
Asymmetrische Verfahren verwenden die Erkenntnis, dass die Faktorisierung großer
Zahlen aufwändig, während das Multiplizieren zu einer Primzahl einfach ist (sog.
„Einwegfunktion“).
Für das Programm sollen die mathematische Zusammenhänge allerdings in den
Hintergrund rücken. Die Schülerinnen und Schüler sollen in erster Linie die Idee
hinter dem asymmetrischen Verschlüsselungsverfahren verstehen, also wann muss
welche Operation eingesetzt werden um die Ziele Abhörsicherheit und Authentizität zu erreichen. Intern soll das Programm auch nicht mit sehr großen Primzahlen
arbeiten, damit der Rechenaufwand in Grenzen gehalten werden kann. Dies ist nämlich der große Nachteil bei der Verwendung asymmetrischen Verfahren [TS03, S.
485f].
Weil den Schülerinnen und Schülern die zentralen Operationen nahe gebraucht werden sollen, fiel die Entscheidung auch auf ein asymmetrisches Verfahren. Auf diese
Weise lässt sich die Idee am besten in der Spiel- und Lernwelt modellieren und
grafisch ausdrücken, da einfache Werkzeuge definiert werden können, die die einzelnen Operationen repräsentieren. Bei symmetrischen Verfahren wären, wenn man
nach diesem Schema verfahren würde, nur zwei Werkzeuge (Ver- und Entschlüsseln) notwendig und das Problem wäre damit zu einfach. Die Frage, ob die Qualität
dieser Verfahren besser im Sinne von performanter oder sicherer ist, lässt sich vor
allem im Bezug auf die Sicherheit und verschiedene Anwendungsszenarien nicht so
leicht beantworten und soll nicht näher diskutiert werden. Dafür sei auf die umfangreiche Literatur zu diesem Thema verwiesen (z.B. Pfitzmann [Pfi00, S. 263-269])
verwiesen.
Verfälschen von Nachrichten
Für das Problem der Nachrichtenintegrität gibt es ebenfalls eine Reihe von guten
Lösungen. Ausgewählt wurde das Verfahren der Nachrichten-Digest. Dabei wird
4
KONZEPTION
47
Abbildung 14: Der Einsatz und die Verschlüsselung von Nachrichten-Digests28
eine kryptografische Hash-Funktion H verwendet, um den Nachrichteninhalt m
abzubilden. Wird m verändert, unterscheiden sich die Funktionswerte H(m) und
H(m0 ). Daran lässt sich nun erkennen, ob eine Verfälschung stattgefunden hat. Weiterhin muss dieser Nachrichten-Digest verschlüsselt werden, was einfach über zwei
Werkzeuge „Ver- und Entschlüsseln“ geschehen soll, damit der Digest nicht an den
veränderten Text angepasst werden kann. Stimmen nun der vom Empfänger berechnete und der an die Nachricht angehängte Digest überein, kann sich der Empfänger
über die Integrität der Nachricht sicher sein (Vgl. S. 47, Abb. 14).
Grafisch soll dieses Problem über Treffpunkte dargestellt werden, die von Agenten
vereinbart werden. Der Benutzer sieht während des Nachrichtenverlauf beim Empfänger und beim Absender ein Symbol, welches für einen bestimmten Ort steht.
Stimmen beide überein, wurde die Nachricht nicht verfälscht, ansonsten liegt ein
Fehler vor und die Agenten würden an unterschiedlichen Stellen aufeinander warten. Wenn nun der Empfänger festgestellt hat, dass die Nachricht verfälscht wurde,
kann er den Absender erneut zum Versenden der Einladung veranlassen. Das passiert im Idealfall dann solange, bis die Nachrichtintegrität festgestellt wurde.
28
4
KONZEPTION
48
Abbildung 15: Programmoberfläche von Gimp
4.2
Prototypentwicklung und grafische Oberfläche
Zunächst wurde ein Oberflächenprototyp entwickelt, der vor allem die Aufgabe hatte, die Bedienstruktur und die grafischen Elemente, die in der späteren Realisierung
von Bedeutung sind, zu testen. Es handelt sich also um einen horizontalen Prototypen, der noch keine (tieferen) Funktionalitäten aufweisen sollte. Allerdings sollte
ein ausgewähltes Problem bereits im Prototypen verwirklicht werden, damit absehbar wird, ob die Bedienelemente auch den Anforderungen genügen.
Die Idee war zunächst, die Oberfläche mit vielen Fenstern aufzubauen, wie in G IMP
realisiert. Dort werden für zahlreiche Funktionen in seperaten Fenstern dargestellt
(Vgl. S. 48, Abb. 15). Da G IMP ähnlich wie das vorliegende Projekt funktionell über
Plugins erweiterbar ist und diese Plugins auch eine bedeutende Stellung innerhalb
des G IMP-Konzepts einnehmen, seien Plugins auch nur über zusätzliche Fenster
darstellbar []. Dieser Ansatzpunkt wurde in der Konzeption nicht aufgegriffen. Es
sollten alle Plugins das gleiche bzw. die gleichen Fenster und Bedienelemente nutzen.
4
KONZEPTION
49
Abbildung 16: Programmoberfläche des ersten Prototyps
Der Prototyp des vorliegendes Projekts wurde ebenfalls mit zahlreichen Fenstern
erstellt. Das Ziel war vor allem, eine optische Unabhängig von Hauptprogramm
und Plugins. Dadurch wirkte die Oberfläche aber sehr unübersichtlich. Zahlreiche
Fenster öffneten sich, wodurch leicht der Überblick verloren ging (Vgl. S. 49, Abb.
16).
Die Schlussfolgerung war, dass zumindest die Fenster zur Bearbeitung von Agentenverhalten, Nachrichtentypen und sonstigen Optionen mit Tabs (Karteikartenreiter) in ein Fenster integriert werden sollten. Wenn möglich, sollte auch das Hauptprogramm und die Problemsimulation in eine Oberfläche integriert werden. Daraufhin wurde der Prototyp verändert und wirkte nun wesentlich übersichtlicher (Vgl.
S. 50, Abb. 17).
Mit dem Prototyps wurde aber die grundlegende Funktionsweise des Programms
deutlich. So sollten Probleme mit Hilfe einer Animation dargestellt werden und
textuell beschrieben werden. Über die verschiedenen Tabs sollte das Verhalten der
Agenten und Nachrichtentypen verändert werden können. Außerdem sollte festgelegt werden, wie Agenten auf den Erhalt oder das Absenden von Nachrichten (die
4
KONZEPTION
50
Abbildung 17: Programmoberfläche des zweiten Prototyps
sog. Ereignisse) reagieren. Dabei sollten einem Ereignis verschiedene Werkzeuge
zugeordnet werden. Dies sollte grafisch mit Drag and Drop realisiert werden.
Im Prototypen war angedacht, dass die Werkzeuge über den Tab „Agenten“ manipuliert werden können. Dies wurde fallengelassen, weil die Probleme dann recht
kompliziert werden würden. Diese Annahme sollte in der Evaluation überprüft werden. Grafisch wurden in der Endversion noch zahlreiche Details verbessert, sodass
das Programm einen modernen Anstrich bekam. Die Systemsteuerung wurde über
bekannte Mediaplayer-Bedienelemente (Start/ Pause, Stop, Forward und Reload)
realisiert, es sollte ein kleines Menü integriert und - wie bereits im Prototypen realisiert - sollten Tabs genutzt werden.
4.3
Unterteilung in Rahmenwerk und Plugins
Was im Prototyp noch nicht deutlich wurde, war die Programmteilung in Rahmenwerk und Plugins. So sollten die Probleme in Verteilten Systemen als eigenständige
Teile umgesetzt werden, die einfach und schnell entwickelt werden können. Das
Hauptprogramm sollte diese Plugins einfach „finden“ und integrieren. Dafür muss
4
KONZEPTION
51
ein Plugin lediglich ein Problem simulieren, eine Animation bereitstellen, die auf
verschiedene Problemzustände reagiert, Werkzeuge zur Verfügung stellen, mit denen Probleme gelöst werden können und Teilzustände von Problemen definieren.
Sind alle Teilprobleme gelöst, ist das Gesamtproblem gelöst. Als Teilproblem kann
Zustand definiert werden, der ein bestimmtes Verhalten überwacht. Es ist aber auch
möglich, eine Werkzeug-Ereignis-Konstellation vorzugeben, die erfüllt sein muss.
Werkzeuge werden in der Entwicklung als Komponenten bezeichnet und untergliedern sich in funktionale und Datenkomponenten. Funktionale Komponenten sollen
das Verhalten der Agenten beeinflussen, Datenkomponenten sollen verschiedene
Informationen des Agenten speichern und veränderbar machen.
Die Oberfläche des Programms sollte komplett im Rahmenwerk umgesetzt werden,
damit ein Plugin-Entwickler von dieser Aufgabe entlastet wird. Lediglich die Animation sollte selbst geschrieben werden. Als Vorgaben für die Animation gibt es
eine gewisse Fenstergröße, das Hintergrundbild, die Agentenbilder und verschiedene Nachrichtenbilder.
4.4
Einordnung des Projekts
Anhand der aufgestellten Typologien soll das Projekt im Folgenden eingeordnet
werden. Zunächst beschäftigt es sich mit grundlegenden Problemen in Verteilten
Systemen und ist für einen Einzelnutzer ausgelegt. Der Softwaretyp ist Simulation,
auch wenn das Projekt im Schema von eher ein „Experten- und Modellbildungssystem“ ist [AP94, S. 39-59]. Weiterhin ist das Projekt spielorientiert, was bedeutet,
das eine Nutzerin oder ein Nutzer in eine Spiel entführt ist. Wissen wird dabei explorativ aufgebaut.
Die Software ist um weitere Probleme, die mit nachrichtenbasierter Kommunikation zusammenhängen, erweiterbar und sollte mit anderen Lernformen kombiniert
eingesetzt werden. Die Simulation bezieht sich auf das Verständnis und nicht auf
das Bedienen-Können von Werkzeugen. Die Steuerung des Programms ist auf das
4
KONZEPTION
52
Problem in Form vom Zusammenstellen von Algorithmen auf einer abstrakten Ebene bezogen. Gelernt werden soll mit Hilfe der Simulation komplexere Vorgänge.
Als „Tutorial“ soll der begleitende Unterricht dienen. Zur Informationsvermittlung
in der Spielwelt sollen Texte und vor allem Animationen dienen. Gelernt wird nicht
sozial, dafür aber parasozial. So soll der Bürgermeister als Ansprechpartner dienen.
Die Oberfläche wurde mit modernen Bedienelementen und Animationen ausgestattet.
M ERKMAL
VORLIEGENDES P ROJEKT
Gegenstand
Verteilte Systeme
Nutzerzahl
Einzelnutzer
Softwaretyp
Simulation
Spielorientierung
spielorientiert
Explorativität
explorativ
Erweiterbarkeit
erweiterbar
Lerngegenstandstyp
systemnah
Problembezug
problembezogen
Art des Wissensaufbaus
Handlungswissen
Tutorials
nicht vorhanden
Informationsvermittlung
Texte, Animationen
Vorführungen
keine Vorführungen
komplexes Lernen
vorhanden
nicht vorhanden
vorhanden
Oberfläche
2D-Grafik
Tabelle 6: Einordnung des vorliegenden Projekts
5
REALISIERUNG
5
53
Realisierung
In diesem Kapitel wird die Implementierung des beschriebenen Konzepts diskutiert.
Dafür sollen zunächst die Auswahl von Programmiersprache und anderen Technologien begründet werden. Anschließend erfolgt eine ausführliche Beschreibung des
Programms und der zugehörigen Plugins. Im letzten Teil dieses Kapitels werden
dann Besonderheiten und Probleme angeführt.
5.1
Programmiersprache und verwendete Technologien
Als Programmiersprache für das Projekt wurde JAVA verwendet. Für JAVA wurde
sich auf Grund der zahlreichen und einfachen Möglichkeiten zur Gestaltung einer
modernen und ansprechenden Oberfläche, der Unterstützung für XML-Operationen
zur Erweiterbarkeit des Programms, der guten Dokumentationsmöglichkeiten (JAVADOCS),
der Multi-Threading-Fähigkeiten und vor allem wegen der Plattformunabhängigkeit entschieden. Somit ist u.a. sichergestellt, dass das Programm auf verschiedenen
System lauffähig ist und sich dort. Für JAVA spricht weiterhin die einfache und
nachvollziehbare objektorientierte Modellierung. Zudem ist JAVA mittlerweile so
verbreitet, dass sich der Einsatz dieser Sprache fast aufdrängt um ein Projekt zu
entwickeln, dass gut und leicht nachvollziehbar sein soll [Ull06, S. 49-79].
Zur Darstellung der grafischen Oberfläche wurde sich für einen Mix aus den JA VA -Grafikpaketen
S WING für die Darstellung von Fenstern und für AWT für Ani-
mationen entschieden. Das Grafikpaket S WING bietet sehr gute Möglichkeiten aktuelle Grafikelemente wie Fortschrittsbalken, Tabs oder Werkzeugleisten zu implementieren. S WING ist eine Erweiterung von AWT und bietet damit weitaus größeren Spielraum als AWT und dieser Spielraum wurde in der Arbeit auch genutzt.
S WING-Komponenten passen sich nicht komplett an das „Look and Feel“ der Plattform an. Eine S WING-Anwendung kann also nicht das Äußere von W INDOWS V IS TA
oder des KDE-Desktops „annehmen“, ist dafür aber flexibeler verwendbar und
performanter als z.B. SWT [Ull07].
5
REALISIERUNG
54
Die Animationen wurden mit Hilfe von AWT verfasst, da für die Zeichnungen nicht
der volle Funktionsumfang von S WING genutzt werden musste und damit das Programm performanter wurde. Die beiden Pakete sind gut miteinander kompatibel,
weshalb die Mischung zu keinerlei Problemen führte [Ull06, S. 842].
Für das Laden von Plugins sind XML-Dateien mitverantwortlich [Con02]. XML
kann als Definitionsbasis für einfache Auszeichnungssprachen wie HTML (Hypertext Markup Language) genutzt werden und baut selbst auf der flexiblen, Korrektheit sichernden und leistungsfähigen Sprache SGML (Standard Generalized
Markup Language) auf [Ull06, S. 796]. Die Nutzung beider Vorteile machte XML
schnell populär. Die Einsatzgebiete sind sehr groß und so eignet sich die Technologie auch für die Beschreibung zentraler Elemente des Plugins. Für die Auswertung
der XML-Dateien wurde das JDOM (JAVA Document Object Model) verwendet,
welches knapp gesagt die Vorteile der Konkurrenten des W3C-(World Wide Web
Consortium) Projekts DOM (Document Object Model) und von SAX-(Simple API
for XML) Projekts vereinen soll [Hun08].
Die Erstellung der Programmhilfe, die ein zentrales Element des Programms ist, da
viele Nutzer wohl nur über wenige Erfahrungen im Umgang mit Simulationen, Verteilten Systemen und teilweise auch der Steuerung eines solchen Programms verfügen werden, wurde mit dem JAVA H ELP S YSTEM erstellt, welches es der Standart
für derartige Projekte ist und den entscheidenden Vorteil hat, dass es auch HTML
basiert und damit auch als Online-Hilfe zur Verfügung gestellt werden kann. JAVA H ELP ist durch die Verwendung von HTML natürlich auch plattformunabhängig.
[SM08]
5.2
Das Rahmenwerk
Das Rahmenwerk des Programm29 stellt zunächst die Systemoberfläche bereit und
zeichnet den „parasozialen“ Bürgermeister (vgl. S. 55, Abb. 18), der den Nutzer der
29
Eine ausführliche, technische Dokumentation befindet sich im Anhang A.
5
REALISIERUNG
55
Abbildung 18: Der Bürgermeister begrüßt den Benutzer
Abbildung 19: Die Programmoberfläche
Software begrüßt und ihn in die Spielwelt einführt. Anschließend kann der Benutzer
mit ein Problem starten, indem er den „Play“-Button in der unter Steuerungsleiste
anklickt. Die Animation rechts zeigt dann speziell für ein Problem eine Animation
an, die auf Benutzereingaben reagiert und somit generisch verschiedene Zustände
eines Problems grafisch verdeutlicht (vgl. S. 55, Abb. 19).
Im Tab „Ereignisse“ kann man die zur Problemlösung relevanten Ereignisse auswählen. Das sind das Senden und das Empfangen einer Nachricht vom einem bestimmten Nachrichtentypen. Vor dem Senden oder nach dem Empfang von Nachrichten eines bestimmten Typs werden dann die Werkzeuge ausgeführt, die der Benutzer zugeordnet hat. Die Reihenfolge der Werkzeuge wird bei der Abarbeitung
5
REALISIERUNG
56
Abbildung 20: Der Ereignis-Tab: Verknüpfung von Werkzeugen mit Ereignissen
berücksichtigt. Für die grafische Darstellung der Benutzerlösung wurden eine an
Ablaufdiagramme angelehnte Form verwendet, die Schülerinnen und Schüler vertraut sein dürften und zudem auch intuitiv handhabbar sind (vgl. S. 56, Abb. 20).
Der Tab „Nachrichtentypen“ erlaubt die Manipulation von Nachrichtentypen. Diese
haben Optionen, denen ein bestimmter, vorgegebener Wert zugeordnet werden kann
(vgl. S. 57, Abb. 21).
5.3
Die Problem-Plugins
Im Folgenden sollen die Problem-Plugins30 näher beschrieben werden. Dabei stehen vor allem die grafische Umsetzung und die Werkzeuge, die zur Problemlösung
notwendig sind, im Vordergrund. Zur grafischen Umsetzung allgemein ist zu sagen,
dass verschiedene Nachrichtentypen über verschiedene Farben dargestellt werden.
Außerdem kann eine Animation weitere grafische Elemente neben der Stadt, den
Nachrichten, Leitungen und Agenten verwenden. Zu diesen Elementen kann ein
Plugin-Autor eine Legende als Bild einfügen, die dem Benutzer die Übersicht erleichtert.
30
Eine ausführliche, technische Dokumentation befindet sich im Anhang A.
5
REALISIERUNG
57
Abbildung 21: Der Nachrichtentypen-Tab: Auswahl von Nachrichten-Optionen
Für die Entwicklung eines Plugins muss der Autor bestimmte Vorgaben einhalten,
damit das Plugin vom Hauptprogramm gefunden und eingebunden werden kann.
Für die Plugin-Beschreibung muss deshalb zunächst ein XML-Dokument angelegt
werden, welches auf funktionale und Datenkomponenten, Lösungszustände, Nachrichtentypen, die Animation und die Simulation verweist. Das Plugin muss als JA VA -kompatible
JAR-Datei vorliegen und die Implementierungen der oben aufge-
führten Komponenten beinhalten, damit es korrekt eingebunden werden kann.
Die zentralen Bestandteile eines Plugins sind die Simulation und die Animation. Die
Problemsimulation koordiniert alle anderen Bestandteile des Plugins und simuliert
das eigentliche Problem. Die Animation, an die bestimmte Vorgaben geknüpft bzw.
Angebote (Fenstergröße, das Hintergrundbild, die Agentenbilder und verschiedene
Nachrichtenbilder) gestellt werden.
Eine funktionale Komponente ist ein Werkzeug, dass das Verhalten eines Agenten
manipuliert. Es kann mehrfach einem bestimmten Ereignis zugeordnet werden. Unter Datenkomponenten werden hingegen Ressourcen verstanden, die entweder mit
der Simulation oder mit einem Agenten verknüpft sein können. Im Rahmenwerk
ist zunächst keine Möglichkeit der Darstellung von Datenkomponenten gegeben.
Um sie sinnvoll zu nutzen, kann der Entwickler sie aber in die Animation einbauen.
5
REALISIERUNG
58
Datenkomponenten können über funktionale Komponenten manipuliert werden.
Zuletzt besteht die Möglichkeit Nachrichtentypen zu definieren. Sie sind notwendig
um die notwendige Übersichtlichkeit im Problem zu wahren und damit man ihnen
Ereignisse zuordnen kann. Generell kann es maximal zwei Ereignisse pro Nachrichtentyp geben (vor dem Senden und nach dem Empfangen einer Nachricht). Als
Konvention an die Plugins wird jedoch vorgegeben, dass Ereignisse, die nicht zur
Problemlösung gebraucht werden, auch nicht dem Benutzer angeboten werden, damit die Übersichtlichkeit gewahrt bleibt.
Die Benutzerlösungen werden fortlaufend in einem eigenen Thread überprüft. Dafür gibt es für Plugin-Entwickler zwei Möglichkeiten. Zunächst kann eine bestimmte Konfiguration von Ereignis-Werkzeug-Verknüpfungen als korrekt gelten. Es besteht aber auch die Möglichkeit, einen oder mehrere Teilzustände zu definieren,
die den Lösungszustand ständig überwachen. Beide Formen haben aber Vor- und
Nachteile. Erste akzeptiert nur vom Entwickler vorgegebene Konfigurationen, wobei es durchaus möglich ist, dass der Entwickler andere Konfigurationen außer Acht
gelassen hat. Die zweite Möglichkeit ist also die konzeptionell „schönere“, riskiert
aber eine längere Wartezeit auf ein Feedback und kann bei Entwicklungsfehler auch
falsche Zustände akzeptieren. Für die Plugins wurden beide Varianten verwendet.
5.3.1
Nachrichtenverlust
Der Verlust von Nachrichten wird über eine rot gefärbte Nachricht dargestellt, die
auf der Hälfte der Wegstrecke verschwindet (vgl. S. 59, Abb. 22). Zur Lösung
des Problems werden Nachrichten wiederholt gesendet, sodass die Nachricht nach
Überwinden des Übertragungsproblems beim Empfänger ankommen kann. Dabei
ist der Abstand der Sendungen voreingestellt, damit die Nutzerinnen und Nutzer
nicht mit zusätzlichen Aufgaben überlastet werden. Derartige Parameter bieten sich
aber für eine Projekterweiterung an, die zur Differenzierung im Unterricht nach
Leistungsstand der Schülerinnen und Schüler führen kann.
5
REALISIERUNG
59
Abbildung 22: Grafische Darstellung einer verlorenen Nachricht
Abbildung 23: Die Werkzeuge des Problems „Verlorene Nachrichten“
Neben dem Beginn der Sendungswiederholung gibt es das Werkzeug Nachrichtenbestätigung, das eine Nachricht vom gleichnamigen Typ generiert und sendet.
Eine solche Nachricht hat die Farbe grün. Es muss dem Ereignis „Empfang“ einer
Standardnachricht zugeordnet werden (vgl. S. 59, Abb. 23), damit der Absender
weiß, dass eine Nachricht angekommen ist. Dann kann man noch das Werkzeug
Sendungswiederholung beenden auswählen, dass beim Empfang einer Nachrichtenbestätigung sinnvoll eingesetzt werden könnte.
Die ID einer Nachricht vom Typ „Nachrichtenbestätigungen“ kann ebenfalls manipuliert werden. Nur wenn die Option „ Nachrichten-ID zitieren“ ausgewählt wird,
wird die Nachrichten-ID der Ursprungs-Nachricht verwendet (vgl. S. 60, Abb. 24).
5
REALISIERUNG
60
Abbildung 24: Optionen des Typs „Nachrichtenbestätigung“
Damit das Problem der verlorenen Nachricht als gelöst gilt, müssen zwei Bedingungen erfüllt sein. Geht eine Nachricht verloren, muss sie anschließend erneut gesendet wird. Außerdem darf keine Endloswiederholung einer Nachricht auftreten,
die die Übertragung anderer Nachricht stören könnte.
Grafisch wird das Problem über drei verschiedene Nachrichtenarten dargestellt. Zunächst werden die beiden Typen „Standardnachicht“ und „Nachrichtenbestätigung“
unterschieden. Eine Nachricht, die verloren geht, wird rot eingefärbt und verschwindet auf der Hälfte des Weges zum Empfänger.
5.3.2
Unterschiedliche Nachrichtenreihenfolgen
Das Problem der Nachrichten, deren Reihenfolge bei verschiedenen Empfängern
unterschiedlich ist, wurde mit zwei Senderagenten und vier Empfängeragenten realisiert. Das Ziel ist es, dass die Nachrichten am Ende des Empfangsprozesses in
gleicher Reihenfolge vorliegen. In der Problemsimulation senden zunächst die beiden rot eingefärbten Agenten an einen zufälligen Empfänger eine farbige Nachricht. Je Sender werden insgesamt zwei Nachrichten an alle Empfänger versendet.
Die beiden gesendeten Nachrichten eines Absenders sind immer richtig sortiert. In
Abbildung 25 auf Seite 61 ist zu sehen, dass zwei Agenten (zufällig) die gleiche
Kombination haben und es in der Abbildung insgesamt drei Kombinationen (ohne
5
REALISIERUNG
61
Abbildung 25: Nachrichten haben bei den Agenten unterschiedliche Kombinationen
Empfänger) gibt.
Zur Lösung des Problems stehen dem Benutzer fünf Werkzeuge zur Verfügung, die
vier Ereignissen zugeordnet werden müssen. Die Ereignisse sind jeweils das Versenden und der Erhalt von Standardnachrichten mit farbigen Codes und von Nachrichtenbestätigungen. Bei einem Sendeereignis muss jeweils ein Zeitstempel eingefügt werden. Beim Standardnachrichtenempfang sollten die restlichen vier Werkzeuge verwendet werden. Zunächst wird der Zeitstempel der Nachricht mit dem
eigenen verglichen und der höhere als eigener Zeitstempel festgelegt. Anschließend
wird dieser um eins erhöht. Dann kann die Nachricht in eine Warteliste eingefügt
werden, sortiert und ausgegeben werden. Außerdem muss beim Erhalt einer Nachricht den anderen Agenten mitgeteilt werden, dass die Nachricht empfangen wurde.
Nur dann darf sie später an den Agenten weitergegeben werden (vgl. S. 62, Abb.
26). Was der Nutzer nicht umsetzen muss, aber Bestandteil des eigentlichen Algorithmus ist, ist die Frage wie die Ausgabe an den Agenten realisiert wird. Steht
eine Nachricht an der Spitze der Warteschlange und es sind von allen Teilnehmern
Bestätigungen eingetroffen, dass die Nachricht empfangen wurde, darf sie erst weitergeleitet werden.
Die Lösung des Problems wird anhand mehrerer Konfigurationen überwacht. Da es
zum Beispiel unerheblich ist, ob der Empfang der Nachricht zuerst bestätigt wurde oder zuerst die Nachricht in die Warteliste eingefügt worden ist. Die Nachrich-
5
REALISIERUNG
62
Abbildung 26: Werkzeuge zur Nachrichtensortierung
tenreihenfolge wird in der Animation mit vier Kästchen neben den Empfängern
gekennzeichnet. Wenn alle Kästchen der Agenten die gleichen Farbkombinationen
haben, funktioniert die Sortierung, sonst nicht. Nachrichten werden in unterschiedlichen Farben dargestellt. Solange nicht alle Nachrichten angekommen sind, kann
die Reihenfolge variieren. Nicht besetzte Felder werden grau unterlegt.
5.3.3
Fälschen von Nachrichten
Bei diesem Problem werden Nachrichten gefälscht, sodass Verabredungsorte von
Sender und Empfänger nicht mehr übereinstimmen. Mit einer Wahrscheinlichkeit
von 25 % ist eine Nachricht gefälscht (vgl. S. 63, Abb. 27), sonst nicht (vgl. S. 63,
Abb. 28).
Zur Prüfung, ob eine Nachricht gefälscht wurde oder nicht, müssen Prüfsummen
berechnet und verschlüsselt werden. Als zusätzliches Werkzeug gibt es die Aufforderung zur Sendungswiederholung, die nicht notwendig zum Problem gehört, aber
in der Spielwelt als sinnvoll erscheint (vgl. S. 63, Abb. 29).
Der Lösungszustand des Problems wird anhand von vorgegebenen Ereignis-WerkzeugZuordnungen überprüft. Auch in diesem Problem sind natürlich mehrere Konfigurationen möglich. Da die Agenten versuchen, sich zu verabreden, kann der Nutzer
neben den Kommunikationspartnern jeweils ein Symbol sehen (z.B. Zoo, Café oder
Kino). Sind die Symbole neben Sender und Empfänger gleich, liegt keine Fälschung
5
REALISIERUNG
63
Abbildung 27: Gefälschte Nachricht werden über unterschiedliche Orte dargestellt
Abbildung 28: Eine echte Nachricht: Identische Orte bei Sender und Empfänger
Abbildung 29: Werkzeuge für das Problem der gefälschten Nachrichten
5
REALISIERUNG
64
Abbildung 30: Animation des Problems der gemeinsamen Ressourcen
vor, sonst kann der Nutzer erkennen, dass die Nachricht gefälscht wurde. Die unterschiedlichen Nachrichtentypen und -zustände werden wieder mit verschiedenen
Farben der Nachrichten symbolisiert.
5.3.4
Inkonsistent-Werden einer gemeinsamen Ressource
Das Problem der inkonsistenten Nutzung gemeinsamer Ressourcen sollte mit einer
quoren-basierten Lösung bearbeitet werden. Dargestellt werden die Repliken mit
einem Eurobetrag neben den Agenten und einer zentralen Ressource in der Mitte,
die immer den aktuellen Stand anzeigt. Aktuelle Ressourcen sind in blauer Farbe
geschrieben, nicht-aktuelle rot (vgl. S. 65, Abb. 31). Außerdem gibt es Schlösser
neben den Agenten, die den Sperrungszustand verdeutlichen (vgl. S. 64, Abb. 30).
Zunächst muss der Benutzer das System aufbauen und versuchen, dass die Repliken konsistent bleiben. Dafür stehen ihm sechs Werkzeuge zur Verfügung. Durch
„Ressourcenversand generieren“ sendet ein Agent seine aktuelle Ressource an einen
anderen. Mit „Schreiberlaubnis generieren“ wird eine Nachricht versendet, die dem
Empfänger mitteilt, ob er auf die Ressource eines Agenten schreiben darf oder nicht.
5
REALISIERUNG
65
Abbildung 31: Aktuelle und nicht-aktuelle Ressourcen
Abbildung 32: Werkzeuge des Problems der gemeinsamen Ressourcen
„Ressourcen aktualisieren“ veranlasst einen Agenten, seine sowie die Ressourcen
der Agenten, von denen er eine Schreiberlaubnis empfangen hat, zu aktualisieren.
Dies geschieht jedoch nur, wenn das Schreibquorum erfüllt ist. „Ressource (ent-)
sperren“ verändert den Sperrungszustand der eigene Ressource (vgl. S. 65, Abb.
32).
Neben der Werkzeugkonfiguration wird noch überprüft, ob die Mindestquoren für
das Lesen und Schreiben einer Ressource erfüllt sind. Diese Parameter lassen sich
im Nachrichtentypen-Tab einstellen (vgl. S. 66, Abb. 33).
Grafisch wird das Problem mit Geldbeträgen in Euro neben den Agenten symbolisiert. Stimmt der Betrag eines Agenten mit den mittleren überein, der den korrekten Betrag anzeigt, so ist dieser blau eingeschrieben, sonst rot. Außerdem befinden sich Schlößer neben den Agenten, die den Sperrzustand der Ressource symbolisieren sollen. Unterschiedliche Nachrichtentypen sind wieder verschieden far-
5
REALISIERUNG
66
Abbildung 33: Quoreneinstellungen des Problems der gemeinsamen Ressourcen
big dargestellt, besondere Nachrichtenmerkmale wie eine Schreiberlaubnis oder verweigerung werden ebenfalls symbolisch abgebildet.
5.3.5
Mitlesen von Nachrichten
Das Mitlesen von Nachrichten wurde so simuliert, dass bei einem Nachrichtenaustausch immer auch ein dritter Agent beteiligt ist. Dieser kann die Nachricht
mitlesen, wenn sie unverschlüsselt versendet wurde (vgl. S. 67, Abb. 34). Ein Nebenaspekt des Problems ist die Nachrichtenauthentizität. Der Empfänger soll sich
sicher sein, dass die Nachricht auch tatsächlich vom Absender stammt. Das Problem gilt dann als gelöst, wenn der Mitleser mit der gelesenen Informationen nichts
anfangen kann und gleichzeitig die Nachricht beim Empfänger korrekt entschlüsselt wird. Außerdem muss sichergestellt sein, dass der Empfänger der Nachricht
vertrauen kann.
Zur Lösung des Problems stehen wieder einige Werkzeuge zur Verfügung (vgl. S.
67, Abb. 35). Der Benutzer muss öffentliche und geheime Schlüssel den Ereignissen
so zuordnen, damit beide Bedingungen erfüllt sind. Ordnet er eine Verschlüsselung
der Nachricht an ohne sie korrekt zu entschlüsseln, kann der Empfänger nichts mit
5
REALISIERUNG
Abbildung 34: Ein dritter Agent liest Nachrichten mit
Abbildung 35: Werkzeuge zur Nachrichtenver- und entschlüsselung
67
5
REALISIERUNG
68
Abbildung 36: Zwei Fragezeichen: Die Nachrichten werden verschlüsselt, aber
nicht entschlüsselt
den Informationen anfangen (vgl. S. 68, Abb. 36).
Auch die Nachrichtensicherheit wird anhand von vorgegebenen Ereignis-WerkzeugVerknüpfungen überprüft. In der Animation wird das Mitlesen von Nachrichten
durch einen dritten Agenten dargestellt, der eine Zeitung vor sich hat und dessen
Mitlesen über eine rote „Leitung“ zu Nachricht symbolisiert wird. Der Nachrichtenempfänger hat ebenfalls eine Zeitung vor sich. Die Zeitung kann entweder die Aufschrift „News“ haben, was symbolisiert, dass die Nachricht gelesen werden kann
oder ein Fragezeichen, was heißen soll, dass die Nachricht nicht gelesen werden
kann. Die unterschiedlichen Nachrichtentypen oder -zustände werden über unterschiedlich farbige Nachrichten dargestellt.
6
EVALUATION
6
69
Evaluation
Die Beurteilung der Software besteht aus einer Einschätzung, ob und wie die gesteckten Ziele tatsächlich umgesetzt wurden. Zudem wurde die Software mit einer
neunten Klasse ausprobiert. Dieser Schulversuch soll ebenfalls zur Evaluation der
Software diskutiert werden.
6.1
Schulversuche
Um die Nutzbarkeit der Software, Effektivität und Effizienz des Lernen mit der
Lernsoftware bezogen auf konkrete Ziele zu testen, wurde sie mit einer Informatikklasse erprobt. Dabei ist zunächst zu bemerken, dass die Tests durchaus unvollständig sind und genauere Untersuchungen aus zeitlichen Gründen leider nicht möglich
waren. Die Erweiterbarkeit durch das Erstellen weiteren Plugins konnte im Rahmen
der Evaluation ebenfalls nicht betrachtet werden.
6.1.1
Vorbemerkungen
Prinzipiell ist eine fragebogengestützte Evaluation von Lernsoftware schwierig. Aufgrund von Zeitknappheit ist sie zudem auch nicht umfassend, sodass wichtige Aspekte vorher herausgestellt werden mussten. Dadurch musste u.a. darauf verzichtet
werden, die Effizienz und Nutzbarkeit eines Unterrichts mit der Lernsoftware mit
anderen Lehr- und Lernformen zu vergleichen. Darunter fallen vor allem das Textstudium und die Behandlung des Stoffs in einem Vortrag. Damit sich der Aufwand
einer solchen Software lohnt, sollten zumindest vergleichbare Ergebnisse bei den
unterschiedlichen Lernmethoden zu beobachten sein. Damit dieser Vergleich nicht
ganz weggelassen wird, sollen kurz die Ergebnisse einer Studie vorgestellt werden,
die sich mit der Lernsoftware G ANIMAL [GanoJ] befasste.
Nach dieser Studie, die den Lernerfolg durch Prüfung von Wissens- und Transfer-
6
EVALUATION
70
fragen testete, ergaben sich kaum Unterschiede zwischen den vier Gruppen: ältere Lernsoftware („A DL A“), neuere Lernsoftware („G ANIMAL“), dem Textstudium
und einer Vorlesung. Die Unterschiede waren bei beiden Fragetypen gering, wobei
der Lehrtext bei Wissensfragen leicht besser abschnitt als die anderen Methoden
und G ANIMAL bei Transferfragen die besten Ergebnisse erzielte. Wie die Autoren
annahmen und die Studie in Ansätzen auch zeigte, lassen sich durch Lerntexte die
besten Ergebnisse beim Aufbau von Basiswissen erzielen. Lernsoftware hingegen
eignet sich gut für einen aufbauenden Ansatz. Allerdings muss gesagt werden, dass
die Fragen wohl zu einfach gestellt wurden, sodass die Ergebnisse mit Vorsicht betrachtet werden müssen [Ker03, S. 6-9]. Da das G ANIMAL-System nicht für Schulen entwickelt wurde und es einige Unterschiede zwischen Schul- und Hochschuldidaktik gibt, ist es in Schulen sicher nicht sinnvoll, Textarbeit dort einzusetzen,
wo andere, z.B. handlungsorientierte Methoden eingesetzt werden können. Damit
lassen sich nachweislich bessere Lernerfolge erzielen, auch beim Aufbau von Basiswissen.
Für das vorliegende Projekt heißt das nun, dass sich ein kombinierter Einsatz mit
anderen Lernmethoden empfiehlt. Leider konnten unterschiedliche Vorgehensweisen, die auf unterschiedliche Bedürfnisse der Lernenden eingehen, aus zeitlichen
Gründen nicht mehr erprobt werden.
6.1.2
Fragebogenentwicklung
In zwei Schulversuchen sollte herausgefunden werden, ob und wie die Software
in Schulen tatsächlich eingesetzt werden kann. Durch Beobachtungen während der
Versuche und durch einen Fragebogen sollten folgende Fragen geklärt werden:
1. Eignet sich die Komplexität der Probleme und Lösungsstrategien prinzipiell
für den Einsatz an Schulen?
2. Welche Unterschiede gibt es zwischen den einzelnen Problemen in Bezug auf
ihre Komplexität?
6
EVALUATION
71
3. Welche Voraussetzungen müssen Schülerinnen und Schüler haben, damit sie
erfolgreich mit der Software lernen können?
4. Wie muss der Lehrende den Unterricht begleiten, damit der Einsatz der Software erfolgsversprechend ist?
Zur Beantwortung dieser Fragen müssen natürlich zunächst Lernziele definiert werden, die durch den Fragebogen geprüft werden können. Die Schülerinnen und Schüler sollen
• ein grundsätzliches, intuitives Verständnis von Verteilten Systemen entwickeln,
• die Probleme und ihre Relevanz erfassen und
• die Lösungsstrategien zu den Problemen verstehen und in anderen Zusammenhängen anwenden können.
Neben diesen grundsätzlichen Fragen sollten auch unterrichtspraktische Aspekte
durch die Schulversuche getestet werden:
• Sind die Schulen für den Einsatz der Software ausgestattet (vorhandene Hardware, Internetanschluss)?
• Wie lange dauert bei einem guten, durchschnittlichen und leistungsschwächeren Schüler die komplette oder Einzelproblemdurchführung?
• Bestehen Möglichkeiten der Differenzierung nach Leistungsstand?
Aus diesen Grundfragen wurde anschließend der Fragebogen entwickelt. Die Schülerinnen und Schüler sollten ihn direkt im Anschluss an die Nutzung der Software
ausfüllen. Der mittelfristige Lernerfolg konnte aus praktischen Gründen nicht kontrolliert werden.
6
EVALUATION
72
Der Fragebogen untergliedert sich in drei Teile. Im ersten Teil sollten die Schülerinnen und Schüler ihre persönliche Meinung zur Software zum Ausdruck bringen.
Im zweiten Abschnitt wurde der Lernerfolg anhand einiger Fragen überprüft. Im
letzten Teil sollten Daten zu Programmfehlern und sonstigen Schwierigkeiten in
der Durchführung gesammelt werden. Den Fragen wurden jeweils Wertansprüche
(Erfüllung von unabdingbaren Notwendigkeiten (1), in den Anforderungen definierte Eigenschaften, die über die Minimalanforderungen hinausgehen (2) sowie
idealistische Eigenschaften, die für spätere Fortführungen und das Erstellen weiterer Plugins genutzt werden können (3))31 [Bau97] zugeordnet. Die Schülerinnen
und Schüler konnten bei einem Großteil der Fragen zwischen acht Abstufungen
auswählen und immer auch weitere Anmerkungen niederschreiben.
Im Folgenden sollen Erwartungen zu den einzelnen Fragen dargestellt werden, die
als Grundlage für Auswertung dienen.
1. Teil: Einschätzung des Programms
1.1 Würden Sie sagen, dass Sie durch das Programm etwas gelernt haben (viel/
wenig)[1]?
Die Frage soll die subjektive Wahrnehmung der Teilnehmerinnen und Teilnehmer
zeigen, ob sie etwas gelernt haben, und ist natürlich zentral für das Projekt. Es wird
davon ausgegangen, dass die Schülerinnen und Schüler einen Lernerfolg bei sich
verzeichnen können.
1.2 Wie beurteilen Sie das Programm im Ganzen (sinnvoll/ weniger sinnvoll)[-]?
Diese Frage soll vor allem die Schülerinnen und Schüler motivieren, dass ihre Angaben und Eindrücke von Bedeutung sind. Schlussfolgerungen lassen sich kaum
daraus ziehen, da es sich um ein Lernprojekt handelt. Möglich wären auch negative
Einschätzungen, da die Software z.B. keine moderne 3D-Grafik verwendet und den
Schülerinnen und Schülern nicht klar geworden sein könnte, welchen Vorteil sie von
31
Die Wertansprüche werden in eckigen Klammern dargestellt.
6
EVALUATION
73
der Software im Gegensatz zum klassischen Unterricht hatten. Die Akzeptanz als
Lernmethode für elektronische Lernspiele ist zumindest in Deutschland noch nicht
gegeben [Kri08].
1.3 Wie beurteilen Sie den Entwicklungsstand des Programms (verbesserungswürdig/ komplett)[2]?
Auch bei dieser Frage wird eine grundsätzliche, subjektive Einschätzung der Schülerinnen und Schüler erwartet, zu der vorher noch nicht viel gesagt werden kann.
Durch den relativ kurzen Entwicklungszeitraum ist aber zu erwarten, dass das Ergebnis eher in Richtung „verbesserungswürdig“ tendiert.
1.4 Fanden Sie, dass die Grafik im Allgemeinen und besonders die Animationen
hilfreich für das Verstehen und das Lösen der Probleme war (nicht hilfreich/ sehr
hilfreich) [2]?
Die Grafik soll vor allem motivieren und nicht sofort klar machen, dass es um Lernen geht und nicht um Spaß. Natürlich ist die Grafik im Vergleich zu modernen
3D-Spielen nicht besonders anspruchsvoll. Sie verwendet aber moderne Bedienelemente.
Wichtiger ist es aber zu erfassen, ob die Animationen dem Zweck dienen, das Lernen zu unterstützen und hilfreich beim Verstehen und Lösen des Problems sind.
Erwartet wurde bei dieser Frage, dass viele Schülerinnen und Schüler die Animationen als hilfreich empfanden.
1.5 Wie angemessen finden Sie die Steuerung (sehr angemessen/ nicht angemessen)[2]?
Diese Frage ist deshalb von Bedeutung, da eine lange Eingewöhnzeit in die Steuerung die knappe Unterrichtszeit weiter verkürzen würde und demotivierend wirken
kann. Es wird erwartet, dass die Schülerinnen und Schüler die Steuerung als einfach
bezeichnen, da Bedienelemente aus modernen Betriebssystemen, Programmen und
Webapplikationen verwendet wurden.
6
EVALUATION
74
1.6 Für wie wichtig halten Sie das Thema Verteilte Systeme für die Schule (sehr
wichtig/ unwichtig)[2]?
Es ist sicher schwierig, ein Unterrichtsthema zu begründen und es Schülerinnen und
Schüler „schmackhaft“ zu machen. Trotzdem soll mit Hilfe der Software und des
begleitenden Unterrichts sichergestellt werden, dass die Lernerinnen und Lerner das
Thema für relativ wichtig halten.
2. Teil: Was Sie tatsächlich gelernt haben
Dieser Fragebogenteil wird für alle fünf Probleme extra ausgefüllt. Es ist zu erwarten, dass vor allem das Problem der inkonstitenten Nutzung einer gemeinsamen
Ressource zu Problemen führt, da es recht komplex ist. Die Hoffung ist aber, dass
durch den Vergleich mit den anderen Problemen Schlussfolgerungen gezogen werden können, die zur Weiterentwicklung der Quoren-Lösung und zur Neuentwicklung weiterer Probleme beitragen können.
2.x Haben Sie das Problem bearbeitet? (ja/ nein, dann weiter mit 2.x+1)[-]
2.x.1 Für wie relevant halten Sie das Problem (sehr relevant/ nicht relevant)[1]?
Es ist wichtig, dass die Schülerinnen und Schüler feststellen, dass das Problem erstens für sie und zweitens für das Thema Verteilte Systeme von Bedeutung ist. Dadurch soll sichergestellt werden, dass eine Motivation und Verknüpfung (Einordnung) zum Problem hergestellt wurde. Es ist zu erwarten, dass vor allem komplexere, aber auch sehr einfache Probleme schlechter motivieren können.
2.x.2 Wie kann das Problem in der Praxis auftreten (Stichpunkte)[2]?
Diese Frage soll Rückschlüsse auf den Lernerfolg der Schülerinnen und Schüler ermöglichen. Es soll getestet werden, ob sie etwas mit dem Problem anfangen und es
einordnen können. Es ist zu erwarten, dass Schülerinnen und Schüler mit besseren
Leistungen hier bessere Ergebnisse abliefern.
2.x.3 Wie löst man das Problem (Stichpunkte)[2]?
6
EVALUATION
75
Ebenfalls für die Lernerfolgskontrolle ist diese Frage von Bedeutung. Es ist zu erwarten, dass die Lösungswege auf unterschiedlichem Niveau nachvollzogen werden
können.
2.x.4 Wie viel Zeit haben Sie ungefähr gebraucht (1 Minute bis 15 Minuten)[2]?
Die Auswertung der Frage soll dabei helfen, die Komplexität des Problems, der
Lösungswege und vielleicht bestimmte Designfragen zu überprüfen.
3. Teil: Programmfehler und sonstige Schwierigkeiten
3.1 Haben Sie Fehler im Programm festgestellt (Stichpunkte)[2]?
Diese Frage dient dazu, Programm- oder auch Designfehler festzustellen um sie zu
beheben.
3.2 Kamen Ihnen konkrete Bedienelemente ungewöhnlich vor (Stichpunkte)[2]?
6.1.3
Ergebniserfassung und Auswertung
Das Programm wurde mit 13 Schülerinnen und Schülern der neunten Klassen am
Jenaer Gymnasium Carl Zeiss mit mathematisch-naturwissenschaftlich-technischen
Spezialklassen im wahlobligatorischen Unterricht (WOU) Informatik getestet. Dieser Unterricht ist ein obligatorisches Zusatzangebot und kann in einer Naturwissenschaft oder in Informatik belegt werden. Die Schülerinnen und Schüler haben
neben diesem WOU auch noch „normalen“ Informatik-Unterricht, was in anderen
Thüringer Schulen unüblich ist. Von daher haben sie auch Erfahrungen im Umgang
mit Algorithmen und durch die Behandlung der visuellen Programmierumgebung
P UCK[Koh04] in der achten Klasse auch einige praktische Kenntnisse, die andere
Schülerinnen und Schüler in Thüringen nicht haben dürften.
Das Programm wurde in einer Doppelstunde getestet, die von 14.00 bis 15.30 Uhr
stattfand. Zunächst erfolgte eine kurze informelle und anschließend eine formale
Definition von Verteilten Systemen, eine Diskussion möglicher Anwendungen und
6
EVALUATION
76
die Ziele von Verteilten Systemen, die über Transparenzeigenschaften beschrieben
worden [TS03, S. 21-24]. Dann wurde eine kurze Einführung in das Programm und
vor allem die Steuerung gegeben. Die einzelnen Probleme wurde nicht vorgestellt.
Sollten die Ergebnisse bei einigen Problemen keinen oder einen geringen Lernerfolg nachweisen, kann durch eine vorherige Vorstellung der Probleme und einer
Lösungsstrategie der Erfolg gesteigert werden.
Die Schülerinnen und Schüler hatten insgesamt 50 Minuten Zeit mit dem Programm
zu arbeiten. Anschließend füllten sie die Fragebögen aus.
Da es meist acht Auswahlmöglichkeiten gab, werden die Ergebnisse auch in acht
Stufen dargestellt. Beachtet wurden nur die Durchschnittswerte, die sich bei den
jeweiligen Fragen ergaben. Dabei ist der Wert 8 der „beste“ und 1 der „schlechteste“32 . Interessante Anmerkungen sollen ebenfalls in der Auswertung berücksichtigt
werden.
1.1 Würden Sie sagen, dass Sie durch das Programm etwas gelernt haben (viel/
wenig)[1]?
Die erste Frage, die einen besonderen Stellenwert für die Bewertung der Software
hat, wurde im Durchschnitt mit 3,8 bewertet. Dabei ist diese subjektive Einschätzung der Teilnehmer schlechter als der tatsächliche Lernerfolg, der in der Fragen zu
den einzelnen Problemen gemessen wird, und unterscheidet sich bei den einzelnen
Schülerinnen und Schüler recht stark (Standardabweichung 1,58).
Dies könnte daran liegen, dass diese ungewöhnliche Lernform noch keine große
Akzeptanz hat. Bezeichnend ist dabei die Anmerkung einer Schülerin oder eines
Schülers, die oder der die schlechteste Antwort ankreuzte und bemerkte, dass er
nichts gelernt habe, weil er ja alles selber machen musste. Hier wird deutlich, dass
Lernen für einige Schülerinnen und Schüler sehr eng mit passiven Methoden wie
Zuhören oder Abschreiben verknüpft ist und kein konstruktives und/ oder selbstgesteuertes Lernen in Betracht gezogen wurde.
32
Antwortmöglichkeiten werden jeweils in Klammern dargestellt
6
EVALUATION
77
Abbildung 37: Ergebnisse des ersten Teils. Mittelpunkt der Linien sind die Durchschnittswerte, die Linien stellen die Standardabweichung dar.
1.2 Wie beurteilen Sie das Programm im Ganzen (sinnvoll/ weniger sinnvoll)[-]?
Mit der zweiten Frage sollten die Schülerinnen und Schüler das Programm einschätzen. Da das Programm ein Lernprogramm ist, sollte die Einschätzung stark von der
Beurteilung der ersten Frage abhängen. Tatsächlich wurde die Frage im Schnitt mit
4,4 bewertet, die Standardabweichung beträgt 1,33 und ist damit etwas homogener.
Lernerfolg und Sinn des Programms wurde von den Schülerinnen und Schüler also
etwas kritisch eingeschätzt.
1.3 Wie beurteilen Sie den Entwicklungsstand des Programms (verbesserungswürdig/ komplett)[2]?
Auch die dritte Frage sollte wieder einen subjektiven Eindruck erfassen. Die Bewertung fiel mit einem Ergebnis von 5,25 recht positiv und mit einer Standardabweichung von 1,25 relativ homogen aus. Daraus könnten man schlussfolgern, dass
einigen Schülerinnen und Schülern zwar Bedienschwierigkeiten und Programmfehler aufgefallen sind, aber die Anzahl gering war.
1.4 Fanden Sie, dass die Grafik im Allgemeinen und besonders die Animationen
6
EVALUATION
78
hilfreich für das Verstehen und das Lösen der Probleme war (nicht hilfreich/ sehr
hilfreich) [2]?
Diese Frage wurde sehr positiv beantwortet (6,1), wobei eine Schülerin oder ein
Schüler hier nur einen Punkt vergab, weshalb die Standardabweichung mit 1,64
recht hoch ausfiel. Damit zeigte sich aber, dass die Animationen den Lernerfolg
sehr gut steigern konnten und von den Schülerinnen und Schülern (intuitiv) als Anhaltspunkt genutzt wurde, welche Änderungen sie an ihren Lösungen vornehmen
mussten.
1.5 Wie angemessen finden Sie die Steuerung (sehr angemessen/ nicht angemessen)[2]?
Die Frage 1.5 fiel ebenfalls sehr positiv aus (6,2), die Standardabweichung war
sehr gering (0,95). Daraus lässt sich schlussfolgern, dass die Wahl von gewohnten
Bedienelemente richtig war.
1.6 Für wie wichtig halten Sie das Thema Verteilte Systeme für die Schule (sehr
wichtig/ unwichtig)[2]?
Das Thema Verteilte Systeme für die Schule wurde von den Schülerinnen und Schülern als durchaus wichtig beurteilt (5,9). Daraus lässt sich zumindest schlussfolgern,
dass der erste Teil des Unterrichts, die allgemeine Einführung einen motivierenden
Charakter hatte. Wahrscheinlich ist aber auch, dass durch die Nutzung des Programms, dem Kennenlernen einiger Probleme in Verteilten Systemen und durch
die konstruktive Auseinandersetzung mit diesen Problemen eine Bedeutung für die
Schule erkannt wurde, was besonders erfreulich ist, da es nicht immer einfach ist,
Schülerinnen und Schüler für bestimmte Inhalte zu motivieren.
Im zweiten Teil des Fragebogens sollte der tatsächliche Lernerfolg bei den Schülerinnen und Schülern überprüft werden.
Verlorene Nachrichten
Als Erfolg zu betrachten ist zunächst die Tatsache, dass die Relevanz des Problems
6
EVALUATION
Abbildung 38: Lernerfolg der Schülerinnen und Schüler
Abbildung 39: Herstellen eines Praxisbezugs zum Problem
79
6
EVALUATION
80
mit 6,7 sehr hoch eingeschätzt wurde (Standardabweichung 0,78). Dabei ist natürlich zu bemerken, dass weniger komplexe Probleme und Lösungen sicher intuitiv
relevanter erscheinen. Zehn Schülerinnen und Schüler haben das Problem bearbeitet. Zwei Schülerinnen und/ oder Schüler vermerkten, dass die Zeit nicht mehr ausreichte um die Problembearbeitung fortzusetzen.
Die Lösung wurde fünfmal korrekt und dreimal unvollständig erfasst, zwei Schülerinnen und/ oder Schüler schrieben keine Lösungsskizze. Der Praxisbezug als
Transferleistung, die eigentlich nicht durch das Programm oder den Unterricht vermittelt wurde, wurde von drei Schülerinnen und Schüler vollständig und ebenfalls
von drei Schülerinnen und Schülern teilweise erfasst. Viermal wurde kein (sinnvoller) Praxisbezug hergestellt. Zu den Ergebnissen ist allgemein zu bemerken, dass die
Motivation der Schülerinnen und Schüler zum (gewissenhaften) Ausfüllen der Fragebögen sicher gering war. Dadurch wurden die Ergebnisse sicher etwas verfälscht.
Im Durchschnitt wurden weniger als fünf Minuten zur Lösung des Problems benötigt.
Gefälschte Nachrichten
Auch für das Problem der gefälschten Nachrichten wurde die Relevanz als sehr
hoch eingeschätzt (6,9). Insgesamt haben acht Schülerinnen und Schüler angegeben, das Problem bearbeitet zu haben. Da ein Schüler den Fragebogen aber nicht
weiter ausgefüllt hat, entfällt dieser Fragebogen bei der Auswertung.
Überraschend war, dass der Lernerfolg höher war als bei dem Problem der verlorenen Nachrichten. So gaben sechs Schülerinnen und Schüler eine korrekte Lösung
wieder und haben ganz oder teilweise einen guten Praxisbezug herstellen können.
Die Bearbeitungsdauer war im Allgemeinen sehr gering (zwischen zwei und fünf
Minuten), eine Schülerin oder ein Schüler brauchte etwa eine halbe Stunde.
Mitgelesene Nachrichten
Das Problem der mitgelesenen und nicht-authentischen Nachrichten wurde von
zwölf Schülerinnen und Schüler bearbeitet, wobei eine Schülerin oder ein Schülern
6
EVALUATION
81
wieder keine weiteren Angaben machte und lediglich eine Relevanzeinschätzung
abgab, weshalb ihre oder seine Wertung nicht mit in die Durchschnittsbetrachtung
einfliesst. Wie schon bei den vorangegangenen Problemen erschien den Schülerinnen und Schülern das Problem erfreulicherweise als sehr relevant (6,6), die Streuung der Werte war relativ gering (1,18). Eine hohe Relevanzeinschätzung lässt immer vermuten, dass die Schülerinnen und Schüler das Problem erfasst und in seiner
Bedeutung reflektiert haben.
Auch der Lernerfolg ist wieder gut. Sieben Schülerinnen und Schüler haben die
Lösung komplett erfasst, zwei teilweise und einer oder eine nicht. Einen sinnvollen Praxisbezug konnten vier Schülerinnen und Schüler ganz und ebenfalls vier
teilweise korrekt herstellen. Dreimal gelang dies nicht oder wurde nicht versucht.
Auch diese Ergebnisse sind sehr erfreulich. In der Stunde gab es jedoch ein Problem
mit dem öffentlichen Verschlüsselungsverfahren. Hier war nicht genau klar, was gemacht werden musste bzw. wozu ein öffentlicher Schlüssel dient. Weiterhin war es
problematisch, dass die Problembeschreibung nicht verständlich machte, dass die
Nachrichten auch einem Absender sicher zugeordnet werden müssen. Im Schnitt
wurden zehn Minuten zur Problemlösung benötigt, wobei eine Schülerin oder ein
Schüler den Schnitt deutlich hob, da sie oder er 40 Minuten brauchte.
Unterschiedliche Nachrichtenreihenfolge
Nur fünf Schülerinnen und Schüler bearbeiteten das Problem der unterschiedlichen
Nachrichtenreihenfolge. Davon machte zwei Schülerinnen und Schüler wieder keine Angaben, weshalb die Daten nicht in die Betrachtungen einfliessen. Bei der Bearbeitung des Problems gab es größere Probleme, was sich auch in der Relevanzbetrachtung niederschlägt (5,0). Hier waren die Ansichten auch recht differenziert
(Standardverteilung 1,79).
Nur zwei Schülerinnen und Schüler machten konkrete Zeitangaben (fünf bzw. zehn
Minuten) für die Lösungsdauer. Ein Proband konnte die Lösung korrekt, ein anderer teilweise skizzieren, einmal gelang dies gar nicht. Zweimal wurde ein schwacher
Praxisbezug hergestellt, einmal keiner. Die Ergebnisse sind natürlich nicht erfreu-
6
EVALUATION
82
lich. Das Problem scheint auf den ersten Blick zu komplex und demotiviert damit
etwas. Lösungen für dieses Problem werden im nächsten Kapitel diskutiert.
Gemeinsam genutzte Ressource
Ähnliche Ergebnisse ergab das Problem der gemeinsam genutzten Ressourcen. Hier
bearbeiteten ebenfalls nur fünf Schülerinnen und Schüler das Problem. Nur einmal
wurde eine Zeit angegeben (15 Minuten), was darauf schließen lässt, dass die anderen das Problem nicht lösen konnten. Die Relevanz wurde wieder differenziert, aber
insgesamt niedrig bewertet (4,8), was daran liegen könnte, dass das Problem nicht
im vollem Umfang erfasst worden ist.
Erstaunlicherweise konnte mehrmals ein sinnvoller Praxisbezug zugeordnet werden
(dreimal), eine Lösungsskizze wurde nur zweimal in Ansätzen korrekt angefertigt.
Auch für dieses Problem scheint zu gelten, dass es den Schülerinnen und Schüler
als zu komplex erschien.
Weitere Ergebnisse der Befragung
Einige Programmfehler sind den Schülerinnen und Schülern aufgefallen, die notiert
und behoben wurden. Die Bedienung bereitete entgegen der Auswertung der Frage
1.5 einige Schwierigkeiten, die ebenfalls zu behoben worden. Die relativ niedrigen
Anforderungen an die Hardware konnten die Schule mit einem gut ausgestatteten
Computerkabinett erfüllen. Es ist davon auszugehen, dass ältere Computer für den
Aufbau der Grafik etwas länger brauchen, aber es ansonsten wenige Probleme geben sollte.
6.1.4
Schlussfolgerung aus den Ergebnissen
Die Ergebnisse sind im Ganzen betrachtet als erfolgreich zu bezeichnen. Die offenkundigen Probleme, die es gab, lassen sich leicht beheben. Merkwürdig ist, dass
die Schülerinnen und Schüler den Lernerfolg relativ schlecht einschätzten, aber die
Auswertung des zweiten Teils bei drei Problemen sehr erfreuliche Ergebnisse ver-
6
EVALUATION
83
muten ließ. Lediglich die Frage, ob auch alle Werkzeuge korrekt verstanden worden
sind, konnte nicht erfasst werden.
Ansonsten wurden auch die meisten Annahmen bestätigt. Ein Lernerfolg kann nur
durch einen begleiteten Unterricht sichergestellt werden, der vor allem motivierend
in das Thema einführt und gleichzeitig das Programm erklärt. Der zweite Teil ist
in der Teststunde leider nicht gelungen, weshalb zu viel Zeit mit individuellen Erklärungen verschwendet wurde. Der zeitliche Rahmen von 90 Minuten ist ebenfalls
realistisch, wenn keine 20-minütige Befragung stattfindet. Dann sollten alle Schülerinnen und Schüler die drei einfachen und die besseren auch eins von den beiden
komplexeren Themen bearbeiten können.
Wenn man sicherstellen will, dass alle Probleme und deren Lösungen nachhaltig
von den Schülerinnen und Schüler verstanden werden, wäre auch eine dritte Unterrichtsstunde sinnvoll, damit vor allem die komplexen Themen sowie das Funktionieren des Public-Key-Verfahrens intensiver behandelt werden können.
Die Probleme der unterschiedlichen Nachrichtenreihenfolge und der gemeinsam genutzten Ressource müssten für den Einsatz in der Schule etwas überdacht werden.
Da es schwierig ist, die Probleme zu splitten oder angemessen zu reduzieren, sollten
sie anders in den Unterricht eingebaut werden. Denkbar wäre eine Erläuterung oder
Erarbeitung des Problems mit Praxisbezug und eine Lösungsskizze. Dann sollten
auch die meisten Probleme im Umgang mit den Plugins behoben werden können.
Dazu könnten auch entsprechende Materialien zur individuellen Arbeit bereitgestellt werden.
Weiterhin sollte der Einsatz der Software in der Regel erst in der elften oder zwölften Klassen stattfinden, was bessere Ergebnisse ermöglichen sollte.
6
6.2
EVALUATION
84
Schwächen der Lösung
Vergleicht man die dargestellten Forschungsergebnisse und die tatsächliche Implementierung, gibt es natürlich einige Schwächen, die hier diskutiert werden sollten.
Die Grafik des vorliegenden Projekts entspricht nicht modernen 3D-Welten in aktuellen Computerspielen. Eine solche Entwicklung war im Rahmen dieser Arbeit aber
auch nicht möglich. Fraglich ist auch, ob in solchen 3D-Welten der Lerngegenstand
tatsächlich besser und motivierender umgesetzt werden könnte. Immerhin müssen
ja Algorithmen modelliert werden, wenn auch auf einer abstrakten Ebene.
Weiterhin bietet die Software keine sozialen und nur sehr eingeschränkte parasoziale Lernprozesse. Für Themen aus dem Bereich der Informatik sind sicher kooperative Lernformen in Spielwelten denkbar, die aber ebenfalls eine längere Entwicklungszeit benötigen würden. Das Design der parasozialen Charaktere wie dem
Bürgermeister könnte auch tiefer gehen und z.B. über Emotionen bestimmte Systemzustände verstärkt darstellen.
Es fehlt außerdem ein Tutorial zur Bedienung des Programms und zur Einführung
in die Spielwelt sowie in die Thematik der Verteilten Systeme, was helfen könnte,
die Software unabhängiger von einem einbettetenden Unterricht zu machen.
Bei der Darstellung der Algorithmen ist es bisher möglich „wenn- dann- Konstrukte“ einzubauen. Allerdings werden Werkzeuge, die auf eine solche Bedingung folgen, entweder ausgeführt oder nicht. Bisher ist noch keine Implementierung vorhanden, die z.B. einen alternativen Pfad von Werkzeugen ausführbar macht. Komplexere Werkzeuge werden in der bisherigen Lösung zwar textuell beschrieben, eine
grafische Beschreibung in Form eines Ablaufsdiagramms wäre aber ebenfalls denkbar gewesen.
Zu den Problemen ist nur soviel zu sagen, dass die beiden komplexeren Plugins
(Inkonsistent-Werden einer gemeinsamen Ressource und unterschiedliche Nachrichtenreihenfolge) durch weitere Parameter ergänzt werden könnten um sie allgemeiner darzustellen. Bisher wurde nur ein bestimmtes, eingeschränktes Szenario
6
EVALUATION
85
erarbeitet. Außerdem könnte die Komplexität zu hoch sein, was sich im Schulversuch bereits andeutete. Um dieses Problem zu umgehen, wurden Lösungsvorschläge
erarbeitet.
6.3
Stärken der Lösung
Soweit es im Rahmen der Arbeit möglich war, wurden aktuelle Forschungsergebnisse zu Lernsoftware und Lernen mit Computerspielen umgesetzt, um Schülerinnen,
Schülern und anderen Lernenden einen schnellen und motivierenden Einstieg in
grundlegende Probleme Verteilter Systeme zu ermöglichen. Verglichen mit anderen
Projekten, hat das vorliegende Projekt einige Stärken.
Die Software ermöglicht den Nutzern mit einfachen Mitteln, komplexe Algorithmen
nachzubilden, was bei allen anderen Anwendungen, die im Rahmen dieser Arbeit
vorgestellt wurden, nicht der Fall ist. Die Nutzer werden dabei unterstützt, indem
sie in den Animationen nachvollziehen können, in welchem Zustand ihre Lösung
ist und was sie vielleicht noch abändern müssten. Der Schulversuch machte deutlich, dass diese generischen Animationen sehr gut angenommen wurden. Durch den
simulierenden Charakter des Projekts kann nachvollzogen werden, welche Werkzeuge welchen Einfluss auf das Problem haben. Mit einfachen Werkzeugen, die in
der Regel schon vom Namen her ihr Funktionieren erkennen lassen, können diese
Algorithmen einfach, explorativ und selbstständig verstanden werden.
Schülerinnen und Schüler können komplexe Zusammenhänge mit der Software erlernen (Handlungswissen) und nicht eben nur einfache Fakten, was auch der Schulversuch verdeutlichte. Außerdem sind die Handlungen, die die Nutzer auszuführen
haben, am eigentlichen Problem orientiert. Das Lernen findet weiterhin in einem
explorativen und daher angstfreien Zusammenhang statt. Der Anwender kann beliebige Konfigurationen ausprobieren ohne Angst vor Fehlern oder Blamage haben
zu müssen. Motivierend sollen auch die Punkte wirken, die ein Nutzer sammeln
kann.
6
EVALUATION
86
Das Rahmenwerk wurde so gestaltet, dass das Programm für sehr viele Probleme
in der nachrichtenbasierten Kommunikation verwendbar ist. Wie das Beispiel der
quoren-basierten Konsistenz zeigt, können auch komplexere Probleme mit der Software modelliert werden. Plugins, die weitere Probleme simulieren, können schnell
und einfach erstellt und in das Hauptprogramm eingebunden werden. Die vorgegebene Struktur macht Teile der konzeptionellen Arbeit überflüssig.
Die Software ist weiterhin plattformunabhängig und kann auch auf älterer Hardware
problemlos eingesetzt werden.
6.4
Anwendungsmöglichkeiten
Durch den Einsatz der Software sind verschiedene Anwendungsszenarien bereits
vorgegeben. Am besten eignet sich der Einsatz in der Schule mit einem begleitenden Unterricht, der kurz benennt, was Verteilte Systeme sind und warum sie für
Schülerinnen und Schüler von Bedeutung sind, die prinzipielle Programmsteuerung
und das Ziel der Software vorstellt und auch eine Auswertung des Erlernten nach
dem Einsatz der Simulation sicherstellt.
Denkbar ist aber auch, dass die Simulation im Rahmen eines Selbststudiums genutzt
werden kann. Dort müssten die Grundlagen für das Verstehen der Probleme selbst
erarbeitet werden und in einer Auswertungsphase müssten die Probleme und ihre
Lösungen noch einmal recherchiert werden. Dann könnte das Programm auch als
Grundlage für Hausaufgaben, Schülervorträge, -projekte oder -geleiteten Unterricht
eingesetzt werden.
6.5
Ausblick
Eine Weiterentwicklung des Projekts bietet sich in erster Linie durch weitere Plugins an, die Probleme der nachrichtenbasierenten Kommunikation darstellen können.
Wenn man Selektionen und eventuell Schleifen in das Projekt einbinden würde,
6
EVALUATION
87
könnten sehr viele, auch komplexere Probleme einfach und schnell in die Spielwelt
aufgenommen werden. Für eine Großzahl von Problemen reichen aber die jetztigen
Möglichkeiten aus.
Es bietet sich natürlich auch an, ein Tutorial zu ergänzen sowie weitere Begleitmaterialien zu erstellen, die den Schuleinsatz auch für die Lehrenden effizienter gestalten würden bzw. einen Einsatz ohne begleitenden Unterricht ermöglichen. Dazu
sollten auch weitere Versuche in Schulen stattfinden, die mehr evaluieren als die
prinzipielle Eignung als Lernsoftware, unterrichtspraktische Fragen und eine knappe Evaluation der einzelnen Plugins.
Basierend auf Teilen des bisherigen Konzepts könnte das Projekt für soziale Lernprozesse ausgebaut werden. Dafür könnten die Probleme durch geschickte Kombination von Teilproblemen oder durch Ausdifferenzierung erschwert werden. Die
Rolle des Technikers, in die der Nutzer bisher schlüpft, müsste ebenfalls konzeptionell erweitert werden. Denkbar wären etwa in Anlehnung an beliebte Computerspiele die Entwicklung unterschiedlicher Eigenschaften und Stärken von verschiedenen Nutzern und/ oder zwei Teams, die gegeneinander wettstreiten. Um echtes
soziales Lernen zu ermöglichen, wären Problemlösungen nur durch Kooperationen
und Wissensteilung und -zusammenführung zu ermöglichen.
7
7
ZUSAMMENFASSUNG
88
Zusammenfassung
Wie die Arbeit gezeigt hat, werden Verteilte Systeme in Zukunft an Bedeutung gewinnen und möglicherweise ein Thema für den Informatikunterricht sein. Das vorliegende Projekt zeigt eine Möglichkeit auf, wie diese Systeme unterrichtet werden
könnten. Neben dem Einsatz dieser Software sollte das Programm eingebettet in
„klassischen“ Unterricht verwendet werden.
Das vorliegende Projekt wurde unter Einbeziehung aktueller, pädagogischer und didaktischer Forschungsergebnisse als spielorientierte Lernsoftware zum Thema Verteilte Systeme entwickelt, die Lernende dabei unterstützen soll, die recht komplexen
Algorithmen und Verfahrensweisen zur Lösung grundlegender Probleme in Verteilten Systemen zu erlernen.
Dabei wurde auch auf die Verwendung von aktuellen Technologien und sog. ehrlichen Lösungen geachtet, die zwar die Komplexität bestimmter Probleme und deren
Lösungen reduzieren, sie aber nicht falsch darstellen. Die Software ist erweiterbar,
sodass weitere Module schnell und einfach hinzugefügt werden können.
In Schulversuchen wurde gezeigt, dass ein unterrichtspraktischer Einsatz möglich
und sinnvoll ist. Die Software kann Lehrpersonen entlasten, ermöglicht den Einsatz
einer innovativen Lernmethode und sichert den Lernerfolg zum Beispiel durch Animationen, die den Lösungszustand von Problemen erkennen lassen. Im Vergleich
zu anderen Lösungen können insbesondere die Algorithmenorientierung, die Explorativität, das Darstellen komplexer Lernvorgänge sowie das Handlungswissen,
das mit Hilfe der Software aufgebaut werden kann, hervorgehoben werden.
LITERATURVERZEICHNIS
89
Literaturverzeichnis
[ABD+ 07a] A SSCHOFF, A. ; BADE, J. ; D ITTICH, C. ; G ERDING, T. ; H ASS LER ,
N. ; K LEBERT, J. ; W EYER, M.: Abschlussbericht Projektgrup-
pe FILIUS. <http://www.die.informatik.uni-siegen.
de/pgfilius/download/Benutzungshandbuch.pdf> am
11.03.08, 2007
[ABD+ 07b] A SSCHOFF, A. ; BADE, J. ; D ITTICH, C. ; G ERDING, T. ; H ASS LER ,
N. ; K LEBERT, J. ; W EYER, M.: Handbuch der Projektgrup-
pe FILIUS. <http://www.die.informatik.uni-siegen.
de/pgfilius/download/Benutzungshandbuch.pdf> am
11.03.08, 2007
[AP94]
A AMODT, A. ; P LAZA, E.: Case-Based Reasoning: Foundational Issues, Methodological Variations, an System Approaches. In: AICOM
7 (1994), S. 39–59
[Bau97]
BAUMGARTNER, P.: Evaluation vernetzten Lernens. In: Virtueller
Campus. Forschung und Entwicklung für neues Lehren und Lernen
(1997), S. 131–146
[BeioJ]
B EILER, H.:
go?
Where in the World is Carmen Sandie<http://www.longplays.de/longplays/
w/whereintheworldiscarmensandiego/
carmensandiego.htm> am 01.04.2008, o.J.
[Ben04]
B ENGEL, G.: Verteilte Systeme. 3. Aufl. Wiesbaden : Viehweg Lehrbuch, 2004
[Ber07]
B ERNDT, E.: Warum die Werkzeug-Metapher in Bildungsprozessen
in die Irre führt. In: OBST - Osnabrücker Beiträge zur Sprachtheorie
72 (2007), S. 109–133
[BeroJ]
B ERNATH, U.: Qualitätsaspekte des eLearnings. o.J.
[BGH+ 00]
90
B URGER, H. ; G ALATA, R. ; H ECHENLEITNER, A. ; K REISEL, K. ;
L EPPMEIER, M. ; L IESSEL, W. ; W IEDEMANN, A.: Informatik und
Schule. Schwerpunkte, Hinweise auf Materialien, Informationsquellen. Augsburg, 2000
[Bi007]
F. A. B ROCKHAUS AG, Bibliographisches I. (Hrsg.): Simulation.
<http://lexikon.meyers.de/meyers/Simulation> am
17.03.08, 2007
[Bop06]
B OPP, M.: Didactic Analysis of Digital Games and Game-based Learning. In: P IVEC, M. (Hrsg.): Affective and Emotional Aspects of
Human-computer Interaction: Game-based and Innovative Learning
Approaches: The Future of Learning. Amsterdam, 2006, S. 8–37
[BP99]
BAUMGARTNER, P. ; PAYR, S.: Lernen mit Software. Digitales Lernen. Innsbruck : Österreichischer StudienVerlag, 1999
[Bre95]
B REZINKA, W.: Der Gegenstand der Erziehungswissenschaft und
die Aufgabe der erziehungswissenschaftlichen Forschung. In: Erziehungsziele, Erziehungsmittel, Erziehungserfolg. Beiträge zu einem
System der Erziehungswissenschaft. München : Ernst Reinhardt Verlag, 1995 (5), S. 15–42
[BöroJ]
B ÖRDLEIN, C.:
Eine Einführung in die Verhaltesanaly-
se [Manuskript].
<http://verhalten.org/dateien/
verhaltenbuch.pdf> am 02.03.08, o.J.
[Bru60]
B RUNER, J.S.: The process of education. Cambridge : Harvard University Press, 1960
[Con02]
C ONSORTIUM, World Wide W.:
ge (XML) 1.0.
Extensible Markup Langua-
2. Aufl., deutsche Übersetzung von Stefan
Mintert. <http://edition-w3c.de/TR/2000/REC-xml-20001006/> am
01.04.2008, 2002
[CURoJ]
91
CURE-Benutzerhandbuch.
<http://teamwork.
fernuni-hagen.de/CURE/doc/manual.html>
am
16.03.08, o.J.
[Ede96]
E DELMANN, W.: Lernpsychologie. 5. Aufl. Weinheim, 1996
[EWJR08]
E GGER, D. ; W ERNICKE, A. ; J OOST, R. ; R EINHARDT, M.: GNU
Image Manipulation Program. Benutzerhandbuch. 2002-2008
[Fre06]
F REITAS, S. de:
Learning in Immersive Worlds. A review of
game-based learning.
<http:\\www.jisc.ac.uk/media/
documents/programmes/elearninginnovation/
gamingreport_v3.pdf> am 15.03.08, 2006
[GanoJ]
G ANIMAL: GANIMAL Homepage. <http://rw4.cs.uni-sb.
de/projects/ganimal/> am 04.05.08, o.J.
[Hol03]
H OLTKAMP, H.:
Einführung in TCP/IP.
<http://www.
rvs.uni-bielefeld.de/~heiko/tcpip/tcpip.pdf> am
13.03.08, 1997-2003
[HPE+ oJ]
H ELLWEG, Matthias ; P LIENINGER, Frank ; E NGELS, Volker ;
G RASSE, Thomas ; R ASEL, Martin ; D ENTLER, Kathrin ; B RANDTNER ,
Christian:
Fountain of Wisdom: Technische Dokumentation.
<http://kalu.fernuni-hagen.de/downloads/FaPra_
04_05/Technische_Dokumentation_FlOW.pdf>
am
16.03.08, o.J.
[HS07]
H EPTNER, L. ; S CHNARRENBERGER, F.:
Spielbasiertes Ler-
nen und gemeinsame Wissenskonstruktion.
In: F ERNUNIVER -
SITÄT
H AGEN, Juniorprofessur für Verteilte Lernsysteme und
kooperative Arbeits-/Lernumgebung der Fakultät für Mathematik und Informatik d. (Hrsg.): Gemeinsame Wissenskonstruktion.
<kalu.fernuni-hagen.de/downloads/1915_SS_
07.pdf> am 12.03.08, 2007, S. 29–42
[Hui87]
92
H UIZINGA, J.: Homo ludens. Vom Ursprung der Kultur im Spiel.
Reinbek bei Hamburg : ANPASSEN, 1987
[Hun08]
H UNTER, J.: JDOM: FAQ. <http://www.jdom.org/docs/
faq.html> am 01.04.2008, 2008
[Ker01]
K ERRES, M.: Multimediale und telemediale Lernumgebungen. Konzeption und Entwicklung. 2. Aufl. Oldenburg : Oldenbourg, 2001
[Ker03]
K ERREN, A.: Exploratives Lernen mit partiell generierter Lehr- und
Lernsoftware. <http://www.ads.tuwien.ac.at/people/
kerren/pubs/kerren-gml03.pdf> am 04.05.08, 2003
[Koh04]
KOHL, L.: Entwurf und Implementierung einer visuellen Programmiersprache für den Einsatz in Schulen (Diplomarbeit). 2004
[Kri08]
K RINGIEL, D.:
das Spielen bei.
Games in der Schule. Lehrer bringen Schülern
<http://www.spiegel.de/netzwelt/
spielzeug/0,1518,550345-4,00.html> am 04.05.2008,
2008
[KSJ06]
K RISTÖFL, H. ; S ANDTNER, M. ; JANDEL, H.:
Qualitätskriteri-
en für E-Learning. Ein Leitfaden für Lehrer/innen, Lehrende und
Content-Ersteller/innen.
<www.e-teaching-austria.at/
download_mat/Qualitaetskriterien.pdf> am 15.03.08,
2006
[Ku003]
K ULTUSMINISTERKONFERENZ (Hrsg.): Einheitliche Prüfungsanforderungen Informatik. 2003
[KW06]
K RAPP, A. ; W EIDENMANN, B.: Pädagogische Psychologie. 5. Aufl.
Basel : Psychologische Verlags Union, 2006
[Lef06]
L EFRANCOIS, G. R.: Psychologie des Lernens. 3. Aufl. Berlin :
Springer, 2006
[LP99]
93
K ULTUSMINISTERIUM, Thüringer (Hrsg.): Lehrplan für das Gymnasium. Informatik. Erfurt : <http://www.thillm.de/thillm/
pdf/lehrplan/gy/gy_lp_if.pdf> am 30.04.08, 1999
[Maa94]
M AASS, S.: Maschine, Partner, Medium, Welt... Eine Leitbildgeschichte der Software-Ergonomie.
In: H ELLIGE, H. D. (Hrsg.):
Leitbilder der Informatik- und Computer-Entwicklung (Tagungsband)
Bd. 33. 1994
[oAoJ]
OA:
Foundation of Wisdom - Ein interaktives Lernspiel in Cure.
Benutzerhandbuch.
<http://kalu.fernuni-hagen.de/
downloads/FaPra_04_05/Fountian_of_Wisdom.pdf>
am 16.03.08, o.J.
[Pfi00]
P FITZMANN, A.:
Sicherheit in Rechnernetzen: Mehrseitige Si-
cherheit in verteilten und durch verteilte Systeme.
Karlsruhe,
Hildesheim, Dresden : <http://dud.inf.tu-dresden.de/
~pfitza/DSuKrypt.pdf> am 02.05.08, 1999-2000
[RSA78]
R IVEST, R. ; S HAMIR, A. ; A DLEMAN, L.: A Method for Obtaining
Digital Signatures and Public Key Cryptosystems. In: Commun. ACM
21 (1978), Nr. 2, S. 120–126
[SM08]
S UN
M ICROSYSTEMS,
Inc.:
<http://java.sun.com/products/javahelp/>
JavaHelp
am
02.04.2008,
System.
1994-
2008
[SS04]
S CHUBERT, S. ; S CHWILL, A.: Didaktik der Informatik. München :
Spektrum, 2004
[Sun06]
S UNNEN, P.: Lernprozesse am Computer. Theoretische und emirische Annäherungen. Frankfurt a.M. : Europäischer Verlag der Wissenschaften, 2006
[Tan03]
TANNENBAUM, A.: Computernetzwerke. München : Pearson Studium, 2003
[TS03]
94
TANNENBAUM, A. ; S TEEN, M. van: Verteilte Systeme - Grundlagen
und Paradigmen. München : Pearson Studium, 2003
[Ull06]
U LLENBOOM, C.: Java ist auch eine Insel. 5. Aufl. Bonn : Galileo
Press, 2006
[Ull07]
U LLENBOOM, C.: Java ist auch eine Insel. 6. Aufl. Bonn : Galileo
Press, 2007
[Win04]
W INKLER, W.: Probleme schnell und einfach lösen. 99 Lösungswerkzeuge. Frankfurt a. M. : Moderne Verlagsgesellschaft, 2004
[WR02]
W ILLIGE, M. ; RÜB, H.: Zur Evalution von Online-Lernprogrammen.
Hamburg : Institut für berufliche Bildung, Arbeitsmarkt- und Sozialpolitik, 2002
Erklärung
Ich erkläre, dass die vorliegende Arbeit selbstständig und nur unter Verwendung der
angegebenen Literatur und Hilfsmittel verfasst habe.
Sämtliche Stellen, die anderen Werken entnommen sind, wurde unter Angabe der
Quelle als Entlehnung kenntlich gemacht.
Jena, den 03.06.2008
95
A
TECHNISCHE DOKUMENTATION
96
Abbildung 40: UML-Diagramm 1: Systemübersicht
A
A.1
Technische Dokumentation
Beschreibung der Systempakete
Das Projekt ist grob in zwei Teile gegliedert. Zum Einen wurde ein Rahmenwerk
(Framework) geschaffen, welches die wichtigsten Systemkomponenten enthält und
eine möglichst einfache Entwicklung von zusätzlichen Funktionalitäten ermöglichen soll. Zum Anderen gibt es verschiedene Plugins, die Probleme in Verteilten
Systemen abbilden und mögliche Lösungsstrategien erlernbar machen.
A.1.1
Der Systemkern: systemcontrol
Der Systemkern hat die Aufgabe, grundlegende Funktionalitäten für das System und
Schnittstellen für die anderen Pakete bereitzustellen. Die Klasse SystemCore enthält
die main-Methode und initialisiert die notwendigen Programmfunktionalitäten. In
der Klasse werden zunächst ein Psydo-Problem (SystemSimulation), längere Hilfstexte und die System-Oberfläche (GUI) geladen. Zudem werden .xml-Dateien analysiert, die Plugin-Informationen bereitstellen. Neben der System-GUI baut sich für
den Benutzer sichtbar auch ein weiteres Fenster auf, welches einen Begrüßungstext
darstellt.
A
97
Abbildung 41: UML-Diagramm 2: Systemsteuerung und -verwaltung
Neben diesen sequentiellen Funktionen, die die Klasse bereitstellt, ist sie auch Schnittstelle zwischen und zu verschiedenen anderen Systemkomponenten. Dies betrifft in
erster Linie Methoden, die zwischen Problemen/ Plugins und der System-GUI vermitteln. Außerdem verwaltet die Klasse verschiedene Systemzustände. Diese sind:
Problem aktiv, kein Problem aktiv oder alle Probleme gelöst.
Eine Unterklasse von SystemCore ist DelaySelcter, die lediglich für ein zeitverzögertes Auswählen eines Problems verantwortlich it. Trotz der geringen Funktionalität musster die Klasse eigenständig implementiert werden, da ansonsten die Auswahl die Systemoberfläche blockiert hätte. Weiterhin befindet sich im systemcontrol-Paket die Klasse FileIO, die für Datenoperationen verantwortlich ist. Sie sucht
nach Plugins im Plugin-Ordner (Vgl. S. 97 Abb. 41).
A
A.1.2
98
Das systemcontrol.runtime-Unterpaket
Im Paket systemcontrol befindet sich das runtime-Unterpaket, das aus drei Klasse besteht. ScoreCount realisiert die Zählung der Punkte. Dabei kann ein Problem
Punkte addieren oder subtrahieren. Außerdem kann ein Pausezustand gesetzt werden, der zur Folge hat, dass die keine Punkteoperationen mehr durchgeführt werden
können.
In GameData werden alle Statusinformationen zusammengefasst und Schnittstellen für das Bereitstellen dieser Informationen für andere Klassen bereitgestellt. Die
Spieldaten sind dabei der aktuelle Punktestand sowie eine Liste von gelösten Problemen. Damit diese beiden spielrelevanten Daten nicht (einfach) per Texteditor
manipuliert werden können, wird GameData serialisiert als Objekt in eine Datei geschrieben. Da das Programm Plugin-fähig ist und die Auswahl der Plugins variabel
sein kann, macht es keinen Sinn, die Zustände eines Plugins zu speichern, da das
Problem bei einem anderen Programm nicht mehr vorhanden sein könnte.
systemcontrol.runtime stellt außerdem die Klasse PluginFinder bereit. Sie kann
über die Methode getPlugins() angesprochen werden. Diese ruft zuerst die Methode analyseDocs() auf, die mit Hilfe von systemcontrol.FileIO eine Liste von xmlPlugin-Dateien sucht. Anschließend werden die Plugin-Informationen mit Boolean
checkPlugin( String file ) geprüft. Dort werden die Simulations-, die Animationsund weitere Klassen (Komponenten, Nachrichtentypen und Stadien), die zu einem
Plugin gehören auf Vorhandensein und auf die Frage überprüft, ob die Klassen vorgegebene Interfaces implementieren. Ist dies der Fall, wird das Plugin anerkannt
und die Daten aus der xml-Datei in ein Objekt der Klasse Plugin geladen. Dies
besteht aus den Klassenpfaden und -namen und diversen Kurz- und/ oder Langbeschreibungen. Ein Feld von Plugin-Objekten wird dann an den Aufrufer zurückgegeben (Vgl. S. 99 Abb. 42).
A
99
Abbildung 42: UML-Diagramm 3: Laufzeitkomponenten zur Systemverwaltung
A.1.3
Das systemcontrol.runtime.simulation-Unterpaket
Jedes Problem simuliert den Austausch von Nachrichten und stellt außerdem eine Animation bereit. SystemSimulation in systemcontrol.runtime.simulation macht
dies ebenfalls. Dazu werden zunächst Instanzen der Agenten-Klasse als Threads erzeugt. Diese senden Nachrichten aneinander, was von SystemSimulation koordiniert
wird. Über die System-GUI kann dann die Simulation gestartet werden. Jetzt nehmen die Agenten ihre Arbeit auf und senden Nachrichten. Gleichzeitig wird eine
Thread-Instanz der Klasse DelaySelecter des Pakets systemcontrol erzeugt, welche
in einer festzulegenden Zeit ein Plugin/ Problem auswählt, das anschließend als aktuelles Problem (currentProblem) in SystemSimulation geladen wird (Vgl. S. 99
Abb. 42).
A.1.4
Systemwerkzeuge: util.xmlhandling
Das Paket util umfasst nur eine Klassen. XmlHandler stellt wie der Name schon
sagt, Funktionalitäten zur Auswertung von XML-Dateien bereit. Dabei wird zu-
A
100
Abbildung 43: UML-Diagramm 4: Systemwerkzeuge
nächst ein Parser geladen und anschließend die Anzahl der Knoten im Dokument
ermittelt. Als Schnittstellen für andere Klassen kann entweder ein String-Wert an
Hand eines Tag-Namen und einer Positionsnummer oder ein Feld von Stringwerten
zu einem gegebenen Tag geladen werden (Vgl. S. 100 Abb. 43).
A.1.5
Die Problemsimulation: problem
Das Paket problem untergliedert sich in drei Unterpakte. problem.ressourcemodel
stellt verschiedene Schnittstellen (Interfaces) für die Plugin-Programmierung bereit, problem.runtime enthält systemnahe Klassen zur „Verwaltung“ der Simulation
verantwortlich sind und problem.simulationmodel stellt verschiedene Klassen bereit, die die Kommunikation simulieren und in Form von abstrakten Klassen oder
Schnittstellen überschrieben werden müssen (Vgl. S. 101 Abb. 44).
A.1.6
Die Problem-Schnittstellen: problem.ressourcemodell
Das Interface Problemable ist der Kern der Problemsimulationen. Zu einem Problem gehört ein ProblemSolveTracker, Agenten-Objekte, ein Plugin-Objekt, Nachrichtentypen, funktionale Komponenten (FunctionComponents), Datenkomponen-
A
101
Abbildung 44: UML-Diagramm 5: das Problempaket
ten (DataComponents), eine Liste von Ereignissen und von Problemstadien. Dazu
kommen verschiedene getter-, adder- und setter-Methoden sowie das Herzstück,
die sendMessage( Message msg )-Methode, die das Kommunikationsproblem simulieren soll. Mit der Methode addEvent( Event event, Message msg) können neue
Ereignisse ausgelöst werden.
Mit der Schnittstelle Componentable können verschiedene Komponenten definiert
werden. Komponenten sind Werkzeuge oder Daten von Agenten, die die Kommunikation beeinflussen. Sie haben einen Namen. Im Interface FunctionComponentable werden funktionale Werkzeuge definiert. Sie stellen Methoden bereit, die das
Verhalten der Kommunikationspartner ändern. Eine funktionale Komponente kann
aktiv oder inaktiv sein. Außerdem kann einer funktionalen Komponente verschiedene Daten zugeordnet werden. Neben verschiedenen getter- und setter-Methoden
ist die operate( Message msg, Event event )-Methode das Kernstück einer jeden
Komponente, wo die eigentliche Funktionalität implementiert werden soll.
Die Schnittstelle DataComponentable wird wie FunctionComponentable ebenfalls
von Componentable abgeleitet. Ihr Herzstück ist keine Funktion, sondern ein bestimmter Wert value vom Typ Integer, eine Versionsnummer des Wertes (version)
A
102
und der Zugriffszustand isLocked, der angibt, ob auf die Komponente geschrieben
oder von der Komponente gelesen werden darf. Eine genaue Definition dieses Zustand muss in der jeweiligen Implementierung der Schnittstelle festgelegt werden.
In MessageType wird ein Interface bereitgestellt, welche die Definition verschiendener Nachrichtentypen ermöglicht. Jedem Nachrichtentypen werden zwei Events
zugeordnet: ein Sendungs- und ein Empfangsereignis. Außerdem kann ein Nachrichtentyp verschiedene Optionen haben. Das Interface Animable steht für die Animation, die dem Problem zugeordnet wird. Sie wird in der System-GUI gezeichnet
und stellt verschiedene Systemzustände grafisch dar. Aufgerufen wird eine Animation mit der Methode initPainting( Message msg ). Aus der Nachricht kann dann der
Sender, der Empfänger und der Nachrichtentyp abgeleitet werden. Eine ProblemImplementierung kann außerdem einer Nachricht einen Zustand zuordnen, womit
zum Beispiel ein Problem in der Kommunikation dargestellt werden kann.
Das letzte Interface ist das Statable-Interface. Ein Status überprüft, ob ein (Teil)Problem gelöst wurde und gibt entspricht einen Wahrheitswert zurück. In einer
Statable-Implementierung werden die Methoden operate, getState und getStateDescription definiert. operate( Message msg ) sollte beim Senden einer Nachricht in
der Problem-Klasse aufgerufen werden und den Zustand des Status ändern (Problem gelöst oder ungelöst) (Vgl. S. 103 Abb. 45).
A.1.7
Die Problem-Verwaltung: problem.runtime
Die Klasse ProblemSolveTracker wird von einem Problem als Thread initialisiert
und überprüft fortwährend, ob alle Teilprobleme gelöst sind. Einem Problem-Tracker
werden also alle Statable-Interfaces übergeben. Sind alle Teilprobleme gelöst, wird
eine Methode in der Problemsimulation aufgerufen, die das Problem beendet und
den Status der Systemsimulation auf „kein Problem aktiv“ setzt. Außerdem läuft
in ProblemSolveTracker eine Uhr, die die Zeit zur Problemlösung misst. Wird das
Problem durch die Pause-Taste der GUI angehalten, stoppt die Zeit. Das Zeitmes-
A
Abbildung 45: UML-Diagramm 6: die Problemschnittstellen
103
A
104
Abbildung 46: UML-Diagramm 7: Paket zur Problemverwaltung
sen ist dafür notwendig, damit Punkte an den Benutzer verteilt werden, die abhängig
von der Lösungszeit sind. Wird das Problem vom Benutzer übersprungen, wird eine Methode im Hauptprogramm aufgerufen, die den Punktestand um 1000 Punkte
vermindert.
Die Plugin-Klasse fasst alle notwendigen Informationen zu einem Plugin in Form
von Stringwerten zusammen. Dazu gehören etwa Klassennamen und -pfade für die
Simulation und die Animation, die funktionalen und Daten-Komponenten sowie
die Stadien und Nachrichtentypen. Außerdem enthält die Klasse verschiedene Kurzund/ oder Langbeschreibungen. Die Daten werden von der Klasse util.PluginFinder
gesetzt und vor allem von der System-GUI verwendet(Vgl. S. 104 Abb. 46).
A
A.1.8
105
Das Kommunikationsunterpaket: problem.simulationmodel
In problem.communication werden Klassen beschrieben, die für die Kommunikation notwendig sind. Einem Agent-Objekt wird eine ID sowie ein Problem zugeordnet. Die Hauptaufgabe eines Agenten ist das Empfangen und das Senden von Nachrichten. Das wird in den Methoden sendMessage( Message msg ), retrieveMessage(
Message msg ) und in der run() realisiert. In run werden Nachrichten automatisch an
eine zufällige ID mit zufälligen Abständen von maximal 3,5 Sekunden gesendet, in
sendMessage können Nachrichtenversendungen von Komponenten ausgelöst werden. Ein Agenten-Thread kann außerdem gesperrt werden, so dass entweder gar
keine oder nur noch Komponenten-generierte Kommunikation stattfinden kann.
Das Event-Klasse wird von einer Problemsimulation aufgerufen, wenn eine Nachricht gesendet oder empfangen wurde. Einem Event können vom Benutzer funktionale Komponenten zugeordnet werden, die dann bestimmte Funktionalität zur
Lösung eines Problems bereitstellt. Daneben hat ein Event einen Namen, damit dieses in der GUI dargestellt werden kann. Über getter- und setter-Methoden können
die assoziierten Komponenten hinzugefügt, entfernt oder geordnet werden.
Objekte der Message-Klassen bilden eine Nachricht ab. Eine Nachricht hat stets
einen Absender, einen Empfänger, eine ID, einen Nachrichtentypen sowie eine Botschaft. Über Konstruktoren werden Messages erzeugt, über getter-Methoden können sie von den funktionalen Komponenten ausgewerten und über setter-Methoden
verändert werden.
Das problem.simulationmodel-Unterpaket stellt für die Darstellung der Kommunikation auch den Nachrichtentyp „Standardnachricht“ bereit. Eine Standardnachricht
hat nur die Option „Nachrichten-ID erzeugen“ und implementiert ansonsten die normalen Events, die von dem MessageType-Interface vorgegeben werden (Vgl. S. 106
Abb. 47).
A
106
Abbildung 47: UML-Diagramm 8: Nicht-generische Kommunikationskomponenten
A
A.1.9
107
Die grafische Benutzeroberfläche: gui
Das gui-Paket stellt Funktionen bereit, wie das System und vor allem die Probleme/
Plugins grafisch dargestellt werden können. Dabei gibt es für jedes Fenster und für
jede Zeichnung eine eigene Klasse. Die Ressourcen zum Zeichnen der Oberfläche
(Bilder) sind im Ordner „dates“ gespeichert und stammen aus einer freien Bilderund Grafiksammlung33 .
Das Herzstück der grafischen Benutzeroberfläche ist die SystemGUI-Klasse, die als
Datenelement ein Objekt des Interfaces Problemable erhält und daraus generisch
die wichtigsten Daten für die Darstellung des Problems erzeugt. Durch diese wird
ein Fenster erzeugt, dass die zentralen Bedienelemente der Simulation bereitstellt.
Dazu gehören:
• die Steuerungsbuttons,
• das Menü,
• den Ladebalken,
• die Status- und Punkteanzeige,
• die Übersichtsfläche,
• die Nachrichtentypenoberfläche,
• die Ereignisoberfläche und
• die Werkzeugoberfläche
Klassifieren kann man diese Komponenten in allgemeine Bedienelemente sowie
in die Gruppen der einzelnen Tabs. Zu den allgemeinen Elementen gehören drei
Buttons. Der „play“-Button startet die Simulation bzw. startet sie erneut, wenn das
System im Pause-Zustand war. Der „pause“-Button hält die Simulation an, was vor
33
http://commons.wikimedia.org/wiki/Category:Fairytale_icons
A
108
allem bedeutet, dass keine Einstellungen an der Problemsimulation mehr vorgenommen werden können, dass der Punktestand nicht weitergezählt wird und dass die
Agenten und die Animation anhalten. Der „forward“-Button ermöglicht es dem Benutzer, ein Problem zu überspringen, was einen Punktabzug zur Folge hat. Im Menü
stehen die Funktionen „Spiel laden“ und „Spiel speichern“ zur Verfügung, die mit
Hilfe der util.GameData-Klasse entsprechende Operationen ausführen. Außerdem
kann das Spiel beendet werden und es können verschiedene Hilfefenster angezeigt
werden. Weiterhin sind in der allgemeinen Oberfläche eine Statusanzeige, die wichtige Systeminformationen auf den Bildschirm schreibt, eine Punktestandsanzeige,
die von der Klasse systemcontrol.ScoreCount gesteuert wird und ein Fortschrittsbalken (JAVAx.S WING.JProgressBar), der Systemprozesse verdeutlichen soll.
Daneben gibt es vier Tabs. Im ersten Tab, dem Übersichtstab, werden Informationen zum Stand der Simulation (z.B. „2 von 3 Teilproblem sind gelöst“, „derzeit funktioniert die Kommunikation problemlos“) angezeigt und daneben befindet
sich die aktuelle Animation, die die textuelle Beschreibung grafisch unterstützt. Die
Animation wird zu Beginn einer Probleminitialisierung (problemabhängig) geladen. Die textuelle Beschreibung ändert sich in Abhängigkeit von der ProblemSolveTracker-Klasse ebenso wie die Animation, die abhängig von der Problemsimulation ist, wenn verschiedene Stadien der Problembearbeitung erreicht werden. Der
„Nachrichtentypen-Tab“ stellt eine Nachricht als Bild dar und beschreibt kurz, was
ein Nachrichtentyp ist und warum verschiedene Typen notwendig sind. Außerdem
können hier Nachrichtentypenoptionen eingestellt werden. Im Ereignis-Tab werden links in Abhängigkeit der funktionalen Komponenten eines Problems alle diese
Komponenten dargestellt. Wie bei den Nachrichtentypen erfolgt auch auf dieser Seite eine kurze Erläuterung, was Ereignisse sind. Auf der rechten Seite sieht man eine
Combo-Box, die alle Events des Problems zur Auswahl stellt. Mit Hilfe von Drag
and Drop können funktionale Komponenten von links zu den Ereignissen rechts
gezogen und damit zugeordnet werden. Die Assoziation wird dann grafisch sichtbar. Diese Operation kann natürlich rückgängig gemacht werden. Entsprechend des
Event-Designs können einem Event auch mehrere Werkzeuge zugeordnet werden.
A
109
Die Zuordnung ist an sich auch geordnet. Die Ordnung kann ebenfalls per Drag and
Drop geändert werden. Mit einem „Klick“ auf die rechte Maustaste kann man die
Werkzeugbeschreibung zu einer funktionale Komponente einsehen. Im WerkzeugTab kann der Nutzer Informationen zu Werkzeugen allgemein und Parameter zu den
vom Problem bereitgestellten Werkzeugen ansehen und verändern.
Animationen und Zeichnungen werden in JAVAx.S WING.JPanels dynamisch und
problemzustandsabhängig geladen. Diese Zeichnungen werden in eigengen Klassen
definiert. Die SystemAnimation-Klasse stellt die Animation im Übersichtstab bereit. Sie zeichnet zunächst einen Hintergrund (Stadtkarte von Jena), sechs Agenten
und Verbindungslinien zwischen diesen. Die Systemsimulation ruft bei jeder Nachrichtenübertragung die Methode initPainting auf, die die Koordinaten der Senderund Empfängeragenten zuordnet und anschließend den Weg berechnet. Mit Abständen von 200ms werden dann Nachrichten zwischen den beiden Punkten in Weg/20
Pixel-Abständen neugezeichnet. Während eine Nachrichtenübertragung stattfindet,
wird die Animation für andere Sendungen blockiert, die aber trotzdem stattfinden
können. Der Punktestand bemisst sich aber nur nach gezeichneten Nachrichtenübertragungen. Die Animation kann vom System auch komplett gestoppt, etwa wenn es
sich im Pause-Modus befindet.
Die Klasse FlowDiagram zeichnet ein Ereignis und darunter der Reihenfolge nach
die zugeordneten funktionalen Komponenten. Die Klasse ComponentPainter zeichnet alle Werkzeuge und die DragPainter-Klasse ist für das Zeichnen einer Komponente während des Ziehens (Drags) verantwortlich.
Ein weiteres Fenster wird durch die Klasse MayorMessageGUI bereitgestellt. Diese
zeichnet in Abhängigkeit von zwei String-Parameter des Konstruktors einen kurzen
Text in die Titelleiste und einen langen in ein Textfeld. Daneben ist ein Bild des
Bürgermeisters zu sehen. Durch das Klicken auf einen OK-Button schließt man das
Fenster. Funktionalität bietet die Klasse ansonsten keine. Die Klasse SystemMessageGUI gibt lediglich in Abhängigkeit eines String-Parameters eine Botschaft zu
Dateioperationen aus (Vgl. S. 110 Abb. 48).
A
110
Abbildung 48: UML-Diagramm 9: Das GUI-Paket
A.1.10
Vorgabe zur Struktur von Plugins
Plugins müssen oder können Interfaces aus dem Unterpaket problem.ressourcemodel
implementieren, zentrale Informationen in einer XML-Datei bereitstellen und in
den Plugin-Ordner gepackt als JAR-Datei abgelegt werden, damit das Hauptprogramm sie verarbeiten kann. Pflicht ist das Implementieren der Schnittstellen Problemable und Animable. Daneben kann eine beliebige Anzahl von Statable-, FunctionComponentable-, DataComponentable- und MessageType-Implementierungen
angeboten werden, ohne die die Simulation wohl keinen Sinn machen würde. Besonders müsste mindestens ein Status vorhanden sein, damit kontrolliert werden
kann, ob das Problem gelöst ist. Außerdem müsste mindestens eine Komponente
oder ein Nachrichtentyp geschrieben werden, damit das Verhalten der Simulation
vom Benutzer beeinflusst werden kann.
Die Implementierungen müssen weiterhin in einer bestimmten Struktur angeordnet werden. Im Unterpaket plugin.PLUGINNAME müssen die Problemable- Implementierung sowie die XML-Beschreibung des Problems zu finden zu sein. Außerdem ist es anzuraten, dass im Verzeichnis plugin/exampleproblem/dates alle Bilder
und andere Dateien gespeichert werden, die zur Darstellung oder Implementierung
A
111
des Plugins nötig sind. Die komplette Paketstruktur kann man Tabelle 7 entnehmen.
PAKET
I NTERFACES
plugin.PLUGINNAME
Problemable
plugin.PLUGINNAME.data
Bilder, Textdateien etc.
plugin.PLUGINNAME.animation
Animable
plugin.PLUGINNAME.ressources.messagetypes
MessageType
plugin.PLUGINNAME.ressources.components.functioncomponents FunctionComponentable
plugin.PLUGINNAME.ressources.components.datacomponents
DataComponentable
plugin.PLUGINNAME.ressources.states
Stateable
Tabelle 7: Vorgegebene Paketstruktur eines Plugins
A.1.11
Pluginbeschreibung in XML-Dateien
Das Programm ist in der Lage, dynamisch Plugins zu laden. Dazu müssen die classDateien in einen Unterordner im Plugin-Paket abgelegt werden. Weiterhin müssen
die Klassen die Interfaces aus dem problem-Paket implementieren und ex muss eine
XML-Datei vorhanden, die das Problem beschreibt, damit das Laden des Plugins
erfolgreich ist. Die XML-Datei ist nach dem Standart des W3Cs (World Wide Web
Consortium) „wohlgeformt“ [Con02].
Eine solche Plugin-XML-Datei muss mit einem plugin-Tag beginnen und schließen,
dem sogenannten Wurzelelement. Dazwischen werden zunächst der Klassenname,
eine Beschreibung, ein Ordner und die Animation beschrieben. Anschließend werden zusätzliche Klassen wie funktionale und Datenkomponenten, Nachrichtentypen
und Stadien beschrieben. Ein Plugin-Parser überprüft die Korrektheit der Angaben
und lässt schließlich das Plugin zu oder verweigert es, wenn es die Vorgaben verletzt.
A
A.2
112
Beschreibung der Plugins
EINLEITUNG ERGÄNZEN
A.2.1
Verlorene Nachrichten
Das Plugin „Verlorene Nachrichten“ enthält folgende Klassen:
• LostMessage
• LostMessageAnimation
• AcknowledgementType
• Acknowledgement
• SendRepeating
• SendRepeatingStop
• LosingOfMessageState
• SendState
Das Herzstück des Plugins ist die LostMessage-Klasse. Sie implementiert Problemable. Die sendMessage-Methode erzeugt dabei eine Zufallszahl zwischen 0 und
100. Ist der Wert größer als der einer Verlustkonstante PROPLOST, wird die Nachricht normal gesendet, sonst geht sie verloren. Dies wird über einen Zusatz im
Text-Element der Nachricht gekennzeichnet. Die Animation zeigt dann keine blaue
Nachricht mehr, die von Agent X zu Agent Y geschickt wird, sondern eine rote Nachricht, die bei der Hälfte verschwindet. Daneben implementiert die Klasse
hauptsächlich die einfachen getter- und setter-Methoden des Interfaces und initialisiert die Kommunikation und übernimmt aus der Systemsimulation die Agenten.
A
113
Die Klasse LostMessageAnimation ist eine Implementierung des Animable-Interfaces.
Auch sie zeichnet eine Stadt im Hintergrund und die Agenten sowie die Verbindungslinien zwischen ihnen. Außerdem wird die Nachrichtendarstellung auf gleiche
Weise realisiert wie in SystemAnimation. Da aber grüne Nachrichtenbestätigungen
gleich nach dem Eintreffen einer Standardnachricht gezeichnet werden sollen, werden nicht die Nachrichten beliebig aussortiert, die wie in der Systemanimation in
der Systemsimulation zu einem Zeitpunkt ankommen, während die Animation gerade zeichnet, und später von einer neuen Nachricht überschrieben werden, sondern
es wird ein Stack verwendet, der alle Nachrichten tatsächlich, wenn auch zeitverzögert, in richtiger Reihenfolge zeichnet. Nachrichten können dadurch nicht mehr
verschluckt werden.
AcknowledgementType implementiert MessageType. Im Vergleich zur Standardnachricht wird lediglich die Option „Nachrichten-ID zitieren“ hinzugefügt. Ist diese
nicht ausgewählt, kann das Sendungswiederholungen-stoppen-Werkzeug nicht die
richtige Nachrichten-ID bestimmen und die entsprechende Nachricht nicht aus der
Sendungswiederholung entfernen.
In der Acknowledgement-Klasse wird das Versenden einer Nachrichtenbestätigung
implementiert. Die Klasse ist dem Interface FunctionComponentable zugeordnet
und verschickt in der operate-Methode lediglich eine Nachricht vom Typ Nachrichtenbestätigung. Ist eine Nachricht empfangen worden, wird aus der ursprünglichen
Nachricht der Sender als Empfänger und Empfänger als Sender definiert. Ist dies
nicht der Fall, bleiben Sender und Empfänger gleich. Die Nachrichten-ID wird in
Abhängigkeit der gewählten Nachrichtentypoption aus der ursprünglichen Nachricht zititert oder neugeneriert, wobei dies nicht zum gewünschten Ergebnis für den
Benutzer führt.
SendRepeating ist ebenfalls eine Implementierung von FunctionComponentable.
Sie hat einen JAVA.util.HashSet-Datensatz, in der Nachrichten gespeichert werden,
die wiederholt gesendet werden soll. Genau dies tut die Komponente auch in der
operate-Methode. Ist eine Nachricht noch nicht im HashSet, wird sie hinzugefügt
A
114
und anschließend immer wieder gesendet. Da dies zu einer Blockierung der Leitung führt, können andere Agenten nicht mehr senden und werden gesperrt. Von
der Sperrung wird neben dem Sender aber auch der Empfänger ausgenommen, damit dieser eventuell eine Bestätigung versenden kann. Die Sperrung wurde deshalb
eingefügt, damit in der Animation die Sendungswiederholung ohne Abbruch in alle
Konsequenz gezeigt werden kann.
Die Klasse SendRepeatingStop entfernt eine Nachricht aus dem Hashset von SendRepeating, wenn diese eintrifft. Damit sie entfernt werden kann, ist es notwendig,
dass auch tatsächlich der Absender der ursprünglichen Nachricht eine Nachricht
empfangen hat. In der Statable-Implementierung SendState wird lediglich überprüft, ob eine Nachrichtenblockierung vorhanden ist, die durch eine nicht abbrechende Sendungswiederholung ausgelöst wurde. Wenn das der Fall ist, wird an den
Problem-Tracker ein false gesendet und das Problem gilt weiterhin als ungelöst. In
LosingMessagesState wird überprüft, ob eine Nachricht, die gesendet wurde, aber
nicht ankam später beim Benutzer ankommt. Ist das der Fall, gilt das Teilproblem
als gelöst.
A.2.2
Falsche Nachrichtenreihenfolge
Das Plugin „Falsche Nachrichtenreihenfolge“ enthält folgende Klassen:
• WrongMessagesOrder
• WrongMessagesOrderAnimation
• AddMessageToList
• AddTimeStemp
• IncTimeStemp
• RefreshTimeStemp
A
115
• SortAndOutput
• OrderingState
Die Klasse WrongMessagesOrder implementiert Problemable und stellt die zentrale
Funktionen sendMessage( Message msg ) und initSimulation() bereit. initSimulation() übernimmt zunächst standardmäßig alle Agenten und sperrt anschließend alle
außer den Agenten mit der Nummer vier, dem in der Simulation eine besondere
Rolle zukommt. Dieser hat einen farbigen Code und sendet ihn an seine Kollege. Der Code besteht aus vier Farben und wird in vier unterschiedlich gefärbten
Nachrichten verschickt. sendMessage( Message msg ) sammelt zunächst pro Empfänger vier Nachrichten und fügt dem Nachrichtentext eine Zahl zwischen Null und
Drei bei, anhand der Agent die Farbe erkennen kann. Dann wird mit einer Wahrscheinkeit von 25 % die Nachrichtenreihenfolge von zwei Nachrichten vertauscht.
Zudem werden pro Agent eine Datenkomponente initialisiert, die die Reihenfolge
der Nachrichten speichert.
Das Plugin stellt daneben noch fünf funktionale Komponenten bereit. AddMessageToList fügt eine Nachricht in eine Liste ein und speichert diese zwischen. Diese
muss dem richtigen Ereignis zugeordnet sein, damit die Agenten überhaupt den
farbigen Code speichern können. AddTimeStemp verändert eine Nachricht von einem Agenten und fügt ihr den aktuellen Zeitstempel des Absenders bei. IncTimeStemp erhöht einfach den Zeitstempel des Agenten. RefreshTimeStemp vergleicht
den Zeitstempel der Nachricht mit dem eigenen und ersetzt den eigenen mit dem
der Nachricht, wenn der Nachrichtenzeitstempel höher ist. SortAndOutput sortiert
die Nachrichten aus der Nachrichtenliste nach dem Zeitstempel der Nachrichten.
Die Datenkomponente WaitingList speichert den aktuellen Zeitstempel eines Agent
in der Integer-Variable value und zudem die Nachrichtenliste. Zusätzlich zu den
Interface-Vorgaben werden die Methode add( Message msg ), removeAll() und changeElements( int a, int b ) implementiert, die eine Nachricht zur Nachrichtenliste
hinzufügen, alle entfernen oder die Plätze zweier Elemente tauschen.
A
116
Die Status-Implementierung OrdingState überprüft, ob tatsächlich eine Sortierung
der Nachrichten nach dem Zeitstempel vorgenommen wird. Implementierungen von
Nachrichtentypen werden nicht benötigt, alle versendeten Nachrichten sind vom
Typ StandardMessge. WrongMessageOrderAnimation stellt das Problem grafisch
dar. Unter den Agenten wird eine farbige Kombination angezeigt, die der Reihenfolge der Nachrichten entspricht. Agent Nummer 4 hat immer die richtige Reihenfolge
und ist der einzige, der Nachrichten in dieser Problemsimulation sendet. Neben den
Agenten kann man außerdem ein Feld mit einer Nummer sehen, das dem Zeitstempel entspricht. Nachrichten werden entsprechend der Stelle im Code eingefärbt.
A.2.3
Inkonsistentes Nutzen gemeinsamer Ressourcen
Das Problem Inkonsistentes Nutzen gemeinsamer Ressourcen enthält folgende Schnittstellenimplementierungen:
• InconsistentRessources
• InconsistentRessourcesAnimation
• Ressource
• SendRessource
• SendWriteAuthorization
• RefreshRessource
• CurrentVersionFinder
• ReadDemandType
• WriteDemandType
• RessourceType
• WriteAuthorizationType
A
117
• WriteType
• RessourceState
• QuorumState
Die Klasse InconsistentRessources implementiert die Schnittstelle Problemable und
simuliert das Problem der inkonsisten Nutzung gemeinsamer Ressourcen. Dabei
bedient sich die Klasse einer Unterklasse Simulation, die die Kommunikation bei
dem recht komplexen Problem kontrolliert. Wie im Problem der falschen Nachrichtenreihenfolge werden zunächst von InconsistentRessources alle Agenten gesperrt.
Anschließend wählt die run()-Methode von Simulation einzelne Agenten aus, die
Schreib- und Leseanfragen stellen und dafür temporär entsperrt werden. Die entsperrten Agenten stellen Lese- oder Schreibanfragen entsprechend eines festzulegenden Quorums an andere Agenten und erwarten eine Antwort. Die sendMessage(
Message msg )-Methode des Problems ist entsprechend knapp gefasst, da die Simulation die eigentliche Arbeit verrichtet.
Wie im Problem falsche Nachrichtenreihenfolge gibt es je Agent wieder eine Datenkomponente, die die gemeinsam genutzte Ressource repräsentiert. Der Name
dieser Klasse ist Ressource. Eine Ressource wird beschrieben durch einen Wert
value, einen Sperrungszustand eine Versionsnummer. Die Komponente speichert
darüberhinaus auch die ID des Agenten, mit der sie verknüpft ist und stellt einige
Methoden zur Manipulation der Daten bereit sowie eine toString()-Methode, die als
Schnittstelle zur Animation dient, die den aktuellen Wert und die aktuelle Version
der Ressource darstellt.
Auf Grund der Komplexität des Problems benötigt es eine größere Anzahl von
Nachrichtentypen und funktionalen Komponenten. SendRessource bereitet das Versenden einer Ressource vor. Dabei wird eine Nachricht vom Typ RessourceType
mit dem aktuellen Wert der Ressource und der aktuellen Version an einen anderen
Agenten verschickt. SendWriteAuthorization bereit das Verschicken einer Schreiberlaubnis (Nachrichtentyp WriteAuthorizationType) vor und sperrt die Ressource
A
118
des Agenten für den Absender der Nachricht, die die Komponente ausgelöst hat.
Die funktionale Komponente RefreshRessource ist die Hauptkomponente des Problems und bearbeitet in der operate( Message )-Methode gleich mehrere Aufgaben.
Zunächst zählt die Methode die Anzahl der Ereignisse, auf die die Komponente
reagiert. Überschreitet diese Anzahl das Quorum, wird die eigene Ressource aktualisiert und es werden Nachrichten vom Typ WriteType an die Agenten geschickt, die
eine Schreiberlaubnis gegeben haben. Wird eine Schreiberlaubnis verweigert, wird
ein neuer Agent angeschrieben, der noch nicht befragt wurde. Scheitert das Quorum
endgültig, werden die restlichen Agenten, die bereits eine Erlaubnis versendet haben, wieder entsperrt.
Die funktionale Komponente CurrentVersionFinder überprüft beim Empfang einer
Ressource, ob dessen Version höher ist als die eigene. Ist das der Fall, wird der
neue Wert an Stelle des alten gespeichert. War die empfangene Nachricht vom Typ
WriteType, wird die Ressource versucht zu entsperren. Die Nachrichtentypen ReadDemandType und textitWriteDemandType werden zu Beginn der automatisch Simulation versendet. Beiden Typen werden Optionen beigefügt, wieviele Agenten
mindestens für das Zustandekommen eines entsprechenden Quorums benötigt werden.
Das Plugin stellt zusätzlich zwei Problemlösestadien zur Verfügung. QuorumState
überwacht dabei, ob die Bedingungen für ein Schreib- und Lesequorum erfüllt sind
(Vgl S. 44, Formel 2). Der Überwacher RessourceState überprüft schließlich, ob
das vom Benutzer eingestellte Quorum für Lese- und Schreibprozesse tatsächlich
erfüllt ist.
Die Animation des Plugins wird in der Klasse InconsistentRessourcesAnimation
beschrieben. Sie stellt neben den Agenten und den Nachrichten mit unterschiedlichen Farben auch ein Schloss neben jedem Agenten dar, welches den Sperrungszustand der Ressource repräsentiert. Außerdem wird neben jedem Agenten ein Feld
gezeichnet, welches den Zustand der eigenen Ressource darstellt. Dort zu sehen sind
der aktuelle Wert der Ressource und die Versionsnummer. In der Mitte der Animati-
A
119
on wird zudem immer der reale Berechnungsstand angezeigt. Aktuelle Ressourcen
werden dabei blau, nicht-aktuelle rot gezeichnet.
A.2.4
Lauschangriff
Das Mitlesen von Nachrichten und das Verhindern dieses Problems werden von
folgenden Klassen realisiert:
• Bugging
• BuggingAnimation
• Keys
• Decrypt
• Encrypt
• RequestPublicKey
• SendPublicKey
• KeyRequestType
• KeyType
• CryptingState
Bugging ist wieder die zentrale Klasse des Plugins. In ihr wird der Nachrichtenaustausch simuliert. Das Problem an sich, kann in dieser Klasse nicht simuliert werden,
da es „über“ der Kommunikation steht, wer eine Nachricht mitlesen kann. Deshalb
wird diese Funktionalität in die BuggingAnimation-Klasse ausgelagert. Dort wird
zunächst die normale Kommunikation gezeichnet. Außerdem gibt es einen Agenten, der neben Sender und Empfänger eine Nachricht mitlesen kann. Von diesem
A
120
Agenten aus wird eine rote Linie auf das „Kabel“ bzw. die Nachricht, die ausgetauscht wird, gezeichnet. In der sendMessage( Message msg )-Methode der Hauptklasse wird jeder Nachricht vor dem Senden der Text „Klartext“ beigefügt. In der
Animation wird dann überprüft, ob der Text noch so da ist oder nicht. Ist das der
Fall, werden bei Empfänger und Mitleser eine Zeitung gezeichnet. Ist der Nachrichtentext verschlüsselt, wird beim Mitleser eine Zeitung mit Fragezeichen gezeichnet,
was symbolisieren soll, dass die Nachricht nicht gelesen werden kann. Der Verschlüsselungsstatus der Nachricht wird außerdem mit über unterschiedliche Farben
und ein offenes oder geschlossenes Schloss repräsentiert.
Die Datenkomponente Keys wird allen sechs Agenten zugeordnet und repräsentiert
eine Sammlung von öffentlichen Schlüsseln sowie den eigenen, geheimen Schlüssel. Mit dem Werkzeug Encrypt kann dann eine Nachricht verschlüsselt werden.
Die Verschlüsselung wird von der Komponente bzw. der Entschlüsselungskomponente Decrypt tatsächlich vorgenommen. Allerdings in stark vereinfachter Form. So
handelt es sich um einen Cäsar-Code mit ASCII-Alphabet, wobei der öffentliche
Schlüssel der negative geheime Schlüssel ist. Aufwendigere Methoden machen für
die interne Simulation sicher keinen Sinn. Die funktionale Komponente RequestPublicKey bereitet eine Anfrage vom Typ KeyRequestTyp vor, ob der Empfänger dem
Absender seinen öffentlichen Schlüssel zusendet. Im Idealfall reagiert der Empfänger einer solchen Nachricht mit der Komponente SendPublicKey, die dem Absender
den eigenen Schlüssel zustellt (Nachrichtentyp KeyType).
Der Lösungszustand wird mit CryptingState überwacht, welcher überprüft, ob Nachrichten tatsächlich verschlüsselt werden und ob der Empfänger der Nachricht diese
auch wieder entschlüsselt und dann lesen kann.
A.2.5
Verfälschte Nachrichten
Die folgenden Klassen implementieren das Problem der verfälschten Nachrichten:
• MessageFake
A
121
• MessageFakeAnimation
• CompareCheckSum
• CreateCheckSum
• EncryptCheckSum
• DecryptCheckSum
• SendReapting
• RequestSendRepeating
• RepeatRequestType
• IntegrityState
Das Problem wird wieder in der Hauptklasse, MessageFake simuliert. In der zentralen sendMessage( Message msg )-Methode wird zunächst ein Ort ausgewählt, an
dem sich der Absender mit dem Empfänger treffen will. Wieder mit einer Wahrscheinlichkeit von 25 % tritt das Problem auf. In diesem Falle wird der Ort verändert. Insgesamt stehen fünf Orte zur Auswahl. Im Nachrichtentext wird dann die
String-Konstante „fake“ angehängt, so dass es für die Animation ersichtlich wird,
das etwas schief gegangen ist.
Datenkomponenten werden für dieses Problem nicht benötigt. Als funktionale Komponente ist zunächst das Erstellen einer Prüfsumme von Bedeutung (CreateCheckSum). In ihr wird auf Basis des Nachrichtentextes, also des Ortes, eine Prüfsumme
berechnet. Das Verfahren dafür ist eine Modulo-Operation durch 11. Das Ergebnis wird an die Nachricht herangehangen. Natürlich wurde darauf geachtet, dass
nicht zwei Orte das gleiche Ergebnis bei dieser Operation aufweisen. In der Klasse CompareCheckSum wird die angehängte Prüfsumme mit einer selbsterrechneten
Prüfsumme verglichen. Ist das Ergebnis ungleich, können weitere Komponenten
ausgeführt werden, sonst passiert nichts.
A
122
Die funktionale Komponenten EncryptCheckSum und DecryptCheckSum kümmern
sich um das Ver- und Entschlüsseln der Prüfsumme, damit diese nicht mitverfälscht
werden kann. Die Grundlage dafür ist wieder ein Cäsar-Code. RequestSendRepeating erzeugt eine Nachricht vom Typ RepeatRequestType, die den Empfänger auffordert die vorherige Nachricht erneut zu senden. Da dabei der Inhalt der ursprünglichen Nachricht nicht verwendet werden kann und sich ein Agent auch nicht merkt,
was er zuvor verschickt hat, wird ein neuer Treffpunkt vereinbart. SendRepeating
sendet dann erneut eine Nachricht.
IntegrityState überprüft die Konfiguration darauf, ob eine Nachricht erneut gesendet wird, wenn ein gemeinsamer Treffpunkt nicht zu Stande gekommen ist. Die
Animation des Problems wird in der Klasse MessageFakeAnimation beschrieben.
Die Animation ordnet wieder Nachrichten mit unterschiedlichen Typen verschiedene Farben zu. Ist die Nachricht verfälscht, erhält sie ebenfalls eine andere Farbe.
Außerdem wird während des Übertragsvorgangs neben Absender und Empfänger
ein Bild des Ortes gezeichnet, an dem sie sich treffen wollen. Sind die Orte unterschiedlich, weiß der Benutzer, dass die Nachricht verfälscht wurde.

Wissenschaftliche Hausarbeit zur Ersten Staatsprüfung für

Transcrição

Documentos relacionados

Wir suchen Sie. Vertriebsingenieur Simulation / Automation (m/w)

CIAK RONCATO, ein führender italienischer Koffer

Knigge-Tipps rund um die Kommunikation Wussten Sie, dass

Dax - Multi-Asset-Strategie - Trust-Wi

plecs workshop

Wochenblatt, Oktober 2005 - Evangelische Kirche der Pfalz

Predigt für die Passionszeit (Karfreitag) Kanzelgruß: Die Gnade

Ein Tag bei RTL aktuell

plexim Workshop: Simulation of Power Electronic Systems with PLECS

E-Mail mit Eudora