Programmierung verteilter Systeme

Didaktische Umsetzung des Themas
„Programmierung verteilter Systeme“ für den
Informatikunterricht der S II
Schriftliche Hausarbeit im Rahmen der Ersten Staatsprüfung für das Lehramt
für die Sekundarstufen I und II
Dem Staatlichen Prüfungsamt für Erste Staatsprüfungen für Lehrämter an
Schulen Duisburg vorgelegt von
Niels Pinkwart
(Duisburg, Mai 1999)
Themensteller:
Prof. Dr. H.U. Hoppe
(Gerhard-Mercator-Universität GH Duisburg,
Fachbereich Mathematik, Fachgebiet Informatik)

Inhaltsverzeichnis
Inhaltsverzeichnis
Seite
1 Einleitung 4
2 Verteilte Systeme 7
2.1 Geschichtliche Entwicklung 7
2.2 Definition 8
2.3 Eigenschaften verteilter Systeme 9
2.3.1 Verteilungsgrad 9
2.3.2 Raum und Zeit 10
2.3.3 Architektur 11
2.3.4 Transparenz 12
2.3.5 Kommunikation 13
2.3.6 Schnittstellen und Protokolle 13
2.3.7 Synchronisation und Nebenläufigkeit 15
2.4 Vor- und Nachteile von Verteilung 16
2.4.1 Vorteile 17
2.4.2 Nachteile und Probleme 18
2.5 Beispiele 20
2.5.1 Flugzeugsteuerung 20
2.5.2 Rechnerverbundsystem von Reiseunternehmen 21
2.5.3 E-Mail 22
2.5.4 Groupware 22
3 Didaktik der verteilten Systeme 24
3.1 Einordnung in die Fachdidaktik 24
3.2 Behandlung im Unterricht 28
3.2.1 Analytischer Zugang: Vergleich verteilter Systeme 29
3.2.2 Theoretischer Zugang: Nebenläufige Prozesse 30
3.2.3 Algorithmischer Zugang: Protokolle 31
3.3 Der Programmieransatz 32
3.4 Lehrplanbezug 34
3.4.1 Grundkurs 34
3.4.2 Leistungskurs 35
3.5 Fazit 36
4 Die „Robots“-Umgebung 38
4.1 Kurzbeschreibung 38
4.2 Grundlegende Konzepte des Aufbaus 39
4.2.1 Spielfeld: Positionen und Attribute 39
4.2.2 Akteure: Roboter und Spieler 40
4.2.3 Aktionen 42
4.2.4 Regelwerke 43
4.2.5 Hilfen für den Roboter 45
4.3 Beispiele 46
4.3.1 Roboter 46
4.3.2 Spiel „Goldsuche“ 48
4.3.3 Spiel „Winterspiele“ 49
4.3.4 Spiel „Erobere die Fahne“ 50
5 Einzelheiten zu „Robots“ 52
5.1 Informatische Aspekte 52
5.2 Didaktische Aspekte 54
5.3 Einsatzmöglichkeiten 55
5.3.1 Interaktiv gesteuertes Spiel 55
5.3.2 Algorithmen I: einfache Robotersteuerung 56
Seite 2

Inhaltsverzeichnis
5.3.3 Algorithmen II: kommunizierende Roboter 57
5.3.4 Entwicklung eigener Spiele 58
5.3.5 Java-RMI verstehen: der Quellcode 58
5.4 Grenzen 59
5.4.1 Die lokale Sicht 59
5.4.2 Roboter als autonome Agenten 59
5.4.3 Fazit 60
6 Unterrichtssequenz 61
6.1 Voraussetzungen und Zielgruppe 61
6.2 Grobstruktur 61
6.3 Feinstruktur 63
6.4 Anschlussmöglichkeiten 72
6.4.1 Petri-Netze 72
6.4.2 Datensicherheit 72
6.4.3 Java-RMI 73
6.4.4 Architekturen 73
6.5 Leistungsbewertung 74
6.5.1 Mitarbeit im Unterricht 74
6.5.2 Klausur 75
7 Alternativen 78
7.1 Inhalte 78
7.2 Java MatchMaker 80
7.3 JavaSpaces 82
7.4 AgentSheets 83
8 Zusammenfassung und Ausblick 86
8.1 Zusammenfassung 86
8.2 Einsatzbericht 87
8.2.1 Allgemeines 87
8.2.2 Zeitplanung 88
8.2.3 Entwickeltes Spiel 89
8.2.4 Entwickelter Roboteralgorithmus 91
8.2.5 Schlussfolgerungen 93
8.3 Ausblick 94
8.3.1 Tendenzen verteilter Systeme: Jini 94
8.3.2 Schulanwendungen 95
8.3.3 Perspektiven in der Robots -Umgebung 96
Anhang A: Robots-Dokumentation 99
A.1 Systemanforderungen und Installation 99
A.2 Server: Starten eines Spiels 100
A.3 Client: Verbinden mit einem Spiel 102
A.4 Struktur des Programms 105
A.5 Wichtigste Variablen und Methoden 110
Anhang B: Literaturverzeichnis 118
Anhang C: Erklärungen 121
Anlage : Diskette mit Robots-Programm
Seite 3

Einleitung
1 Einleitung
Why build distributed systems ?
People are distributed, information is distributed.
(Sape Mullender)
In vielen Bereichen des täglichen Lebens werden heute Computer benutzt –
teils bewusst wie beim Zugriff auf das Internet, teils eher unbewusst wie beim
Fahren eines Autos mit modernen computerunterstützten Fahrhilfen. Bei vielen
dieser Anwendungen kooperieren mehrere, auf verschiedene Rechner verteilte
Prozesse miteinander. Die Untersuchung der Zusammenarbeit dieser Prozesse
ist Gegenstand des Gebiets der verteilten Systeme.
Dieses ist in der Informatik kein Neuland mehr. In Bereichen wie Algorithmik,
theoretischer oder technischer Informatik sind Einflüsse der zunehmenden
Vernetzung von Computern mit dem Ziel der Ermöglichung von
kooperierenden und miteinander kommunizierenden Anwendungen deutlich.
Auch stehen Veranstaltungen mit dem Thema „verteilte Systeme“ an einigen
Universitäten im Vorlesungsprogramm.
Im Schulbereich hingegen werden verteilte Systeme bis heute nicht behandelt,
und auch grundlegende didaktische Untersuchungen über verteilte Systeme
fehlen noch. Ziel dieser Ausarbeitung ist es, das Gebiet der verteilten Systeme
als Gegenstand des Informatikunterrichts der Sekundarstufe II zu analysieren
und einen möglichen Ansatz, der auf der Programmierung innerhalb einer
verteilten Spielumgebung beruht, aufzuzeigen.
Zunächst werden dazu im folgenden Kapitel die wichtigsten informatischen
Grundlagen verteilter Systeme angegeben. Neben einer Begriffsdefinition wird
auf die im Nachfolgenden relevanten Eigenschaften (z.B. Architekturform,
Transparenzbegriff, Kommunikationsarten) verteilter Systeme eingegangen.
Zentrale, für einen Einsatz im Informatikunterricht wichtige Themenbereiche
wie Protokolle und Synchronisation werden ebenso erläutert.
Seite 4

Einleitung
In Kapitel 3 werden dann die didaktischen Aspekte verteilter Systeme
untersucht. Ausgehend von fünf generellen Thesen zum Bildungswert der
Informatik wird eine Einordnung der Relevanz verteilter Systeme für die
Schulinformatik gegeben. Daran anschließend werden drei kurze Beispiele für
unterschiedliche Unterrichtsszenarien angeführt. Der Ansatz, verteilte Systeme
über Programmiertätigkeit im Unterricht zu behandeln, wird vorgestellt und
begründet. Weiterhin findet sich in Kapitel 3 eine Darstellung des
Lehrplanbezugs hinsichtlich Grundkurs und Leistungskurs.
In den Kapiteln 4 und 5 wird dann die Robots-Umgebung vorgestellt,
innerhalb derer die Programmierung verteilter Systeme im Informatikunterricht
ablaufen könnte. Kapitel 4 enthält eine Kurzbeschreibung von Robots sowie
eine Angabe der grundlegenden Konzepte (Spielfeld, Roboter, Aktionen und
Regelwerke). Auch werden Beispiele für Roboter und Spielregeln gezeigt.
In Kapitel 5 werden zunächst einige informatische Aspekte (Struktur des
Programms, Kommunikationsform, Architektur) und didaktische
Möglichkeiten vom Robots-System beschrieben. Nachfolgend werden fünf
Stufen der Verwendung von Robots im Informatikunterricht skizziert, die von
der einfachen Verwendung als Spiel über die Programmierung von
kooperierenden Agenten bis hin zur Analyse des RMI-Mechanismus gehen.
Daran anschließend findet sich eine Analyse der Grenzen von Robots
hinsichtlich der realisierbaren Spiele (oder allgemein: Simulationen).
Auf die erzielten Ergebnisse und Analysen aufbauend wird in Kapitel 6 ein
Beispiel für eine Unterrichtsreihe zum Thema „Programmierung verteilter
Systeme“ angegeben. Die Reihe ist für einen Informatik-Leistungskurs der
Jahrgangsstufe 12 oder 13 konzipiert und beinhaltet thematisch die
Programmierung kooperierender Roboteralgorithmen, den Entwurf und die
Implementierung von Spielregeln sowie die Erstellung von
Synchronisationsstategien für nebenläufige Prozesse. Es werden vier
verschiedene Anschlussmöglichkeiten an die Unterrichtsreihe angegeben und
die Frage der Leistungsbewertung diskutiert.
Seite 5

Einleitung
Kapitel 7 enthält Alternativmodelle zu Robots. Im Rahmen des
Unterrichtsthemas „Programmierung verteilter Systeme“ werden zunächst
andere mögliche Unterrichtsinhalte angegeben und bewertet. Nachfolgend
werden Java MatchMaker und JavaSpaces, zwei Tools zur Unterstützung der
Erstellung von verteilten Anwendungen vorgestellt. Zwar wird keines der
beiden wird im Robots-System verwendet, dennoch stellen sowohl der
MatchMaker als auch JavaSpaces sinnvolle Alternativen zur direkten
Verwendung von Java-RMI dar. Kapitel 7 schließt mit der Beschreibung von
AgentSheets – einer verteilten Umgebung, die in einigen Punkten Ähnlichkeit
mit Robots hat.
In Kapitel 8 werden abschließend die Ergebnisse dieser Ausarbeitung
zusammengefasst und einige Ausblicke gegeben. Weiterhin findet sich hier ein
Bericht über den Einsatz der Robots-Umgebung im Rahmen der
Modellierungswoche 1999 an der Universität Duisburg.
Seite 6

Verteilte Systeme
2 Verteilte Systeme
In diesem Kapitel werden die wichtigsten informatischen Aspekte von
verteilten Systemen erläutert. Angefangen mit einer kurzen geschichtlichen
Einordnung, die notwendigerweise übersichtsartig bleibt und keinen Anspruch
auf Vollständigkeit hat, werden Definition und zentrale Eigenschaften
verteilter Systeme angegeben.
2.1 Geschichtliche Entwicklung
In den letzten Jahrzehnten machten sowohl die Computertechnik als auch die
Informatik rasante Entwicklungen durch. Wichtig für die Entwicklung des
Gebiets der verteilten Systeme ist hierbei die Art und Weise, in der Computer
in den einzelnen Zeitabschnitten genutzt worden sind.
In den 50er Jahren wurde die Zeit der Computerbenutzung unter den
Programmierern aufgeteilt. Der jeweilige Benutzer hatte den Computer
innerhalb seines Zeitintervalls für sich zur alleinigen Verfügung.
Dieses Prinzip wurde auch in den 60er Jahren zunächst weiterverfolgt, wenn
auch durch die Entwicklung von Batchsystemen erweitert. Durch diese war es
möglich, Ein- und Ausgabe eines Programms zu unterschiedlichen Zeiten zu
realisieren.
In den 70er Jahren hielten „Tíme-Sharing“-Systeme ihren Einzug. An
verschiedenen Terminals konnten mehrere Benutzer zeitgleich auf einem
Großrechner arbeiten. Jeder dieser Benutzer hatte dabei den Eindruck, an
einem eigenen Rechner zu arbeiten, Verbindungen zu anderen Benutzern
existierten nicht.
Dies war auch in den 80er Jahren noch nicht der Fall, in denen die Terminals
durch Arbeitsstationen mit eigenem Prozessor ersetzt wurden. Dieser Schritt
war hauptsächlich wirtschaftlich bedingt. Die Verwendung von vielen
Seite 7

Verteilte Systeme
Einzelrechnern war sowohl in der Anschaffung als auch beim Aufrüsten des
Systems günstiger als die Benutzung eines Großrechners [Mullender].
In den 90er Jahren wurden die Arbeitsstationen schließlich vernetzt, jeder
Benutzer hatte prinzipiell die Möglichkeit, sowohl auf den eigenen Rechner als
auch auf über das Netz verfügbare Ressourcen (z.B. Festplatten, Drucker,
Rechenzeit) zuzugreifen.
Diese technischen Voraussetzungen bildeten die Basis für die Entstehung von
verteilten Systemen, die über die reine Nutzung von Netzressourcen
hinausgehen und eine Kooperation von verschiedenen, im Netz verteilten
Anwendungen beinhalten.
2.2 Definition
Obwohl mittlerweile eine große Menge von Literatur über verteilte Systeme
existiert, ist doch eine präzise Definition des Begriffs „verteiltes System“ nur
schwer zu finden. Einige Autoren drücken dies auch direkt aus:
• „Verteilte Verarbeitung ist ein relativ neues Gebiet, und es gibt bisher keine
allgemein gültige Definition.“ [Sloman/Kramer]
• „It is dangerous to attempt an exact definition of a distributed system.“
[Mullender]
• „The distinction between distributed systems and centralized ones is not
precisely defined ... There is no single characteristic or rule that
distinguishes distributed systems.“ [Coulouris/Dollimore]
Die Schwierigkeit einer exakten Definition wird hauptsächlich daraus
abgeleitet, dass das Gebiet der verteilten Systeme sehr groß und vielfältig ist
(siehe Beispiele in Abschnitt 2.5) und dass mithin jede Formalisierung eine
künstliche Einschränkung bedeuten würde.
Insbesondere die Fragestellung, welche Komponenten eines Systems (z.B.
Hardware, Daten, Kontrolle oder Verarbeitung) in welchem Grad verteilt sein
Seite 8

Verteilte Systeme
müssen, damit das System als Ganzes als verteilt bezeichnet werden kann, ist
nur schwer zu beantworten.
Aus diesem Grund ziehen viele Autoren eher eine Merkmalsdefinition heran.
Ein verteiltes System wird durch seine Eigenschaften (siehe 2.3 und 2.4) als ein
solches charakterisiert (z.B. [Mullender], [Coulouris/Dollimore] und [Mattern]).
Im Rahmen dieser Arbeit werde ich eine leicht veränderte Version der von
Sloman/Kramer gegebenen Definition zugrunde legen:
Ein verteiltes System besteht aus mehreren, nicht notwendig
verschiedenen, miteinander kooperierenden Anwendungen, die in der
Regel auf verschiedenen Computern laufen und zusammen in der Lage
sind, ein gemeinsames Ziel zu erreichen.
2.3 Eigenschaften verteilter Systeme
In den folgenden Abschnitten werden Unterscheidungsmöglichkeiten von
verteilten Systemen nach Grad und Art der Verteilung sowie wichtige
Eigenschaften und Charakteristika kurz erörtert. Die Beschreibung bleibt
hierbei auf die wesentlichen, für die nachfolgenden Kapitel bedeutsamen
Punkte begrenzt.
2.3.1 Verteilungsgrad
Wie bereits in 2.2 angedeutet, können Systeme auf durchaus verschiedenen
Ebenen verteilt sein. Enslow stellte hierzu ein Modell auf, das die Ebenen der
Hardware, der Kontrolle und der Daten berücksichtigt. Hiernach besitzt ein
System auf jeder dieser Ebenen einen Verteilungsgrad. Die Charakterisierung
eines Systems kann durch die Analyse dieser Grade erfolgen, als „vollständig
verteilt“ wäre ein System mit höchstem Verteilungsgrad auf allen Ebenen zu
bezeichnen.
Seite 9

Verteilte Systeme
völlig autonome
Prozesse
Master/Slave-
Beziehung
Kontrolle
Daten
Daten vollständig
repliziert
Hardware
alle Komponenten
auf einem Rechner
Dimensionen der Verteilung nach Enslow
nur lokale
Daten
lokal verteilte
Komponenten
In der neueren Literatur (z.B. [Borghoff/Schlichter]) werden dem Modell noch
weitere Ebenen wie die Verarbeitung oder die Last hinzugefügt, an dem
zugrundeliegenden Prinzip ändert sich dadurch jedoch nur wenig. Ein verteiltes
System kann durch seinen Verteilungsgrad in jeder der betrachteten Ebenen
charakterisiert werden.
2.3.2 Raum und Zeit
Eine weitere Charakterisierung verteilter Systeme ist durch die Komponenten
Zeit und Raum möglich:
• Ist das System dazu gedacht, von den Anwendern überwiegend zeitgleich
genutzt zu werden oder nicht ?
• Befinden sich die potentiellen Benutzer des Systems in räumlicher Nähe
zueinander oder ist das System eher dazu geeignet, unter großer, ggf. bis zu
weltweiter, Benutzerdistanz verwendet zu werden ?
Bei zeitgleicher Nutzung wird das System als synchron, im anderen Fall als
asynchron bezeichnet (detailliertere Darstellung bei Witzel). Dass die zeitliche
Komponente durchaus unabhängig von der räumlichen ist, verdeutlichen
folgende Beispiele:
Seite 10

Verteilte Systeme
zeitlich
asynchron
zeitlich
synchron
moderne Bürosoftware E-Mail
betriebliche Fertigungssteuerung
Computerintegrierter Klassenraum
Verbundsystem von Reisebüros
Netzwerkspiele
Flugzeugsteuerung Computerkonferenzen
räumliche
Nähe
2.3.3 Architektur
räumliche
Distanz
räumliche und zeitliche (A-)Synchronität in Beispielen
Neben der physikalischen Topologie des von einem verteilten System
benutzten Kommunikationsnetzwerkes lässt sich eine logische Architektur
definieren, in der zwei Komponenten dann miteinander verbunden sind, wenn
zwischen ihnen ein Informationsfluss vorliegt. Wie schon in 2.3.1 unter dem
Aspekt der Kontrolle angedeutet, existieren zwei gegensätzliche
Architekturformen, wobei Systeme durchaus auch auf Mischformen dieser
Architekturen aufbauen können:
Ein zentralisiertes System besteht aus einem Server und mehreren Clients. Die
Funktion des Servers kann von der reinen Bereitstellung von Diensten bis hin
zur völligen Kontrolle des Programmablaufs (sog. Master/Slave-Beziehung)
gehen, auch wenn in letzterer Form der Verteilungsgrad des Systems potentiell
eher gering sein dürfte.
Der Informationsfluss in zentralisierten Systemen findet in der Regel nur
zwischen Server und Client statt, ein Nachteil dieser Architektur ist der Ausfall
des Systems bei Serverdefekt. Dafür sind für gewisse Anwendungen ggf.
nötige Ablaufsteuerungen einfach (serverseitig) zu realisieren.
Seite 11

Verteilte Systeme
In dezentralen Systemen existiert keine globale Kontrollinstanz. Die Prozesse
kommunizieren ohne „Serverumweg“ direkt miteinander. Dieser
Architekturtyp bringt im Vergleich zu zentralisierten Systemen eine bessere
Lastenteilung (kein stark belasteter Server), ein höheres Geschwindigkeits-
potential durch Wegfall des z.T. unnötigen Serverumwegs und einen größeren
Verteilungsgrad, allerdings sind Probleme der Nebenläufigkeit von Prozessen
(siehe 2.3.7) von eminenter Bedeutung [Herrtwich/Hommel].
2.3.4 Transparenz
Eine zentrale Eigenschaft verteilter Systeme ist deren Transparenz. Unter
Transparenz wird die „Unsichtbarkeit“ der Verteiltheit des Systems für den
Benutzer verstanden: bei Verwendung von Systemkomponenten sollte nicht die
Struktur des Systems im Vordergrund stehen, sondern die Funktionalität.
Konsequenzen werden von Borghoff/Schlichter und Coulouris/Dollimore aufgezeigt.
Beispiele:
• Zugriffstransparenz: Die Syntax des Zugriffs auf lokale
Systemkomponenten unterscheidet sich von der des Zugriff auf
Netzkomponenten nicht (z.B. Zugriff auf Dateien generell über „open“)
• Ortstransparenz: Der Zugriff auf Netzressourcen ist ohne Wissen des
genauen Lagerungsortes möglich. Beispiel: Netzwerkdrucker werden über
Namen angesprochen
• Fehlertransparenz: Das System verheimlicht, wenn möglich, aufgetretene
Fehler vor dem Benutzer, dieser kann normal weiterarbeiten. Bsp.: Ein
System verwendet replizierte Daten, bei Ausfall einer Festplatte wird
automatisch eine der bestehenden Kopien verwendet
Die Transparenz eines Systems charakterisierte Lamport relativ ironisch:
„Verteilte Systeme sind Systeme, in denen ich durch den Ausfall einer
Komponente, von deren Existenz ich bisher nichts wusste, in meiner Arbeit
beeinträchtigt werde“.
Seite 12

Verteilte Systeme
2.3.5 Kommunikation
Die Kommunikation zwischen den Teilkomponenten ist eine der wichtigsten
Eigenschaften eines verteilten Systems, da ohne Kommunikation keine echte
Kooperation (siehe Definition in 2.2) möglich ist.
Nach heutigem Stand werden im Wesentlichen drei Techniken zur
Realisierung der Kommunikation eingesetzt:
1. Nachrichten
Die einzelnen Prozesse im System senden sich gegenseitig Nachrichten.
Dabei müssen die Empfängerprozesse Routinen zur Bearbeitung der
Nachrichten zur Verfügung stellen, außerdem ist eine genaue Spezifikation
der Semantik der verwendeten Nachrichten nötig (siehe Schnittstellen,
2.3.6)
2. Remote Procedure Call (RPC)
Beim RPC wie bei der objektorientierten Variante, der Remote Method
Invocation (RMI), veranlasst ein Prozess die Ausführung einer Prozedur
bzw. Methode eines anderen Prozesses, der (allerdings nicht notwendig)
auf einem anderen Rechner läuft. Wie beim Nachrichtenverkehr muss auch
hier die Semantik der aufgerufenen Prozeduren klar definiert sein,
weiterhin müssen Datentypen (Parameter und Ergebnistyp) bekannt sein
(siehe Schnittstellen, 2.3.6).
3. gemeinsame Daten
Bei dieser Kommunikationsform nutzen die Prozesse eine gemeinsame
Datenumgebung. Hier sind Aspekte der Synchronisation und
Nebenläufigkeit (siehe 2.3.7) von besonderer Bedeutung, da die Gefahr von
Dateninkonsistenz oder –verlust droht.
2.3.6 Schnittstellen und Protokolle
Schnittstellen und Protokolle dienen aus informatischer Sicht generell dazu, die
Kommunikationsmöglichkeiten zwischen verschiedenen Komponenten oder
Teilsystemen einer Maschine zu beschreiben.
Seite 13

Verteilte Systeme
Schnittstellen (von Systemkomponenten) sind dabei Vorrichtungen zum
Informationsaustausch und bestehen aus der Zusammenfassung aller von außen
benötigten (Importschnittstelle) und aller von außen abrufbaren
(Exportschnittstelle) Größen [Duden].
Protokolle sind Sätze von Regeln zum Beherrschen der Kommunikation. Sie
existieren unabhängig von konkreten Systemkomponenten, müssen aber von
diesen beachtet werden, und legen Format und Reihenfolge des
Informationsaustausches fest [Sloman/Kramer].
Beispiele für Schnittstellen und Protokolle finden sich in Computersystemen
annähernd beliebig viele: Hardwareschnittstellen (Verbindungsstecker),
Netzschnittstellen zur Beschreibung des Zugriffs auf das lokale Netzwerk oder
auch Benutzerschnittstellen. Diese legen, heute zumeist über graphische
Oberflächen, die Möglichkeiten fest, die der Benutzer bei der Bedienung eines
Programms hat. Das Protokoll wird hierbei vom Programm direkt vorgegeben,
z.B. durch die Vorgabe einer Reihenfolge zur Bearbeitung der einzelnen
Schritte.
In verteilten Systemen kommt den Softwareschnittstellen der Komponenten
eine besondere Bedeutung zu. Nur durch die genaue Angabe von Syntax und
Semantik der Kommunikationsmöglichkeiten einer Komponente ist eine
Zusammenarbeit mit anderen Komponenten möglich. Konkret muss eine
Softwareschnittstelle z.B. folgendes beinhalten:
• Welche Nachrichten werden verstanden ?
• Was geschieht bei Erhalt einer Nachricht ?
• Welche Nachrichten werden verschickt und welche Reaktion wird vom
Empfänger erwartet ?
• (für RPC): Welche Prozeduren sind aufrufbar und was bewirken sie ?
• Welche Daten sind als Parameter erforderlich und welchen Typ hat das
Resultat ?
Seite 14

