3 Lernmaterialien zur technischen Informatik
4 Der Rechner-Baukasten
Carsten Kelling 1997 (); letzte Änderung: 17. September 1997

2 Visualisierung und Simulation mit Java

Dieses Kapitel geht auf die Praxiseignung von Java für Zwecke der Visualisierung und Simulation ein. Dazu gibt 2.1 zunächst einen Überblick über verschiedene Ansätze, mit denen man technisches Wissen zu vermitteln versucht. In 2.2 werden aus diesen Untersuchungen die Schlußfolgerungen gezogen und einige Eigenschaften postuliert, die ein "gutes" Visualisierungsmedium besitzen muß. Schließlich berichtet 2.3 von der Machbarkeit "guter" Visualisierung mit Java, wobei die Unterstützung durch den Rechner-Baukasten mit einbezogen wird.

2.1 Bestehende Ansätze

2.1.1 Lehrbücher: Gedruckte Bücher

Lehrbücher haben seit langem die Aufgabe, komplexe Themen nur mit Texten und Abbildungen zu erläutern, was nicht immer gelingt. Gute Beispiele für Literatur, die auch schwierige Sachverhalte der Informatik verständlich und interessant ausbreitet sind die Werke von Hennessy und Patterson (u.a. [HennPatt90] und [HennPatt94]). Diese Bücher zeigen, daß komplizierte Themen keine komplizierte Sprache zur Erklärung benötigen; dennoch fühlt sich der Leser niemals unterschätzt und die Autoren erscheinen stets kompetent. Beispiele, die die informatischen Themen mit Vorgängen und Objekten der Alltagswelt vergleichen, z.B. eine Pipeline mit einer Fertigungsstraße in einer Fabrik, erleichtern das Verständnis. Kurzum: Es wird eindrucksvoll demonstriert, wie Wissen durch das geschriebene Wort vermittelt werden kann.

Jedoch stoßen auch exzellente Bücher bei der Unterstützung des Textes durch Abbildungen an ihre Grenzen. Dieses läßt sich exemplarisch an den Kapiteln über die Befehlspipeline moderner Mikroprozessoren in [HennPatt90] und [HennPatt94] aufzeigen. Bereits [HennPatt90] vermittelt auf die gewohnt gute Weise die Konzepte des Pipelinings, also die Theorie. Es verfügt aber neben einigen verwirrenden Tabellen und kleinen zweifarbigen Zeichnungen über keine passenden Mittel, um die gelegentlich sehr komplizierten zeitlichen Abläufe in der Praxis einer Pipeline darzustellen. Dieser Mißstand wurde offenbar bei der Erstellung von [HennPatt94] erkannt, wo das entsprechende Kapitel über eine Vielzahl großer Abbildungen verfügt, die durch die zusätzliche Schmuckfarbe noch an Deutlichkeit gewinnen.

Damit wird Pipelining in Standardsituationen und einigen Ausnahmen erstmalig verständlich, aber noch nicht wirklich anschaulich. Ein Problem ist, daß man nicht gewährleisten kann, daß Abbildungen und erläuternde Texte auf einer (Doppel-)Seite erscheinen. Somit besäße man am liebsten zwei Exemplare des Buches, um in dem einen den Text zu verfolgen und das andere ständig bei der passenden Grafik aufgeschlagen zu haben. Ein anderes Problem ist der zur Verfügung stehende Platz. Die Grafiken müssen bei dem Thema Pipelining relativ groß sein, um alle notwendigen Einzelheiten enthalten und lesbar darstellen zu können. Damit reduziert sich die Anzahl der Beispiele, die dem Leser in relativ vielen Schritten nahegebracht werden können, auf zwei oder drei pro Buch, das dennoch abschnittsweise bereits einem Comic ähnelt. Schließlich verbieten sich bei den a priori statischen Abbildungen zusätzliche Erklärungen, wie etwa kontextsensitive Hilfe bei Zeigen auf bestimmte Komponenten.

Ebensowenig verfügt natürlich der Textanteil eines Buches über eine nicht-lineare Komponente, wie etwa Hyperlinks mit den oben genannten Einsatzmöglichkeiten. Schließlich verbietet sich bei Büchern jede Form von Interaktivität, die etwa ein Ausprobieren ermöglichen würde.

2.1.2 Intel P6-Demo

Von der Firma Intel existiert ein Demonstrationsprogramm, das die Vorteile ihrer P6- gegenüber der älteren P5-Architektur erläutern soll [IntelP6]. Es handelt sich hierbei um ein typisches mit dem Macromedia Director entwickeltes Werk. Dieses Multimediapräsentationsprogramm erlaubt es, Diashows zu erstellen, die sich mit diversen Effekten wie Überblendungen versehen lassen und unterschiedliche Ablaufpfade enthalten, die der Benutzer auswählen kann.

