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

5 Zusammenfassung und Ausblick

Dieses Kapitel faßt in 5.1 noch einmal den Inhalt dieser Arbeit zusammen, dies sind die erstellten "Produkte" und die gewonnenen Erkenntnisse. Abschnitt 5.2 gibt einen Ausblick auf die weitere Entwicklung von Rechner-Baukasten und "Lernmaterialien". Abschließend behandelt 5.3 bekannte Einschränkungen von Rechner-Baukasten und Demonstrations-Applets.

5.1 Zusammenfassung

Dieser Abschnitt führt die Ergebnisse dieser Arbeit an und enthält jeweils Verweise auf die Abschnitte, die sich mit ihnen befassen.

5.1.1 Eignung von Java für die Visualisierung von Zeitabläufen

Abschnitt 2 hat sich mit der Frage beschäftigt, ob Java ein adäquates Mittel ist, um Zeitabläufe in Mikrorechnern zu simulieren und zu visualisieren. Dazu stellte 2.1 Bestehende Ansätze zunächst einige andere Medien vor, die zur Wissensvermittlung erdacht wurden. Abschnitt 2.2 Didaktische Notwendigkeiten leitete aus diesen empirischen Betrachtungen ab, welche Eigenschaften Lernmaterialien haben müssen. In dem abschließenden 2.3 Simulation mit Java wurde der Rechner-Baukasten an diesen Maßstäben gemessen und von den praktischen Erfahrungen mit Java bei seiner Entwicklung berichtet.

5.1.2 Die Lernmaterialien zur technischen Informatik

Die meisten Leser werden einem Ergebnis dieser Arbeit wahrscheinlich bei dem Studium des etwa 50 DIN-A4-Seiten starken Dokumentes "Lernmaterialien zur technischen Informatik" begegnen. Diese Unterlagen im HTML-Format sind für das Selbststudium gedacht und mit diversen Illustrationen versehen. Auf zehn HTML-Seiten sind bisher Applets vorhanden, die die Simulation von Zeitabläufen in Mikrorechnern ermöglichen. Dabei können beispielsweise ein Von-Neumann-Rechner mit Cache, ein einfacher RISC-Prozessor mit Cache oder auch nur ein einzelnes Register vorwärts und rückwärts simuliert werden. Durch Einfärben der Rahmen von Registern oder der Speicherzellen eines RAM-Bausteins kann die Aufmerksamkeit des Lesers auf bestimmte Punkte gelenkt werden. Es erscheinen zu jedem simulierten Schritt eigene Hilfetexte, die die Vorgänge an den hervorgehobenen Stellen erläutern. Auf Bussen werden der Transfer von Binärwörtern oder die Propagation einer Taktflanke durch animierte Punkte visualisiert. Ein Abdruck der "Lernmaterialien", selbstverständlich nur mit kommentierten Abbildungen statt funktionsfähiger Applets, findet sich in Kapitel 3 Lernmaterialien zur technischen Informatik.

5.1.3 Der Rechner-Baukasten

Die Applet-Aufbauten in den "Lernmaterialien" wurden mit Hilfe der Java-Klassenbibliothek "Rechner-Baukasten" erstellt. Diese etwa 37000 Zeilen Code - über 1,1 MByte Quellcode, die in 700 KByte Java-Bytecode übersetzt werden - wurden zum einen für 13 Modelle von typischen Komponenten der Registertransferebene verwendet. Diese Komponenten simulieren das Verhalten ihrer Vorbilder bei Datenspeicherung und -verarbeitung und verfügen außerdem über die gerade erwähnten Möglichkeiten der Visualisierung von Zeitabläufen.

Zum anderen enthält der Rechner-Baukasten einige Klassen, die wichtige Hilfsfunktionen bereitstellen und für ein einheitliches Aussehen der Demonstrations-Applets sorgen. Zu diesen Klassen gehören eine Darstellmöglichkeit für formatierte Hilfetexte und ein Simulationssteuerfenster.