Verteilte Systeme
2.3.7 Synchronisation und Nebenläufigkeit
In Computersystemen, insbesondere in verteilten Systemen, laufen (z.T. auf
verschiedenen Rechnern) eine gewisse, bei komplexen Systemen recht große,
Anzahl von Prozessen. Eine Teilmenge dieser Prozesse lässt sich hinsichtlich
der Bearbeitungsreihenfolge ihrer Elemente klassifizieren:
Typ Bearbeitungsreihenfolge
seriell (sequentiell) Die Prozesse finden nacheinander statt.
parallel Die Prozesse finden gleichzeitig statt
nebenläufig Die Prozesse können unabhängig voneinander
ablaufen, Reihenfolge spielt keine Rolle
Greifen Prozesse auf Systemressourcen zu, die auch von anderen Prozessen
benutzt werden, so können erhebliche Probleme entstehen. Dies betrifft vor
allem nebenläufige Prozesse, da bei seriellen Prozessen der Zugriff auf die
Ressourcen nicht gleichzeitig stattfinden kann und bei parallelen Prozessen die
Gleichzeitigkeit bereits bei der Programmierung berücksichtigt wurde.
In nebenläufigen Prozessen hingegen kann es vorkommen, dass
unterschiedliche Prozesse zeitgleich bzw. zeitlich sehr nah beieinander auf eine
gemeinsam genutzte Ressource zugreifen wollen, ohne dass dies direkt gewollt
ist. Konflikte entstehen z.B. beim schreibenden Zugriff auf gemeinsame
Variablen oder Dateien, wie folgendes Beispiel zeigt [Duden]:
Die Prozesse A und B greifen auf die gemeinsam genutzte Variable x zu.
Prozess A Prozess B
(A1) x:= 2x; (B1) x:= x-1;
(A2) write x; (B2) write x;
Abhängig von der Reihenfolge der Ausführung der Befehle A1, A2, B1 und B2
können (bei Startwert x=2) folgende Ausgaben erfolgen:
Seite 15

Verteilte Systeme
Reihenfolge Ausgabe
A1,A2,B1,B2 4 3
A1,B1,A2,B2 oder A1,B1,B2,A2 3 3
B1,A1,A2,B2 oder B1,A1,B2,A2 2 2
B1,B2,A1,A2 1 2
Mechanismen, welche die Reihenfolge von nebenläufigen Prozessen regeln,
werden als Synchronisation bezeichnet [Mullender]. Während dies in
nichtverteilten Systemen oder auch in stark zentralisierten verteilten Systemen
aufgrund der globalen Kontrollinstanz noch recht einfach realisierbar ist
[Sloman/Kramer], ist bei (auch teilweise) dezentralen verteilten Systemen die
Sachlage ungleich schwieriger.
Synchronisation hat generell zwei durchaus gegenläufige Zielsetzungen:
• Ermöglichen von Prozessparallelität wo immer dies gefahrlos möglich ist
(Ziel: Performancegewinn)
• Erzwingen von Sequentialität falls nötig zur Vermeidung von Konflikten
und Deadlocks (= wechselseitige Blockierung mehrerer Prozesse)
Es existieren eine ganze Anzahl von Synchronisationsansätzen, die z.B. auf
kritischen Abschnitten, wechselseitigen Ausschluss, Semaphoren oder
Synchronisationsphasen beruhen. Ausführlich werden diese Ansätze von
Mattern, Raynal/Helary, Herrtwich/Hommel und Witzel dargestellt.
2.4 Vor- und Nachteile von Verteilung
Verteilte Systeme bieten sowohl dem Programmierer als auch dem Anwender
eine ganze Reihe von Vorteilen, insbesondere in Hinsicht auf Flexibilität und
Leistung. Dem gegenüber stehen Nachteile und potentielle Probleme bezüglich
Komplexität und Sicherheit.
Die wichtigsten Vor- und Nachteile werden nachfolgend skizziert. Es ist dabei
zu beachten, dass (vgl. 2.3.1) Systeme unterschiedliche Verteilungsgrade
haben. In voller Konsequenz gelten die angesprochenen Punkte größtenteils
nur bei hohem Verteilungsgrad.
Seite 16

Verteilte Systeme
2.4.1 Vorteile
Ressourcenteilung
Von verschiedenen Benutzern benötigte Ressourcen müssen in verteilten
Systemen nicht auf jedem Rechner lokal vorhanden sein. Dies bezieht sich
sowohl auf Hardwarekomponenten wie Drucker oder Festplattenspeicherplatz,
als auch auf Softwarekomponenten wie Daten und Programme
[Coulouris/Dollimore].
Erweiterbarkeit
Durch die in verteilten Systemen erzwungene Modularität ist es ohne weiteres
möglich, die Leistungsfähigkeit des Systems beispielsweise durch Integration
neuer Arbeitsstationen oder Software schrittweise auszubauen, ohne die
Funktionalität des Gesamtsystems zu unterbrechen, wie dies etwa beim
Austausch eines Großrechners durch einen anderen der Fall wäre
[Sloman/Kramer].
Verfügbarkeit
Durch die in verteilten Systemen im Gegensatz zu auf Großrechnern
basierenden Systemen kostengünstig mögliche Schaffung von Redundanz und
Datenreplikation muss ein Ausfall einer der Komponenten des Systems nicht
zwangsläufig die Verwendbarkeit des Systems beeinträchtigen. Bei Ausfall
einer gesamten Arbeitsstation kann die Arbeit beispielsweise von einer anderen
Station, idealerweise ohne Datenverlust, weitergeführt werden
[Coulouris/Dollimore].
Flexibilität
Durch die in verteilten Systemen erforderliche präzise Schnittstellendefinition
(siehe 2.3.6) ist es möglich, einzelne Teile des Systems durch andere
leistungsfähigere Komponenten mit gleicher Schnittstelle zu ersetzen, ohne
damit die Funktionalität des Gesamtsystems zu stören [Duden].
Seite 17

Verteilte Systeme
Lastenteilung
Vergleichbar mit der Ressourcenteilung (s.o.), ist in verteilten Systemen auch
die Prozessorbelastung (Rechenzeit) teilbar. Aufwendige Berechnungsroutinen
können auf aktuell nicht ausgelasteten Rechnern oder auch, falls vorhanden,
auf für diese Berechnungen spezialisierten Maschinen ausgeführt werden
[Sloman/Kramer].
lokale Kontrolle
Durch die lokale Souveränität über Daten und Verarbeitung kann das System
besser an die lokalen Anforderungen der einzelnen Arbeitsplätze angepasst
werden (siehe auch Flexibilität), was wiederum Vorteile z.B. in der
Benutzerfreundlichkeit mit sich bringt [Sloman/Kramer].
2.4.2 Nachteile und Probleme
Sicherheitslücken
Zur Ermöglichung von Flexibilität und Erweiterbarkeit werden in verteilten
Systemen notwendigerweise viele Softwareschnittstellen freigelegt und zur
Benutzung durch alle Anwender freigegeben. Stärker als bei möglicherweise
sogar nicht an das lokale Netzwerk angeschlossenen Einzelarbeitsplätzen
besteht hier das Risiko der Verwendung der Routinen und Daten durch
unberechtigte Personen [Coulouris/Dollimore]. Bei sicherheitsrelevanter
Information ist daher die Verwendung von Schutzmechanismen, z.B. die
Verschlüsselung von Daten und Einsatz von Zugriffsberechtigungen sowie
digitalen Signaturen, anzuraten.
Dateninkonsistenz
Bei gemeinsam genutzten Daten, z.B. einer verteilten Datenbank, kann schnell
das Problem der Dateninkonsistenz auftreten. Das System muss, insbesondere
bei zeitgleicher Änderung des Datenbestandes durch verschiedene Benutzer,
geeignete Mechanismen zur Verfügung stellen, damit keine der Änderungen
verloren geht. Auch die Datenreplikation kann hier zum Problem werden.
Seite 18

Verteilte Systeme
Werden Datenänderungen und Replikationsvorgänge nicht korrekt
synchronisiert, sind Inkonsistenzen unausweichlich.
Komplexität des Systems
Anders als bei lokal auf einem Rechner laufenden Anwendungen, deren
Zustand meist relativ klar definierbar ist (z.B. durch Struktogramme), haben
verteilte Systeme auch einen verteilten Zustand, beschrieben durch den
Zustand aller Einzelkomponenten. Berücksichtigt man nun noch die möglichen
extern bewirkten Zustandsänderungen einer Komponente durch
Nachrichtenaustausch mit anderen Komponenten, so wird die erhöhte
Komplexität recht deutlich [Mullender]. Ein Ansatz zur Analyse von Zuständen
in verteilten Systemen ist die Verwendung von Petri-Netzen [Baumgarten], bei
denen genau die Kommunikation zwischen Komponenten mit nachfolgender
Zustandsänderung durch „Transitionen“ beschrieben werden kann.
Zu der erhöhten Zustandskomplexität in verteilten Systemen kommen noch
neue Arten von möglichen Fehlern, z.B. durch Ausfall von nicht-lokalen
Komponenten, die von der Software berücksichtigt werden müssen.
Borghoff/Schlichter kommentieren dies: „Das Testen eines verteilten Systems ist
sehr komplex ... Meist gibt es nur real-life-Tests.“
Abhängigkeit vom Netzwerk
Da in verteilten Systemen die einzelnen Komponenten über ein
Kommunikationsnetzwerk Informationen austauschen, ist die Abhängigkeit
von der Funktion des Netzwerkes offensichtlich. Diese zeigt sich sowohl in der
Beschränkung der maximal erzielbaren Geschwindigkeit als auch im
(zumindest teilweisen) Ausfall des Systems bei Netzwerkdefekten
[Coulouris/Dollimore].
verteilte Programmierung
Zunächst ist die verteilte Programmierung ein positiver Aspekt verteilter
Systeme. Mehrere Programmierer arbeiten lokal an ihrem Rechner und legen
Schnittstellen offen, damit andere Programmierer und Benutzer die erzeugten
Routinen verwenden können.
Seite 19

Verteilte Systeme
Dieser Ansatz beinhaltet jedoch folgende Probleme [Sloman/Kramer]:
• Die Einigung auf gemeinsame Standards kann bei örtlicher Verteilung der
Programmierer schwierig sein.
• Gewisse Programmmodule werden möglicherweise mehrfach (in
inkompatiblen Versionen) erzeugt und verwendet.
Abhilfe können hier ein zentrales Management, die strikte Einhaltung von
Standards sowie häufiger Informationsaustausch unter den Programmierern
schaffen.
lokal geringere maximale Rechenleistung
Falls ein Programm sehr große Rechenleistung erfordert, ist ein Großrechner
dazu aufgrund der lokal sehr viel größeren Leistung besser in der Lage als eine
normale Arbeitsstation. Insbesondere fällt dieses Argument ins Gewicht, wenn
das zu berechnende Problem strukturell nicht sinnvoll verteilbar ist, z.B. wenn
es aus sehr vielen aufeinander aufbauenden Rechenschritten besteht
[Coulouris/Dollimore].
2.5 Beispiele
Wie bereits in der Einleitung angedeutet, existiert heute eine riesige Anzahl
von verteilten Systemen, die allerdings aufgrund ihrer Transparenz nicht immer
sofort als solche zu identifizieren sind. Ich gebe an dieser Stelle drei Beispiele
für existierende verteilte Systeme und stelle kurz das Konzept von Groupware
vor.
2.5.1 Flugzeugsteuerung
In modernen Flugzeugen, und zunehmend auch in Fahrzeugen, existieren eine
ganze Anzahl von computergesteuerten Einheiten. So werden z.B. die
einzelnen Teile der Cockpitanzeigen von anderen Rechnern gesteuert als die
Seite 20

Verteilte Systeme
eigentlichen Funktionseinheiten, die beispielsweise für die Autopilot-Funktion,
die Notfallprogramme, die computerunterstützte Bremsvorrichtung oder den
Kollisionswarner zuständig sind.
Aus diesen Beschreibungen wird zunächst deutlich, wie extrem bedeutsam hier
das absolut korrekte Zusammenspiel der einzelnen Systemkomponenten ist.
Durch die Verteiltheit des Systems „Flugzeugsteuerung“ werden aber mehrere
Vorteile genutzt, die besonders in den Bereichen der Verfügbarkeit und
Erweiterbarkeit zu finden sind. Nachträgliche Sicherheitseinrichtungen können
leicht integriert werden und bei Ausfall einer Komponente ist das Flugzeug
trotzdem noch in weiten Teilen funktionsfähig.
An diesem Beispiel wird der Aspekt „Transparenz“ besonders deutlich. Wohl
kein Betrachter eines Cockpits wird anhand der Bedieninstrumente erahnen
können, dass hier nicht ein, sondern mehrere Computer am Werk sind.
2.5.2 Rechnerverbundsystem von Reiseunternehmen
In heutigen Reisebüros ist die Abfrage von freien Flügen oder Hotelzimmern
problemlos durch Computereinsatz möglich. Hier liegt offensichtlich ein, wenn
auch stark zentralisiertes, verteiltes System vor, da die Abfrage stets über einen
Zentralrechner erfolgt. Beachtenswert ist die (allein auf Deutschland bezogene)
Größe des Systems, da fast jedes Reisebüro an das System („START“)
angeschlossen ist (siehe [Start]).
Probleme beim Einsatz des Systems treten weniger in der Abfrage noch freier
Kapazitäten (Lesezugriff) auf, sondern bei der Buchung (Schreibzugriff). Da
die einzelnen Rechner in den Reisebüros klassische nebenläufige Prozesse
(siehe 2.3.7) sind, die auf einen gemeinsamen Datenbestand zugreifen müssen,
ist der Effekt der Fehl- oder Doppelbuchungen gut erklärbar - wobei die
Tatsache, dass diese Effekte heute nur noch selten auftreten, für eine gute
Lösung des Synchronisationsproblems im „START“-System spricht.
Seite 21

Verteilte Systeme
2.5.3 E-Mail
Die Anzahl der an das Internet angeschlossenen Firmen und Privathaushalte
wächst ständig, und fast jeder der Anschlüsse beinhaltet in der Regel
mindestens eine E-Mail-Adresse. Nach Prognosen der Deutschen Telekom
werden im Jahr 2003 bereits die Hälfte aller Deutschen einen Internet-
Anschluss haben [NRZ].
Die Möglichkeit, sich auf elektronischem Wege Nachrichten zu senden, wird
reichlich genutzt, das dafür verwendete System bildet zugleich eines der
größten existierenden verteilten Systeme.
Es zeichnet sich durch die für das Internet typische Fehlertoleranz und
Lastenteilung aus. Auch bei Ausfall einiger für die Nachrichtenweiterleitung
wichtige Rechner können alternative Wege gefunden werden, die Nachricht
zum Ziel zu bringen.
Die dezentrale Verteiltheit dieses Systems in diesem Beispiel ist geradezu
zwingend erforderlich. Kein Großrechner könnte die Belastung der weltweit
versendeten E-Mails bewältigen, und die Bandbreite heute existierender
Leitungen würde in Servernähe bei weitem nicht ausreichen.
2.5.4 Groupware
Im Gegensatz zu den vorigen drei Beispielen ist Groupware kein Beispiel für
ein verteiltes System, sondern eine Beschreibung für eine ganze Klasse von
verteilten Systemen.
Ellis definiert Groupware als computerbasierte Systeme, die eine Gruppe von
Menschen bei ihrer gemeinsamen Aufgabe unterstützen und die eine
Schnittstelle zu einer gemeinsamen Umgebung bereitstellen.
Die Ähnlichkeit zur Definition verteilter Systeme (in 2.2) ist offensichtlich,
einschränkende Bedingungen liegen aber in der Festlegung der Benutzer auf
eine (i.a. bekannte) Gruppe und der Forderung einer gemeinsamen Umgebung
sowie einer gemeinsamen Aufgabe. Beispiele wie unter 2.5.1 und 2.5.3 fallen
daher nicht in den Groupware-Bereich.
Seite 22

Verteilte Systeme
Wichtige vorkommende Groupware-Systeme sind:
• Netzwerkspiele
• moderne, die Teamarbeit unterstützende, Office-Pakete, z.B. [Notes]
• Konferenzsysteme
• Fertigungssteuerungssysteme in Betrieben, siehe [Sloman/Kramer]
Im Schulbereich ist Groupware beispielsweise durch einen
computerintegrierten Klassenraum, beschrieben von Hoppe/Luther, sinnvoll
einsetzbar.
Der Bereich der Groupware ist bei weitem zu groß und vielfältig, um an dieser
Stelle ausreichend beschrieben zu werden. Eine gute Übersicht über
informatische Aspekte findet sich bei Borghoff/Schlichter, soziale
Zusammenhänge werden von Rolf erläutert. Bei Lloyd ist eine ganze Anzahl von
Artikeln über mögliche Zukunftstendenzen von Groupware vorhanden.
Seite 23

Didaktik der verteilten Systeme
3 Didaktik der verteilten Systeme
Die im vorigen Abschnitt dargelegten Eigenschaften und Möglichkeiten
verteilter Systeme legen es nahe, über eine Behandlung dieser Systeme im
Informatikunterricht an Schulen nachzudenken.
In diesem Kapitel wird zunächst die Bedeutung verteilter Systeme für die
Didaktik der Informatik allgemein analysiert. Darauf aufbauend werden
spezielle Möglichkeiten für den Unterricht aufgezeigt – eine gewisse
didaktische Reduktion scheint dabei wegen der Komplexität der Thematik
unausweichlich. Insbesondere wird auf die Rolle des Programmierens
eingegangen, die als ein Schlüssel zum Verständnis der Kerngebiete verteilter
Systeme angesehen wird.
3.1 Einordnung in die Fachdidaktik
In diesem Abschnitt wird eine allgemeine Einordnung des Gebiets der
verteilten Systeme in die Didaktik der Informatik gegeben, wobei der
Schwerpunkt nicht auf konkrete Unterrichtsinhalte, sondern auf übergeordnete
Aspekte gelegt wird. Dazu werden die in von Hoppe und Hoppe/Luther im
Kontext der Rechtfertigung von Informatik als Schulfach angegebenen Thesen
zum Bildungswert der Informatik betrachtet und bezüglich verteilter Systeme
als Gegenstand diskutiert.
Nach oben angegebener Literatur existieren im wesentlichen fünf Ansätze zur
Begründung des allgemeinen Bildungswertes von Informatik. Nicht jeder
dieser Ansätze ist alleine realistisch und tragfähig genug zur Begründung von
Informatikunterricht, dennoch spiegeln die Thesen durchaus wichtige
Themengebiete der Schulinformatik wieder und ermöglichen eine Einordnung
der Bedeutung verteilter Systeme:
Seite 24

Didaktik der verteilten Systeme
Algorithmieren als Kulturtechnik
In diesem Ansatz, der insgesamt als zu einschränkend bewertet werden kann,
steht die Rolle des Programmierens und Algorithmierens im Mittelpunkt. Diese
beiden Fertigkeiten werden als zentraler Bildungswert der Informatik
angesehen.
Von diesem Standpunkt aus betrachtet liefern verteilte Systeme die
Möglichkeit, die Algorithmier- und Programmierfähigkeiten der Schüler auf
eine höhere Ebene zu bringen. Die Notwendigkeit der Kooperation von
verschiedenen Komponenten im verteilten System wirkt sich in der
Unumgänglichkeit des Entwurfs und der Programmierung von
Kommunikationsschnittstellen aus. Dabei wird eine Verallgemeinerung des
prozeduralen Programmierens durch RPCs für die Schüler erkennbar.
In diesem Kontext ist auch die zur Programmierung gehörende Fehleranalyse
anzusprechen, die bei verteilten Systemen zwar strukturell schwieriger, aber
auch allgemeiner ist und daher eine echte Erweiterung darstellt.
Umgang mit Informations- und Kommunikationstechnik
Dieser Ansatz definiert den Bildungswert der Informatik über das zu
erreichende Verständnis von Computerhard- und software. Ziel ist hier der
souveräne und verständige Umgang mit Computertechnik sowie wichtigen
Softwareprodukten wie Textverarbeitungen, Tabellenkalkulationen,
Grafikprogrammen oder auch den neuen Medien (Stichwort Internet).
Auch wenn dieser Ansatz die Bedeutung von Informatik als Schulfach
bestenfalls in der Sekundarstufe I teilweise rechtfertigen kann, bringt hier die
unterrichtliche Betrachtung von verteilten Systemen folgende Erweiterungen:
• auf Hardwareseite bieten verteilte Systeme eine motivierende Grundlage
zur Betrachtung von lokalen Netzwerken. Behandelbar sind auch
Routingmechanismen in WANs (wide area networks).
• Wird der Schwerpunkt im Unterricht auf das Verständnis und die
Bedienung von modernen Softwareprodukten gelegt, so ist die Behandlung
von verteilten Systemen – wenn auch hier zunächst nur aus Benutzersicht –
sehr empfehlenswert, da diese Systeme grundlegende, in der Informatik
Seite 25

Didaktik der verteilten Systeme
zukunftsträchtige Kommunikationsfunktionen bieten, deren Kenntnis aus
dem hier zugrundegelegten Standpunkt heraus unverzichtbar ist.
Modellierung von Problemen, Prozessen und Abläufen
In dieser Definition der Bedeutung von Informatik wird der Schwerpunkt auf
Beschreibung, Abstraktion und Strukturierung von Problemen sowie der
Analyse und Lösung durch geeignete Prozesse und Abläufe gelegt.
Verteilte Systeme bilden in diesem Feld eine natürliche Ergänzung des
Unterrichtsstoffs, da sie in vielen Problemen bereits implizit enthalten sind.
Fast alle komplexeren Modellierungsaufgaben enthalten sich gegenseitig
beeinflussende Komponenten – diese können durchaus als Teile eines
verteilten Systems angesehen werden. Durch explizite Hinzunahme des
Unterrichtsgegenstands „verteilte Systeme“ kann hier der Stoff von einer
übergeordneteren Position aus strukturierter behandelt werden.
Allgemeine Wissenschaft der Informationsverarbeitung
Eine Betrachtung der Informatik als allgemeine Wissenschaft der
Informationsverarbeitung ist zumindest zum heutigen Zeitpunkt eine Illusion,
da viele Teile, insbesondere der menschlichen Informationsverarbeitung, nicht
von der Informatik abgedeckt werden können.
Sicherlich sind aber Prozesse der Informationsverarbeitung ein wichtiger Teil
der Informatik, und hier liefert die Behandlung verteilter Systeme eine
deutliche Erweiterung der vorstellbaren Aspekte. Es ergeben sich realistischere
Modelle z.B. in Hinsicht auf:
• Informationsverteilung
In vielen realistischen Systemen ist die insgesamt verfügbare Information
nicht an einem Ort gebündelt, sondern auf viele Einheiten verteilt. Gerade
wenn menschliche Informationen betrachtet werden, ist dies der einzige
mögliche Ansatz. In solchen Systemen auftretende Informations-
verarbeitung kann sinnvoll nur unter Einsatz verteilter Systeme behandelt
werden.
Seite 26

Didaktik der verteilten Systeme
• Informationsaustausch
Sollen Prozesse des Austauschs von Informationen beschrieben werden,
können aus dem Gebiet der verteilten Systeme kommende Aspekte wie
Synchronisation und Nebenläufigkeit nur dann unberücksichtigt bleiben,
wenn diese im konkret betrachteten Fall keine Rolle spielen. Dies ist aber
nur bei einem Teil der denkbaren Verarbeitungsmodelle der Fall – genau
die Modelle, die eine starre Reihenfolge der Verarbeitung voraussetzen und
keine parallelen Mechanismen betrachten.
Realistischere Modelle des Informationsaustauschs, bei denen oben
genannte Einschränkungen wegfallen, erfordern daher die Kenntnis einiger
Grundlagen aus dem Gebiet der verteilten Systeme.
• Fehler
Die im Unterricht thematisierbaren Typen von Fehlern bei der
Informationsverarbeitung werden bei ausschließlicher Verwendung
nichtverteilter Systeme deutlich eingeschränkt. Als Beispiel seien hier die
Möglichkeiten des Datenverlustes oder der Dateninkonsistenz angeführt.
Beide Effekte können bei rein lokaler Verarbeitung zurecht vernachlässigt
werden, da ihre Behandlung rein theoretisch bliebe. In verteilten Systemen
hingegen sind diese realistischen Probleme leichter darstellbar.
Automatisierung geistiger Tätigkeiten
Begreift man den Bildungswert der Informatik im Zusammenhang des
„historisch und kulturell bedeutsamen Bemühens um die Automatisierung
geistiger Tätigkeiten“ [Hoppe/Luther], so ist die Betrachtung verteilter Systeme
im Informatikunterricht aus drei Blickwinkeln heraus bedeutsam:
• historisch
In der im Vergleich zu anderen Wissenschaftsdisziplinen relativ jungen
Historie der Informatik sind sicherlich Aspekte, welche die Vernetzung von
Rechnersystemen betreffen, seit spätestens 1990 ein nicht wegzudenkender
Bestandteil. Der Zusammenhang der Nutzung dieser Vernetzung zum
Gebiet der verteilten Systeme ist offensichtlich.
Seite 27