Abbildung 1: Die Intel Multimedia-P6-Demo enthält nur einen Satz von vorgefertigen Illustrationen.

Die P6-Demo erreicht ihren Benutzer, wie bei Director-Dateien üblich, als ein einziges ausführbares Programm. Nach einer vorbereitenden Dokumentation sucht man also vergebens. Nach Start des Programms erscheint ein Bildschirm wie der in Abbildung 1 gezeigte. Hierbei handelt es sich um eine einzige Folge von Bildern, die mit den Pfeilsymbolen rechts unten durchlaufen werden kann. Zuerst führt dabei die P5-Architektur mystische Operationen durch, danach folgt der P6. Die einzelnen Bilder liegen fertig und statisch vor; das Programm paßt sich nicht der Bildschirmgröße an. Als einzige Interaktion pro Bild läßt sich der jeweilige Hilfetext gegebenenfalls scrollen. Die angezeigte Legende ist die einzige vorhandene Dokumentation.

Dieses Programm zeigt exemplarisch sehr eindrucksvoll die Nachteile von Multimediashows als Lernmedium:

Die einzelnen Bilder sehen schön und professionell aus, bleiben aber völlig schleierhaft, nicht zuletzt wegen der fehlenden Dokumentation. Die zu kurzen Hilfetexte erhöhen nur die Verwirrung des Betrachters.
Keine wirkliche Simulation findet statt, der Leser bekommt statt dessen vorgefertigte Bilder zu sehen. Er kann sich nur auf festgelegten Ablaufpfaden bewegen, die aus Aufwandsgründen nicht besonders zahlreich sind - in der P6-Demo gibt es nur das Vor und Zurück auf einer einzigen "Strecke". Damit ist es nicht möglich, einen Ablauf strukturell gleich, aber mit anderen Zahlenwerten zu betrachten, oder mit (zu anderen Zeitpunkten auftretenden) Sonderfällen oder gar völlig eigene Wege zu gehen. Man vergleiche dies mit den Freiheitsgraden der in Abschnitt 3.3.2 integrierten Von-Neumann-Rechner-Applets, wo ein Programmablauf simuliert wird und der Benutzer Register- und Speicherinhalte frei modifizieren darf! Kein noch so fleißiger Multimediaschaffender kann das Verhalten beliebiger Leser vollständig vorwegnehmen; nur echte Simulation schränkt den Leser weder bei Varianten von Standardfällen noch bei eigenen motivationsfördernden Experimenten ein.
Eine Plattformunabhängigkeit ist nur insoweit gegeben, als die "Dias" sicherlich auf jeder Plattform, eine ausreichende Anzahl verfügbarer Farben vorausgesetzt, gleich aussehen. Es wird jedoch ein natives Abspielprogramm für die jeweilige Plattform benötigt; häufig werden von den Herstellern nur die verbreiteten Personal Computer mit Intel oder Apple kompatibler Hardware unterstützt und auf diesen wiederum nur MS Windows und Mac OS.
Es ist sehr zweifelhaft, ob Teile einer bestehenden Animation für eine neue herangezogen werden können - es fehlt eine Modularität. Auch wenn im Rahmen einer Schritt-für-Schritt-Einführung bestehende "Aufbauten" nur gering abgewandelt werden, reduziert sich der Aufwand für die Erstellung wahrscheinlich kaum, sondern kommt einem völligen Neuschreiben gleich.

2.1.3 WinASP

Abbildung 2: Das Programm WinASP simuliert ohne Pausen einen Prozessor.

Das Programm WinASP stellt die Aktivitäten in dem in Abbildung 2 zu erkennenden Ausschnitt eines Mikroprozessors dar [WinASP]. Anscheinend wird tatsächlich simuliert, denn das Programm und mit ihm der modellierte Prozessor können sehr lange laufen, mit ständig wechselnden Werten in den Registern.

Allerdings läuft das Programm auch sehr schnell, vor allen Dingen aber ohne Pausen: Der Benutzer hat nur die Wahl, sich an einem Standbild zu delektieren, oder den Prozessor ein Programm abarbeiten zu lassen, woraufhin dieser zügig, aber ohne jegliche Unterbrechungen für Erklärungen losläuft. Man sieht dabei leuchtend rote "Schlangen" über die Busse huschen, die Bedeutung der Vorgänge aber bleibt im Dunkeln.

Dieses Programm ist ebenfalls ein Beispiel dafür, daß die Steigerung von "Bild", die "Animation" nämlich, kein Garant für Verständlichkeit ist, nach dem Motto "Viel Bewegung, wenig Begreifen".