Der Rechner-Baukasten insgesamt wurde in Kapitel 4 ausführlich vorgestellt. In einem bottom up-Vorgehen wurden dort zunächst die einzelnen Komponenten des Rechner-Baukastens vorgestellt, und dann ihre Erzeugung und Plazierung auf dem Bildschirm beschrieben. Es wurde die mächtige Basisklasse Rechner vorgestellt, die dem Programmierer weitere Arbeit abnimmt.

In den Abschnitten 4.5 Wertzuweisung und Berechnung und 4.6 Visualisierung wurde gezeigt, wie die Komponenten Daten neu berechnen und untereinander austauschen können und wie diese Vorgänge mit den Bordmitteln des Rechner-Baukastens sichtbar gemacht werden können. Abbildung 38 zeigt noch einmal, wie die Aufmerksamkeit des Betrachters gelenkt und Datenflüsse anschaulich gemacht werden können: Bei der Adressierungsart "Register indirekt mit Offset und Index" des MC 68000 [Motorola86] ergibt sich die effektive Speicheradresse als Summe der Werte eines beliebigen Registers, in diesem Beispiel Register 1, des speziellen Indexregisters und eines im Befehlswort enthaltenen Operanden. Diese drei Bestandteile sind in dem in Abbildung 38 gezeigten Demonstrationsschritt rot eingefärbt, ebenso der Addierer. Man beachte, daß nicht das gesamte Befehlsregister, sondern nur der Operandenteil hervorgehoben wurden, um zu verdeutlichen, daß nur dieser Bestandteil des Befehlswortes auf dem Registerausgang nach rechts zu sehen ist. Die Punkte auf den aktivierten Busses bewegen sich von den Registern auf den Addierer zu und von dessen Ausgang über den Adreßbus zum RAM. Im nächsten Demonstrationsschritt wird der Speicher auf Befehl die richtige, durch die Adresse bezeichnete Speicherzelle rot hervorheben, wobei der Hilfetext beschreibt, daß der Speicher nun "arbeitet"; es kann natürlich auch technischer auf Aspekte wie die Haltezeit der Adresse eingegangen werden. Es bleibt dem Benutzer unbenommen, jederzeit Schritte rückgängig zu machen, falls er beispielsweise nachsehen möchte, warum ausgerechnet Register 1 aktiviert wurde.

Die Abschnitte 4.7 bis 4.12 wendeten sich ebenfalls noch an den Programmierer. Dort wurde sowohl auf weitere Eigenschaften der eigentlichen Komponenten des Rechner-Baukastens eingegangen als auch auf die Hilfsklassen, die von allgemeinem Interesse sein könnten. Eine Übersicht der Hilfsklassen ist in Abbildung 39 dargestellt.

5.1.4 Die Simulationsansätze

Mächtige Java-Klassen allein machen noch keine Simulation. Deswegen mußten im Rahmen dieser Arbeit auch Überlegungen zu Simulationsalgorithmen angestellt werden, die sich für die Implementation mit Java eignen und die didaktisch vorteilhafte Präsentation der Vorgänge in und zwischen den Rechnerkomponenten ermöglichen.

Dazu ist zunächst festzuhalten, daß der Rechner-Baukasten den Programmierer auf kein bestimmtes Vorgehen festlegt. Die Methoden, um Werte zu übertragen, zu speichern und zu berechnen, lassen sich universell einsetzen.