Didaktik der verteilten Systeme
• kulturell
Sprache und die damit eng zusammenhängende Kommunikation sind
grundlegende Bausteine menschlicher Kultur. Verteilte Systeme benutzen
als zentrales Element genau diese Bausteine und sind analytisch daher gut
geeignet, zum Verständnis der Grundlagen dieser geistigen Tätigkeiten
beizutragen.
• geistige Tätigkeiten
Da geistige Tätigkeiten nur in wenigen Fällen völlig isoliert von der
Umwelt stattfinden können – oft ergeben sich wichtige Ideen erst als
Resultat vom häufigen Wechsel kommunikativer und reflektierender
Phasen –, kann die Bemühung um Automatisierung geistiger Tätigkeiten
sich nicht auf rein lokal stattfindende Berechnungsprozesse einschränken.
Verteilte Systeme liefern hier einen Ansatzpunkt zur Untersuchung
weitergehender Automatisierungsmöglichkeiten.
Zusammenfassend kann festgestellt werden, dass verteilte Systeme unabhängig
von der konkreten Definition des Bildungswertes der Informatik fachdidaktisch
durchaus bedeutsam sind. In vielen Teilgebieten der Schulinformatik bietet die
Behandlung verteilter Systeme die Möglichkeit, sowohl einerseits allgemeinere
Resultate herzuleiten als auch andererseits ein detaillierteres Verständnis von
Zusammenhängen zu erzeugen.
3.2 Behandlung im Unterricht
Aufgrund der Vielfältigkeit des Themas der verteilten Systeme gibt es eine
Fülle von prinzipiell möglichen Unterrichtssequenzen mit verschiedenen
Inhalten. Nachfolgend werden drei Beispiele angeführt, die auf sich deutlich
voneinander unterscheidenden Ansätzen beruhen. Die präsentierten Beispiele
lassen sich beispielsweise im Rahmen einer exemplarischen Unterrichts-
sequenz realisieren, ein eher integrativer Ansatz wird in Kapitel 3.3
beschrieben.
Seite 28

Didaktik der verteilten Systeme
3.2.1 Analytischer Zugang: Vergleich verteilter Systeme
In diesem Ansatz liegt der inhaltliche Schwerpunkt auf dem Vergleich
verschiedener existierender verteilter Systeme. Methodisch kann die Sequenz
(nach einer Einleitung durch den Lehrer) in Gruppenarbeit mit anschließender
Ergebnispräsentation in Referatsform und Diskussion im Klassenverband
durchgeführt werden.
Behandelt werden können etwa folgende inhaltliche Aspekte:
• Architektur
Vergleich der Architekturformen der betrachteten Systeme mit den
extremen Formen (dezentral und zentralisiert) und Diskussion der
spezifischen Eigenschaften dieser Architekturen (siehe 2.3.3)
• Funktionalität
Beschreibung der in den betrachteten Systeme verteilt realisierten
Funktionen.
• Vorteile
Analyse der Gründe für die Verteilung der betrachteten Systeme.
Insbesondere Aspekte wie Ressourcenteilung, Flexibilität und
Erweiterbarkeit (siehe 2.4.1) können hier im Vergleich zu nichtverteilten
Systemen betrachtet werden.
• Nachteile
Bewusstmachung der Risiken von verteilten Systemen. Als Beispiel kann
hier die Datensicherheit, z.B. anhand der Betrachtung von electronic
banking, dienen.
Dieser Zugang zu verteilten Systemen bleibt in vielen wichtigen Punkten
sicherlich nur oberflächlich, ermöglicht aber einen einfachen ersten Eindruck
der Möglichkeiten von Verteilung. Unterrichtsziele liegen größtenteils im
Umfeld vom „Umgang mit modernen Informations- und
Kommunikationsmedien“, ein Einsatz bietet sich vor allem im
Wahlpflichtbereich der Sekundarstufe I an.
Seite 29

Didaktik der verteilten Systeme
3.2.2 Theoretischer Zugang: Nebenläufige Prozesse
Dieser Ansatz beinhaltet weitgehend theoretische Überlegungen. Im Rahmen
einer Sequenz zur theoretischen Informatik wird hier das Problem der
Synchronisation nebenläufiger Prozesse (siehe 2.3.7) thematisiert und eine
Lösung durch Einsatz von Petri-Netzen gesucht.
Folgende Struktur der Sequenz ist denkbar:
1. Einführung
Präsentation eines einfachen, auf Synchronisation beruhenden, Problems,
z.B. der ungeregelte Zugriff mehrerer unabhängiger Prozesse auf eine
gemeinsame Variable.
2. Präsentation einer Lösungsmethode
Einführung von einfachen Petri-Netzen (z.B. S/T-Systemen) und Analyse,
wie diese Netze zur Zustandsbeschreibung eingesetzt werden können.
3. Entwurf einer einfachen Lösung
Mittels der Petri-Netze wird von den Schülern eine einfache Lösung des
Problems, z.B. über Sperrmechanismen, entwickelt.
4. Komplexere Lösungen
Angeregt durch den Lehrer werden mögliche Schwachstellen der
erarbeiteten Lösungen analysiert. Anhand eines komplexeren Problems,
beispielsweise des Philosophenproblems, werden die Mechanismen
überarbeitet. Am Ende dieses Teils Vorstellung der von den Schülern
erzielten Lösungen.
5. Verallgemeinerung
Hinweis auf die Bedeutsamkeit der erzielten Ergebnisse, z.B. in
Zusammenhang mit Ressourcennutzung und Nachrichtenbehandlung in
verteilten Systemen. Dieser Punkt kann auch als einleitende Fragestellung
an den Anfang der Sequenz gestellt werden.
Auch diese Unterrichtssequenz behandelt nur Teile des Gebiets der verteilten
Systeme, allerdings ist (im Sinne des exemplarischen Unterrichts) der Tiefgang
im Teilgebiet „Synchronisation“ recht groß.
Seite 30

Didaktik der verteilten Systeme
Als Vorkenntnisse sind nur grundlegende Programmierfertigkeiten zur
Realisierung der erarbeiteten Lösungen erforderlich, ein Einsatz dieser
Unterrichtssequenz kann daher ab der Jahrgangsstufe 11 erfolgen.
3.2.3 Algorithmischer Zugang: Protokolle
Eine auf dem Schwerpunktthema „Protokolle“ aufbauende Unterrichtseinheit
kann in Projektform ablaufen:
1. Auswahl eines Projektziels
Aus einer Anzahl von vom Lehrer vorgegebenen Auswahlmöglichkeiten
wird ein Projektziel bestimmt. Das Projekt sollte so beschaffen sein, dass
eine Schwerpunktlegung auf Nachrichten und Protokolle möglich ist und
nicht zu viele andere Probleme auftauchen. Als Beispiel dient i.f. der
Aufbau eines schulinternen E-Mail-Systems
2. Analyse der Nachrichtenflüsse
Die in der Realisierung des Projekts zu erwartenden Nachrichten werden
betrachtet. Im betrachteten Beispiel können dies etwa folgende sein:
• Mails an einzelne Personen
• Mails an Gruppen von Personen
• Empfangsbestätigungen
• Antworten
• Fehlermeldungen
3. Entwurf eines Protokolls
Ausgehend von den möglichen Nachrichten wird ein Protokoll entworfen,
dass in der Lage ist, diesen Nachrichtenverkehr zu regeln.
4. Programmierphase
Zunächst werden die nötigen Programmgerüste erstellt (hier: einfacher
Server zur Nachrichtenspeicherung und ein Programm zum Abrufen von
Nachrichten). Im zweiten Schritt werden in mehreren Gruppen die
Schnittstellen implementiert, wobei die vorher definierten Protokolle zu
beachten sind.
Seite 31

Didaktik der verteilten Systeme
5. Ergebnisbetrachtung
Test des Systems. Treten Fehler auf, sind folgende Möglichkeiten zu
unterscheiden:
• Fehler in den Programmgerüsten
• Fehler in den Schnittstellen
• Fehler im Protokoll
Insbesondere im letzten Fall sollte eine genaue Analyse und Diskussion
des Fehlers erfolgen.
Diese Unterrichtssequenz erfordert einige Programmiererfahrung und ist daher
ab der Jahrgangsstufe 12 sinnvoll durchführbar. Im Gegensatz zu den
Zugängen in 3.2.1 und 3.2.2 ist der motivierende Effekt der Erschaffung eines
nützlichen und einsetzbaren Programms vorhanden.
Fachlich steht das Thema „Protokolle“ im Mittelpunkt und kann auch (je nach
Projektthema) gut vertieft werden. Zusammenhänge zu dem in 3.3
beschriebenen Programmieransatz sind jedoch zu erkennen, wenn auch
aufgrund der Einfachheit des Themas nur in Ansätzen.
3.3 Der Programmieransatz
Das Programmieren hat im heutigen Informatikunterricht sicherlich eine
wichtige, wenn auch nicht unumstrittene Rolle. Einerseits darf
Informatikunterricht nicht zu einem Programmierkurs reduziert werden,
andererseits bietet gerade das Programmieren vielfältige Möglichkeiten zur
Realisierung und Abstraktion wichtiger Themen [Hoppe/Luther].
Betrachtet man das Programmieren als Primärerfahrung der Informatik,
vergleichbar mit dem Rechnen bei der Mathematik [Hoppe/Luther], so bietet die
Programmierung verteilter Systeme die Möglichkeit, sowohl zu elementaren
Einsichten über Prinzipien verteilter Systeme zu gelangen als auch auf diesen
Einsichten aufbauend zu abstrahieren und allgemeine Schlüsse zu ziehen.
Auch für die Programmierfertigkeiten der Schüler ist das Thema „verteilte
Systeme“ bedeutsam. Wird das zu erstellende Programm verteilt programmiert
Seite 32

Didaktik der verteilten Systeme
(einzelne Schüler oder Kleingruppen entwickeln Komponenten, die zur
späteren Zusammenarbeit mit anderen Komponenten gedacht sind), so ist eine
größere Kooperation unter den Schülern sowie die Einhaltung von festgelegten
Standards notwendig.
Entwurf und Entwicklung eines verteilten Systems beinhalten viele allgemeine
sowie informatische didaktische Aspekte, wobei deren Ausprägung durch das
konkret zu programmierende System beeinflusst wird:
Neben den in den Abschnitten 2.3 und 2.4 dargelegten Eigenschaften verteilter
Systeme, die fachdidaktisch durchaus bedeutsam sind, können noch folgende
informatische Ziele erreicht werden:
• Verallgemeinerung des prozeduralen Programmierens durch RPCs
• Einblick in Grundlagen des Software-Engineerings
• Über die reine Algorithmik hinausgehende Fehleranalyse
• Entwicklung und Verständnis von Kommunikationsmodellen
• Beachtung von Prinzipien der Datensicherheit
Allgemeindidaktische Ziele, die durch die (insbesondere verteilte)
Programmierung verteilter Systeme erreicht werden können, sind:
• Verallgemeinerung des Automatisierens geistiger Tätigkeiten
• Kooperation
• Handlungs- und Prozessplanung
• Einigung über gemeinsame und sinnvolle Standards
Eine Erläuterung der Methodik zum Erreichen dieser Ziele wird im Rahmen
der Beschreibung einer Unterrichtseinheit zur Robots-Umgebung in Kapitel 6
gegeben.
Seite 33

Didaktik der verteilten Systeme
3.4 Lehrplanbezug
Die aktuell gültigen Unterrichtsrichtlinien für Informatik in der Sekundarstufe
II stammen aus den Jahren 1981 (Grundkurs, siehe [RichtlinienGK]) bzw. 1991
(Leistungskurs, [RichtlinienLK]). Der Grundkurslehrplan wird allerdings nach
telefonischer Auskunft des Ritterbach-Verlags in der nächsten Zeit aktualisiert,
ein Entwurf ist im Internet zu finden [RichtlinienGKneu].
3.4.1 Grundkurs
Der aktuell gültige Grundkurslehrplan sieht vier Lernbereiche vor:
1. Algorithmik
2. Daten und Datenstrukturen
3. Hard- und Softwaresysteme
4. Realisierung, Probleme und Auswirkungen der praktischen
Datenverarbeitung
Die Behandlung verteilter Systeme ist explizit in keinem der Lernbereiche
vorgesehen, und auch mit den im Lehrplan detailliert aufgeführten
empfohlenen Unterrichtsinhalten stimmen Inhalte aus dem Gebiet „verteilte
Systeme“ nicht überein – sieht man von der Tatsache ab, dass sich unter den
allgemein gehaltenen Inhaltspunkten wie „Datenfluss und Datenorganisation“
oder „Modellbildung“ auch Teile verteilter Systeme behandeln lassen.
Grundsätzlich lässt sich feststellen, dass der gültige Grundkurslehrplan in
vielen technischen bzw. maschinennahen Bereichen Schwerpunkte setzt. Dies
wird verständlich, wenn man das Erscheinungsjahr berücksichtigt. Moderne
Inhalte, insbesondere auch in Richtung verteilter Systeme, sind aus
verständlichen Gründen nicht enthalten – 1981 hat noch keiner der für den
Lehrplan zuständigen Personen die in Kapitel 2.1 beschriebene rasante
Entwicklung vorausahnen können.
Seite 34

Didaktik der verteilten Systeme
Der Entwurf für den neuen Grundkurslehrplan ist sehr offen gestaltet und
beinhaltet wesentlich weniger Themen als die aktuellen Richtlinien. Ein
gesetzter Schwerpunkt ist die Ebene „Lernen im Kontext“, die exemplarischen
und handlungsorientierten Unterricht anhand von die Schüler interessierenden
Beispielen fordert. Als Beispiele werden Telekommunikation, Strategiespiele
und Datensicherheit ausdrücklich genannt.
Damit ist eine Unterrichtsreihe zur „Programmierung verteilter Systeme“, hier
insbesondere auch die in Kapitel 6 beschriebene „Robots“-Unterrichtsreihe,
durch den Lehrplanentwurf gerechtfertigt.
3.4.2 Leistungskurs
Der gültige Leistungskurslehrplan ist zehn Jahre jünger als der Grund-
kurslehrplan, beinhaltet aber dennoch die gleichen vier Lernbereiche.
Das Thema „verteilte Systeme“ ist auch hier nicht direkt vorgesehen, es sind
aber folgende Unterrichtsgegenstände enthalten:
• Schnittstellen als funktionale Spezifikation abstrakter Datentypen
• Veränderbarkeit der Implementierung bei gleicher Schnittstelle
• lokale Netzwerke
• Schnittstellenspezifikation als Teil des Entwurfsphase bei Software-
Entwicklung
• Prinzipien der Lokalität, Modularisierung und Mehrfachverwendung bei
Software-Entwicklung
• Gesellschaftliche Aspekte der Telekommunikation
• Problem der Überschaubarkeit von Systemen
Wie erkennbar ist, ist eine Unterrichtseinheit zum Thema „verteilte Systeme“
durchaus mit den im Lehrplan angegebenen Inhalten vereinbar, wenn auch
einige wichtige Aspekte von verteilten Systemen (z.B. Transparenz,
Architekturformen, Nebenläufigkeit, Synchronisation und Verifikation durch
Petri-Netze) nicht im Curriculum vorkommen.
Seite 35

Didaktik der verteilten Systeme
Im Vergleich zum Grundkurslehrplan von 1981 wird deutlich, dass 1991
bereits einige Tendenzen zur Verteilung von Systemen voraussehbar waren,
insbesondere waren Netzwerke bekannt und (zu einem damals noch geringen
Teil) in Schulen installiert.
3.5 Fazit
Das Gebiet der verteilten Systeme bietet eine breite Palette von modernen
informatischen Inhalten, deren fachdidaktische Relevanz zum Teil erheblich
ist. Beispiele sind hier:
• Problem der Synchronisation nebenläufiger Prozesse und seine Lösung
durch Einsatz von Petri-Netzen
• Prinzipien der Rechnerkommunikation: Einsicht in die Funktion von
Schnittstellen und Protokollen
• Vergleich von verteilten und nichtverteilten Systemen: Realisierung der
Vorteile und Nachteile von Verteilung.
Die technische Ausrüstung heutiger Gymnasien spricht einer Unterrichtsreihe
zum Thema „verteilte Systeme“ nicht entgegen. An den meisten Schulen
finden sich heute relativ moderne, vernetzte PCs. Durch die Initiative „Schulen
ans Netz“ hat ein großer Teil der Schulen sogar Zugriff auf das Internet.
Der Lehrplan im Leistungskurs ermöglicht die Behandlung verteilter Systeme
im Informatikunterricht, wenn er sie auch nicht direkt fordert oder als
empfehlenswert klassifiziert. Dies hängt wohl mit dem Erscheinungsjahr 1991
zusammen, in dem verteilte Systeme noch nicht die heutige Bedeutung hatten.
Im Grundkursbereich ist aus dem aktuellem Lehrplan eine Rechtfertigung der
Behandlung verteilter Systeme im Unterricht nicht direkt ableitbar. Die
(vorläufigen) neuen Richtlinien hingegen ermöglichen dies.
Seite 36

Didaktik der verteilten Systeme
Insgesamt erscheint eine Unterrichtsreihe über verteilte Systeme im
Informatikunterricht der Sekundarstufe II didaktisch gerechtfertigt und nach
den technischen Möglichkeiten an den meisten Schulen durchführbar.
Eine auf der (z.T. verteilten) Programmierung verteilter Systeme aufbauende
Unterrichtsreihe wird nach der Vorstellung der dafür geschriebenen
Programmierumgebung in Kapitel 6 angegeben.
Seite 37

Die „Robots“-Umgebung
4 Die „Robots“-Umgebung
4.1 Kurzbeschreibung
Robots ist eine verteilte Spielumgebung, die primär für den Einsatz im
Informatikunterricht der Sekundarstufe II gedacht ist. Grundlegende
Eigenschaften der Robots-Umgebung werden im folgenden kurz beschrieben.
Auf einem zweidimensionalen Spielfeld, welches im Regelfall aus Gras- und
Wasserfeldern besteht, können Roboter agieren. Die Aktionsmöglichkeiten der
Roboter lassen sich grob in 5 Kategorien einteilen:
• Bewegung
• Objekte nehmen und ablegen
• Roboterinteraktion
• Roboterkommunikation
• Spielspezifische Aktionen
Die Bewegungsaktionen (warten, nach vorne und hinten gehen, nach rechts
und links drehen, rennen) dienen der Fortbewegung des Roboters auf dem
Spielfeld, die objektbezogenen Aktionen betreffen das Aufnehmen und
Ablegen von Gegenständen auf dem Spielfeld. Roboterinteraktion ist primär
durch die Möglichkeit des Berührens anderer Roboter verwirklicht.
Durch das Ablegen von Notizen sowie das Senden von Nachrichten haben die
Roboter zusätzlich die Möglichkeit, miteinander auf verschiedene Arten zu
kommunizieren. Letztlich kann jedes Spiel noch spezifische Aktionen
erlauben, siehe hierzu die Abschnitte 4.3.2 ff.
Die spiellogischen Auswirkungen der Aktionen, insbesondere die der Aktionen
in den letzten drei Kategorien, werden durch Regelwerke festgelegt. Durch
Änderung des Regelwerks ergeben sich somit verschiedene Spiel-
möglichkeiten, die völlig unterschiedliche Ziele, Spielfelder, Aktions-
möglichkeiten und Kooperationsanforderungen (insbesondere bei
Seite 38

Die „Robots“-Umgebung
gruppenbasierten Spielen) beinhalten können. Beispiele für Spielregeln werden
in den Abschnitten 4.3.2 ff. gezeigt.
Innerhalb der Robots-Umgebung existieren genaugenommen zwei
verschiedene verteilte Systeme, die unabhängig voneinander im Unterricht
behandelbar sind und auch unterschiedliche didaktische Möglichkeiten bieten.
Zunächst ist das System selbst, bestehend aus der Serveranwendung und den
Clientanwendungen, ein verteiltes System. Aber auch die „Roboterwelt“ ist
verteilt. Lässt man die Umgebung beiseite und bezieht sich nur auf die Roboter
mit ihren Aktions- und (vor allem) Kommunikationsmöglichkeiten, so liegt
auch hier ein verteiltes System vor, welches das eigentliche Spiel repräsentiert.
4.2 Grundlegende Konzepte des Aufbaus
4.2.1 Spielfeld: Positionen und Attribute
Das Spielfeld in der Robots-Umgebung ist in der Klasse Mastergame
dargestellt und besteht im Wesentlichen aus einem zweidimensionalen Feld
von Spielfeldpositionen (Klasse Position).
Jede Position wiederum besteht aus einer Betretbarkeitsinformation und einer
Liste von Attributen (Klasse Attribute). Diese Attribute stellen alles das
dar, was sich auf der Position befindet, so zum Beispiel den Boden, die Spieler
oder auch zurückgelassene Notizen. Sie bestehen aus zwei Variablen:
• name (String): Name des Attributs (z.B. „Player“, „Ground“,
„Notice“,...)
• object (Object): „Daten“ des Attributs (falls nötig), z.B. Informationen
über die Bodenstruktur, den Inhalt einer Notiz etc.
Ähnlich wie die Betretbarkeitsinformation bei Positionen besitzen Attribute
Informationen über Lesbarkeit und Entfernbarkeit. Diese Informationen
können folgender Art sein (Beispiele hier für den Fall „Attribut entfernbar“,
restliche Fälle analog):
Seite 39

Die „Robots“-Umgebung
Information Attribut entfernbar für Beispiel
always jeden Roboter Notizen
never keinen Roboter Boden oder Spieler
canSwim Roboter, die schwimmen
können
Player=XXX Roboter mit dem Namen XXX (Spiel Goldsuche): Bei Heimatbasis
-
abgelegtes Gold
Group=XXX Roboter der Gruppe XXX -
Ground=XXX jeden Roboter, wenn der Boden
des Feldes XXX ist
(Spiel Goldsuche): Auf dem Feld
liegendes Gold ist nur entfernbar,
wenn gegraben worden ist
Attribute liegen standardmäßig fest auf einer Position und können nur durch
Roboteraktionen (bzw. genauer gesagt durch die Reaktion eines Regelwerks
auf diese Aktionen) entfernt oder hinzugefügt werden.
Durch einen AttributeMover ist es jedoch auch möglich, bewegliche
Attribute, die sich ohne Fremdeinwirkung fortbewegen, zu benutzen. Beispiel
für bewegliche Attribute sind die Schneebälle beim Spiel „Winterspiele“.
4.2.2 Akteure: Roboter und Spieler
Die auf dem Spielfeld agierenden Objekte sind Roboter. Jeder Client definiert
zunächst einen Roboter in Hinsicht auf folgende Punkte:
• Aussehen:
Das „Aussehen“ eines Roboters besteht aus vier Bildern, in denen der
Roboter von hinten, rechts, vorne und links zu sehen ist, sowie aus einem
Bild der Heimatbasis (nur wichtig in Spielen, bei denen eine solche benutzt
wird).
• Name:
Jeder Roboter besitzt einen Namen, anhand dessen er im Spiel identifiziert
wird.
• gewünschte Gruppe:
Die gewünschte Zugehörigkeit zu einer Gruppe kann vom Roboter
angegeben werden, es ist jedoch Sache des Regelwerks, diese Wünsche zu
Seite 40

Die „Robots“-Umgebung
berücksichtigen oder zurückzuweisen (für ein Solospiel oder eine andere,
vom Server bestimmte Gruppeneinteilung).
• Eigenschaften
Es existieren mehrere charakteristische Eigenschaften, die ein Roboter hat
(oder haben kann):
- Fähigkeit zu rennen
- Fähigkeit zu schwimmen
- Anzahl der maximal gleichzeitig tragbaren Gegenstände
- Sendeleistung (angegeben in Anzahl von Feldern)
- Berührdistanz (Entfernung, über die andere Roboter berührt werden
können, angegeben in Feldern)
- Sichtweite und Sichtwinkel (90, 180 oder 360 Grad)
Ein beliebig guter Roboter ist jedoch nicht erstellbar, die maximal
erlaubten Grenzen werden in Kapitel 5.3.1 erläutert.
• Algorithmus:
Das eigentliche „Herzstück“ eines Roboters ist der Algorithmus, also die
Vorschrift, die angibt, welche Aktionen (siehe Abschnitt 4.2.3) der Roboter
in Abhängigkeit vom subjektiv wahrgenommenen Spielstand durchführt.
Es existieren prinzipiell zwei Möglichkeiten, einen Roboteralgorithmus zu
programmieren:
Durch Überlagerung der getAction-Methode ist es möglich, nach
Abfrage der Spielfeldumgebung eine Aktion zurückzuliefern.
Durch Überlagerung der doActions-Methode besteht hingegen die
Möglichkeit, beliebig viele Aktionen innerhalb eines Methodenaufrufes
durchzuführen. Außerdem ist hier eine detaillierte Kontrolle darüber
möglich, welche Informationen wann vom Server abgefragt werden.
Beide Varianten funktionieren im Echtzeitmodus. In einem rundenbasierten
Spiel ist wird jedoch nur die getAction-Methode abgefragt, somit ist die
zweite Variante hier nicht geeignet.
Das Abfragen der getAction-Methode im Rundenmodus liegt darin
begründet, dass es ja genau der Sinn und Zweck dieses Modus ist, dass die
Spieler der Reihe nach je genau einen Zug durchführen können.
Seite 41

Die „Robots“-Umgebung
Prinzipiell ist es auch zumindest im Echtzeitmodus möglich, gar keinen
Algorithmus zu definieren und das Spiel manuell über
Benutzerkommandos zu steuern. Auch wenn dies sicherlich nicht der
primäre Sinn der Robots-Umgebung ist, so sind die direkten
Benutzerkommandos zumindest zu Testzwecken oder für „Mensch gegen
Mensch“ bzw. „Mensch gegen Maschine“-Spiele recht gut nutzbar.
Ist der Roboter komplett definiert, so kann er sich beim Server anmelden und
nach erfolgreicher Anmeldeprozedur am Spiel teilnehmen.
Serverseitig wird aus dem Roboter ein Spieler (Klasse Player) mit
identischem Namen, Aussehen und gleichen Eigenschaften konstruiert. Ein
Spieler hat jedoch zusätzlich noch weitere Informationen, die sich in zwei
Gruppen klassifizieren lassen:
vom Client abfragbare Informationen:
Beispiele sind hier die Gruppe, der Punktestand, die empfangenen Nachrichten,
die mitgeführten Gegenstände, der Markierungszustand oder die Blickrichtung
serverinterne Informationen:
z.B. interne Statusvariablen, Informationen über Zugberechtigung und Position
des Roboters
4.2.3 Aktionen
Die Aktionen der Roboter werden durch Objekte der Klasse Action
beschrieben. Generiert in den auf Clientseite liegenden Algorithmen (oder die
dortigen Benutzerinterfaces) und an den Server per RMI an die Methode
performAction im Regelwerk weitergeleitet, besteht eine Aktion aus zwei
Komponenten:
• command (String): Name der Aktion
• data (Object): Eventuelle Parameter
Seite 42