Wenn schon das Betrachten eines Simulationsvorganges in einzelnen, didaktisch aufeinander abgestimmten Schritten nicht möglich ist, so erlaubt es dieses Programm schon gar nicht, die Simulation rückwärts laufen zu lassen. Bei Eintreten eines Zustandes ist der vorherige für immer verloren; es ist nicht möglich, sich Schritte, deren Ablauf man vergessen hat, oder interessante Sonderfälle noch einmal anzusehen.

Das Programm WinASP ist nur für eine einzige Plattform verfügbar. Es wurde für MS Windows 3.1 geschrieben und blockiert auch auf dessen Nachfolger MS Windows 95, das eigentlich präemptives Multitasking kennt, während einer Simulation alle laufenden Programme. Deswegen ist keine Bildschirmkopie möglich, die die Visualisierungstechnik des Programmes durch hin- und herfließende rote Linien zeigt.
Es ist nicht davon auszugehen, daß WinASP ein Baukastensystem zugrunde liegt, mit dessen Hilfe man den bestehenden Aufbau schnell modifizieren oder neue erstellen könnte.

2.1.4 PowerPC-Simulator

Abbildung 3: Der PPC-601-Simulator erscheint schlicht, aber unübersichtlich.

Dieser Simulator eines Prozessors vom Typ PowerPC 601 liegt als C-Quellcode vor, der sich auf Unix-Rechnern mit X-Windows-GUI übersetzen läßt. Er simuliert die komplizierten Zeitabläufe in der Registerbank des PPC und arbeitet nichtsdestotrotz sehr schnell. Diese Eigenschaften sind aber auf Kosten der Benutzerschnittstelle umgesetzt worden. Wie Abbildung 3 zeigt, werden sehr viele Zahlenwerte und Statusinformationen auf spartanischste Art angezeigt.

Eine aus dem Programm aufrufbare Dokumentation fehlt völlig. Es läßt sich somit resümieren, daß dieses Programm möglicherweise denjenigen, die mit dem PowerPC 601 vertraut sind, umfassende empirische Messungen ermöglicht, daß es aber keineswegs als Einführung in die PowerPC-Architektur dienen kann.

2.2 Didaktische Notwendigkeiten

Aus den Schwächen der in den Abschnitten 2.1.1 bis 2.1.4 vorgestellten Medien lassen sich zwei Maximen für die lerntheoretische Aufarbeitung eines Themas ableiten:

2.2.1 Animationen statt Bilder

Die reine Existenz einer Vielzahl von Programmen mit bewegten Bildern scheint es zu belegen: Illustrationen müssen animiert erscheinen. Tatsächlich bieten Animationen gegenüber statischen Bildern einige Vorteile:

Weil über die Zeit gesehen verschiedene Abbildungen an derselben Stelle erscheinen können, ergibt sich eine deutliche Platzersparnis. Der gewonnene Raum kann für begleitende Texte genutzt werden.
Eine Beschränkung auf einige wenige Beispiele entfällt bei elektronischen Medien, solange die Animationen nicht zu viele Ressourcen benötigen.
Animationen bedeuten immer erhöhte Attraktivität, sind also didaktisch klug, um die Leser bei der Stange zu halten.
Der Spieltrieb des Menschen sollte niemals in den Vorzügen unterschätzt werden, die er geschickt kanalisiert haben kann. Mit genügend interessanten Vorgängen am Bildschirm kann der Traum jedes Lehrers von Schülern, die kaum mit dem Lernen aufhören wollen, wahr werden.

Die obigen Beispiele animierter Darstellungen haben aber auch sehr deutlich einige mögliche Nachteile von Animationen aufgezeigt:

Die Versuchung scheint groß zu sein, aufwendig zu erstellende Inhalte durch simplen grafischen Overkill zu ersetzen (siehe 2.1.2 Intel P6-Demo). Auch wenn Inhalte vorhanden sind, von ihnen aber durch die Animation abgelenkt wird, statt sie erläutern, folgt daraus "Bewegung ohne Begreifen".
Eine Animation, die kein Selbstzweck oder netter Bildschirmeffekt sein will, muß über vernünftige Steuermöglichkeiten verfügen. Das Ausführen einzelner Schritte sollte ebenso möglich sein wie längere Simulationsläufe (siehe als Negativbeispiel 2.1.3 WinASP).
Der Ressourcenverbrauch, insbesondere die Größe der benötigten Dateien, sollte sich in Grenzen halten. Ansonsten fallen eine Verbreitung über das Internet oder die bei Java übliche Übertragung von Bytecode erst bei Bedarf als Möglichkeiten aus.

Abbildung 4: Visualisierung des Datenflusses mit dem Rechner-Baukasten. Gezeigt ist das Ende eines RAM-Auslesevorganges; die Pfeile deuten die Richtung an, in der sich die Punkte bewegen. Ein RAM kann per Applet hier simuliert werden.