Es wurden zwei Simulationsansätze für die Demonstrations-Applets entworfen und bei diesen eingesetzt. Abschnitt 4.8 Der Simulationsansatz expliziert, daß der erste Ansatz wegen der Trennung von Simulations- und Demonstrationscode elegant erschien. Eine einzige Methode führt bei diesem Ansatz die gesamte Simulation korrekt durch, auch ohne grafische Repräsentationen. Durch die Unabhängigkeit von Visualisierungsanweisungen sollte sich auch eine maximale Geschwindigkeit für längere Simulationsläufe ergeben. Als problematisch erwies sich aber die Synchronisation der Simulations- mit der ebenfalls vorhandenen Demonstrationsmethode, weil die erklärenden Schritte relativ zu denen der Simulation beliebig klein wählbar sein müssen. Spätestens bei der besonderen Eigenschaft aller Demonstration-Applets, der Bewegung rückwärts durch die Zeit, kam es, kombiniert mit unvorhersehbaren Benutzereingaben, fast zwangsläufig zu Inkonsistenzen.

Der zweite und verbesserte Ansatz sieht deswegen die Verquickung von Simulations- und Demonstrationsbefehlen vor. Simulationsinstruktionen werden so kurz wie möglich vor denjenigen Befehlen ausgeführt, die die Zustandsänderungen der Komponenten "aufdecken". Das Geschwindigkeitsargument ließ sich durch ein Methodenpaar entkräften, das den Komponenten mitteilt, ob sie Visualisierungsbefehle beachten sollen oder nicht.

5.2 Ausblick

Die uns alltäglich umgebende Technik entwickelt sich mit nie zuvor erreichter Geschwindigkeit weiter. Neue Technologien entstehen und altvertraute verschwinden in immer kürzeren Abständen. Viele Menschen fürchten sich vor Geräten, die sie nicht mehr verstehen und die die Gesellschaft täglich durch ihren Einsatz verändern.

Der Rechner-Baukasten wird dazu beitragen, auf einem wichtigen Wissensgebiet das Vertrautwerden mit der Technik zu erleichtern. Die mit seiner Hilfe illustrierten Lernmaterialien zur technischen Informatik werden künftigen Studenten vielleicht einmal so selbstverständlich erscheinen wie uns Lehrbücher heute.

Der Rechner-Baukasten erläutert aber nicht nur heutige Technik, er ist selbst eine Neuheit. Das vor drei Jahren noch nicht vorhandene Java ist eine seiner Grundlagen, ebenso wie das Internet und mächtige Browser, die wir noch nicht lange wie selbstverständlich nutzen.

Es gibt also zwei Gründe, warum die Entwicklung am Rechner-Baukasten und den "Lernmaterialien" weitergehen wird: Die Inhalte sollten ebenso weiterentwickelt werden wie die Technik, die bei ihrer Vermittlung hilft.

5.2.1 Inhaltliche Fortentwicklung

Die Lernmaterialien werden in der nächsten Zeit um didaktisch ausbalancierte Schritt-für-Schritt-Anleitungen für alle bereits erstellten Demonstrations-Applets erweitert werden. Einige nicht direkt auf ein bestimmtes Applet bezogene allgemeine Abschnitte können weiter ausgebaut werden.

Insbesondere liegt dem Autor das Kapitel über Aufbau und Funktionsweisen von Pipelines am Herzen. Die Ausführungen in [HennPatt94] führen verbal schon sehr gut in das Thema ein, leiden aber bisher an dem Problem der Visualisierung. Eine Vielzahl von Abbildungen macht den Textfluß schwer zu verfolgen und doch können mit ihnen nur einige wenige Beispielabläufe dargestellt werden. Es wird zu den im Buch vorhandenen, sich langsam verbessernden und realitätsnäher werdenden Aufbauten jeweils ein Applet geben. Die Wiederverwendung von Code zur Erweiterung von Aufbauten und Verhaltensmodellen wird durch den Rechner-Baukasten besonders unterstützt. Aufbauten lassen sich durch das System der Koordinaten, die die Komponenten voneinander abfragen, leicht verschieben und abschnittsweise strecken.

Es erscheint auch lohnenswert, einzelne Komponenten mit über die Registertransferebene hinausgehendem Wissen auszustatten, insbesondere über die ausgeführten Maschinenprogramme und besondere Bedeutung einzelner Speicherzellen. Damit könnte etwa ein Cache-Applet darauf hinweisen, daß ein gerade aus dem Cache verdrängter Wert der Schleifenzähler eines Sortieralgorithmus ist, daß die Verdrängungsstrategie also nicht optimal arbeitet.