Die „Robots“-Umgebung
Unabhängig vom Regelwerk existieren stets folgende Basisaktionen:
Name Parametertyp Beschreibung
warte - Nichts tun
gehe „vor“ oder „zurück“ Bewegen des Roboters
renne - 2 Felder vor auf einmal gehen
drehe „links“ oder „rechts“ Drehen des Roboters um 90 Grad
nimm auf Attribute Aufnehmen des durch das übergebene
Attribut beschriebenen Gegenstands
lege ab Attribute Ablegen des durch das übergebene Attribut
beschriebenen Gegenstands
hinterlasse Notiz Object Hinterlassen einer Notiz, deren Inhalt das
übergebene Objekt ist
sende Object Senden einer Nachricht, deren Inhalt das
übergebene Objekt ist
berühre Player Berühren des übergebenen Spielers
Jedes Regelwerk kann noch beliebig viele weitere gültige Aktionen definieren,
eine genauere Beschreibung hierüber wird im folgenden Unterkapitel gegeben,
Beispiele sind in den Abschnitten 4.3.2 ff. angeführt.
4.2.4 Regelwerke
Verschiedene Spiele, so unterschiedlich sie auch zunächst aus vielen
Gesichtspunkten sein mögen, unterscheiden sich neben dem Spielfeld letztlich
nur durch das Regelwerk. Regelwerke sind bei Robots durch RuleManager
verwirklicht. Die Klasse BasicRuleManager liefert die Steuerungslogik
eines „neutralen“ Spiels ohne wirkliche Spielregeln. Durch Überlagerung
dieser Klasse lassen sich „echte“ Spielregeln realisieren, Beispiele siehe
Abschnitte 4.3.2 ff.
Neben Methoden, die einmalig beim Spielbeginn und –ende sowie bei An- und
Abmeldung eines Spielers aufgerufen werden, reagiert der RuleManager vor
allem auf Aktionswünsche der Roboter. Die Bearbeitung eines
Aktionswunsches geschieht in 4 Schritten:
Seite 43

Die „Robots“-Umgebung
1) Allgemeine Überprüfungen:
Ist der aktionswillige Spieler angemeldet ?
Hat der Spieler Zugberechtigung ?
Läuft das Spiel ?
2) Klassifikation der Aktion:
Überprüfung, ob es sich bei der übergebenen Aktion XXX um eine
Standardaktion handelt. Ist dies der Fall, so wird die Methode
performXXX aufgerufen, andernfalls die Methode
performGeneralAction. In diesen (überlagerbaren) Methoden wird
die Aktion dann durchgeführt und bei Erfolg die Rückgabe „ok“ geliefert.
3) Reaktion auf Aktionsdurchführung:
War der Rückgabewert unter 2) „ok“, so wird (bei durchgeführter Aktion
XXX) nun die (ebenfalls überlagerbare) Methode XXXperformed
aufgerufen, die die Auswirkungen einer erfolgreichen Aktion des Typs
XXX realisiert.
4) Überprüfung auf Spielende:
Als letzter Schritt wird nun geprüft, ob das Spiel aufgrund der
durchgeführten Aktion beendet ist. Dies geschieht durch Abfrage der
Methode checkEnd.
Ziel dieser Art und Weise der Aktionsbehandlung ist es, die Erstellung von
neuen Regelwerken so einfach wie möglich zu gestalten. Soll beispielsweise
ein Spiel geschrieben werden, in dem das Berühren eines Roboters einen
speziellen Effekt hat, so ist lediglich die contactPerformed-Methode des
BasicRuleManagers zu überlagern, die die Reaktion auf bereits erfolgte
Aktion „Berühren“ beschreibt.
Mit der eigentlichen Aktionsdurchführung in Bezug auf Änderungen am
Spielfeld, z.B. beim Aufnehmen von Gegenständen, hat der Entwickler neuer
Spiele zumindest bei den Standardaktionen nur selten zu tun.
Seite 44

Die „Robots“-Umgebung
4.2.5 Hilfen für den Roboter
Ein grundlegendes Ziel bei der Entwicklung von Robots war es, dass bei der
Programmierung der Roboteralgorithmen die Tatsache, dass die Umgebung
verteilt ist, sich nur auf der „Roboterebene“, also der Kommunikation zwischen
den Robotern, bemerkbar macht. Die zur Verständigung zwischen Server und
Client notwendigen Routinen sind daher gekapselt und stehen jedem Roboter
anhand von drei Klassen zur Verfügung:
• ActionManager
Der ActionManager dient zur Übermittlung von Aktionen an den
Server. Zentral ist die Methode doAction(Action), die genau dieses
leistet.
• InformationManager
Der InformationManager liefert dem Roboter Informationen über
den aktuellen Spielstand (diese werden vom Server geholt). Wichtigste
Spielstandinformationen sind: Gruppe des Roboters, Punktstand,
Blickrichtung, neu empfangene Nachrichten, Markierungszustand und
getragene Gegenstände
• LocalEnvironment
Das LocalEnvironment stellt die lokale Umgebung des Roboters dar.
In einem Radius von standardmäßig 10 Feldern wird die Umgebung des
Roboters „zwischengespeichert“. Ziele dieser Zwischenspeicherung sind
die Ermöglichung einer akzeptablen Bildschirmdarstellung und die Option
für die Roboter, auch auf Positionen zuzugreifen, die nicht im aktuellen
Sichtfeld liegen. Zu beachten ist jedoch, dass nur die Positionen innerhalb
des Sichtfeldes auch gesichert „aktuell“ sind in der Hinsicht, dass sich
andere Felder mittlerweile ohne Wissen des Roboters geändert haben
könnten.
Eine Abfrage der Umgebungspositionen ist über die Methode
getPosition(int forward, int rightward) möglich, die
genau die Position zurückgibt, die forward Felder vor und rightward
Seite 45

Die „Robots“-Umgebung
Felder rechts des aktuellen Roboters (alles bezogen auf dessen
Blickrichtung) liegt.
Durch Verwendung dieser Klassen wird unter anderem die Fehlerabfrage und
die automatische Aktualisierung der Bildschirmausgabe geleistet, weiterhin
dienen die Hilfsklassen zur Vereinfachung der Roboterprogrammierung.
4.3 Beispiele
Zur Veranschaulichung der unter 4.2 aufgeführten Konzepte für Roboter und
Regelwerke werden in diesem Kapitel die bei Robots standardmäßig
vordefinierten Roboter und Robotertypen (Roboter mit Eigenschaften und
Bilddaten, aber ohne Algorithmus) sowie die drei vorhandenen Spiel-
möglichkeiten vorgestellt.
4.3.1 Roboter
In Robots sind fünf Roboter vordefiniert, die jeweils ihre eigene
Eigenschaftscharakteristik und Bilddaten besitzen. Diese Roboter können
durch eigene Roboterklassen so erweitert werden, dass der reine „warte“-
Algorithmus, den die hier vordefinierten Roboter haben, durch eine sinnvollere
Befehlsvorschrift überlagert wird.
CarryRobot
Ein CarryRobot kann 30 Gegenstände tragen und hat eine
Sicht von 3 Feldern bei 180 Grad Sichtwinkel. Dieser Roboter
hat eine schwache Sendeleistung von nur 2 Feldern Reichweite und kann keine
anderen Roboter berühren. Auch kann er weder rennen noch schwimmen.
Seite 46

Die „Robots“-Umgebung
ContactRobot
Herausragende Eigenschaft eines ContactRobot ist es,
andere Roboter auf 2 Felder Entfernung berühren zu
können. Die Sendeleistung ist mit 4 Feldern Reichweite gut, das Sichtfeld
beträgt 2 Felder bei 360 Grad Sichtwinkel. Dieser Roboter kann allerdings nur
4 Gegenstände tragen und weder rennen noch schwimmen.
HiTechRobot
Ein HiTechRobot kann rennen und schwimmen.
Weiterhin hat er ein enorm großes Sichtfeld von 4 Feldern
bei Rundumsicht. In allen anderen Punkten ist dieser Roboter aber eher
schwach. Er hat eine geringe Sendeleistung von nur 2 Feldern Reichweite und
kann nur 2 Gegenstände tragen. Außerdem fehlt ihm die Möglichkeit, andere
Roboter zu berühren.
RunRobot
Ein RunRobot kann (wie der Name schon andeutet ...)
rennen. Weiterhin hat er ein großes Sichtfeld von 5 Feldern
bei 180 Grad Sichtwinkel. Dieser Roboter kann 8 Gegenstände tragen und
andere Roboter, die direkt neben ihm stehen, berühren. Die Sendeleistung ist
mit nur einem Feld Reichweite sehr gering. Auch kann ein RunRobot nicht
schwimmen.
SwimRobot
Ein SwimRobot kann schwimmen, aber nicht rennen.
Maximal 12 Gegenstände sind gleichzeitig tragbar, die
Sendeleistung liegt bei nur 2 Feldern Reichweite. Das Sichtfeld eines
SwimRobot beträgt 4 Felder bei 90 Grad Sichtwinkel, und andere Roboter,
die direkt neben ihm stehen, können berührt werden.
Seite 47

Die „Robots“-Umgebung
Als Beispiel für die Roboterprogrammierung dienend, sind bei Robots zwei
Roboter mit Algorithmus bereits vorhanden. Gedacht sind diese für das Spiel
„Goldsuche“, welches im folgenden Abschnitt beschrieben ist.
GoldSearchRobot
Der GoldSearchRobot sucht Gold und bringt dies zu seiner Heimatbasis.
Er hat folgende Handlungsvorschrift:
1. Falls schon 2 Goldstücke gesammelt sind , dann gehe einen Schritt
zur Heimatbasis zurück.
2. Ist die aktuelle Position die Basisposition und wird ein Goldstück
getragen, so lege Gold ab.
3. Ist das aktuelle Feld noch nicht umgegraben, so tue dies.
4. Ist Gold auf aktueller Position, so nimm es auf.
5. Trifft nichts von 1. bis 4. zu, so bewege dich zufallsgesteuert weiter
GoldHunterRobot
Der GoldHunterRobot ist sozusagen das „Gegenstück“ zum
GoldSearchRobot. Er gräbt nicht, sondern versucht, durch das Stehlen von
Gold zum Sieg zu kommen.
Algorithmus:
1. Falls ein Spieler in Berührungsdistanz ist, berühre ihn
2. Falls ein Spieler innerhalb von 5 Feldern ist, bewege dich einen
Schritt hin
3. Sonst: Zufallsbewegung
4.3.2 Spiel „Goldsuche“
Das Spiel „Goldsuche“ wird durch den GoldRuleManager geleitet und hat
informell beschrieben folgende Regeln:
Auf jedem Grasfeld liegt mit 20prozentiger Wahrscheinlichkeit Gold.
Dieses ist sichtbar, wenn auf dem Feld gegraben worden ist (Aktion
Seite 48

Die „Robots“-Umgebung
"grabe"). Jeder Spieler startet an seiner Heimatbasis, an der er Gold
ablegen kann, ohne dass andere Spieler dieses aufnehmen können. Für
jedes Goldstück, das ein Spieler besitzt oder an seiner Heimatbasis
abgelegt hat, erhält er einen Punkt. Erreicht jemand 10 Punkte, ist das
Spiel beendet. Das "Berühren" anderer Spieler wird zum "Berauben":
hat der berührte Spieler Gold bei sich, so „wandert“ eines dieser
Goldstücke zum Dieb.
Spieltechnische Besonderheiten:
Einzelspiel, bedingt sichtbare Objekte, Verwendung von Heimatbasen
Besondere Aktionen:
„grabe“ (Parameter: keine)
4.3.3 Spiel „Winterspiele“
Durch den WinterRuleManager definiert, bestehen die „Winterspiele“ aus
folgenden Regeln:
In einer verschneiten Landschaft können Schneemänner gebaut (Aktion
"Schneemann") und Schneebälle geworfen werden (Aktion "werfe"),
wobei der Bau eines Schneemannes 10 Runden dauert. Das "Berühren"
anderer Roboter hat den Effekt, dass diese mit Schnee "eingeseift"
werden. Trifft einen Roboter dieses Schicksal, so wird ihm kalt
(genauso, wenn ihn ein Schneeball trifft). Schneemänner können
fliegende Schneebälle abfangen. Ein Spielende ist direkt nicht
vorgesehen, Ziel ist es jedoch, bei all diesen Aktionen so warm wie
möglich zu bleiben.
Spieltechnische Besonderheiten:
Einzelspiel, bewegliche Objekte, Aktionen mit mehreren Runden Dauer
Besondere Aktionen:
„werfe“ (ohne Parameter)
„Schneemann“ (ohne Parameter)
Seite 49

Die „Robots“-Umgebung
4.3.4 Spiel „Erobere die Fahne“
Das komplexeste hier gegebene Beispiel ist „Erobere die Fahne“, gesteuert
durch den FlagRuleManager. Beschreibung:
Das Spiel „Erobere die Fahne“ verläuft in zwei Gruppen, die jeweils
eine Fahne besitzen. Ziel ist es, dass ein Spieler der eigenen Gruppe
unbeschädigt das Feld betritt, auf dem die Fahne der anderen Gruppe
steht. Beschädigungen eines Roboters können erfolgen durch
1. das Berührt-Werden durch einen anderen Roboter (mit
50prozentiger Wahrscheinlichkeit).
2. das Laufen in eine Falle.
Jeder Roboter hat Fallen bei sich (die Hälfte der Anzahl der maximal
tragbaren Gegenstände), die er durch einfaches Ablegen auf jedem
Grasfeld verstecken kann . Fallen können durch die Aktion "suche" im
Radius der Berührdistanz eines Roboters sichtbar gemacht werden.
Steht man direkt vor einer Falle, so kann diese durch "entschärfe"
entfernt werden. Kosten: "suche" 5 Runden, „entschärfe" 10 Runden.
Beschädigte Roboter werden in der Nähe ihrer eigenen Fahne
automatisch wieder repariert. Auf dem Spielfeld sind außerdem felsige
Felder zu finden, auf denen eine Bewegung 3 Runden dauert.
Spieltechnische Besonderheiten:
Gruppenspiel, nicht sichtbare Objekte, Aktionen mit mehreren Runden
Dauer
Besondere Aktionen:
„suche“ (parameterlos)
„entschärfe“ (parameterlos)
Seite 50

Die „Robots“-Umgebung
Beispiele für Spielszenarien: „Erobere die Fahne“ und „Winterspiele“
Seite 51

Einzelheiten zu „Robots“
5 Einzelheiten zu „Robots“
In diesem Kapitel wird auf informatische und grundlegende didaktische
Aspekte von Robots eingegangen. Weiterhin werden Beispiele für den
denkbaren Einsatz der Umgebung im Informatikunterricht gegeben, ohne
hierbei der im nächsten Kapitel vorgestellten Unterrichtsreihe zu weit
vorzugreifen. Schließlich werden auch die Grenzen von Robots –
insbesondere in Hinsicht auf realisierbare Spiele – beschrieben.
5.1 Informatische Aspekte
In diesem Abschnitt werden einige, größtenteils mit dem Gebiet der verteilten
Systeme zusammenhängende, wichtige Aspekte der Robots-Umgebung
genannt und kurz diskutiert.
a) Programmiersprache:
Robots ist komplett in Java (JDK 1.2) geschrieben. Die Begründung der Wahl
von Java liegt darin, dass Java eine moderne, die objektorientierte
Programmierung unterstützende Sprache ist, die zusätzlich (im Vergleich etwa
zu C++ oder Delphi) zu den Standardsprachen in Netzanwendungen,
insbesondere im Internet, gehört.
Die in Java zur Verfügung stehenden Operationen zur Erstellung von verteilten
Systemen - hier vor allem die RMI-Methoden - sind in der Handhabung recht
einfach sowie gut erklärbar.
Ein Nachteil von Java ist die Geschwindigkeit. Lässt man beispielsweise
mehrere Clients auf einem Rechner parallel laufen, so wird dies an der doch
merklichen Geschwindigkeitsabnahme deutlich. Im einem normalen Spiel, in
dem die einzelnen Clientanwendungen auf verschiedenen Rechnern laufen,
treten jedoch die in Kapitel 2 genannten Vorteile von verteilten Systemen zu
Seite 52

Einzelheiten zu „Robots“
Tage. Die Lastenteilung bewirkt eine im Vergleich zur Einzelplatzanwendung
deutlich bessere Performance.
b) Kommunikationsmechanismus:
Wie unter a) schon kurz angedeutet, ist die Kommunikation zwischen Client
und Server über RMI gelöst, wobei sowohl der Server als auch jeder Client je
eine Schnittstelle besitzen, wobei die Client-Schnittstelle im Wesentlichen für
den serveraktiven Rundenmodus benötigt wird.
Eine Alternative zur direkten Verwendung von Java-RMI wäre sicherlich der
Einsatz des Java MatchMakers gewesen, eine Begründung der getroffenen
Wahl findet sich in Kapitel 7.2.
c) Architektur
Unter a) und b) wurde bereits erwähnt, dass die Robots-Umgebung auf einer
klassischen Client/Server-Architektur beruht. Wie bereits in Kapitel 2 genannt,
liegen die Vorteile dieser Architektur in der einfacheren Handhabbarkeit,
insbesondere das dynamische An- und Abmelden von Spielern sowie die
Übermittlung zentraler Daten wie Spielregeln, -beginn und -ende sind in dieser
Architekturform leichter lösbar als in einer dezentraleren Form. Auch
Synchronisationsprobleme bei Roboteraktionen lassen sich besser handhaben.
Der in Kauf genommene Nachteil bei einer Client/Server-Architektur ist die
Abhängigkeit vom Server – bei Ausfall ist kein Spiel möglich.
Innerhalb der „Roboterwelt“ ist jedoch die Architektur des eigentlichen
Systems nicht direkt erkennbar, da die Roboter ja durchaus in der Lage sind,
scheinbar direkt mit anderen Robotern kommunizieren zu können. In dieser
Betrachtungsweise erscheint das System dem Benutzer als dezentral.
d) Kommunikationsform
Die Serveranwendung und die Clientanwendungen übermitteln ihre
Nachrichten synchron, wobei der Grad der Synchronität im serveraktiven
Rundenmodus höher ist als im clientaktiven Echtzeitmodus. In letzterem kann
ein Client nach erfolgter Anmeldung durchaus auch „nichts“ tun bis er die
Seite 53

Einzelheiten zu „Robots“
Meldung bekommt, dass das Spiel beendet ist. Hierauf erfolgt eine
automatische Reaktion des Systems.
Roboter können hingegen miteinander asynchron und synchron
kommunizieren. Das Ablegen von Notizen auf dem Spielfeld entspricht genau
der asynchronen Form: es ist hier zeitlich i.A. nicht vorhersehbar, wann eine
Nachricht ankommt. Das Senden von Nachrichten hingegen ermöglicht eine
synchrone Kommunikation.
5.2 Didaktische Aspekte
Anhand der Robots-Umgebung ist es möglich, zentrale mit dem Gebiet der
verteilten Systeme zusammenhängende Fragestellungen im Unterricht zu
thematisieren. Als Beispiel hierfür können die Begriffe
• Protokolle
• Schnittstellen
• Synchronisation und Nebenläufigkeit
• Kommunikationsformen
• Datensicherheit
genannt werden.
Weiterhin ist durch die Struktur des Programmcodes , insbesondere durch die
relativ leichte Änderbarkeit der Spielregeln, ein einfacher Einstieg in die
konkrete Programmierung verteilter Systeme möglich. Auf der Ebene der
Roboterprogrammierung ist auch echte verteilte Programmierung eines
verteilten Systems realisierbar. Eine genauere Beschreibung der didaktischen
Einsatzmöglichkeiten findet sich in Kapitel 3.3 und der Unterrichtsreihe in
Kapitel 6.
Seite 54

Einzelheiten zu „Robots“
5.3 Einsatzmöglichkeiten
5.3.1 Interaktiv gesteuertes Spiel
Die einfachste Möglichkeit der Benutzung von Robots ist sicherlich das
Spielen eines vorgegebenen Spiels mit Direktsteuerung der Roboter.
Hierbei kann entweder einer der Beispielroboter verwendet oder ein eigener
Roboter mit selbstdefinierten Eigenschaften erzeugt werden.
Für alle Roboter gilt die Einschränkung, dass sie nur 40 „Eigenschaftspunkte“
haben dürfen, andernfalls werden sie von Server als „unfair“ abgelehnt. Die
Eigenschaftspunkte setzen sich wie folgt zusammen:
Roboter kann rennen: 10 Punkte
Roboter kann schwimmen: 10 Punkte
Berührdistanz: (10 ⋅ Distanz) Punkte
Tragen: (Anzahl der tragbaren Gegenstände) Punkte
Senden: (2 ⋅ Sendereichweite) Punkte
Sicht: (Sichtweite ⋅ Sichtwinkel/90) Punkte
Der Einsatz von Robots als direkt interaktiv gesteuertes Netzwerkspiel
beinhaltet je nach verwendetem Regelwerk bereits implizit einige mit dem
Gebiet der verteilten Systeme zusammenhängende Themen. Bei
Gruppenspielen ist die Kommunikation ein entscheidender Faktor zum
erfolgreichen Spiel, und auch der Punkt der lokalen Kontrolle - bei Robots
vor allem durch die lokale Sicht der Roboter vorhanden - wird durch die
Tatsache bemerkbar, dass sich das Spielgeschehen „rund um den eigenen
Roboter“ unbemerkt ändern kann.
Seite 55