Mit dem Rechner-Baukasten können mehr als nur vorgefertigte Animationen abgespielt werden, deswegen eröffnen sich bei seinem Einsatz sofort folgende Vorteile:

Die Darstellung der Zeitabläufe in beliebigen Rechneraufbauten ist möglich. Durch die Unterteilung in Schritte kann der Leser sich beliebig lange für die Betrachtung eines Bildes Zeit nehmen. Die Datenflüsse auf Bussen werden auch bei einem solchermaßen "stehenden" Bild stets deutlich.
Es erfolgt keine Bandbreitenverschwendung im Internet - alle Animationen werden im laufenden Applet vor Ort mit einfachen Zeichenoperationen erzeugt.
Der Rechner-Baukasten enthält Klassen, um die eingesparte Fläche dafür zu nutzen, kontextabhängige Texte zu jedem Schritt anzuzeigen.
Direkte Hilfe ist durch die info tips möglich. Dieses sind kleine Hilfetexte am Mauszeiger, die erscheinen, wenn eine Komponente meldet, daß der Mauszeiger länger unbeweglich über ihr stand. Alle Komponenten des Rechner-Baukastens können erkennen, ob der Mauszeiger in ihrem "Territorium" steht und haben den Wert der info tips mit sinnvollen Angaben vorbelegt.

2.2.2 Begleitende Dokumentation

Alle obigen Beispiele haben gezeigt, daß weder aufwendige Grafiken und Animationen noch penible Simulationen alleine ausreichen, um technische Prozesse verstehbar zu machen. Es ist von existentieller Wichtigkeit, daß jeder interaktive Abschnitt von Lernmaterialien sowohl einleitende als auch nachbereitende Dokumentation besitzt. Verständlichkeit kann nur entstehen, wenn der Leser vor dem ersten Mausklick im "Simulator" sowohl die theoretischen Grundlagen des dargestellten Sachverhaltes kennengelernt hat als auch über die Bedienung und Eigenheiten des "Simulators" selbst in Kenntnis gesetzt wurde. Weil man die Bequemlichkeit des Lesers immer in Betracht ziehen muß, ist es nicht ausreichend, eine separat zu lesende Dokumentation, in welcher Form auch immer, zu erstellen oder Schwachpunkte des "Simulators" nur in einer "README"-Datei zu erwähnen - solche Dokumente werden allenfalls nach Gehversuchen mit dem "Simulator" auf der verzweifelten Suche nach Hilfe gelesen.

Abbildung 5: Ein vierfach-assoziativer write back-Cache vor und nach einem Speicherbefehl. Das Befehlswort SA 21 (store absolutely) wurde in line Nr. 1 des Cache abgelegt, der dazugehörige Tag-Eintrag vermerkt die Daten als valid (grüner Hintergrund). Das Datenwort 38 hexadezimal wurde in line 3 gespeichert und als dirty (gelber Hintergrund) gekennzeichnet, denn es wurde wegen des write back-Verhaltens noch nicht unter Hauptspeicheradresse 21 abgelegt. Man beachte, daß der vorhergehende Ladebefehl die 38 von Adresse 30 aus dem Hauptspeicher geholt hat, weswegen sie vor dem Ausführen des Speicherbefehls bereits in line 2 gespeichert war. Ein Cache kann per Applet hier simuliert werden.

Bestenfalls sind auch während der "Simulation" schrittbezogene Erläuterungen verfügbar. Dieses ist praktikabel und angenehm weder mit gedruckten Beilagen noch mit üblichen digitalen Hilfedateien realisierbar.

Die Kombination von HTML und Rechnerbaukasten als Produkt dieser Arbeit geben einem Autor und Programmierer alle Voraussetzungen an die Hand, um für die genannten Arten von Dokumentation zu sorgen: Die Applets sind fest in das HTML-Dokument integriert; der Benutzer läßt sich durch Links so steuern, daß er zwangsläufig an den fundierenden Seiten "vorbei muß", bevor er auf ein Applet trifft. Ausführbare Dateien, die als "Juwel" aus Lernmaterialien hervorstechen werden hingegen garantiert als erstes angeklickt. Trotz der unbegrenzten Menge an Beschreibungen, die einem Applet beigegeben werden kann, erfolgt die Bewegung durch die Materialien komfortabel - der Leser bewegt sich innerhalb eines einzigen Mediums und benutzt die bekannten Möglichkeiten des Browsers.