5.2.2 Technische Fortentwicklung

Die vielleicht wichtigste technische Veränderung der nächsten Monate wird der weitere Ausbau des Editor-Applets sein. Für das Erstellen größerer Aufbauten müssen zunächst Algorithmen für deren Speicherung und Wiederherstellung implementiert werden. Anschließend könnte die Benutzerschnittstelle wesentlich verbessert werden, in dem es möglich wird, Komponenten nur mit der Maus zu erzeugen und plazieren. Sobald eine mit der Maus "festgehaltene" Komponente dabei dicht bei einer anderen Komponente "losgelassen" wird, sollte der Editor in seinen Datenstrukturen festhalten, daß die "fallengelassene" Komponente von nun an die entsprechenden Koordinaten der bereits plazierten Komponente für sich selbst benutzt. Das Prinzip der komponentenrelativen Koordinaten würde also nicht aufgegeben, sondern im Gegenteil aufgewertet, in dem seine Vorteile erhalten bleiben, seine Komplexität aber vom Benutzer ferngehalten wird.

Wenn man schon an mit der Maus plazierbare Objekte denkt, kommt man schnell zu JavaBeans. Dieses mit dem JDK 1.1 [JDK 1.1] eingeführte Konzept sieht eigenständige Komponenten vor, die zur Laufzeit in Programme eingefügt werden können. Über ein Kontextmenü soll man bei Beans mit einer grafischen Repräsentation Eigenschaften einstellen können, wie etwa die Datenbreite eines RAMs, die die Komponente wie ihren gesamten Zustand auf Befehl selbständig speichert. So lassen sich per point-and-click ganze Programme aus beliebig großen Komponenten zusammensetzen und komplexe Aufbauten sicher speichern, ohne sich um die Problematik der Zustandscodierung und -speicherung kümmern zu müssen. Alle Visualisierungskomponenten des Rechner-Baukastens werden zu JavaBeans erweitert werden.

Anschließend an diese Umwandlung der Komponenten werden auch diverse andere Aspekte des Rechner-Baukastens auf den Stand gemäß JDK 1.1 umgestellt werden. Es handelt sich hierbei meistenteils um interne Änderungen wie diejenige der Behandlung von Benutzereingaben, die der Anwender kaum zu Gesicht bekommen wird. Einige Änderungen werden jedoch auch lange bestehende störende Mängel beseitigen, wie z.B. daß Applets ihre Bildschirmkoordinaten nicht kennen, was es wiederum unmöglich macht, Steuer- und Informationsfenster ästhetisch um den Browser herum anzuordnen. Während der Realisierung dieser Anpassungen werden hoffentlich auch endgültige Versionen der verbreiteten Internet-Browser mit Unterstützung für JDK 1.1 erscheinen.

5.2.3 Fortentwicklung durch Leser und Programmierer

Der Autor erhofft sich in den nächsten Monaten eine rege Interaktion mit denjenigen, die den Rechner-Baukasten zum Wohle der Lernenden einsetzen. Er bittet um Benachrichtigungen, falls Benutzer Fehler gefunden haben oder features vermissen. Gleichzeitig gibt er jedoch zu bedenken:

• Der Rechner-Baukasten kann nur Grundlage für eigene Projekte sein, insbesondere nicht jede erdenkliche Rechnerkomponente mit jedem möglicherweise gebrauchten feature enthalten. Bitte scheuen Sie sich als Programmierer nicht, dem objektorientierten Paradigma gemäß zu handeln und bereits für ein neues feature eine Klasse des Baukastens abzuleiten
• Sollten mehrere Benutzer ähnliche Erweiterungen verlangen, wird der Autor aber gerne Erweiterungen in seine Klassen aufnehmen; auch läßt er sich mit Freuden mitteilen, was andere Sinnvolles "dazugestrickt" haben, um eine erweiterte offizielle Version des Rechner-Baukastens herauszugeben.
• Und noch ein Wort zu Änderungen: Bitte verändern Sie nicht die Original-Quelltexte, auch wenn es vielleicht verlockend erscheint, um im Code einmal aufzuräumen…