Einzelheiten zu „Robots“
5.3.2 Algorithmen I: einfache Robotersteuerung
Sozusagen die „Fortsetzung“ der Direktsteuerung von Robotern ist die
Hinzunahme einer automatischen Steuerung. Die Programmierung einer
solchen Steuerung wurde bereits in Kapitel 4.2.2 kurz skizziert und soll hier
nochmals verdeutlicht werden.
Jeder aus der Klasse AbstractRobot abgeleitete Roboter besitzt die
Methode „Action getAction(String lastresult)“. Wie zu
erkennen ist, erhält diese Methode als Übergabewert das Ergebnis der letzten
Aktion, sie selbst muss als Rückgabe die nächste Aktion liefern.
Durch Verwendung der in Anhang A.5 dokumentierten Methoden und
Variablen lässt sich somit auf einfache Art und Weise eine Robotersteuerung
programmieren. Als Beispiel sei hier folgende triviale Steuerung gezeigt:
1) Wenn direkt vor mir ein anderer Roboter ist, so berühre ihn
2) Sonst: gehe solange geradeaus wie möglich, dann drehe nach rechts
public Action getAction(String lastresult)
{
}
// Abfrage der Position direkt vor Roboter
Position vor_mir = getEnvironment().getPosition(1,0);
// Ist ein anderer Roboter auf der Position ?
Attribute anderer_Roboter = vor_mir.getAtribute(„Player“);
if (anderer_Roboter != null) {
}
// berühre den Roboter
return new Action(„berühre“,anderer_Roboter.getData());
// gehe vor, solange der letzte Schritt funktioniert hat
if (lastresult.equals(„ok“) {
}
return new Action(„gehe“,“vor“);
// ... dann drehe rechts
return new Action(„drehe“,“rechts“);
Die Programmierung von einfachen Roboteralgorithmen kann zunächst zum
Üben des Umgangs mit den zur Verfügung gestellten Klassen dienen.
Auch wenn bei einfachen Algorithmen zunächst auf Nachrichten und Notizen
verzichtet wird, so sollte eine gute Steuerungsvorschrift doch auf nicht selbst
verursachte wichtige Veränderungen eingehen. Beispiel bei der Goldsuche:
Seite 56

Einzelheiten zu „Robots“
verringert sich ohne eigene Aktionen die eigene Goldmenge, so ist man
offenbar beraubt worden. Mögliche Konsequenz: Suchen des Diebs. Diese
nicht selbst verursachten Veränderungen sind eine allgemeine Charakteristik
von verteilten Systemen und können durchaus thematisiert werden.
5.3.3 Algorithmen II: kommunizierende Roboter
„Fortsetzung“ der einfachen Algorithmen können komplexere, Kommunikation
von Robotern verwendende, Robotersteuerungen sein, die insbesondere bei
Gruppenspielen vonnöten sind.
Programmiertechnisch ist die Kommunikation einfach realisierbar. Die
Aktionen
Action(„hinterlasse Notiz“,Object notiz)
Action(„sende“,Object nachricht)
veranlassen das Ablegen von Notizen bzw. das Senden von Nachrichten und
ermöglichen somit asynchrone und synchrone Verständigungsmechanismen.
Durch den Vektor
getInformationManager().messages
können die selbst empfangenen Nachrichten abgefragt werden.
Anders als bei der Direktsteuerung der Roboter (siehe 5.3.1), bei der die
übersendeten Nachrichten im Klartext auf dem Bildschirm erscheinen und
somit direkt „natürlich“ interpretierbar sind, ist es bei diesem Einsatzgebiet von
Robots zentral, innerhalb der eigenen Gruppe sinnvolle Protokolle für die
Kommunikation der Roboter festzulegen. In Hinsicht auf die
Konkurrenzbeziehung der Gruppen (natürlich abhängig von den Spielregeln)
ist auch die Frage der Datensicherheit von Belang. Es ist sicherlich nicht
wünschenswert, dass die gegnerischen Gruppen „geheime“ Daten abhören oder
sogar interpretieren können.
Seite 57

Einzelheiten zu „Robots“
5.3.4 Entwicklung eigener Spiele
Auf einer von den in 5.3.1 bis 5.3.3 beschriebenen Einsatzmöglichkeiten
grundsätzlich verschiedenen Ebene liegt der Entwurf und die Implementierung
neuer Spiele. Die Methode zur Programmierung dieser Spiele (bzw. der
Spielregeln) wurde bereits in Abschnitt 4.2.4 erklärt.
Anders als bei der Roboterprogrammierung wird in diesem Einsatzgebiet
deutlich, dass Robots auf einer Client/Server-Architektur aufgebaut ist. Die
Spielregeln werden hierbei zentral durch den Server vorgegeben. Diesem fällt
somit die Aufgabe zu, für (spielinterne) Datensicherheit und –konsistenz zu
sorgen – zwei zentrale Themen im Bereich der verteilten Systeme.
Weiterhin müssen nach dem Entwurf des Spiels die Schnittstellen für die
potentiellen Benutzer freigelegt werden, vor allem die im Spiel möglichen
Aktionen sowie die vorkommenden Attribute. Schnittstellen als wesentlicher
Aspekt von Verteilung werden so in ihrer Bedeutung direkt klar: ohne
Freilegung der Schnittstellen wird kein vernünftiges Spiel möglich sein.
5.3.5 Java-RMI verstehen: der Quellcode
Die letzte hier angeführte Möglichkeit, Robots im Informatikunterricht
einzusetzen, betrifft weniger die Ebene der konkreten Programmierung,
sondern die (in Java) einsetzbaren Mechanismen zur Realisierung von
Rechnerkommunikation.
Sicherlich eine Ebene tiefer liegend als die in den vorigen Abschnitten
aufgeführten Ansätze, bietet die Analyse des Quellcodes – hier vor allem die
NamingUnit und die Klassen, die die RMI-Aufrufe leisten – die
Möglichkeit, sich etwas ausführlicher mit den nötigen Aufrufen und den dabei
möglichen Fehlern zu beschäftigen.
Ansatzpunkt können hier beispielsweise die try ... catch Blöcke in den
jeweiligen Klassen sein, deren Analyse genau die Erfordernisse für eine
funktionierende Rechnerkommunikation liefert.
Seite 58

Einzelheiten zu „Robots“
5.4 Grenzen
Robots liegt die Konzeption von Robotern als autonomen Agenten mit lokaler
Information zugrunde. Bei allen Möglichkeiten, die dieser Ansatz eröffnet,
ergeben sich doch auch gewisse Einschränkungen bei den sinnvoll
implementierbaren Spielmöglichkeiten:
5.4.1 Die lokale Sicht
Bedingt durch die Tatsache, dass jeder Roboter stets nur einen gewissen Teil
des Spielfeldes in aktueller Form zur Verfügung hat, fallen Spiele, die eine für
alle Spieler gleiche Sicht auf das Spielfeld voraussetzen, aus dem Rahmen der
realisierbaren Projekte.
Beispiele sind hier „Memory“, „Schach“ oder andere Brettspiele.
Die Spiele, die eine synchronisierte, global wahrnehmbare Spielumgebung für
alle Spieler voraussetzen, lassen sich durch Verwendung des Java-
MatchMakers [Tewissen] weitaus eleganter implementieren als in der Robots-
Umgebung, siehe dazu Kapitel 7.2.
5.4.2 Roboter als autonome Agenten
Jeder Roboter handelt, auf einem eigenen Algorithmus basierend, autonom.
Wenngleich dies auch in Kooperation mit anderen Robotern geschehen kann,
so widerspricht die Autonomie doch der Konzeption von „durch einen Spieler
bewegten Spielfiguren“, die vielen Spielen zugrundeliegt (Beispiele: „Mensch-
ärgere-dich-nicht“, „Mühle“ u.ä.).
Zwar ist die Robots-Umgebung tragfähig genug, die oben als Beispiel
genannten Spiele von Spielfeld und Regeln her zu ermöglichen, jedoch ist
folgender grundsätzlicher Unterschied vorhanden:
Seite 59

Einzelheiten zu „Robots“
In den oben genannten Spielen liegt die eigentliche Intelligenz stets beim
Spieler, der alle seine Spielfiguren steuert, um sein Ziel zu erreichen.
Bei einer Robots-Version dieser Spiele wäre die Arbeit auf die einzelnen
Roboter, die die Spielfiguren darstellen, verteilt. Diese müssten durch (wohl
erhebliche) Kommunikation versuchen, zum gemeinsame Spielziel zu
gelangen.
Der andere denkbare Ansatz, die Spielfiguren als „leblose“ Attribute zu
implementieren, die der Roboter als Akteur bewegen muss, ist letztlich
unrealistisch, da die hier ins Spiel kommende Komponente der benötigten Zeit
zur Bewegung von Spielsteinen in den meisten Spielen eher hinderlich ist.
5.4.3 Fazit
Die in Robots sinnvoll implementierbaren Spiele sind genau die, die auf
Spielern mit lokaler Sicht und Information aufbauen. Spieler in Robots-
Spielen haben zwar Möglichkeiten zur Verständigung mit Mitspielern, es
existiert aber keine globale Kontrollinstanz für eine Spielergruppe. Dadurch
werden einige Spiele (z.B. viele Brettspiele) nur in veränderter, wenn auch
nicht minder interessanter, Form realisierbar.
Ein breites Feld von gut in Robots zu simulierenden Spielen sind alle Arten
von Geländespielen (einfaches Beispiel: „Fangen“ in allen Variationen) sowie
ein großer Teil von sportlich orientierten Spielen, z.B. Völkerball oder Fußball.
Seite 60

Unterrichtssequenz
6 Unterrichtssequenz
Ausgehend von den in Kapitel 3 erarbeiteten didaktischen Aspekten verteilter
Systeme wird in diesem Abschnitt ein Beispiel für eine die Robots-
Umgebung verwendende Unterrichtssequenz gegeben.
6.1 Voraussetzungen und Zielgruppe
Für die nachfolgend angegebene Unterrichtsreihe sind folgende
Voraussetzungen notwendig bzw. wünschenswert:
• Computerraum mit einer genügenden Anzahl von vernetzten PCs.
• evtl. Liveboard oder Möglichkeit zur Wandprojektion eines
Bildschirminhalts
• interessierte Lerngruppe mit mindestens sechs Schülern
• grundlegende Programmierkenntnisse der Schüler (Variablen, Methoden,
Schleifenprogrammierung), idealerweise in Java oder einer anderen
objektorientierten Sprache
Im Folgenden wird aus oben genannten Gründen, insbesondere der
Programmiererfahrung, ein leistungsmäßig durchschnittlicher Informatik-
Leistungskurs, evtl. auch eine Informatik-AG, in der Jahrgangsstufe 12 oder 13
als Zielgruppe angesehen.
6.2 Grobstruktur
Wie bei jeder größeren Unterrichtsreihe bestand beim Entwurf der vorgelegten
Sequenz die Wahl zwischen den zwei grundlegend verschiedenen Ansätzen
„top-down“ und „bottom-up“. Ich habe mich aus folgenden Gründen für eine
„top-down“-Struktur entschieden:
Seite 61

Unterrichtssequenz
• Motivation
Durch die direkte Präsentation und Benutzung der Spielumgebung zu
Beginn der Unterrichtsreihe ist eine hohe Anfangsmotivation zu erwarten.
Dies wäre bei einem „bottom-up“-Ansatz, der typischerweise mit den
Grundlagen von RMI beginnt, wahrscheinlich anders, auch wenn dies stark
abhängig von der konkret vorliegenden Lerngruppe ist.
• Übersichtlichkeit
Die Gesamtkomplexität – sowohl die des Gebiets der verteilten Systeme als
auch die des Robots-Systems – ist recht groß, so dass ein „bottom-up“-
Ansatz von der Einführung der Grundlagen bis zur Benutzung des Systems
sehr lange dauern würde. Es bestünde die Gefahr, dass der Zusammenhang
der einzelnen Unterrichtsthemen aus dem Auge verloren wird.
• Natürlichkeit
Die in der Unterrichtsreihe behandelten Themen können aus
Fragestellungen der Schüler entstehen, die von der Art „Wie funktioniert
das ?“ statt „Warum machen wir das ?“ sind.
Die Grobstruktur der Unterrichtsreihe sieht wie folgt aus:
1. Einführung in die Robots-Umgebung
2. Programmierung von Roboteralgorithmen Teil 1: einfache Algorithmen
3. Entwurf und Implementation eines selbstdefinierten Spiels
4. Programmierung von Roboteralgorithmen Teil 2: komplexere Algorithmen
zur Steuerung kommunizierender und kooperierender Roboter
5. Nebenläufigkeit
Zentrale fachliche Inhalte sind Protokolle und Schnittstellen,
Kommunikationsmechanismen, kooperierende Prozesse und Nebenläufigkeit.
Wichtige anvisierte Ziele dieser Unterrichtseinheit sind neben dem Verständnis
der fachlichen Inhalte auch die Erweiterung der Programmierfähigkeiten der
Schüler und die Verbesserung der Analyse von Algorithmen vor allem
hinsichtlich Nebenläufigkeit. Weiterhin wird auch auf die Erreichung
allgemeindidaktischer Ziele wie Kooperationsfähigkeit, Handlungs- und
Seite 62

Unterrichtssequenz
Prozessplanung sowie Training von Entscheidungsprozessen in Gruppen
hingearbeitet.
Die Dauer der Unterrichtsreihe beträgt in einem Leistungskurs mit 5
Wochenstunden ca. 5 Wochen, in einer AG entsprechend mehr.
6.3 Feinstruktur
Nachfolgend wird eine detaillierte Beschreibung der Unterrichtssequenz
angegeben. Zu jedem Unterthema (siehe Grobstrukturierung in 6.2) werden die
Einzelschritte mit den wichtigsten Kenndaten (Dauer, Unterrichtsform, Ablauf,
Hausaufgabe, Ziele) sowie einer Begründung der Wahl dieser Schritte genannt.
Phase 1: Einführung in die Robots-Umgebung
- Einführung in die Benutzeroberfläche
- erstes einfaches Spiel mit Direktsteuerung
- weitere Spiele mit Direktsteuerung
Gegenstand: Einführung in die Benutzeroberfläche
Dauer: 1 Std. Unterrichtsform: Unterrichtsgespräch mit Demonstrationen
am Liveboard
Ablauf: Der Lehrer erklärt und demonstriert die grundlegenden Funktionen und
Möglichkeiten der Robots-Umgebung, insbesondere:
• Robots als Spielumgebung, gedacht für mehrere über ein Netzwerk
verbundene Spieler
• Strukturierung in Server und Client-Programme
• Starten eines Spiels (Server) und Verbinden mit einem Spiel (Client)
• Aktionsmöglichkeiten der Roboter und Bedienung über Buttons
Hausaufgabe: -
Ziel: Vertrautwerden mit der Umgebung
Begründung: Durch eine detaillierte Einführung werden zukünftige
grundlegende Probleme der Bedienung und Funktion des Systems vermieden.
Seite 63

Unterrichtssequenz
Gegenstand: erstes einfaches Spiel mit Direktsteuerung
Dauer: 1/2 Std. Unterrichtsform: Einzelarbeit am Computer
Ablauf: In einem neutralen Spiel mit auf dem Liveboard sichbaren Server
probieren die Schüler die grundlegenden Aktionsmöglichkeiten der Roboter –
und auch die verschiedenen Robotertypen – aus.
Hausaufgabe: -
Ziele: Vertrautwerden mit den einfachen Aktionsmöglichkeiten und den
verschiedenen Robotertypen. Training des Umgangs mit der Umgebung.
Begründung: Für zukünftige Punkte ist es wichtig, dass die Schüler verstehen,
welche Basisaktionen (insbesondere der Kommunikation) möglich sind und
wie diese wirken.
Gegenstand: weitere Spiele mit Direktsteuerung
Dauer: 1-2 Std. Unterrichtsform: Einzelarbeit am Computer
Ablauf: Nacheinander werden die drei Spiele „Goldsuche“, „Winterspiele“ und
„Erobere die Fahne“ vom Lehrer vorgestellt und per Direktsteuerung gespielt
(z.T. auch ohne sichtbaren Server). Bei der Vorstellung der Spiele sind vor
allem anzugeben:
• Spielziel
• besondere im Spiel vorkommende Gegenstände
• besondere Aktionsmöglichkeiten
Hausaufgabe: -
Ziele: Erkennen der Möglichkeiten, die die Robots-Umgebung bietet.
Anstellen erster Überlegungen für Steuerungsalgorithmen.
Motivationssteigerung durch Spaß am Spielen.
Begründung: Für den Entwurf eigener Spiele ist die Kenntnis der generellen
Möglichkeiten wichtig. Auch erleichtert ein Austesten von Spielen per
Direktsteuerung das spätere Programmieren von Roboteralgorithmen.
Phase 2: einfache Roboteralgorithmen
- Konstruktion eines eigenen Roboters
- Erklärung der Programmierumgebung für Robotersteuerung
- Entwurf einfacher Roboteralgorithmen
Seite 64

Unterrichtssequenz
Gegenstand: Konstruktion eines eigenen Roboters
Dauer: 1 Std. Unterrichtsform: Unterrichtsgespräch und Einzelarbeit
Ablauf: Der Lehrer erklärt zunächst anhand von Beispielen die Eigenschaften,
die Roboter haben können (siehe 4.2.2 und 5.3.1) sowie die Möglichkeiten,
diese Eigenschaften zu programmieren. Jeder Schüler konstruiert daraufhin
seinen persönlichen Roboter (zur späteren Verwendung).
Hausaufgabe: Anfertigen von Roboterbildern (je ein Roboter aus vier
Perspektiven), diese Bilder werden später gescannt und im Spiel verwendet.
Ziele: Motivationssteigerung, Gewinn eines ersten Einblicks in die
Roboterprogrammierung.
Begründung: Durch „eigene“ Roboter kann die Identifikation mit dem Spiel
größer werden.
Gegenstand: Erklärung der Programmierumgebung für Robotersteuerung
Dauer: 2 Std. Unterrichtsform: Lehrervortrag und Einzelarbeit
Ablauf: Zunächst erfolgt die Erklärung, dass die Roboterbewegungen in
Robots auch automatisiert ablaufen können. Die Programmierung der
Roboter (vgl. 5.3.2) wird dann schrittweise eingeführt:
1. Ausführen von Aktionen über den ActionManager
2. Abfrage von Statusvariablen über den InformationManager
3. Zugriff auf die Spielfeldumgebung über das LocalEnvironment
Zu jedem dieser drei Schritte werden kleine Beispielaufgaben gestellt, um eine
direkte Umsetzung des Lernstoffs zu ermöglichen. Beispiele:
zu 1.: Roboter, der im Kreis läuft
zu 2.: Ergänzung von (1) dadurch, dass der Roboter eine Nachricht sendet,
wenn er nach Norden schaut.
zu 3.: Ergänzung von (2) dadurch, dass die Nachrichten nur gesendet werden,
wenn ein anderer Roboter in Sichtweite ist
Ziel: Lernen des Umgangs mit der Programmierumgebung
Begründung: Durch eine (kurze) Sequenz dieser Art wird die Erstellung
komplexerer Algorithmen vorbereitet. Weiterhin macht die große Anzahl der
zur Robotersteuerung wichtigen Methoden eine Einführung sinnvoll.
Seite 65

Unterrichtssequenz
Gegenstand: Entwurf einfacher Roboteralgorithmen
Dauer: 2 Std. Unterrichtsform: Einzelarbeit am Computer
Ablauf: Aufbauend auf den erworbenen Kenntnissen sollen die Schüler nun
einen auf das Spiel „Goldsuche“ passenden, möglichst effektiven
Roboteralgorithmus schreiben. Am Ende dieses Teils werden die
programmierten Roboter durch einen Einsatz im Spiel getestet.
Hausaufgabe: Analyse und Korrektur der Schwachstellen des konstruierten
Algorithmus. Die Ergebnisse der Hausaufgabe können in folgenden Teilen der
Unterrichtsreihe verwendet werden.
Ziele: Üben der Roboterprogrammierung, Kreativität beim Erstellen von
Algorithmen (durch offene Aufgabenstellung)
Begründung: Diese Phase bereitet zusammen mit der vorigen den Hauptteil der
Unterrichtsreihe vor. Das Spiel „Goldsuche“ ist als erstes Beispiel für
„ernsthafte“ Roboteralgorithmen einfach genug, da die Kommunikation unter
den Robotern hier keine Rolle spielt.
Phase 3: Entwurf und Implementation eines selbstdefinierten Spiels
- Entwicklung einer realisierbaren Spielidee
- Analyse des geplanten Spiels
- Implementierung des Spiels
- Testphase
Gegenstand: Entwicklung einer realisierbaren Spielidee
Dauer: 1 Std. Unterrichtsform: Diskussion in Gesamtgruppe
Ablauf: Die Schüler kennen aus den vorangegangenen Unterrichtsstunden die
grundlegenden Möglichkeiten der Roboterprogrammierung sowie einige
Beispiele für realisierbare Spiele. Nun wird in einer Diskussion ein
„Wunschspiel“ ermittelt. Der Lehrer achtet dabei nur auf die grundsätzliche
Programmierbarkeit des Spiels in der Robots-Umgebung (siehe 5.4) sowie
darauf, dass ein gruppenbasiertes Spiel gewählt wird, da die Kommunikation
unter den Robotern im späteren Verlauf der Unterrichtsreihe wichtig wird.
Hausaufgabe: -
Ziele: Kreativität, Üben der Entscheidungsfindung in Gruppen
Seite 66

Unterrichtssequenz
Begründung: Die Entscheidung, überhaupt ein Spiel von den Schülern selbst
entwickeln zu lassen, liegt im daraus resultierenden tieferen Verständnis der
Umgebung sowie in den Chancen, die diese Programmierung bietet (s.u.). Die
Freistellung der Wahl des Ziels verfolgt oben genannte Ziele sowie die
Steigerung der Motivation.
Gegenstand: Analyse des geplanten Spiels
Dauer: 1-2 Std. Unterrichtsform: Diskussion in Gesamtgruppe
Ablauf: Das in der letzten Stunde geplante Spiel wird nun analysiert und soweit
formalisiert, dass eine Implementierung möglich ist. Es sind folgende Punkte
zu klären:
• Was passiert bei Spielstart ?
• Wann ist das Spiel beendet ?
• Was passiert bei Spielende ?
• Was ist nötig beim Anmelden eines neuen Spielers ?
• Was ist nötig beim Abmelden eines Spielers ?
• Welche (ggf. wie bewegten Attribute) werden benutzt ?
• Welche Auswirkungen haben die Standardaktionen ?
• Welche besonderen Aktionen gibt es und welche Auswirkungen haben sie ?
Hausaufgabe: -
Ziele: Einigung über gemeinsame und sinnvolle Standards (bezüglich der
Namensgebung von Attributen und Aktionen), Abstraktionsfähigkeit (von der
Spielidee zur Vorbereitung der Verwirklichung)
Begründung: Dieser Schritt ist zur Vorbereitung der Spielimplementierung
notwendig. Die oben angeführten Punkte entsprechen fast direkt den zu
programmierende Methoden im RuleManager, so dass hier eine wichtige
Vorbereitung der nächsten Phase geleistet wird.
Seite 67

Unterrichtssequenz
Gegenstand: Implementierung des Spiels
Dauer: 3-4 Std. Unterrichtsform: kooperative Einzel- oder Gruppenarbeit
Ablauf: Das Ergebnis der Spielanalyse aus den letzten Stunden bildet die Basis
zur Implementierung des Spiels. Zunächst wird vom Lehrer die grundsätzliche
Struktur eines Regelwerks (siehe 4.2.4 und 5.3.4) erklärt. Mit Hilfe der
Dokumentation, des kommentieren Quellcodes der existierenden Spiele und
(falls nötig) des Lehrers werden dann die Methoden auf Schüler(gruppen)
aufgeteilt und programmiert.
Hausaufgabe: -
Ziele: Einhaltung von vereinbarten Standards, Analyse von kommentiertem
Programmcode und Umsetzung in eigene Programme, erste Erfahrungen der
Programmierung in verteilten Umgebungen
Begründung: Die Form der Programmierung des Regelwerks ist grundlegend
anders als die der Roboterprogrammierung. Der hier gewählte „top-down“-
Ansatz ist recht gut durchführbar, da
• einige Konzepte (z.B. Attribute und Aktionen) schon bekannt sind
• die Zahl der unbekannten Klassen überschaubar ist
• die wichtigen Methoden ausführlich kommentiert in einigen Beispielen
vorliegen
Gegenstand: Testphase
Dauer: 1-2 Std. Unterrichtsform: kooperative Einzelarbeit und
Unterrichtsgespräch
Ablauf: Die entwickelten Methoden werden zu einem Regelwerk
zusammengesetzt und das entstandene Spiel wird per Direktsteuerung der
Roboter auf Funktion getestet. Eventuelle Fehler werden korrigiert.
Hausaufgabe: -
Ziele: Softwaretest und Fehleranalyse
Begründung: Der Test des Spiels ist nötig zur Sicherstellung der
Funktionalität. Treten Fehler auf, so kann (falls damit zusammenhängend) auf
die Bedeutung der Einhaltung der vereinbarten Standards hingewiesen werden.
Seite 68

Unterrichtssequenz
Phase 4: komplexere Algorithmen
- Entwicklung von Algorithmen zur Steuerung kommunizierender und
kooperierender Roboter
Gegenstand: Entwicklung von Algorithmen zur Steuerung kommunizierender
und kooperierender Roboter
Dauer: 6-8 Std. Unterrichtsform: Gruppenarbeit, kooperative Einzelarbeit
Ablauf: Die Schüler teilen sich in mehrere Gruppen auf (Anzahl der Gruppen
wie im programmierten Spiel sinnvoll). Jeder Schüler programmiert nun eine
Robotersteuerung mit dem Ziel, dass seine Gruppe das Spiel gewinnt. Dazu
werden i.A. einige gruppeninterne Absprachen über Taktiken und
Kommunikationsarten notwendig sein. Ein permanentes Testen der
Algorithmen wird dabei durch einen ständig laufenden Server ermöglicht.
Hausaufgabe: -
Ziele: Handlungs- und Prozessplanung (durch Planen der Steuerung),
Kooperation (durch Absprachen mit anderen Gruppenmitgliedern), Entwurf
von Kommunikationsmodellen (impliziter Zugang zu Protokollen),
Erweiterung der Programmierfähigkeiten (durch Kennenlernen von verteilter
Programmierung), Kreativität (beim Suchen nach Strategien erforderlich)
Begründung: Diese Unterrichtsstunden sind von zentraler Bedeutung für die
gesamte Unterrichtsreihe: Durch die Programmierung der
zusammenarbeitenden Robotersteuerungen werden erste Erfahrungen in den
Bereichen „Protokolle“, „Kommunikationsmechanismen“ und
„Nebenläufigkeit“ erworben und so ein implizites Wissen über diese Themen
aufgebaut, auf dem in späteren Sequenzen aufgebaut wird.
Durch die verteilte Programmierung der Gruppensteuerung werden
Delegations- und Kooperationsprinzipien erfassbar, weiterhin kann ein
Einblick in die typischen Probleme und Möglichkeiten verteilter
Programmierung erreicht werden, wenn auch reduziert dadurch, dass die
Schüler in einem Raum sitzen und sich daher einfach absprechen können
Seite 69

Unterrichtssequenz
Phase 5: Nebenläufigkeit
- Demonstration von Synchronisationsproblemen
- Referat über Nebenläufigkeit und Synchronisation
- Umsetzung in Robotersteuerung
Gegenstand: Demonstration von Synchronisationsproblemen
Dauer: 1 Std. Unterrichtsform: Unterrichtsgespräch
Ablauf: Es ist zu erwarten, dass in den Kommunikationsmechanismen der von
den Schülern programmierten Roboteralgorithmen Probleme vorliegen, die auf
die Nebenläufigkeit der einzelnen Algorithmen zurückzuführen sind. Der
Lehrer demonstriert am Liveboard die Probleme und wirft die Frage auf, woran
die Verständigungsschwierigkeiten trotz augenscheinlich korrekter
Steuerungen liegen. Es ist zu erwarten, dass Antworten der Schüler bereits in
die Richtung „zeitliche Koordinierung unabhängiger Prozesse“ gehen.
Hausaufgabe: -
Ziel: Begreifen von Grundzügen des Synchronisationsproblems (hier in
konkreter Form am Beispiel der selbstgeschriebenen Robotersteuerungen)
Begründung: Herstellung eines Zusammenhangs mit dem nachfolgenden
Referat.
Bem.: Treten bei den Robotersteuerungen keine Probleme auf, so kann
alternativ eine Beschreibung der Kommunikationsprotokolle durch die
Schülergruppen erfolgen, wobei die während der Programmierung
aufgetretenen Probleme und deren Lösung beschrieben werden.
Seite 70

Unterrichtssequenz
Gegenstand: Referat über Nebenläufigkeit und Synchronisation
Dauer: 1 Std. Unterrichtsform: Schülerreferat
Ablauf: Nach der Vorbereitung des Themas in der letzten Stunde wird nun ein
Schülerreferat (bereits am Anfang der Unterrichtsreihe vergeben) zu folgenden
Themen gehalten:
• Definition von Nebenläufigkeit
• Synchronisationsprobleme nebenläufiger Prozesse anhand von Beispielen
(z.B. Philosophenproblem)
• einfache Lösungsmechanismen
Hausaufgabe: -
Ziele: Verständnis der bei nebenläufigen Prozessen auftretenden Probleme
(Verallgemeinerung der bereits bekannten Kommunikationsprobleme der
Roboter), Einführung von Fachbegriffen.
Begründung: Durch das (nicht zwingend bis ins letzte Detail gehende) Referat
soll die Einsicht erzeugt werden, dass die diskutierten Probleme über
Synchronisation nicht spielspezifisch sind und dass bereits allgemeine
Untersuchungen und Lösungsmöglichkeiten existieren.
Gegenstand: Umsetzung in Robotersteuerung
Dauer: 2 Std. Unterrichtsform: Gruppen- und kooperative Einzelarbeit
Ablauf: Die im Referat angegebenen Möglichkeiten zur Lösung des
Synchronisationsproblems werden nun in die Robotersteuerungen umgesetzt.
Hausaufgabe: -
Ziele: Praktische Umsetzung des erworbenen theoretischen Wissens, Analyse
von Algorithmen hinsichtlich Nebenläufigkeit und Synchronisation
Begründung: Der Wissenstransfer dient zum Verständnis der Thematik: durch
die praktische Implementation der Synchronisationsmechanismen kann ein
Begreifen des Stoffs auf einer tieferen, anschaulicheren Ebene stattfinden.
Seite 71

Unterrichtssequenz
6.4 Anschlussmöglichkeiten
Die oben dargestellte Unterrichtsreihe bietet eine Reihe von sinnvollen
Anschlussmöglichkeiten, die entweder als eigene Unterrichtsreihen oder auch
bei aktuellen Nachfragen der Schüler in Form von Exkursen stattfinden
können, hier evtl. durch Kurzreferate gestützt:
6.4.1 Petri-Netze
In der letzten Phase der Unterrichtsreihe wurde bereits das
Synchronisationsproblem nebenläufiger Prozesse thematisiert. Dies kann als
Anlass genommen werden, eine Verallgemeinerung mittels Darstellung durch
Petri-Netze durchzuführen (siehe dazu auch Abschnitt 3.2.2)
6.4.2 Datensicherheit
Werden bei der Betrachtung der Kommunikation unter den Robotern einer
Gruppe Schwachstellen in der Datensicherheit deutlich, z.B. durch
unverschlüsseltes Versenden von auch für die Gegner bedeutsamen
Informationen, so kann der Lehrer diese Sicherheitslücken ausnutzen und einen
„Spion“-Roboter einsetzen, der die Gruppe besiegt (oder auch nur die
Kommunikation stört).
Die Analyse, warum die eigene Gruppe verloren hat, bietet einen praktischen
Zugang zum Thema Datensicherheit. Dieser kann für eine Unterrichtsreihe
genutzt werden, die einen Überblick über existierende Probleme - auch im
Zusammenhang mit dem Internet - und Lösungen gibt.
Bleibt man im Robots-Bereich, so können diese Lösungen auch umgesetzt
werden, z.B. durch Codierung und Signatur von Nachrichten.
Seite 72

Unterrichtssequenz
6.4.3 Java-RMI
Sowohl in der Programmierung der Roboter als auch in der Implementation
eines Spiels wird RMI indirekt verwendet. Die entsprechenden Methoden und
Aufrufe sind allerdings im Robots-Programm so gekapselt, dass sie nicht
direkt benutzt werden. Taucht nun von Schülerseite die Frage auf, wie die
Kommunikation zwischen Clients und Server tatsächlich funktioniert, so kann
eine kurze Unterrichtssequenz zum Thema RMI angeschlossen werden. Eine
Möglichkeit besteht darin, den Quellcode zu analysieren – insbesondere
anhand der abgefangenen Exceptions ist ein Verständnis der
Voraussetzungen möglich.
Nach dieser Analyse kann ein eigenes kleines Programm, z.B. ein Chat-Tool,
geschrieben werden, um den Umgang mit RMI zu lernen. Die bereits
vorhandenen Kenntnisse über Synchronisation und Nebenläufigkeit sind
hierbei hilfreich.
6.4.4 Architekturen
Ausgehend von der Frage „... und wie könnte ein Spiel ohne einen zentralen
Server funktionieren ?“ kann das Gebiet der Systemarchitekturen behandelt
werden. Erkannt werden können hier neben den Vorteilen dezentraler
Architekturen (siehe 2.4.1) auch die Probleme in Hinblick auf Datenkonsistenz
(wie kann ein global gültiges Spielfeld dargestellt und aktualisiert werden?),
Turntaking-Mechanismen (wie wird bestimmt, wer wann agieren darf ?) sowie
An- und Abmelden von Applikationen. Auch der Aspekt der Synchronisation
kann an einem komplexen Beispiel vertieft behandelt werden, da die
Synchronisation der Spieleraktionen in einem dezentralen System nicht durch
eine „synchronized“-Methode einfach erreichbar ist.
Die Überlegungen werden aus Zeitgründen theoretisch bleiben müssen, da die
Robots-Umgebung zu komplex ist, um im Rahmen eines Informatikkurses
auf eine dezentrale Architektur umprogrammiert zu werden.
Seite 73

Unterrichtssequenz
Es ist jedoch als Projekt die Programmierung einer einfacheren verteilten
Anwendung mit dezentraler Architektur denkbar, wozu allerdings Kenntnisse
von Java-RMI erforderlich sind (siehe 6.4.3).
6.5 Leistungsbewertung
Wird die oben beschriebene Unterrichtsreihe nicht in einer Arbeits-
gemeinschaft durchgeführt, so ist die Schülerleistung sowohl in der
Unterrichtsmitarbeit als auch ggf. in einer Klausur zu bewerten.
6.5.1 Mitarbeit im Unterricht
Die Bewertung der Mitarbeit im Unterricht ist bei der Robots-
Unterrichtsreihe schwierig, da viele Phasen mit relativ offenen
Aufgabenstellungen enthalten sind.
Gut zu klassifizieren ist die Schülerleistung in folgenden Bereichen:
• Wortbeiträge in Diskussionen
• Programmierung mit festgelegtem Ziel, z.B. bei der Erstellung einfacher
Roboteralgorithmen (Phase 2) oder der Programmierung der Methoden des
Regelwerks (Phase 3)
• Realisierung der Synchronisation (Phase 5)
Schwierig ist hingegen die Bewertung der Teile mit hohem Kreativanteil,
insbesondere der für die Unterrichtsreihe zentrale Punkt der Programmierung
kooperierender Robotersteuerungen (Phase 4). Hier ist eine Absprache mit den
Schülern über die Bewertungskriterien durchaus denkbar. Mögliche Kriterien
sind z.B. :
• Effizienz der Gruppe (definiert durch das Gewinnen des Spiels)
• klar erkennbare, sinnvolle Strategie (erkennbar an Algorithmen)
Seite 74

Unterrichtssequenz
• Maß von Kommunikation und Kooperation der Roboter (da auch durchaus
eine Gruppe erfolgreich sein kann, in der jeder Roboter rein egoistische
Ziele verfolgt)
6.5.2 Klausur
Aufgrund der Dauer der Unterrichtseinheit ist eventuell auch eine Klausur zu
stellen, die die Inhalte der Unterrichtsreihe als Thema hat. Bei der Wahl der
Klausuraufgaben sind folgende Bereiche denkbar:
1. einfache Roboteralgorithmen
2. Algorithmen für kooperierende Roboter
3. Spieldesign (Regelwerke)
4. Nebenläufigkeit
Die Themenbereiche 1 und 3 sind hierbei weniger geeignet, da sie nur geringen
inhaltlichen Bezug zu den behandelten Kerngebieten verteilter Systeme haben.
Aus den Themenbereichen 2 und 4 lassen sich gemäß den in den Richtlinien
([RichtlinienGK] und [RichtlinienLK]) vorgeschlagenen Anforderungen jedoch für
Klausuren geeignete Aufgaben konstruieren, wie folgendes Beispiel zeigt:
Informatik-LK 13.1
Klausur 1
Aufgabe 1
Gegeben seien die Roboter „Sammler“ und „Träger“:
Sammler Träger
rennen nein nein
schwimmen nein nein
tragen 1 Gegenstand 5 Gegenstände
Sichtfeld 360 Grad, 4 Felder 90 Grad, 5 Felder
Sendeleistung 2 Felder 2 Felder
Berührdistanz 1 Feld 1 Feld
Im Spiel „Goldsuche“ sollen die Roboter so kooperieren, dass der Sammler nach Gold
sucht und jedes gefundene Goldstück dem Träger übergibt. Dieser geht, wenn er 5
Goldstücke hat, zur Heimatbasis, legt alles Gold dort ab und kehrt zum Sammler
zurück, um weiteres Gold aufzunehmen.
a) Geben Sie für die beiden Roboter geeignete Steuerungsalgorithmen an, die die
oben beschriebene Kooperation durchführen.
b) Stellen Sie den verwendeten Verständigungsmechanismus strukturiert dar.
Hinweis: Zur Vereinfachung können Sie Folgendes annehmen:
Seite 75