Schrittbezogene Erläuterungen lassen sich entweder als HTML-Seiten in separat "aufspringenden" Browserfenstern direkt in Java erzeugen oder werden als Teil des Applets angezeigt. Letztere Vorgehensweise, die platzsparender ist und weniger unruhig wirkt, wurde bei den Demonstrations-Applets verwendet und wird direkt von dem Rechner-Baukasten unterstützt. Die Hilfsklasse RTFTextArea (siehe 4.12.6) stellt einen Ausgabebereich für Text zur Verfügung. Dieser Text kann fett oder kursiv gesetzt werden, erscheint auf Wunsch im Blocksatz und läßt sich mit einem automatisch erscheinenden Scrollbalken verschieben, falls er nicht komplett im Ausgabebereich angezeigt werden kann.

2.3 Simulation mit Java

Das Beispiel einer "Diashow" aus 2.1.2 zeigt, daß echte Simulation unbedingt notwendig ist, um für eine so herausfordernde Aufgabe wie die Vermittlung der Zeitabläufe in Mikroprozessorsystemen optimales Anschauungsmaterial zu erzeugen. Die vorliegende Arbeit war zwar von vornherein auf die Verwendung von Java festgelegt, jedoch hat sich diese Programmiersprache in der Praxis allen Anforderungen gerecht erwiesen und die Erwartungen mehr als erfüllt.

Als höhere Programmiersprache ist Java von der Theorie her für alle nur denkbaren Simulationsaufgaben geeignet. Es gibt zwei wesentliche Gründe, warum Autoren statt einer Programmiersprache spezielle Simulationswerkzeuge einsetzen:

Die Fähigkeiten der Sprache in der Praxis werden angezweifelt. Dazu gehören Zweifel an der Stabilität und Zuverlässigkeit der Simulation, an der Ausführungsgeschwindigkeit oder der Portabilität des Codes auf unterschiedliche Plattformen.
Der anscheinend hohe Aufwand wird gescheut - eine nackte Programmiersprache bietet zwar alle Möglichkeiten, aber auch kaum vorgefertigte Module, um Komponenten zu modellieren oder einen Simulationsalgorithmus abzuarbeiten.

Beide Einwände konnten durch diese Arbeit entkräftet werden, wie die folgenden Abschnitte zeigen.

2.3.1 Praxiseignung von Java

Nachdem im Rahmen dieser Arbeit über 37000 Zeilen Code erstellt und einige mehr im Laufe der Entwicklung wieder verworfen wurden, kann die Praxistauglichkeit von Java als erwiesen gelten. Gleich zu Beginn sei hier erwähnt, daß der Code ohne Javas Objektorientierung, die neben der Eleganz und Übersichtlichkeit ja auch zur Vermeidung von Coderedundanz erdacht wurde, sicherlich noch wesentlich länger geworden wäre. Ungewohnt im Vergleich zu nicht-objektorientierter Programmierung ist möglicherweise die in Abbildung 6 gezeigte große Anzahl von benötigten Quellcodedateien (für jede "öffentliche" Klasse eine eigene); es ist aber nach kurzer Umgewöhnung einfacher und übersichtlicher, über Dateigrenzen hinweg zu editieren, als sich in 10000-Zeilen-Codemonstern zu bewegen. Kommerzielle Entwicklungsumgebungen wie Symantecs Visual Café erleichtern die Verwaltung dieser Dateien sowie das Bewegen in und zwischen ihnen.

AboutRechnerDialog.java Adder.java AddressExplainer.java Adressierungsarten.java Adressierungsarten_Control.java ALU.java CacheControl.java ColorControl.java Colorpoint.java Connection.java ConsoleWindow.java DemonstrationStep.java DescriptionLibrary.java EditableTable.java EditableLabel.java EditableMemory.java EditableMemory_Resource.java EditableMemory_ProgramChange.java EditableMemory_ContextMenu.java Editor.java Editor_CoordSimpleBus.java Editor_Main.java Editor_CreateNewComponent.java Editor_PropertiesSimpleBus.java Editor_Description.java Editor_PropertiesSimpleEdge.java Editor_DescriptionSimpleBus.java Editor_DescriptionSimpleEdge.java Editor_PropertiesRechnerKomponente.java Editor_CoordRechnerKomponente.java RKWrapper.java Editor_PropertiesEditableMemory.java Editor_Properties.java ErrorMessage.java Komponenten_RAM.java Komponenten_Register.java Komponenten_Register_Control.java Komponenten_RAM_Control.java LoadProgress.java MeinAufbau.java Misc.java Mux.java Pipeline_1_Control.java PipelineRegister.java PipelineStageLabel.java Pipeline_1.java Rechner.java RechnerKomponente.java RechnerKomponentePanel.java Register16Split.java Register16.java Register8.java RTFParsedText.java RTFTextArea.java SimControl.java SimControlSpeicherhierarchie.java SimpleBus.java SimpleMemory.java SimpleEdge.java Speicherhierarchie.java StandardRechner.java StatInfo.java TagMemory.java TimerThread.java Timer.java Von_Neumann_Rechner.java