5.3 Bekannte Einschränkungen und Fehler

Zum Schluß dieser Arbeit sollen noch kurz bekannte Unzulänglichkeiten des Rechner-Baukastens und der mit ihm erstellten Demonstrations-Applets aufgeführt werden:

• Das Editor-Applet kann Aufbauten weder speichern noch laden. Sobald das JDK in der aktuellen Version 1.1 sich weiter verbreitet haben wird und insbesondere mit ihm erzeugte Applets auch von den üblichen Internet-Browsern ausgeführt werden können, wären Lade- und Speicherfunktionen leicht durch die Nutzung der ab JDK 1.1 vorhandenen Objekt-Serialisation möglich. Auch wird sich durch das Reifen der Java-Spezifikation hoffentlich eine einheitliche Antwort auf die Frage ergeben, wann ein Applet was darf, also insbesondere, ob es auf Dateien zugreifen kann [JavaWhitepaper].
• Eine Plattformunabhängigkeit von 100% wird es wahrscheinlich niemals geben. Plattformunabhängigkeit bedeutet ja auch, daß der Programmierer von keinen festen Größen der GUI-Komponenten ausgehen kann, oder anders herum, daß er immer mit dem Schlimmsten rechnen muß. Der Autor war bemüht, seine Klassen so zu schreiben, daß sie möglichst auf allen Plattformen "gut" aussehen oder wenigstens vollständig zu erkennen sind. Das bedeutet auch, daß Fenster sich immer in der Größe verändern lassen und die in ihnen enthaltenen Objekte sich, sofern sie dieses können, den vorhandenen Platz teilen. Einige wenige Klassen sind jedoch von sich aus nach der Erzeugung nicht mehr veränderbar.
• Wegen des oftmals knappen Bildschirmplatzes sind EditableMemory und die Register teilweise auf den Bildpunkt genau kalkuliert und von der Größe der verwendeten Schrift abhängig, der sie sich anpassen sollten. Unter Umständen kann es unter Unix-Betriebssystemen aber sein, daß die Inhalte solcher Komponenten nicht oder nur zu einem Teil zu erkennen sind.
• Eine Schwäche des JDK, Version 1.0.2, ist es, daß zwar von einem Applet erzeugte Fenster ihre Position ermitteln können, nicht jedoch das Applet selbst. Deswegen können diverse Fenster, wie z.B. das Kontextmenü zu EditableMemory, nicht garantiert an "sinnvollen" Stellen erscheinen.
• Wie so vielen Programmierern oder Hardwareentwicklern in der Geschichte ist es auch dem Autor passiert, daß er die in Zukunft benötigte Anzahl Bits in seinem Code unterschätzt hat - Zahlen werden in allen Komponenten (noch) als Java-int abgelegt, also als vorzeichenbehaftete 32-Bit-Zahl. Damit sind vorläufig keine Register oder RAMs möglich, die 32-Bit-Werte ohne Vorzeichen oder gar noch längere Zahlen speichern.
• Bei hoher Belastung eines Applets durch den Benutzer, insbesondere bei sehr schnellem Klicken auf die Knöpfe "" und "", ist es manchmal möglich, einen java.OutOfMemoryError (Speichermangel) zu erzeugen.

Der Code für die Klassen eines Applets bleibt im Browser geladen, auch wenn die jeweilige HTML-Seite verlassen wird. Damit ist es möglich, Speichermangel in der Java-VM zu erzeugen, wenn viele Applets in einer Sitzung aufgerufen werden.

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