Unterrichtssequenz
1. Es sind keine Wasserfelder vorhanden.
2. Es sind keine weiteren Roboter auf dem Spielfeld.
3. Zu Spielstart stehen Sammler und Träger nebeneinander.
4. Zur Rückkehr zur Heimatbasis kann eine Methode „Action goHome()“
verwendet werden, die eine Bewegungsaktion in Richtung Heimatbasis
zurückliefert. Befindet sich der Roboter bereits an der Basis, so ist die Rückgabe
null.
Aufgabe 2
a) Erläutern Sie das Problem der Synchronisation nebenläufiger Prozesse (evtl.
anhand eines einfachen, selbstgewählten Beispiels).
b) Eine Gruppe von Robotern soll im Spiel „Erobere die Fahne“ zusammenarbeiten.
Dazu wurde folgende, für alle Roboter der Gruppe gültige, Steuerung
geschrieben:
...
private boolean master=false;
private boolean slave=false;
private Position getPlayerPosition()
// liefert die Position eines anderen Roboters (oder null, falls keiner
// in der Nähe
private Action moveAction()
// liefert Bewegungsaktion
...
public void getAction(String lastresult) {
Vector messages = getInformationManager().messages;
for (int i=0; i

Unterrichtssequenz
Anforderungen an Klausuraufgaben (Kenntniswiedergabe, -anwendung,
Problemlösen und Werten) werden erfüllt.
Zu den einzelnen Aufgaben:
Aufgabe 1 hat als zentrale Anforderung den Entwurf von zwei kooperierenden
Anwendungen nach vorgegebenem Kooperationsmuster. Hauptproblem des
Algorithmenentwurfs in Teil a) ist die Kommunikation unter den Robotern.
Diese soll in Teil b) genauer dargestellt werden. Hier liegt der Schwerpunkt auf
Protokollen, wenn dies auch nicht namentlich so benannt ist.
Während in Aufgabe 1 eher die Aspekte der Kenntnisanwendung und des
Problemlösens im Mittelpunkt stehen, beinhaltet Aufgabe 2 im Wesentlichen
die Punkte der Kenntniswiedergabe (Teil a) und des Wertens (Teil b).
Das Hauptgewicht liegt hierbei auf den Gebieten Nebenläufigkeit und
Synchronisation. Zunächst soll eine Begriffsdefinition gegeben werden, daran
anschließend ist ein typisches Problem der Synchronisation nebenläufiger
Prozesse zu erkennen, zu beschreiben und zu lösen.
Seite 77

Alternativen
7 Alternativen
In diesem Abschnitt werden einige Alternativen der unterrichtlichen
Behandlung des Themas „Programmierung verteilter Systeme“ aufgezeigt. Im
Abschnitt 7.1 wird der Inhalt der Roboter-Spielumgebung diskutiert, in den
Teilen 7.2 und 7.3 werden Alternativansätze zur Programmierung angegeben.
In Abschnitt 7.4 wird ein komplett anderer Ansatz vorgestellt, der ähnliche
Inhalte wie Robots hat.
7.1 Inhalte
Die Wahl des Unterrichtsinhalts zum Thema „Programmierung verteilter
Systeme“ ist sicherlich nicht leicht, da eine Vielzahl von Möglichkeiten
besteht. Alternativen zur Robots-Umgebung sind beispielsweise:
• Schulinternes Mailtool
Wie bereits in Abschnitt 3.2.3 beschrieben, beinhaltet die Entwicklung
eines schulinternen Mailtools durchaus interessante und wichtige
informatische Aspekte. Zugleich ist das Thema für die Schüler sehr
anschaulich und zugänglich. Ein Vorteil dieses Unterrichtsinhalts ist die
spätere Einsetzbarkeit des entwickelten Systems. Falls in der Schule frei
zugängliche Computer existieren, kann ein reger Mailverkehr unter den
Schülern entstehen, weiterhin könnten z.B. Rundschreiben auf
elektronischem Weg verteilt werden.
• Verteilte Datenbank
Zu einem schülergewählten Thema kann eine verteilte Datenbank mit
Abfragemechanismen entwickelt werden. Werden zu den reinen Daten
noch lokale Datenmanipulationen hinzugenommen, so ist z.B. ein
Mathematiktool denkbar, in dem aus verschiedenen Bereichen der
Schulmathematik stammende Themen und Lösungsalgorithmen in die
Seite 78

Alternativen
Datenbank eingetragen werden. Die Algorithmen sollten dabei verteilt
arbeiten, d.h. auf benötigte Teillösungen, die auf anderen Rechnern liegen,
zugreifen können.
An diesem Thema ist die Dezentralität des Systems aus informatischer
Sicht sehr reizvoll. Schwerpunkte sind hier in den Bereichen
„Schnittstellen“ und „Protokolle“ gut möglich (und notwendig).
• Diskussionsumgebung
Eine Diskussionsumgebung kann prinzipiell auf einem einfachen, von den
Schülern komplett selbst entwickelbaren, Talktool aufbauen.
Erweiterungen, z.B. durch graphische Veranschaulichungen, sind durch
den Einsatz des Java MatchMakers (siehe 7.2) ebenfalls recht leicht
möglich.
Die Diskussionsumgebung als Unterrichtsinhalt hat den Vorteil, komplett
durch die Schüler implementierbar zu sein. Dadurch sind weitgehende
Kenntnisse der Programmierung verteilter Systeme gut erreichbar.
Angesichts der skizzierten Alternativen kann die Wahl von Robots als
Spielumgebung zur Erreichung der in Kapitel 3 beschriebenen didaktischen
Ziele durch die zu erwartende hohe Motivation der Schüler beim Benutzen des
Systems begründet werden:
• gute Kommunikationsalgorithmen werden sich bei Gruppenspielen im
direkten Erfolg der Gruppe zeigen, in vielen Fällen kann die Analyse der
Algorithmen und deren Schwachstellen dadurch anschaulicher und
„realitätsnäher“ werden.
• Wählt eine Gruppe ein weniger geeignetes Protokoll zur internen
Kommunikation, beispielsweise uncodierte Versendung
„sicherheitsrelevanter“ Nachrichten oder eine generell nicht ausreichende
Funktionsvielfalt, wird der Effekt ebenfalls direkt am Bildschirm anhand
des Verlierens der eigenen Gruppe zu sehen sein. In oben dargestellten
Beispielen ist etwa vorstellbar, dass ein geschickt agierender Gegner
„Spione“ aussendet, die Nachrichten abhören und in gewinnbringende
Information umwandeln. Im Falle der nicht ausreichenden Funktionsvielfalt
könnte am Bildschirm sichtbar werden, dass die Roboter sich nicht richtig
Seite 79

Alternativen
„verstehen“ – dass z.B. keine Einigung über die gemeinsam zu verfolgende
Taktik geschieht.
• Die Implementierung neuer Spielideen ist durch die enorme Menge der
theoretisch denkbaren Spiele sehr reizvoll. Neben den mit dieser Aufgabe
verknüpften informatischen Aspekte der Synchronisation, Nebenläufigkeit,
Datenkonsistenz und Schnittstellenplanung liegt hier auch ein sehr großer
Freiraum für Phantasie und Kreativität, der sicherlich vielen Schülern
gefallen wird, insbesondere wenn in sonstigen Programmieraufgaben eher
die Erfüllung von vorgegebenen „Pflichtenheften“ gefordert ist.
Dennoch ist natürlich ein funktionierendes Spiel eng verknüpft mit einem
gut geschriebenen Regelwerk, und auf Programmierung zurückzuführende
Fehler im Spieldesign sind direkt beobachtbar – und oft auch
generalisierbar in Bezug auf oben genannte informatische Aspekte.
7.2 Java MatchMaker
Der von Frank Tewissen an der Universität Duisburg entwickelte Java
MatchMaker ist eine Java-Klassenbibliothek zum Erstellen von verteilten
Anwendungen (Dokumentation siehe [Tewissen]). Er benutzt Java-RMI und
stellt einen zentralen Nachrichtenserver zur Verfügung, über den andere
Applikationen ihren Nachrichtenaustausch realisieren können.
Die Verwendung des Java MatchMakers bietet folgende Möglichkeiten:
• Vereinfachung von Remote Method Invocation: durch Kapselung der RMI-
Mechanismen ist z.B. kein RMI-Compiler mehr nötig
• Ermöglichung dynamischer Remote Method Invocation
• Ermöglichung der Kopplung von Objekten: gekoppelte Objekte sind
teilweise synchronisiert, so dass z.B. an ein Objekt gesendete Nachrichten
automatisch an alle gekoppelten Objekte weitergeleitet werden
Auf technische Einzelheiten zum Java MatchMaker wird hier nicht
eingegangen, siehe dazu die Dokumentation und die gute Darstellung bei
Witzel.
Seite 80

Alternativen
Mit Hilfe des Java MatchMakers lassen sich auf relativ einfache Weise
verteilte Anwendungen erstellen. Insbesondere die nachträgliche Verteilung
von vorher eigenständig arbeitenden Anwendungen ist leicht möglich.
In der Robots-Umgebung wird der Java MatchMaker nicht verwendet, der
Nachrichtenaustausch wird hier unter direkter Benutzung von Java-RMI
realisiert. Dies kann wie folgt begründet werden:
• In der Robots-Umgebung sind keine zu koppelnden Objekte vorhanden,
da z.B. kein für alle Spieler gleiches, globales Spielfeld existiert. Statt
dessen hat jeder Spieler eine eigene, z.T. veraltete, lokale Sicht.
• Die Vereinfachung des RMI-Mechanismus kann teilweise didaktischen
Zielen gegenläufig sein. Sollen beispielsweise (wie in 5.3.5 oder 6.4.3
skizziert) gerade die Funktion und Verwendung von Remote Method
Invocation im Unterricht thematisiert werden, so ist dies anhand des
Quellcodes als Einstiegsbeispiel möglich.
Sicherlich schließen die angegebenen Gründe eine Verwendung des
MatchMaker nicht grundlegend aus. Bei der vorliegenden Struktur des
Robots-Systems ist jedoch eine Synchronisation von Objekten nicht
erforderlich und teilweise nicht sinnvoll.
Sollte bei einer Erweiterung des Robots-Systems jedoch die Notwendigkeit
der Kopplung von Objekten entstehen (siehe dazu Abschnitt 8.3.3), so wäre die
Verwendung des Java MatchMakers einfach zu implementieren, da in Robots
die RMI-Funktionalitäten bereits gekapselt vorliegen. Eine Änderung wäre
demnach nur in den entsprechenden Klassen notwendig.
Für den Programmierer von Roboteralgorithmen oder Spielregeln - also die
Zielgruppe der Robots-Umgebung - ist der Unterschied zwischen den beiden
verschiedenen Wegen des systeminternen Nachrichtenaustauschs ohnehin nicht
direkt erkennbar, da in keinem der beiden Arbeitsgebiete unmittelbare RMI-
Aufrufe bzw. Kopplungsbefehle notwendig sind.
Letztlich kann festgestellt werden, dass der Java MatchMaker eine gute und
flexible Alternative zu dem in Robots eingeschlagenen Weg des
Seite 81

Alternativen
Nachrichtenaustauschs per direkter Verwendung von Java-RMI darstellt.
Insbesondere für verteilte Anwendungen, die auf Synchronisation von
Teilkomponenten aufbauen, ist der Einsatz des MatchMakers sinnvoll.
7.3 JavaSpaces
JavaSpaces ist ein von Sun entwickeltes Paket zur Unterstützung bei der
Programmierung verteilter Systeme (Dokumentation in [JavaSpaces]). Es
verwendet Java-RMI sowie die Serialisierung von Objekten und stellt folgende
Funktionalität zur Verfügung:
Ein JavaSpaces Server kann „Einträge“ (Kopien von Objekten, die das
Interface net.jini.space.Entry implementieren) aufnehmen.
Applikationen können auf dem Server nach Einträgen suchen (read) und
diese ggf. entfernen (take). Außerdem existiert eine „notify“-Funktion, die
eine automatische Benachrichtigung einer Applikation, wenn ein gewünschter
Eintrag beim Server vorliegt, ermöglicht.
Alle diese Suchmechanismen erlauben den Einsatz von „Wildcards“, d.h. es
müssen beim Abfragen nicht alle Komponenten eines Eintrags angegeben
werden.
Der bei JavaSpaces gewählte Ansatz vereinfacht die Programmierung verteilter
Anwendungen, die über den Austausch von Objekten (bzw. Daten) miteinander
kommunizieren. Dabei sind einige der in diesem Feld typischerweise
auftretenden Probleme durch den JavaSpaces Server gelöst:
• Serverimplementation
• Protokolldefinition
• Nebenläufigkeitskontrolle
• sichere Speicherung der zwischen den Applikationen auszutauschenden
Daten
Seite 82

Alternativen
Wie auch der Java MatchMaker (siehe 7.2), stellt JavaSpaces einige sinnvolle
Hilfen zur Erstellung verteilter Anwendungen zur Verfügung. Beide Ansätze
unterscheiden sich jedoch grundlegend voneinander:
Das Kernkonzept des Java MatchMakers ist das Koppeln von Objekten, also
die Synchronisation. JavaSpaces hingegen bietet dem Programmierer die
Möglichkeit, durch den Austausch von Objekten über den JavaSpaces Server
effiziente asynchrone Kommunikationsmechanismen zu verwenden.
In der Robots-Umgebung bietet sich der Einsatz von JavaSpaces aufgrund der
lokalen Sicht der Roboter eher nicht an. Würden beispielsweise die
Informationen über die Umgebung eines Roboters über JavaSpaces Server
mitgeteilt und nicht per direkter RMI, wie in Robots der Fall, so könnten
diese von beliebigen anderen Robotern leicht abgehört und sogar gelöscht
werden.
Lediglich zur Kontrolle der Zugreihenfolge ließe sich ein JavaSpaces Server
sinnvoll einsetzen – da aber Robots auf einer zentralisierten Architektur
aufbaut, ist dies nicht nötig. Anders wäre dies bei dezentralen Systemen. Hier
ermöglicht der Einsatz von JavaSpaces zur Turntaking-Kontrolle effiziente und
elegante Lösungen.
7.4 AgentSheets
Während in den vorigen Abschnitten zunächst die Inhalte von Robots (in 7.1)
und nachfolgend Alternativen der programmiertechnischen Realisation (7.2
und 7.3) diskutiert worden sind, wird in diesem Abschnitt eine „fertige“
verteilte Umgebung vorgestellt: AgentSheets (siehe [AgentSheets]).
In vielen Bereichen ähnelt die AgentSheets-Umgebung dem Robots-System.
Es befinden sich autonome Agenten auf einem Feld (dem agentsheet). Die
Agenten können ihre Umgebung wahrnehmen und in ihr agieren. Auch
Kommunikation zwischen Agenten ist möglich.
Unterschiede bestehen im Wesentlichen in zwei Gebieten:
Seite 83

Alternativen
• Simulierbare Umgebungen
Während Robots in einigen Teilen speziell auf die Simulation von
Robotern in einer Spielfeldumgebung zugeschnitten ist (z.B. vordefinierte
Eigenschaften der Roboter, Benutzeroberfläche), bietet AgentSheets
größere Freiräume. Simulierbar sind z.B. Fische in einem Aquarium oder
Schalter und Leiterbahnen in einem Schaltkreis.
• Programmierung
Die Programmierung der Agenten läuft bei Robots und AgentSheets
deutlich unterschiedlich ab. Bei Robots wird in echtem Java-Code
programmiert (siehe 5.3.2 ff.), AgentSheets hingegen hat das Konzept der
„taktilen Programmierung“. Diese durch das „AgenTalk“-Tool
verwirklichte Art der Programmierung verläuft visuell und regelbasiert.
Durch die Angabe von „IF-THEN“-Klauseln innerhalb einer graphischen
Benutzeroberfläche kann das Verhalten der Agenten gesteuert werden.
Umgebungsinformationen und Aktionsmöglichkeiten
Seite 84