Abbildung 6: Die Klassen des Rechner-Baukastens

Der bislang schwerwiegendste Nachteil soll ebenfalls frühzeitig behandelt und nicht verschwiegen werden: Java-Programme sind zur Zeit in der Ausführung wesentlich langsamer als vergleichbare Programme, die in nativem Code vorliegen, also für jede Plattform mindestens neu übersetzt werden müssen. Das bedeutet, daß man auf einem Pentium-90 unter MS Windows 95 mit dem Netscape Navigator 3.0 fünf Sekunden warten muß, bis das Von-Neumann-Rechner-Applet einen 527 Befehle entfernten breakpoint erreicht hat. Die Ausführungszeit der einzelnen Demonstrationsschritte - dies sind didaktisch gewählte Unterteilungen eines Maschinenbefehls - vor und zurück ist immer ausreichend gering. Im Applet werden die Demonstrationsschritte durch die Knöpfe "" und "" ausgelöst. Sobald der Leser in den fortgeschrittenen VNR-Applets die Funktionsweise einzelner Befehle verstanden hat, und möchte, daß sich der VNR schneller durch sein Programm bewegt, liegt es sowieso nahe, maschinenbefehlsweise ausführen zu lassen (Knöpfe "" und "") oder gleich bis zu einem breakpoint zu simulieren (Knopf ""). Abbildung 7 zeigt ein typisches Fenster, wie es durch die Klasse SimControl (siehe 4.12.7) des Rechner-Baukastens erzeugt wird, um Steuerelemente zur Verfügung zu stellen.

Abbildung 7: Durch die Hilfsklasse SimControl erzeugtes Fenster mit Steuerelementen für Applets.

Der Autor hat die nicht im Überfluß zur Verfügung stehende Rechenleistung sogar als Vorteil empfunden, weil sie eine gewisse Programmierdisziplin erfordert. Dem Rechner-Baukasten hat dieses einige hochoptimierte Klassen beschert. Die Klasse RTFTextArea beispielsweise, die einen Ausgabebereich für formatierten Text zur Verfügung stellt, führt selbständig einen Cache für die dekodierten Formatinformationen, die ermittelten Zeilenumbrüche und die für einen Blocksatz einzufügenden Lücken. Die laufenden Punkte auf Bussen werden für jeden Animationsschritt genau einmal als lauter Quadrate gezeichnet und danach nur noch als fertiges Bild eingeblendet.

Für den Entwickler von Applets wichtiger als die Ausführungsgeschwindigkeit des Klassencodes ist die turn around time, also die Zeit, die zwischen der Entdeckung eines Fehlers oder eines Mangels in einem laufenden Programm und der Rückkehr an dieselbe Stelle im erneut laufenden Programm vergeht.

Die syntaktischen Fähigkeiten Javas machen die zügige Beseitigung eines Fehlers und die rasche Neuprogrammierung einer Eigenschaft möglich. Bei der Zeit für Übersetzung und Start eines Programmes gilt: Java erzeugt keinen monolithischen Block aus maschinenspezifischem Code mit absoluten Adressen, sondern legt für jede Klasse eine Datei an, die sogenannten Bytecode enthält. Dieser Bytecode wird in der Java-VM interpretiert. Im Prinzip entfallen damit zwei Zeitfaktoren: Nach dem Übersetzen der Klassen in Bytecode erfolgt kein Linken, also kein Zusammenfügen des Codes in einer Datei mit Ersetzen von Funktionsaufrufen durch Sprünge an feste, nun bekannte Adressen. Dieses Linken nimmt bei Sprachen wie C oder C++ einen Großteil der turn around time ein; übersetzt werden müssen bei diesen, wie auch bei Java, nur geänderte Codeteile (Module bzw. Klassen), zusammengelinkt werden müssen alle. Zweiter Vorteil ist, daß die Java-Virtuelle-Maschine Code, also Klassendateien, grundsätzlich erst dann anfordert, wenn diese gebraucht werden. Erst so ist es möglich, auch große Programme über das Internet zu starten - bei einer Java-Textverarbeitung etwa würde der Code für den Thesaurus erst dann übertragen, wenn der Benutzer das erste Mal nach einem Synonym suchen läßt. Auch für den Java-Programmierer, der seinen Code vollständig auf der lokalen Platte hat bedeutet das, daß sein Programm zur Kontrolle der Änderungen schneller gestartet werden kann.

