3 Lernmaterialien zur technischen Informatik
4 Der Rechner-Baukasten
Carsten Kelling 1997 ([EMail senden]); 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:

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:

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

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:

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:

  1. 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.
  2. 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:

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:



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