Alternativen
Beispiel eines Programms
Die so programmierten Algorithmen werden mit „Ristretto“, einem
Compiler, in Java-Code umgesetzt.
Der Ansatz von AgentSheets hat den klaren Vorteil, dass die Steuerung von
Agenten auch ohne spezielle Programmierkenntnisse möglich ist. Damit lassen
sich einige Prinzipien verteilter Systeme losgelöst von programmier-
technischen Details erkennen.
Dieser Ansatz ist jedoch nicht in allen Einsatzgebieten im Informatikunterricht
gewollt. Hier sollte (zumindest auch) die konkrete Programmierung verteilter
Systeme behandelt werden (Begründung siehe 3.3).
Aus diesem Grund ist der Einsatz von AgentSheets in einer Unterrichtsreihe zu
verteilten Systemen im Informatikunterricht der Sekundarstufe II nur in
Teilgebieten sinnvoll. In der Sekundarstufe I hingegen, wo der Schwerpunkt
nicht auf „Lösung von Synchronisationsproblemen“ oder „Entwurf und
Implementation von Protokollen“ liegt, kann AgentSheets gerade wegen seiner
einfachen Programmierschnittstelle sehr gut in einer Unterrichtsreihe (z.B. zum
Oberthema „Modellierung“) verwendet werden.
Seite 85

Zusammenfassung und Ausblick
8 Zusammenfassung und Ausblick
Als Abschluss dieser Arbeit werden in diesem Kapitel die erzielten Resultate
zusammengefasst und einige Perspektiven aufgezeigt. Weiterhin wird ein erster
Bericht über den Einsatz der Robots-Umgebung gegeben.
8.1 Zusammenfassung
Die Hauptergebnisse dieser Arbeit lassen sich wie folgt zusammenfassen:
Durch die zunehmende, sowohl lokale wie auch weltweite, Vernetzung von
Computern gewinnen Anwendungen an Bedeutung, die diese Vernetzung
nutzen. Ein Großteil dieser Anwendungen kann als verteilte Systeme
charakterisiert werden: Systeme, die aus mehreren, an unterschiedlichen Orten
liegenden und miteinander zusammenarbeitenden Komponenten bestehen.
Verteilte Systeme sind aus informatischer Sicht interessant, da sie Beispiele für
einige wichtige Themen der Informatik bieten (z.B. Nebenläufigkeit,
Protokolle, Datenschutz- und sicherheit, Systemarchitekturen).
Auch aus didaktischer Sicht sind verteilte Systeme durchaus von Bedeutung.
Neben vielen modernen und wichtigen Unterrichtsgegenständen, die in
Unterrichtsreihen über verteilte Systeme behandelbar sind, trägt auch das
Thema „verteilte Systeme“ selbst in vielen Punkten zur Rechtfertigung des
Unterrichtsfachs Informatik bei. Eine Rechtfertigung von verteilten Systemen
als Unterrichtsgegenstand ist durch die aktuellen, z.T. noch vorläufigen,
Lehrpläne gegeben.
Eine Behandlung verteilter Systeme im Informatikunterricht kann auf
verschiedenen Ansätzen beruhen. Ein wichtiger Ansatz ist hierbei der
Programmieransatz, der die Rolle des Programmierens im Unterricht betont,
wenn auch nicht als alleiniges Mittel benutzt.
Seite 86

Zusammenfassung und Ausblick
Die Robots-Umgebung bietet eine Möglichkeit, eine Unterrichtsreihe über
„Programmierung verteilter Systeme“ durchzuführen. In dieser Umgebung
agieren programmierbare Roboter auf einem gemeinsamen Spielfeld, wobei die
Regeln des Spiels ebenfalls in weiten Teilen frei definierbar sind. Ein
wesentlicher Teil der Roboteraktionen ist die Kommunikation. In Form von
Notizzetteln oder gesendeten Nachrichten können Roboter miteinander in
Kontakt treten.
Typische Inhalte einer Robots-Unterrichtsreihe sind neben der
Programmierung der Regeln und der Roboteralgorithmen die Themen
„Synchronisation und Nebenläufigkeit“, „Kommunikationsmechanismen“ und
„Protokolle“. Diese lassen sich gut anschaulich darstellen und somit leicht
verstehen.
Neben Robots existieren natürlich noch eine ganze Reihe von Alternativen
zur Thematisierung verteilter Systeme im Unterricht. Zu nennen sind hier (fast)
beliebige andere Beispielprojekte wie die Programmierung eines schulinternen
E-Mail-Systems, verschiedene Tools zur Erstellung verteilter Systeme (z.B.
Java MatchMaker oder JavaSpaces) oder bereits existierende komplette
Umgebungen wie AgentSheets. Jedes dieser Konzepte hat bestimmte
didaktisch gut verwertbare Themen, so dass ja nach gewünschtem
Unterrichtsschwerpunkt ein passendes Projekt gefunden werden kann.
8.2 Einsatzbericht
8.2.1 Allgemeines
Die Robots-Umgebung wurde im Rahmen der Modellierungswoche vom
19.5. bis 21.5. 1999 an der Gerhard-Mercator-Universität GH Duisburg
eingesetzt. Das Thema der Projektgruppe lautete „Programmierung verteilter
Systeme“, erwartete Teilnehmer waren mathematisch begabte Schüler der
Klassen 10 bis 13 mit Programmierkenntnissen in einer imperativen
Programmiersprache (nicht notwendig Java).
Seite 87

Zusammenfassung und Ausblick
8.2.2 Zeitplanung
Die zur Verfügung stehenden 15,5 Arbeitsstunden waren von Wibke Rickert
und mir, den Projektgruppenleitern, wie folgt geplant:
Phase Dauer Inhalt
1 1 h Einführung in und Test von Robots
2 0,25 h Erklärung der Bedienung des JDK und des Editors
3 0,25 h Verteilen einer „Java-Kurzreferenz“ (Erklärung der Syntax
von Java)
4 3 h Einführung in die Objektorientierung
5 0,75 h Ausdenken eines in Robots zu programmierenden
Gruppenspiels
6 1 h Erklärung der Objektstrukturen bei Robots
7 2 h Verteilung und Programmierung der notwendigen
Methoden im Regelwerk
8 1 h Test des Spiels durch direkte Steuerung von Robotern
9 5,25 h Programmierung der Roboteralgorithmen
10 1 h Test der Ergebnisse in der Gruppe
Die tatsächlich vorliegende Teilnehmergruppe bestand aus 3 Schülern und
einer Lehrerin. Einer der Schüler (Jan, Jgst. 13, Informatik-Grundkurs) konnte
bereits gut in Java programmieren und hatte auch Kenntnisse über
Objektorientierung. Die anderen beiden Schüler (Phillip und Alexander, Klasse
10) und die Lehrerin (Fächer: Mathematik und Physik) hatten hingegen
keinerlei Programmiererfahrung.
Angesichts dieser Voraussetzungen wurde der Ablaufplan geändert. Die
Erklärung des JDK sowie die Einführung in Java und die Objektorientierung
wurde vorgezogen, ausgedehnt und nur mit den Schülern der Klasse 10 und
ihrer Lehrerin durchgeführt. In dieser Zeit wurde das Regelwerk von Jan und
mir implementiert.
Seite 88

Zusammenfassung und Ausblick
Durch diese Trennung konnte die nachfolgende Erklärung der Programmierung
in Robots auf die Erstellung von Roboteralgorithmen beschränkt werden.
Es wurden dann zwei Teams zu je drei Personen gebildet, die sich zunächst
eine Gruppentaktik überlegten und dann begannen, diese zu programmieren.
Nach einiger Zeit musste jedoch eingesehen werden, dass die Teilnehmer ohne
Programmiererfahrung mit der Implementation der Roboteralgorithmen
überfordert war. Dies lag meines Erachtens nach darin begründet, dass das
grundlegende Verständnis von Elementen wie Schleifen, bedingten
Anweisungen oder Methoden nicht vorhanden war.
Demzufolge wurde die Gruppe erneut geteilt. Jan und ich begannen mit der
Implementierung eines von der Gesamtgruppe beschriebenen
Roboteralgorithmus, während der Rest der Gruppe eine Dokumentation
entwarf und die für das Spiel nötigen Bilder zeichnete bzw. suchte.
Die Implementation des Roboteralgorithmus konnte in der zur Verfügung
stehenden Zeit zwar nicht abgeschlossen werden, dennoch wurden einige
beachtliche Teile erreicht (siehe 8.2.4).
8.2.3 Entwickeltes Spiel
Das innerhalb der Modellierungswoche entwickelte Spiel ist recht komplex
und zeigt einige der Möglichkeiten von Robots. Nachfolgend eine kurze, von
der teilnehmenden Lehrerin geschriebene, Beschreibung des Spiels. Der
Quellcode ist auf der beiliegenden Diskette zu finden (Klasse
ModellRuleManager).
Zwei Mannschaften spielen gegeneinander. Alle Mitspieler einer Mannschaft
starten an einer gemeinsamen Heimatbasis. Auf den Landflächen des Feldes
sind wie im Spiel „Goldsuche“ Goldstücke verteilt. Ziel des Spiels ist es, pro
Gruppe jeweils 20 Goldstücke zu sammeln und zur eigenen Heimatbasis zu
bringen. Diese ist zwar nicht betretbar, das Gold kann jedoch hineingeworfen
werden. Die Goldstücke können auf dem Spielfeld ausgegraben werden.
Außerdem kann man sie anderen Robotern abnehmen oder aus der
Seite 89

Zusammenfassung und Ausblick
gegnerischen Basis stehlen. Dabei muss natürlich die Tragekapazität des
Roboters berücksichtigt werden.
Zusätzlich sind auf dem Spielfeld 3 Brunnen, die mit Wasserbomben angefüllt
sind, und 3 Baseballschläger verteilt. Jeder Roboter trägt eine Fackel bei sich.
Brennt diese nicht, kann der Roboter sich nur noch blind bewegen, Nachrichten
senden oder Notizzettel ablegen. Alle anderen Aktionen sind mangels Sicht
nicht möglich. Die Fackel kann nur in der Nähe der eigenen Basis neu
entzündet werden. Die Fackel wird gelöscht, wenn man von einer
Wasserbombe getroffen wird oder in eine Pfütze tritt. Die Wasserbomben
können an den Brunnen aufgenommen und bei Bedarf in Blickrichtung fünf
Felder weit geworfen werden. Außerdem können sie auf einem Feld als
unsichtbare Falle (Pfütze) abgelegt werden. Wenn man einen Baseballschläger
besitzt und zur Abwehr einsetzt, kann man eine Wasserbombe zurückschlagen
und ist vor Berührungen (=Goldklauen) geschützt. Man kann gleichzeitig keine
anderen Aktionen durchführen.
Innerhalb der Berührdistanz können Pfützen durch Suche enttarnt werden. Eine
Pfütze auf dem nächsten Feld in Blickrichtung kann durch Zuschütten
entschärft werden.
Szene aus entwickeltem Spiel
Seite 90

Zusammenfassung und Ausblick
8.2.4 Entwickelter Roboteralgorithmus
Beim entwickelten Roboteralgorithmus ist die Kommunikation ein wichtiger
Punkt. Ausgetauscht werden in regelmäßigen Abständen Informationen über
die Heimatbasis der gegnerischen Mannschaft, über die Positionen von
Brunnen und gelegten Pfützen sowie umgegrabenen Feldern.
Der entwickelte Roboteralgorithmus ist für zwei Roboter gedacht. Bei mehr als
zwei Robotern pro Team kann der Informationsaustausch eventuell nicht
vollständig sein, bei nur einem Roboter pro Team läuft der Algorithmus nicht.
Der Algorithmus teilt das Spiel folgendermaßen in Phasen ein:
Phase 0: Initialisierung
Viermal drehen, dann Suchen der eigenen Heimatbasis im lokalen Umfeld und
Errichten eines Koordinatensystems mit Ursprung Heimatbasis. Dieser Schritt
ist zur späteren Kommunikation der Roboter unabdingbar und hilft ebenso bei
der Rückkehr zur Basis, was im Spiel recht oft der Fall ist.
Phase 1: Informationen sammeln
Möglichst viele Positionen des Spielfelds besuchen. Dabei alle Schläger und so
viele Wasserbomben wie möglich aufnehmen. Mit einer Wahrscheinlichkeit
von 5 Prozent eine Pfütze erzeugen.
In diesem Schritt wird vor allem die Datenbasis erstellt, die folgende Aspekte
umfasst:
• Position der gegnerischen Heimatbasis
• Positionen der Brunnen
• Positionen der gelegten Pfützen
• Positionen der bereits umgegrabenen Felder
Phasen 2 bis Spielende: variable Taktik
In den Phasen 2 und höher wird jeweils zufällig eine der drei folgenden
Taktiken ausgewählt:
Seite 91

Zusammenfassung und Ausblick
1. Gold suchen
Gehe auf gemäß Datenbasis noch nicht umgegrabene Felder und suche
Gold. Sind drei Goldstücke gesammelt, so bringe alles Gold zur Basis und
suche weiter. Bei den Bewegungen werden mit fünfprozentiger
Wahrscheinlichkeit Pfützen gelegt.
2. Basis verteidigen
Gehe um die eigene Basis und bewerfe alle Gegner mit Wasserbomben.
Sind diese in Berührreichweite, so nimm ihnen das Gold ab und wirf es in
die eigene Basis.
3. Gegner stören
Gehe auf die Heimatbasis des Gegners. Sammele dort alles Gold ein und
schalte auf „abwehren“, falls ein Schläger vorhanden ist. Wird von den
Gegnern Gold abgelegt, so nimm dies auf und schalte wieder auf
„abwehren“.
Außer Phase 0 ist jede Phase noch in drei Unterphasen eingeteilt:
• Unterphase 0: Setze einen Timer auf 20 Sekunden.
• Unterphase 1: eigentlicher Algorithmus (siehe oben)
• Unterphase 2: (nach Ablauf des Timers) Rückkehr zur Basis und
Informationsaustausch mit Partner.
Der Informationsaustausch läuft wie folgt ab:
Ist man an der Basis angekommen, so werden pausenlos die eigene Datenbasis
gesendet und die eigenen neuen Nachrichten abgefragt. Ist dabei eine
Datenbasis enthalten, so aktualisiere und sende die eigene Datenbasis. Schalte
dann auf die nächste Spielphase um.
Der oben beschriebene Algorithmus konnte innerhalb der Modellierungswoche
aus Zeitgründen nicht vollständig implementiert werden. Es fehlen die
Taktiken „Gegner stören“ und „Basis verteidigen“, die Taktik „Gold suchen“
ist noch fehlerhaft. Funktionstüchtig ist aber insbesondere die
Seite 92

Zusammenfassung und Ausblick
Roboterkommunikation. Der Quellcode ist in der Klasse BasicTeamRobot
zu sehen.
8.2.5 Schlussfolgerungen
Aufgrund der bei einem Großteil der Teilnehmer fehlenden
Programmiererfahrungen und –kenntnisse ist es schwierig, aus den
Ergebnissen der Modellierungswoche generelle Schlussfolgerungen über die
Möglichkeiten von Robots als Unterrichtsgegenstand zu ziehen.
Es lässt sich jedoch feststellen, dass bei bestehenden Erfahrungen mit Java, wie
bei einem der Teilnehmer der Fall, die Programmierung sowohl von
Regelwerken als auch von Roboteralgorithmen durchaus ohne lange
Einarbeitungszeit möglich ist.
Die in den Arbeitsgruppen mit viel Engagement entworfenen Taktiken für das
Teamspiel und Möglichkeiten für Spielregeln lassen die Schlussfolgerung zu,
dass die Robots-Umgebung in vielen Hinsichten motivierend wirken kann.
Auch ohne explizite Einführung von Fachbegriffen wie „Synchronisation“ oder
„Nebenläufigkeit“ diskutierten die Schüler über Möglichkeiten, die
Roboterkommunikation zeitlich zu kontrollieren. Dies könnte im
Schulunterricht leicht abstrahiert und verallgemeinert werden.
Als Ergebnis der Modellierungswoche kann festgestellt werden, dass sich die
Robots-Umgebung für einen Informatik-Leistungskurs, in dem Java als
Programmiersprache eingeführt ist, sehr gut eignet. Liegen fundierte
Kenntnisse in anderen Programmiersprachen vor, so lässt sich Robots
ebenfalls – nach Kurzeinführung in die Programmierung – verwenden.
Sind bei den Schülern jedoch keine Programmierkenntnisse vorhanden, so ist
die Programmierung von Robotern innerhalb kurzer Zeit nicht erreichbar. Hier
wären sicherlich einige Monate anzusetzen, wie auch aktuell in vielen Schulen
bei Verwendung von NIKI in Turbo-Pascal der Fall.
Seite 93

Zusammenfassung und Ausblick
Ist eine Behandlung von Simulationsprojekten in verteilten Umgebungen
innerhalb der Sekundarstufe I gewünscht, so bietet sich eher der Einsatz von
AgentSheets (siehe Kapitel 7.4) an. Der innerhalb der Modellierungswoche
realisierte komplexe Algorithmus zeigt jedoch auch deutlich die Vorzüge, die
direkte Java-Programmierung gegenüber einer graphischen
Programmieroberfläche hat : ein höherer Flexibilitätsgrad und die Möglichkeit,
die komplexen Vorgänge in verteilten Systemen durch konkrete
Programmierung zu verstehen.
8.3 Ausblick
Ein umfassender Ausblick über mögliche Zukunftsperspektiven im Bereich der
verteilten Systeme und deren Didaktik ist aufgrund der enormen
Vielschichtigkeit der Thematik und der Geschwindigkeit der Entwicklung nur
schwer zu geben.
Exemplarisch möchte ich daher nachfolgend einige Perspektiven in drei
unterschiedlichen Teilgebieten aufzeigen, die meines Erachtens nach einen
guten Einblick in mögliche zukünftige Tendenzen geben.
8.3.1 Tendenzen verteilter Systeme: Jini
Wie die in Kapitel 2.1 angegebene geschichtliche Entwicklung der
Computerbenutzung zeigt, geht der Trend eindeutig von der einzelnen
Arbeitsstation hin zu einer vernetzten Umgebung.
Dieser Trend dürfte mit der Vernetzung von Computern allein noch nicht
beendet sein. So ist z.B. die komplette Vernetzung aller elektrischen Geräte
eines Haushalts durchaus denkbar. In diesem Szenario könnten beispielsweise
die Waschmaschine oder die Mikrowelle vom Fernseher aus gesteuert werden.
Bei Funktionsstörungen wären Geräte z.B. per Nachricht an den PC in der
Lage, dem Benutzer dies selbst mitzuteilen und ggf. den Kundendienst zu
rufen. Auch könnte Software, beispielsweise neue wassersparende
Seite 94

Zusammenfassung und Ausblick
Spülprogramme für die Waschmaschine, auf die Geräte eingespielt werden
(siehe [Ernst]).
Der Ansatz der von Sun entwickelten Jini-Technologie geht genau in diese
Richtung. Jini-fähige Geräte können nach Belieben dem Netzwerk hinzugefügt
werden und stellen sofort ihre Funktionalität zur Verfügung; z.B. lassen sich
über eine Kamera Bilder aufnehmen, auf einer Festplatte abspeichern, auf
einem Fernseher anzeigen und über einen Drucker ausgeben. Musikstücke
können über das Internet geladen und auf einem beliebigen Recorder (CDR,
DAT oder Festplatte) abgespeichert werden.
Alle diese Vorgänge sind zentral von einer Station aus steuerbar.
Jini setzt auf Java-RMI auf und verdeutlicht in extremer Weise den Begriff der
Transparenz. Für den Benutzer sind die technischen Einzelheiten, z.B. der
Unterschied des Speicherns von Musikstücken auf Festplatte oder DAT-Tape,
wie auch die Verteiltheit des Systems nicht von Bedeutung. Beispielsweise
verläuft die Bedienung der Kaffeemaschinen zu Hause und im Büro identisch
und kann von einem Arbeitsplatz aus geschehen.
In gewisser Weise kann das Konzept von Jini als richtungsweisend angesehen
werden: durch Jini kann die Vernetzung von Umgebungen erheblich gesteigert
werden (Beispiele siehe oben oder in [Jini]).
Verteilte Systeme werden in diesem Zusammenhang an Bedeutung gewinnen,
da die Verteiltheit in Jini-Systemen der Normalzustand ist.
8.3.2 Schulanwendungen
Schulanwendungen verteilter Systeme lassen sich in den Einsatz und die
Thematisierung dieser Systeme unterscheiden.
Im Bereich des Einsatzes verteilter Systeme lassen sich einige Tendenzen
angeben. Hier können z.B. durch Schulkooperation via Internet
Seite 95

Zusammenfassung und Ausblick
schulübergreifende, ggf. sogar internationale, Projekte durchgeführt und
Partnerschaften eingerichtet werden. Auch der Einsatz von Diskussionstools im
normalen Unterricht ist an einigen Stellen sicherlich sinnvoll und trägt zur
Methodenvielfalt bei. Generell gesehen werden die Informations- und
Kommunikationstechnologien in Zukunft wohl einen wichtigen Platz in der
Gesellschaft einnehmen, so dass die Vertrautmachung mit diesen Systemen –
die größtenteils verteilte Systeme sind – im Schulunterricht geleistet werden
sollte.
Die Thematisierung verteilter Systeme wird im Gegensatz zum oben
beschriebenen Einsatz im Wesentlichen im Informatikunterricht stattfinden.
Hierbei sind verschiedene Ebenen denkbar – von den technischen Grundlagen
bis hin zur Anwendungsbedienung. Wichtige fachliche Inhalte sind dabei
Protokolle, Synchronisation, Kommunikationsmechanismen sowie Datenschutz
und –sicherheit.
Zur Zeit werden einige Umgebungen entwickelt, die die unterrichtliche
Thematisierung verteilter Systeme ermöglichen. Das in 7.4 beschriebene
AgentSheets ist ein Beispiel, der Einsatz von Robots wurde in dieser
Ausarbeitung ausführlich diskutiert.
Letztlich ist eine begründete Vorhersage über zukünftige Arten der
Behandlung verteilter Systeme im Informatikunterricht nur schwer zu geben –
dass jedoch verteilte Systeme Unterrichtsgegenstand sein werden, ist aufgrund
der in den Lehrplänen erkennbaren Tendenz wahrscheinlich.
8.3.3 Perspektiven in der Robots-Umgebung
Innerhalb der Robots-Umgebung sind einige Erweiterungen sowie Änderungen
möglich, um größere oder andere Anwendungsgebiete zu erhalten.
Nachfolgend werden vier denkbare Ansätze beschrieben:
Seite 96

Zusammenfassung und Ausblick
• Nachrichtenfluss
Das in Robots verwirkliche Konzept der lokalen Information kann durch
eine Synchronisationsmöglichkeit bestimmter Komponenten ergänzt
werden. So wäre es in einigen Anwendungen sinnvoll, eine für alle Spieler
gleiche globale Sicht auf das Spielfeld zu haben. Auch wäre es vorstellbar,
dass bei Gruppenspielen die Informationen eines Gruppenmitglieds auch
für alle anderen Mitglieder der Gruppe automatisch verfügbar sind.
Realisierbar wäre die beschriebene Synchronisation z.B. durch
Verwendung des Java MatchMaker (siehe 7.2)
• Spielerdarstellung
Die Möglichkeiten für Agenten sind in Robots durch die Festlegung auf
Roboter mit roboterspezifischen Eigenschaften (schwimmen, rennen,
Tragekapazität etc.) relativ stark eingeschränkt, auch wenn die
Aktionsmöglichkeiten dieser Agenten flexibel realisiert sind.
Zur Ermöglichung allgemeinerer Simulationen könnten auch die Agenten
mit ihren Eigenschaften noch spielabhängig gestaltet werden: Bei der
Anmeldung an ein Spiel werden die Eigenschaften abgefragt und - falls
nicht im Programmcode definiert - interaktiv vom Benutzer gesetzt.
• Architektur
Denkbar wäre es, die Client/Server-Architektur von Robots aufzugeben
und eine dezentrale Struktur zu verwenden. Diese könnte die Prinzipien
verteilter Systeme besser verdeutlichen. Realisierbar wäre ein auf
JavaSpaces (siehe Kapitel 7.3) aufbauender Ansatz:
Der Benutzer wählt eine der Optionen „Neues Spiel starten“ oder „Mit
einem Spiel verbinden“. Im erstgenannten Fall wählt er die gewünschten
Spielregeln aus und errichtet einen JavaSpaces Server. Über diesen kann
dann der Turntaking-Mechanismus laufen: Ein Spieler „nimmt“ das
aktuelle Spielfeld vom Server und verändert es durch eine Aktion. Dann
liefert er es wieder beim Server ab. Durch Zugriffsbeschränkungen lässt
sich ein Rundenmodus erreichen.
• Programmierschnittstellen
Waren die obigen drei Punkte noch eher kleinere Erweiterungen in der
Funktionalität des Robots-Systems bzw. bei „Architektur“ eine Änderung
Seite 97

Zusammenfassung und Ausblick
der Programmstruktur unter Beibehaltung der Funktionen, so sind durch die
Modifikation der Programmierschnittstellen andere didaktische Ziele und
Anwendungsmöglichkeiten erreichbar. Neben einer Erweiterung der
Benutzerschnittstelle mit dem Ziel eines verbesserten interaktiven
Spielmodus oder einer AgentSheets-artigen graphischen Oberfläche zur
Schaffung von Einsatzmöglichkeiten im Primarstufen- und Sek-I-Bereich
ist vor allem die Kombination mit Logikprogrammierung interessant.
Durch Java/PROLOG-Schnittstellen oder die Verwendung von JESS (siehe
[Jess]) wäre es möglich, Robots als Visualisierungsmöglichkeit für
Logikprogramme zu nutzen.
Seite 98