Leider ist der im JDK [JDK 1.1] enthaltene und somit frei verfügbare Java-Compiler javac aus Portabilitätsgründen selbst in Java geschrieben und erkennt obendrein nicht selbsttätig, ob Klassen geändert wurden. Mit kommerziellen Werkzeugen wie dem angesprochenen Visual Café liegt die Kompilierzeit des Von-Neumann-Rechner-Applets, abhängig von der Größe der Änderungen, auf einem Pentium-Rechner mit ausreichend RAM im Bereich einer bis weniger Sekunden. Zwischen dem Starten des appletviewer und der ersten Reaktion des Applets auf Benutzereingaben vergehen etwa 10 bis 15 Sekunden; in dieser Zeit werden die zu Beginn notwendigen Klassen geladen und der Von-Neumann-Rechner aufgebaut. Es erscheinen aber gerade die ersten Versionen von Java-Entwicklungsumgebungen, die ein inkrementelles Debugging wie bei dem objektorientierten Urahn Smalltalk ermöglichen; das bedeutet, daß ein Programm nicht mehr angehalten und anschließend neu übersetzt sowie wieder gestartet werden muß, um eine Änderung vorzunehmen, sondern daß zur Laufzeit einzelne Klassen überarbeitet werden können und in der Java-VM ausgetauscht werden. Spätestens damit wird Java zu einem hervorragenden Werkzeug auch für rapid prototyping, jenem Entwurfsparadigma von Software, bei dem so früh wie möglich ein lauffähiges Produkt entsteht. An diesem wird in der Praxis, im Idealfall bereits mit regelmäßiger Konsultation der späteren Benutzern, gefeilt, anstatt zunächst "am grünen Tisch" das gesamte Projekt zu entwerfen und zu fertigen. Änderungsvorschläge fließen dabei sehr schnell in neue Versionen ein, die dann wiederum sofort bewertet werden können.

Wie bereits angesprochen, wird aus Java-Quellcode keine ausführbare Datei erzeugt, sondern Bytecode, der zur Abarbeitung einer VM als Interpreter bedarf. Dadurch, daß vor der Ausführung niemals maschinenspezifischer Code entsteht, bindet man sich auch an keine Plattform. Durch die millionenfache Verbreitung javafähiger Browser kann mittlerweile davon ausgegangen werden, daß ein Benutzer ein Applet genauso schnell und einfach starten kann, wie eine ausführbare Datei.

Ein weiterer großer Vorteil von Java in diesem Zusammenhang ist es, daß nicht nur ein still ablaufender Simulationsalgorithmus auf jeder Plattform gleichermaßen ausführbar ist. Auch jede noch so aufwendig gestaltete Benutzerschnittstelle kann ohne Neukompilation sofort von jeder VM wieder aufgebaut werden. Um dieses zu gewährleisten benutzt der Java-Programmierer niemals direkt die GUI-Komponenten - wie Fenster, Schaltfläche oder Menüleiste - "seiner" Plattform. Statt dessen verwendet man abstrakte Komponenten, die fester Bestandteil der Java-Klassenbibliothek sind. Diese Komponenten werden zur Laufzeit auf die jeweils vorhandenen GUI-Elemente abgebildet.

Für den praktischen Einsatz von Programmen und ihre Entwicklung sind eine gewisse Stabilität und Robustheit unabdingbar. Diese können seit dem JDK 1.0.2 als gegeben gelten. Auch die virtuellen Maschinen in den Browsern, von deren Implementation der korrekte Lauf von Java-Programmen abhängig ist, dürfen in den aktuellen Versionen als im wesentlichen fehlerfrei gelten.

Die Fehlermeldungen des Java-Compilers sind klarer formuliert als die manch anderer Hochsprache und weisen fast immer korrekt auf einen Fehler hin. Von großem zusätzlichen Nutzen ist es, daß durch die Interpretierung des Bytecode auch zur Laufzeit detaillierte Fehlermeldungen erscheinen können, sofern diese nicht durch einen just in time-Compiler "wegoptimiert" werden. Ein Java-Programm stürzt praktisch niemals kommentarlos ab; statt dessen gibt die Java-VM eine Fehlermeldung aus und versucht, den Programmablauf fortzusetzen, was bei minder schweren Fehlern auch gelingt.

Wo nicht explizit anders erwähnt gelten alle in diesem Abschnitt genannten Vorzüge der Java-Entwicklung bereits für das frei verfügbare JDK von Sun [JDK 1.0.2] [JDK 1.1].

2.3.2 Multimedia-Dokumentation

Keines der oben vorgestellten Lernmedien spricht mehr als nur die optische Wahrnehmung an. Eine "Vertonung" von Hilfetexten könnte jedoch nützlich sein, damit der Betrachter die visualisierten Komponenten immer im Blick behalten kann oder falls der Platz für den Gesamtaufbau begrenzt ist. Zusätzlich erhöht sich bekanntermaßen die Intensität des Lerneffektes mit der Anzahl angesprochener Sinne.

