Dieses Projekt wurde 1997 am Lehrstuhl für Datenverwaltungssysteme an der Technischen Universität Chemnitz durchgeführt. Verantwortlicher Professor: Prof. W. Benn Projektleiter: I. Gringer Programmierer: Chris Hübsch (Klassenbibliothek, Binär Baum, AVL-Baum) Sven Bürgel (Stack, Queue, BBaum) Lars Jordan (Graphtraversierung) Jens Fischer (Hashtable) Radka Peneva (Graphformatierung) Diese Datei enthält Informationen für die HTML-Autoren, welche die Applets des ViA-Projektes in ihre Seiten einbinden wollen und für Java-Programmierer, welche weitere Applets zum ViA-Projekt schreiben. Allgemeine Informationen: ------------------------- In diesem Archiv sind alle Dateien, die während der Entwicklung des ViA-Projektes entstanden sind. Im Verzeichnis selbst sind: -die Homepage (in Bezug auf die Programmierung) des Projektes -Eine kleine Klassenübersicht (teilweise veraltet) -allgemeine Gedanken zum Framework (auch teilweise nicht aktuell) -eine Einführung zu Java Sources: Alle Quellcode der Pakete edu.tucz.via sowie binBaum und zwei weiter Verzeichnisse Sources/Test: Quellcodes der Testapplets Sources/Finals: Quellcodes der fertigen Applets Doku: Die HTML-Dokumentation des Paketes edu.tucz.via Applets: Die Pakete edu.tucz.via sowie binBaum und zwei weiter Verzeichnisse Applets/Tests: Testapplets, die während der Entwicklung entstanden sind Applets/Finals: Fertige Applets, die in die online-Scripte eingearbeitet werden können Informationen für HTML-Autoren: ------------------------------- Die Applets werden wie üblich mit dem Applet-Tag in das HTML-File eingebunden. Ein Tag sieht so aus: Alternativer Text *Appletname: Der Name des Appletfiles (siehe weiter unten) *pfad: Gibt die Lage der Klassenfiles (*.class) an, wenn diese sich nicht im gleichen Verzeichnis, wie das HTML-File befinden. (optional) *Classfile1, classfile2: Netscape Navigator erlaub es, mehrere Klassen in eine Datei zu packen. Dazu werden unkompirimierte zip-archive verwendet. Microsoft Internet Explorer kann diese Archive nicht nutzen. Deshalb müssen immer auch die Einzeldateien verhanden sein. Das File viaclasses.zip ist das Archiv mit den primären Klassen des ViA-Projektes. Bei einigen Applets gibt es noch weitere Klassenarchive. *Die Breite (Width) sollte immer größer-gleich 640 sein, jedoch nicht zu groß, da sonst auf einigen Bildschirmen Platzprobleme entstehen können. *Die Höhe (Height) sollte entsprechend größer-gleich 480 sein. *Der Alternative Text wird in Browsern angezeigt, die kein Java interpretieren können. Die Programmdateien für das Applet sind in *.class-files gespeichert. Diese müssen für den Browser an genau definierten Stellen zu finden sein. Alle ViA-Applets benötigen die Klassen aus dem Verzeichnis edu/tucz/via. Deshalb muß dieses (Unter-)Verzeichnis immer im Verzeichnis mit dem Applet sein. Dies kann auch durch einen Symbolischen Link realisiert werden (Auf geeigneten Systemen natürlich nur). Die beiden Applets AVLBaumApplet und BinBaumApplet benötigen zusätzlich das Paket binBaum. Das Einbinden kann analog zum edu.tucz.via-Paket geschehen. Die BBaum-Applets benötigen noch einige Klassen mehr im Applet-Verzeichnis. (Das liegt am Programmierer) Informationen für Programmierer: -------------------------------- Es existiert eine mit javadoc generierte Dokumentation zu allen Klassen des ViA-Packages. Es ist wichtig, daß man die Klassenstruktur kennt, wenn man diese Anleitung ließt. Jedes Applet, daß dem ViA-Projekt hinzugefügt wird, muß von ViAApplet abgeleitet werden. ViAApplet ist eine Klasse im Package edu.tucz.via. Am besten wird gleich das ganze Package importiert. Die Klassen des ViA-Packages müssen sich in einem Verzeichnis(edu/tucz/via) befinden, der ein Unterverzeichnis des Appletverzeichnisses ist. Ein ViAApplet stellt: -ein ViACanvas (grafikFenster), -eine HTMLStringList (verlauf), -eine AblaufSteuerung und -ein Panel (optionen) dar. Im grafikFenster werden die graphischen Elemente (alle von GraphicalObject abgeleitet) angezeigt. Verlauf stellt HTMLStrings dar, die Informationen an den Anwender darstellen. In optionen werden AWT-Elemente angezeigt, um eine Interaktion mit dem Nutzer zu ermöglichen. Mit den Buttons in der AblaufSteuerung wird der Ablauf der Animation gesteuert. Für kompliziertere Datenstrukturen ist es überaus empfehlenswert die Grafik von der Datenstruktur zu trennen. Graphische Aktionen müssen in Animationen rückgängig gemacht werden können. Bei aufwendigen Animationen können schwere Probleme auftreten, wenn die Grafik auch als Datenspeicher verwendet wird. grafikFenster: Es gibt 4 Arten von GraphicalObject(s): Knoten, CompositeGraphicals (auch Layouts), Pfeile und Sonstiges. *Knoten sind Kreise oder Rechtecke, die Werte speichern oder allgemein Informationen darstellen. Auch der nil(oder null)-Zeiger (EndKnoten) und ein "KopfZeiger" (KopfKnoten) sind Knoten. Außerdem gibt es unsichtbare Knoten (InvisibleKnoten) und den Pfeil (Indicator). *Pfeile verbinden immer 2 Knoten miteinander. Um einen Pfeil "frei hängend" erscheinen zu lassen, wird der InvisibleKnoten verwendet. Pfeile können in keine, eine oder zwei Richtungen zeigen. Außerdem ist es möglich, einen Text anzubringen. Dafür werden die verschiedenen Konstruktoren verwendet. *CompositeGraphicals speichern zusammenhängende graphische Strukturen. Sie haben mehrere Aufgaben: - Knoten nach einem Schema auszurichten (d.h. ein Layout auszuführen) - Knoten und Pfeile einander zuzuordnen - Mehrere Objekte zu einer Einheit auf dem Canvas zusammenzufassen *Sonstige Objekte sind im Moment nur Linien (LineGraphical). Es ist aber auch möglich, weitere Elemente, wie z.B. Quadrate, Text oder Kreise, zu "erfinden". Alle Objekte werden mit addItem/addComposite bzw. putItem hinzugefügt. Bei addXXX wird das Objekt "gelayoutet" und neu gezeichnet. PutXXX wird das Objekt einfach nur hinzugefügt. Mit removeItem bzw. delItem werden Objekte entfernt (remove=mit neuzeichnen). Das ViACanvas benutzt ein virtuelles Koordinatensystem. In der Grundeinstellung ist das Fenster immer 1000 Punkte breit. Die Höhe ergibt sich durch internes Umrechnen genauso, daß die Einheiten auf x- und y-Achse die gleichen Proportionen haben. (d.h. ein Kreis mit drawOval(0,0,10,10) ist auch in logischen Koordinaten immer kreis-rund). Die Umrechnungen werden intern durchgeführt. Deshalb werden alle Punkte auf dem Canvas mit Hilfe der Location-Klassen repräsentiert. -Die Location-Klasse ansich stellt einen festen Punkt im logischen Koordinatensystem dar. Mit dieser Klasse sind auch Verschiebungen des Koordinatenursprungs (normalerweise links-oben) möglich. Eine Veränderung der logischen Breite/Höhe wird in ViACanvas mit zoomIn/zoomOut veranlaßt. -OffsetLocation ist eine Location, die immer als relative Verschiebung zu einer anderen Location zu interpretieren ist. Die Anpassung erfolgt dynamisch. Wenn also die "ZielLocation" sich bewegt, dann wird auch diese Location mit verschoben. -Die RelLocation geht davon aus, daß das ViACanvas immer 1.0 Einheiten breit und auch 1.0 Einheiten hoch ist. Mit dieser Klasse lassen sich also Positionen, wie z.B. "im unteren Drittel(=0.66)" angeben. Die Layout-Klassen rechnen diese virtuellen Koordinaten innerhalb der layout-Methoden der Graphical-Objects in physische Koordinaten um. verlauf: Die HTMLStringList ist einer normalen java.awt.List sehr ähnlich. Ein Änderung ist die Fähigkeit HTML-ähnliche Strings anzuzeigen, die Formatierungen enthalten können. Dafür werden jedoch von der Liste keine Events ausgelöst. AblaufSteuerung: Mit den Buttons kann der Fortgang der Animation bestimmt werden. Wenn die Checkbox aktiviert ist, dann werden gleich alle Schritte der Animation ausgeführt. Während der Animation wird das optionen-Panel deaktiviert, so daß keine Befehle aufgerufen werden solange vorherige noch animiert werden. optionen: In dieses Panel werden die AWT-Elemente eingetragen, um irgendwelche Aktionen auszulösen (löschen, einfügen, etc.) außerdem können darin Parameter entgegengenommen werden (per TextField, List, usw.) Es wird empfohlen, ein CardLayout und darin dann ein GridBagLayout für die UnterPanels zu verwenden. Animation: Eine Animation ist eine Folge von Commands. Es gibt eine Reihe verschiedener Commands. Beispielsweise bewegen sie Knoten auf dem grafikFenster, zeigen Text im verlauf an oder fügen Knoten dem grafikFenster hinzu bzw. entfernen diese. Auch andere Kommandos können in Knoten gefaßt werden (z.B. ein neuzeichnen des grafikFensters oder eine zoomÄnderung) Ein CompositeCommand faßt mehrere Commands entsprechend dem CompositePattern zusammen. Es könne auch eigene Commands erzeugt werden. Dazu müssen nur die 4 Methoden der abstrakten Command-Klasse überschrieben werden. Commands sollte nur die grafische Anzeige verändern und Ausgaben machen. Die dargestellte Datenstruktur sollte intern mit anderen Mitteln dargestellt werden. Nur sehr einfache Datenstrukturen können auch direkt im grafikFenster verwaltet werden. Dazu wird dann meisten gleich ein entsprechendes CopositeGraphical verwendet. Implementationshinweise: Das neue Applet sollte unbedingt von ViAApplet abgeleitet werden. Im init() muß die überschriebene Methode init von ViAApplet aufgerufen werden, da diese wichtige Initialisierungen ausführt. Um einen Copyright-String zu setzen ist lediglich der String AppletCopyright entsprechend zu setzen. Init sollte außerdem die AWT-Elemente für das optionen-Panel erzeugen und die interne Datenstruktur entsprechend initialisieren. Es wird empfohlen, das Eventhandling der Version 1.02 des JDK zu verwenden. Die Klassen des ViA-Packages sind auch JDK1.02-konform entwickelt worden. In der action-Methode werden je nach Aktion entsprechende service-Methoden aufgerufen. In den Service-Routinen werden die internen Datenstrukturen vollständig verändert und eine Animation vorbereitet. Als erstes wird dazu eine neue ViAAnimation erzeugt. Mit add() werden zu dieser Animation Kommandos hinzugefügt. Diese Kommandos sollten graphische Anzeigen machen und gleichzeitig einen Informationstext ausgeben (dazu verwendet man am besten CompositeCommands). Zum Schluß wird doAnimation() mit dieser erzeugten Animation als Parameter aufgerufen. Die Veränderung der internen Datenstruktur kann natürlich parallel oder getrennt von der Animations-Erzeugung geschehen. Eigene Knoten: Es können auch eigene Knoten definiert werden. Entweder leitet man diese von SquareKnoten ab oder von RoundKnoten. Besonders die Position und die Richtung der Pfeile werden bei diesen Knoten anders als in er Default-Implementation sein. Eigene Layouts: Ein eigenes Layout ist immer eine Unterklasse von CompositeCommand. Es sollte die Methoden getAllEffected und exactLayout implementiert werden, um gewünschtes Verhalten zu implementieren. Ebenfalls sind Methoden nötig, die Knoten und Pfeile der Datenstruktur verwalten. Eigene Commands: Eigene Commands müssen nur doIt, unDoIt, showIt und unShowIt (und den Konstruktor) implementieren. unXXX ist die entsprechende Umkehroperation. Es ist darauf zu achten, daß jedes Command seine Veränderungen wirklich vollständig rückgängig macht, da es sonst zu unvorhersehbaren Reaktionen kommen kann, wenn die Animationen länger werden. Bei den show-Methoden können die do-Methoden verwendet werden. Show stellt die Änderung auch dar, während do die Veränderungen nur unsichtbar erledigt (d.h. ein späteres Layout und Neuzeichnen ist nötig). Abschluß: --------- Bei Fragen bin ich per Mail erreichbar (Chris.Huebschu@Informatik.TU-Chemnitz.DE) und werde schnellstmöglich antworten. Vorher sollte man sich jedoch genau mit der Klassenbibliothek beschäftigen.