„Robots“ - Dokumentation
Anhang A: Robots-Dokumentation
1 Systemanforderungen und Installation
1.1 Systemvoraussetzungen
Robots benötigt einen Computer mit installiertem JDK 1.2. Weiterhin ist eine
Netzwerkverbindung mit installiertem TCP/IP – Protokoll nötig.
Für den Betrieb von Clients wird eine Bildschirmauflösung von mindestens
1024x768 Bildpunkten empfohlen. Bei 800x600 ist die Konsole nicht mehr
erkennbar, bei noch geringerer Auflösung sind auch Teile des Spielfeldes
sowie einige der Kontrollbuttons nicht mehr sichtbar.
1.2 Installation
Kopieren Sie alle Dateien auf beiliegender Diskette in ein beliebiges
Verzeichnis, beispielsweise C:\robots . Legen Sie nun die Java-
Sicherheitseinstellungen so fest, dass alle benötigten Netz- , Thread- und
AWT-Zugriffe erlaubt werden. Da es auf meinem Testsystem des öfteren zu
fälschlich ausgelösten Zugriffsberechtigungsverweigerungen kam, wird das
Einfügen von
grant {permission java.security.AllPermission; };
in die Datei "java.policy" empfohlen. Zu beachten ist bei dieser
Vorgehensweise jedoch, dass hiermit praktisch der gesamte
Sicherheitsmechanismus des JDK 1.2 außer Betrieb genommen wird.
Seite 99

„Robots“ - Dokumentation
2 Server: Starten eines Spiels
2.1 Starten des Servers
Rufen Sie die Datei „server.bat“ im Installationsverzeichnis auf.
Sollte wegen Änderung des Quellcodes eine Neucompilierung notwendig sein,
ist vorher die Datei „serverc.bat“ aufzurufen.
2.2 Einstellungen am Spielfeld
Als erster Schritt können nun die Spielfeldgröße sowie die Anzahl der
Wasserflächen eingestellt werden. Durch den „Spielfeld“-Button gelangt man
in den entsprechenden Dialog:
In diesem ist weiterhin die Konsole an- und ausschaltbar sowie die Option
anwählbar, auf dem Serverbildschirm alle Objekte anzuzeigen. Standardmäßig
werden nur die für alle Roboter sichtbaren Objekte dargestellt.
Standardeinstellungen: Spielfeldgröße 10x10, Wassermenge mittel
Seite 100

„Robots“ - Dokumentation
2.3 Auswahl der Spielregeln
Bei Anwählen des „Spielregeln“-Button erscheint folgender Dialog:
Über die linke Box kann nun das gewünschte Spiel eingestellt werden.
Weiterhin kann der Spielmodus (Echtzeit oder Rundenmodus) über die Knöpfe
links bestimmt werden.
Standardeinstellung: neutrales Spiel im Echtzeitmodus
2.4 Starten und Beenden des Spiels
Durch die „Start“- und „Stop“-Buttons kann das Spiel nun mit den gewählten
Einstellungen gestartet bzw. beendet werden. Bei Beendigung des Spiels
werden alle evtl. verbundenen Clients benachrichtigt und die Verbindung zum
Server beendet.
Während eines laufenden Spiels werden in der Konsole An- und Abmeldungen
von Clients angezeigt, die Züge der Roboter werden in der DOS-Konsole
ausgegeben.
Seite 101

„Robots“ - Dokumentation
2.5 Möglichkeiten bei laufendem Spiel
Bei laufendem Spiel lassen sich Spielfeld, -regeln und -modus nicht verändern.
Einstellbar sind jedoch die Geschwindigkeit (über den Schieberegler oben)
sowie die Bildschirmanzeige.
Über die Buttons „Vollbild“ und „Normalbild“ ist die Ansicht zwischen der
normalen Oberfläche (s.o.) und dem Vollbildmodus umschaltbar.
In beiden Ansichten kann über die „Zoom“-Buttons die Größe der einzelnen
Felder vergrößert bzw. verkleinert werden. Standardmäßig ist diese so
eingestellt, dass alle Felder sichtbar sind.
3 Client: Verbinden mit einem Spiel
3.1 Starten eines Clients
Rufen Sie die Datei „client.bat“ im Installationsverzeichnis auf.
Seite 102

„Robots“ - Dokumentation
Sollte wegen Änderung des Quellcodes eine Neucompilierung notwendig sein,
ist vorher die Datei „clientc.bat“ aufzurufen.
3.2 Auswahl eines Roboters
Im oberen mittleren Textfeld kann die Klasse des gewünschten Roboters
angegeben werden (ohne „client.robots.“). Die Angabe einer
ungültigen Roboterklasse wird bei der Anmeldung entdeckt – in diesem Fall
wird ein BasicRobot verwendet.
Zusätzlich ist im oberen rechten Textfeld ein Name für den Roboter eintragbar.
Wird kein Name eingegeben, so wird automatisch der in der Roboterklasse
definierte Standardname des Roboters verwendet.
3.3 Anmelden beim Server
Im oberen rechten Textfeld ist der Name des Rechners einzutragen, auf dem
der Robots-Server läuft. Vorgegeben ist hier „localhost“, also der Rechner,
auf dem auch der Client gestartet wurde.
Ist der korrekte Name eingetragen, so kann die Verbindung zum Server über
den „Anmelden“-Button aufgebaut werden. Nach erfolgreicher Anmeldung
erhält der Client die grundlegenden Spieldaten vom Server, und der Roboter
befindet sich sofort „im Spiel“.
Seite 103

„Robots“ - Dokumentation
3.4 Aktionsdurchführung
Wie oben erwähnt, ist ein Roboter direkt nach erfolgreicher Anmeldung beim
Server ins Spiel aufgenommen. Um auch zu agieren, stehen zwei
Möglichkeiten offen:
• Start des Roboteralgorithmus
Durch den „Start“-Button kann der Roboteralgorithmus gestartet werden,
per „Stop“-Button ist dieser jederzeit wieder
anhaltbar.
• Direkte Angabe von Einzelzügen
Über die Einzelzugbuttons auf der linken
Seite des Fensters (nur aktiviert, falls Spiel
im Echtzeitmodus und kein Algorithmus
gestartet) können Aktionen per
Benutzerkommando veranlasst werden. Die
Standardaktionen sind über die Icons
anwählbar (Parameter der Aktionen ggf.
links davon auswählbar), spielspezifische
Aktionen (wie „grabe“ bei der Goldsuche)
Seite 104

„Robots“ - Dokumentation
können im Textfeld neben „allgemein“ eingegeben und über den
„allgemein“-Button veranlasst werden. Nachteil dieser Methode ist, dass
Nachrichten und Notizen nur Strings als Parameter erhalten können.
Bei den allgemeinen Aktionen ist überhaupt keine Parameterübergabe
möglich.
3.5 Während des Spiels
Während des Spiels erscheinen in den beiden unteren Textgebieten
verschiedene Informationen:
Im rechten Textgebiet werden die übermittelten Aktionen mitsamt der
Reaktion des Servers auf diese ausgegeben.
Das linke Textgebiet enthält Nachrichten vom Server (mit vorangestelltem
[Server]: ), Informationen über aufgenommene Notizen (Notiz: ) und
empfangene Nachrichten (Nachricht:).
4 Struktur des Programms
In diesem Abschnitt werden die Strukturen von Server- und Clientprogramm
anhand von Diagrammen beschrieben. Zu den einzelnen Komponenten werden
die korrespondierenden Klassen genannt, die im beiliegenden Quelltext
ausführlich dokumentiert sind.
Aus Gründen der Übersichtlichkeit werden die Strukturen nicht vollständig
detailliert aufgeführt, sondern nur soweit zum Verständnis des Programms
sinnvoll.
Seite 105

„Robots“ - Dokumentation
4.1 Programmstruktur Server
Der Robots-Server kann grob in drei Komponenten gegliedert werden:
Benutzer-
Interface
Datenfluss
Server
Spiellogik
Server-
Schnittstelle
Diese Dreiteilung ist im Wesentlichen vergleichbar mit der „model-view-
controller“-Architektur von Java-Swing-Komponenten [Swing], wenn auch mit
veränderter Semantik. Das Benutzerinterface ist hauptsächlich zur visuellen
Repräsentation des Spiels da, die Spiellogik liefert die Datenbasis, und die
Server-Schnittstelle, an der die Aktionen der Roboter ankommen, bewirkt
Veränderungen an den Daten.
Zur Struktur der einzelnen Teile:
Sichtbares
Fenster
Spielfelddarstellung
Bilddatenverwaltung
Benutzer-
Interface
Einstellungen
(durch Benutzer)
Seite 106

„Robots“ - Dokumentation
Klassen:
Sichtbares Fenster: MasterUI
Spielfelddarstellung: Masterboard
Bilddatenverwaltung: ImageHandler
Benutzereinstellungen: FieldDiag, RuleDiag
Spielfeldposition
Liste von erweitert
Objekt auf
Position
Feld von
Spiellogik
aktuelles
Regelwerk
Basisregelwerk
Spiellogik: Mastergame
Spielfeldposition: Position
Objekt auf Position: Attribute
Basisregelwerk: BasicRuleManager
Spieler: Player
Liste von
Spieler
Nachrichten an Clients
Seite 107

„Robots“ - Dokumentation
Server-
Schnittstelle
Behandlung von
Clientnachrichten
implementiert
vereinbartes
Interface
Nachrichten von Clients
Behandlung von Clientnachrichten: Actionhandler
vereinbartes Interface: Connectable
(Anm.: Diese Darstellung ist wegen des Fehlens der für die RMI-Operationen
wichtigen Stub- und Skeletonklassen nur symbolisch zu betrachten)
4.2 Programmstruktur Client
Auch die Clientseitige Programmstruktur kann in drei Teile gegliedert werden,
wobei die Trennung in visuelle, Daten- und Kontrollkomponenten durch die
Möglichkeit der Einzelzüge auf Benutzerwunsch teilweise unscharf wird.
Benutzer-
Interface
Client
Roboter
Client-
Schnittstelle
Seite 108

„Robots“ - Dokumentation
Teilkomponenten:
Sichtbares
Fenster
Spielfelddarstellung
Bilddatenverwaltung
Benutzer-
Interface
Sichtbares Fenster und Einzelzüge: ClientUI
Spielfelddarstellung: Board
Einzelzüge
(durch Benutzer)
Bilddatenverwaltung: (master.)ImageHandler
Bei der Struktur der Robotereinheit sind die Hilfsklassen sowie die
Ableitungshierarchie erkennbar:
Basisroboter
erweitert
abstrakter
Roboter
erweitert
Roboter
Zugriff auf
Aktionsweitergabe an Server
Aktionseinheit
lokales
Spielfeld
Informationen
zum Spielstand
Anfrage bei Server
Seite 109

„Robots“ - Dokumentation
Basisroboter: BasicRobot
abstrakter Roboter: AbstractRobot
Aktionseinheit: ActionManager
lokales Spielfeld: LocalEnvironment
Informationen zum Spielstand: InformationManager
Die Client-Schnittstelle ist wie die Server-Schnittstelle strukturiert. Das
vereinbarte Interface ist Receivable, die implementierende Klasse heißt
Communicator.
5 Wichtigste Variablen und Methoden
An dieser Stelle werden die für die Programmierung von Roboteralgorithmen
und Regelwerken wichtigsten Variablen und Methoden, ggf. mit kurzer
Erklärung, aufgelistet. Die Bedeutung der wichtigsten Klassen wurde bereits in
Kapitel 4.2 und im Anhang A.4 erläutert.
Eine ausführliche Kommentierung aller Klassen und deren Methoden ist im auf
Diskette beiliegenden Quelltext zu finden.
Beim Server als „public“ deklarierte Methoden und Variablen, insbesondere in
den Klassen „Action“, „Attribute“, „Player“ und „Position“, sind für die
Roboteralgorithmen zugreifbar.
5.1 Klasse Action (Server)
Konstruktoren:
public Action(String command,Object data)
public Action(String command)
Methoden:
public String getCommand()
public Object getData()
Seite 110

„Robots“ - Dokumentation
5.2 Klasse Attribute (Server)
Konstruktor:
Attribute(String name,String readableIf,String deleteableIf,byte[] imageData)
Methoden:
public String getName()
public Object getObject()
// die nächsten vier Methoden betreffen das Setzen/Abfragen von Sichtbarkeits- bzw. Entfernbarkeitsmerkmalen:
String getReadableIf()
String getDeleteableIf()
void setReadableIf(String s)
void setDeleteableIf(String s)
// Bilddaten: mit OldImageData ist das Bild gemeint, dass bei Clients im „nicht aktuelles Sichtfeld“ -bereich erscheint
byte[] getImageData()
byte[] getOldImageData()
void setImageData(byte[] data)
void setOldImageData(byte[] data)
// (allgemeine und spielerbezogene) Sichtbarkeit und (spielerbezogene) Entfernbarkeit:
boolean isReadable(Player p,Position pos)
boolean isReadable(Position pos)
boolean isDeleteable(Player p,Position pos)
5.3 Klasse AttributeMover (Server)
Konstruktor:
AttributeMover (MoveListener listener,Attribute a,Position pos, int direction,
Variablen:
int direction
int movesToGo
int delaytime
Position pos
int movesToGo,int delaytime)
Seite 111

„Robots“ - Dokumentation
5.4 Klasse BasicRuleManager (Server)
Konstruktor:
BasicRuleManager(MasterUI ui, Mastergame g)
Variablen:
protected MasterUI ui;
protected Mastergame game;
Methoden:
String getName()
String getDescripion()
// wird bei Spielstart einmal aufgerufen:
void startupGame()
// wird bei Anmeldung eines Spielers aufgerufen:
void addPlayer(Player p)
// wird bei Abmeldung eines Spielers aufgerufen:
void removePlayer(Player p)
// Überprüfung auf Spielende:
protected boolean checkEnd()
// wird bei Spielende aufgerufen:
void doEnd()
// Überprüfung und Durchführung von Aktionen:
protected String performWait(Player pl)
protected String performTurn(Player pl, Object data)
protected String performMove(Player pl, Object data)
protected String performRun(Player pl)
protected String performGet(Player pl, Object data)
protected String performPut(Player pl, Object data)
protected String performLeaveNotice(Player pl, Object data)
protected String performSend(Player pl, Object data)
protected String performContact(Player pl, Object data)
protected String performGeneralAction (Player p, Action a)
// Reaktion auf mit „ok“ durchgeführte Aktionen:
protected void waitPerformed(Player pl)
protected void turnPerformed(Player pl, Object data)
protected void movePerformed(Player pl, Object data)
protected void runPerformed(Player pl)
protected void getPerformed(Player p,Object data)
protected void putPerformed(Player p,Object data)
protected void leaveNoticePerformed(Player p,Object data)
protected void sendPerformed(Player p,Object data)
protected void contactPerformed(Player p,Object data)
protected void generalActionPerformed(Player p,Action a)
Seite 112

„Robots“ - Dokumentation
// Blockiere Spieler für „rounds“ Runden:
protected void delayPlayer(Player pl, int rounds)
5.5 Klasse Loader (Server)
Methode:
// Zum Laden von Bilddaten:
public static byte[] load(String filename)
5.6 Klasse Mastergame (Server)
Variablen:
// Feldgröße (nicht ändern !)
int max_x
int max_y
Methoden:
// Abfrage, ob Spiel läuft:
boolean isRunning()
// Anzahl der verbundenen Spieler:
int getPlayerNumber()
// Für Schleifen: Spieler mit Nummer i (i>=0) ausgeben
Player getPlayerNr(int i)
// Position eines Spielers:
Position getPlayerPosition(Player p)
// allgemeine Spielfeldposition:
Position getPosition(int x, int y)
5.7 Klasse MasterUI (Server)
Methoden:
void refreshHighscore(Player pl)
void appendConsoleText(String s)
void drawBoardAt(Position p)
int getDelay()
Seite 113

„Robots“ - Dokumentation
5.8 Interface MoveListener (Server)
Methoden:
// moveAttribute ist nur ein Bewegungswunsch. Die Implementation muss im RuleManager durchgeführt werden.
// Erwarteter Rückgabewert true bei durchgeführter Bewegung
boolean moveAttribute (AttributeMover a, Position oldpos, Position newpos)
void moveEnded (AttributeMover a, Position pos)
5.9 Klasse Player (Server)
Variablen:
// Fähigkeiten des zum Player gehörigen Roboters:
boolean canSwim
boolean canRun
int viewAngle
int viewSize
int maxCarry
int sendSize
int contactSize
// Positionen:
Position pos
Position homepos
// spielstandabhängig:
int direction
int score
boolean marked
Vector items
String group
Vector messages
// Zur freien Verfügung des RuleManagers:
int state
// true, wenn Spieler Zugberechtigung hat
boolean hasTurn
Methoden:
public String getName()
public int getDirection()
public String getGroup()
// Sendet Servernachricht an Client:
Seite 114

„Robots“ - Dokumentation
void putServerMessage(String message)
// Erzwingen einer Aktion:
void forceAction()
byte[] getImageData()
byte[] getHomeImageData()
void setPosition(Position p)
void setPosition(int x,int y)
void sethomePosition(int x,int y)
// Netzadresse:
String getAddress()
5.10 Klasse Position (Server)
Konstruktoren:
public Position()
public Position(int x, int y)
Position(int x,int y,String accessibleIf)
Variablen:
public int x
public int y
// für Clients: actual ist true, wenn Position im Sichtfeld liegt
public boolean actual
public Vector attributes
public String accessibleIf
Methoden:
public void addAttribute(Attribute a)
public void removeAttribute(Attribute a)
// liefert (falls vorhanden) das erste Attribut mit Namen „name“
public Attribute getAttribute(String name)
// liefert alle Attribute mit Namen „name“
public Vector getAllAttributes(String name)
// (allgemeine und spielerbezogene) Betretbarkeit einer Position:
boolean isAccessible(Player p)
boolean isAccessible()
Seite 115

„Robots“ - Dokumentation
5.11 (abstrakte) Klasse AbstractRobot (Client)
Variablen:
// Fähigkeiten des Roboters:
protected boolean canSwim
protected boolean canRun
protected int viewAngle
protected int viewSize
protected int maxCarry
protected int sendSize
protected int contactSize
Methoden:
// Hilfen:
public final ActionManager getActionManager()
public final InformationManager getInformationManager()
public final LocalEnvironment getEnvironment()
// Name und Gruppenwunsch:
public final String getName()
public final void setName(String s)
public final void setPreferredGroup(String s)
// Setzen der Bilddaten (i=0 für „sieht nach Nord“, 1 für West, 2 für Süd, 3 für Ost, 4 für Daten der
// Heimatbasis)
public final void setImageData(int i, byte[] data)
5.12 Klasse ActionManager (Client)
Methode:
public String doAction(Action a)
5.13 Klasse BasicRobot (Client)
Konstruktor:
public BasicRobot()
Methoden:
// Ende des Roboteralgorithmus:
Seite 116

„Robots“ - Dokumentation
public void end()
// Methoden zur Implementation eines Roboteralgorithmus:
protected String doActions(String lastresult)
public Action getAction(String lastResult)
5.14 Klasse InformationManager (Client)
Variablen:
// Abfrage ohne Serveranfrage (schnell, aber evtl. veraltet)
public String group
public int score
public Vector items
public boolean marked
public int direction
public Vector messages
public String rules
Methoden:
// Aktualisieren aller Informationen:
public void getAllInfos()
// Abfrage mit Serveranfrage aktuell, aber langsam)
public String getGroup()
public int getScore()
public Vector getItems()
public void getEnvironment()
public boolean getMarked()
public Vector getMessages()
public int getDirection()
5.15 Klasse LocalEnvironment (Client)
Methode:
// liefert die Position, die „forward“ Felder vor und „rightward“ Felder rechts vom Roboter liegt
public Position getPosition(int forward, int rightward)
Seite 117

Literaturverzeichnis
Anhang B: Literaturverzeichnis
[AgentSheets ]: AgentSheets -Seiten im Internet, online unter
http://www.agentsheets.com
Stand: 17.5.1999
[Baumgarten]: B. Baumgarten 1996
Petri-Netze. Grundlagen und Anwendungen (2.Auflage)
Berlin, Heidelberg: Spektrum
[Borghoff/Schlichter]: U.M. Borghoff und J.H. Schlichter 1995
Rechnergestützte Gruppenarbeit.
Berlin, Heidelberg: Springer Verlag
[Coulouris/Dollimore]: G.F. Coulouris und J. Dollimore 1989
Distributed Systems – Concepts and Design.
Wokingham: Addison-Wesley
[Duden]: Duden Informatik (2.Auflage) 1993
Mannheim: Dudenverlag
[Ellis]: C.A. Ellis, S.J. Gibbs und G.L. Rein 1991
Groupware – Some Issues and Experiences.
Communication of the ACM 34, S. 38-58
[Enslow]: P.H. Enslow 1978
What is a „distributed“ system?
Computer, Januar 1978, S. 13-21
[Ernst]: N. Ernst 1999
Zaubernde JINI
c’t 4/1999, S. 21
[Herrtwich/Hommel]: R.G. Herrtwich und G. Hommel 1989
Kooperation und Konkurrenz
Berlin, Heidelberg: Springer Verlag
[Hoppe]: H.U. Hoppe 1997
Vorlesung „Programmiersprachen im Informatikunterricht“
Gerhard-Mercator-Universität GH Duisburg, WS 1996/97
[Hoppe/Luther]: H.U. Hoppe und W. Luther 1996
Informatik und Schule im Spiegel neuer Entwicklungen in der Fachdidaktik.
Duisburg: Schriftenreihe Informatik SI-14
[Java]: Java-Seiten im Internet, online unter
http://java.sun.com
Stand: 17.05.1999
[JavaSpaces]: JavaSpaces Spezifikation, online im Internet unter
http://java.sun.com/products/javaspaces
Stand: 11.05.1999
[Jini]: Jini Beschreibung, online im Internet unter
http://java.sun.com/products/jini
Stand: 17.05.1999
Seite 118

Literaturverzeichnis
[Jess]: JESS-Dokumentation, online im Internet unter
http://herzberg.ca.sandia.gov
Stand: 17.05.1999
[Lamport]: L. Lamport 1978
Reliability Issues for Fully Replicated Distributed Databases.
Computer Networks 2, 1978, S. 95-114
[Lloyd]: P. Lloyd 1994
Groupware in the 21 st century.
London: Adamantine Press Limited
[Mattern]: F. Mattern 1987
Verteilte Basisalgorithmen.
Berlin, Heidelberg: Springer Verlag
[Mullender]: S. Mullender 1989
Distributed Systems.
New York: acm Press
[Notes]: Lotus Notes Seiten, online im Internet unter
http://www.lotus.com/home.nsf/tabs/lotusnotes
Stand: 18.05.1999
[NRZ]: Neue Ruhr Zeitung, 28. April 1999
[Raynal/Helary]: M. Raynal und J.M. Helary 1990
Synchronization and control of distributed systems and programs.
Chichester: Wiley
[RichtlinienGK]: Kultusministerium Nordrhein-Westfalen 1981
Richtlinien Informatik (Gymnasiale Oberstufe)
Frechen: Ritterbach
[RichtlinienGKneu]: Entwurf der Unterrichtslinien Informatik, online im Internet unter
http://www.learn-line.nrw.de/Themen/GymOberst/media1.html
Stand: 11.05.1999
[RichtlinienLK]: Kultusministerium Nordrhein-Westfalen 1991
Vorläufige Richtlinien: Leistungskurse im Fach Informatik (Gymnasiale Oberstufe)
Frechen: Ritterbach
[RMI]: JAVA -RMI Spezifikation, online im Internet unter
http://java.sun.com/jdk/rmi/index.html
Stand: 19.05.1999
[Rolf]: A. Rolf, J. Friedrich, T. Herrmann und M. Peschek 1995
Informatik und Gesellschaft.
Berlin, Heidelberg: Spektrum
[Start]: START -Beschreibung, online im Internet unter
http://www.start.de/set_amadeus.htm
Stand: 11.05.1999
[Sloman/Kramer]: M. Sloman und J. Kramer 1988
Verteilte Systeme und Rechnernetze.
München, Wien: Hanser Verlag
Seite 119

Literaturverzeichnis
[Swing]: Java Swing Dokumentation, online im Internet unter
http://java.sun.com/products/jfc/tsc/index.html
Stand: 18.05.1999
[Tewissen]: Java MatchMaker-Dokumentation, online im Internet unter
http://collide.informatik.uni-duisburg.de/Software/Docs/JavaMatchMaker
Stand: 11.05.1999
[Witzel]: V. Witzel 1998
Spezifikation und Modellierung von Synchronisations- und Unterstützungsstrategien in
netzwerkbasierten gruppenorientierten Simulationsspielen. Schriftliche Hausarbeit im Rahmen
der ersten Staatsprüfung.
Duisburg
Seite 120

Erklärungen
Anhang C: Erklärungen
Ich versichere, dass ich die schriftliche Hausarbeit einschließlich beigefügter
Zeichnungen, Darstellungen, Computerprogramme u.ä.m. selbständig
angefertigt und keine anderen als die angegebenen Hilfsmittel benutzt habe.
Alle Stellen, die dem Wortlaut oder dem Sinn nach anderen Werken
entnommen sind, habe ich in jedem einzelnen Fall unter genauer Angabe der
Quelle deutlich als Entlehnung kenntlich gemacht.
Ich bin damit einverstanden, dass diese Hausarbeit nach Abschluss meiner
Ersten Staatsprüfung wissenschaftlich interessierten Personen oder
Institutionen zur Einsichtnahme und zur Verfügung gestellt wird und dass zu
diesem Zweck Ablichtungen dieser Hausarbeit hergestellt werden, sofern diese
keine Korrektur- oder Bewertungsvermerke enthalten.
Niels Pinkwart
Duisburg, 23. Mai 1999
Seite 121