Java unterstützt neben der Darstellung von digitalen Bildern und daraus zusammengesetzten Animationen seit den ersten Versionen das Abspielen von Audiodateien - allerdings nur für Applets. Die dem Programmierer zur Verfügung stehenden Methoden erlauben eine simple und plattformunabhängige Nutzung solcher Medien.

Der Rechner-Baukasten legt den Programmierer auf kein Medium für die begleitende Dokumentation fest; es spricht nichts dagegen, statt Texten auch Ton auszugeben. Dennoch ist eine Vertonung der zu jedem Schritt angezeigten Hilfetexte der Demonstrations-Applets aus mehreren Gründen bisher unterblieben:

Audiodaten sind grundsätzlich wesentlich größer als Text, was die Nutzung der Applets online über das Internet wegen der anfallenden Wartezeiten stark einschränken würde.
Audiodaten sind kein passendes Medium während der Entwicklungs- und Reifephase, da sie, anders als Text, bei dem eine Korrektur einzelner Wörter oder Buchstaben leicht möglich ist, nur vollständig geändert werden können.
Einige Applets benutzen adaptive Hilfetexte, die sich also je nach Kontext ändern. Diese sind mit Text(-Bausteinen) relativ einfach zu implementieren, würden aber großen Aufwand vor dem Mikrofon bedeuten. Obendrein sieht man Text nicht an, ob er "zusammengestückelt" wurde, klangliche Versatzstücke fallen aber fast grundsätzlich durch Betonungswechsel etc. auf.
Für längere akustische Erläuterungen müßte eine "Fernbedienung" implementiert und eingeblendet werden, um die Ausgabe gegebenenfalls anzuhalten oder neu zu beginnen.

2.3.3 Zusammenfassung: Vorzüge des Rechner-Baukastens

Die diversen Nachteile der oben genannten Medien und Programme waren Ansporn, es bei der Entwicklung des Rechner-Baukastens besser zu machen. HTML-Seiten mit Applets, die mit dem Rechner-Baukasten erstellt wurden, haben gegenüber anderen Lernmedien einige Vorteile:

HTML alleine erlaubt bereits nicht-lineares Lernen durch die Hyperlinks.
Der Rechner-Baukasten simuliert. Er kann beliebige Mikrorechner oder sonstige Aufbauten nachahmen, auf Wunsch auch rückwärts.
Der Rechner-Baukasten visualisiert. Auch komplizierte Aufbauten wie der aus Abbildung 5 können didaktisch aufbereitet werden Der Rechner-Baukasten stellt also eine Vereinigung zweier Programmklassen dar: Multimediapräsentationsprogramme erstellen schöne, aber inflexible Animationen. Spezielle Simulatoren hingegen sind flexibel in den nachgeahmten Vorgängen, aber meist sehr karg in der Darstellung.
Plattformunabhängigkeit wird durch Java möglich. Ein in Java geschriebenes Programm kann heute wahrscheinlich sofort auf mehr Plattformen ausgeführt werden, als jede andere Form der Codedistribution. Dieses liegt daran, daß die Internet-Browser von Netscape oder Microsoft nicht nur bekannt, sondern auf nahezu jedem Rechner auch installiert sind. Damit ist das Ausführen eines Applets nicht mehr aufwendiger als der Aufruf eines direkt ausführbaren Programms.
Der Baukasten ist ein Modulsystem. Komponenten mit umfangreicher Funktionalität für Simulation und Visualisierung stehen bereit und müssen nur noch erzeugt und benutzt werden. Die Wiederverwendung von Code wird durch den Rechner-Baukasten zweifach unterstützt: Erstens lassen sich durch das System der Koordinaten, die die Komponenten voneinander abfragen, Aufbauten leicht verschieben oder strecken. Es ist somit problemlos möglich, Aufbauten zu erweitern oder in Teilen für andere Applets zu verwenden. Zweitens läßt sich auch Code zur Verhaltenssimulation auf neue Applets übertragen. Der einheitliche Grundvorrat an Methoden für die Simulation macht es auch möglich, eine Komponente durch eine eines anderen Typs zu ersetzen.
Bevor der Leser auf ein Applet trifft, kann er an einleitendem Text vorbeigeführt werden. Entsprechend kann er nach dem Studium des Applets auf nachbereitende Erläuterungen treffen. Kein separates Programm muß dazu aufgerufen werden, keine README-Datei muß gesucht werden.
Solange der Leser mit einem Applet interagiert, können ihm verschiedene Arten von kontextbezogener Hilfe präsentiert werden, ohne daß er zusätzlich blättern muß.
Der Rechner-Baukasten ist offen für zukünftige Erweiterungen wie neue Komponenten oder gesprochene Hilfetexte.

3 Lernmaterialien zur technischen Informatik

4 Der Rechner-Baukasten

Carsten Kelling 1997 (); letzte Änderung: 17. September 1997