Matti Lattu, Co-Autor von Jeliot A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: Excuse me, can you tell me where I am? The man below says: Yes, you‘re in a hot air balloon, hovering 30 feet above this field. You must be an engineer, says the balloonist. I am, replies the man. How did you know? Well, says the balloonist, everything you told me is technically correct, but it‘s of no use to anyone. The man below says: You must be in management. I am, replies the balloonist, but how did you know? Well, says the man, you don‘t know where you are, or where you‘re going, but you expect me to be able to help. You‘re in the same position you were before we met, but now it‘s my fault. Matti Lattu, Co-Autor von Jeliot

Algorithmen-Animation mit Jeliot Ein Projekt der AAPS-Group an der Universität Helsinki 2 03.07.2002 Seminar Softwarevisualisierung, Katja Silligmann

Was ist Jeliot ? Umgebung zum Visualisieren von Algorithmen in Java (proof of concept – Prototyp) Nachfolger von Eliot (Visualisierung von C-Programmen) Jeliot steht für Java-Eliot eliöt kommt aus dem Finnischen, bedeutet: “Lebewesen“ entwickelt im Rahmen der AAPS Forschungsgruppe (Animation Aided Problem Solving), Universität Helsinki

Themenübersicht Motivation Konzepte und Design Benutzung von Jeliot, Beispiel-Animationen Implementierung Offene Probleme Vergleich mit DDD, Leonardo, Tango Jeliot2000

Motivation Traditionell: Animationen müssen von Hand implementiert werden (z.B. Tango, Polka)  Kostet Zeit ! Debugger können nur einfache Datentypen visualisieren, Abstraktionsebene zu niedrig (z.B. DDD)  Programmverständnis ??

Ziele in Jeliot Einfache Visualisierungen eigener Programme Graphische Objekte sollen sich nicht ruckartig, sondern sanft bewegen UserInterface flexibel und trotzdem leicht handhabbar ADTs abstraktem Verständnis entsprechend visualisieren “proof-of-concept“ (zeigen, dass es prinzipiell geht...)

Konzepte Paradigma der selbst-animierenden Datentypen Theater-Metapher als zentrale Design-Strategie  Server-Implementierung  GUI (sowohl in der Server-Implementierung als auch in der GUI)

Konzepte Selbstanimation Prinzip der selbst-animierenden Datentypen : werden von Jeliot zur Verfügung gestellt sind herkömmliche Datentypen inklusive visueller Entsprechung führen Bewegungen aus, die mit den Operationen der ADTs verbunden sind in Jeliot vorhanden: Basistypen, Rstack, Rqueue

Design Theater-Metapher(1) Ein Algorithmus wird als Drehbuch (script) eines Theaterstücks betrachtet Begriffe: Rollen (roles), Darsteller (actor), Bühne (stage), Regisseur (stage director) Rollen entsprechen den Variablen/Datentypen Für jede Rolle gibt es mindestens einen Darsteller Ein Darsteller spielt genau eine Rolle

Design Theater-Metapher(2) Interaktionen zwischen den Rollen: Operationen (in der Praxis meist Zuweisungen und Vergleiche) Rollen sind eigentlich Models (MVC-Pattern) Darsteller sind Views mit einer Menge von Attributen, die das Aussehen beschreiben Attribute: shape, color, size und location (z.B. int dargestellt als Kreis mit Zahl in der Mitte, gelb, Radius 3cm, gezeichnet in der linken unteren Bildecke)

Design Theater-Metapher(3) Regisseur ist der User, bestimmt Aussehen der Darsteller Algorithmus kann auf mehreren Bühnen simultan stattfinden Jeder Bühne steht pro Rolle ein Darsteller zur Verfügung Regisseur kann auf jeder Bühne Rollen auswählen (und damit z.B. nur die für das Verständnis des Algorithmus wichtigen Variablen animieren) Die Bühnen sind verschiedene Views desselben Programms!

Umsetzung der Theater-Metapher GUI: Jedem Stage entspricht ein Fenster, in dem der Algorithmus ablaufen kann User wählt über “Setup“-Fenster eines Stages die darzustellenden Variablen aus und kann Actors dieses Stages manipulieren Kontrolle über Stages und Animation geht vom Director-Fenster aus

Umsetzung der Theater-Metapher Server: Bei Animation gibt es für jede Role-Instanz mindestens eine Actor-Instanz, Actor kennt seine Role, Role braucht Actor nicht zu kennen Stage-Instanzen verwalten die zu ihnen gehörigen Actor-Instanzen Java-Klassen: Director, Stage, Role, Actor mit Verantwortlichkeiten entsprechend der Metapher (Genaueres siehe Animation – Nachrichtenaustausch)

Benutzung von Jeliot(1) EJava Programme müssen in EJava geschrieben sein (Name kommt von Eliot-Java) EJava ist Java(tm) sehr ähnlich, bis auf neue animierfähige Datentypen (erben in Jeliot alle von Klasse: Role) Operationen auf Rstack (LIFO) : push(long value) pop() Operationen auf Rqueue (FIFO) : add(long value) remove()

Benutzung von Jeliot(2) EJava Beschränkungen Keine Vererbung (extends) möglich!  da implizit immer von Applet geerbt wird Fehlerüberprüfung schwächer als in Java, z.B. ist möglich: Rstack stack = new rubbish(); bei Arrays sehr viele Beschränkungen: nur ein-/zweidimensional ist erlaubt muss so deklariert werden: int[] array; array = {1, 2}; nicht möglich ArrayIndexOutOfBoundsException gibt es nicht

Jeliot vorführen: http://cs.joensuu.fi/~jeliot/

Implementierung(1) Implementierung(1)

Implementierung(2) Ablauf: Main Window liest Algorithmus, schickt Code zum Parser. Parser extrahiert animierbare Variablen und bildet Liste. Code Generator fügt Methodenaufrufen auf Variablen Animations-Requests hinzu, Liste von animierbaren Variablen geht an Main Window. Java Compiler kompiliert generierten Code, URL der Class-Datei wird an Main Window gesendet. Main Window leitet Variablenliste und URL an Animator(animation engine) weiter, dieser startet Animation.

Implementierung(3) Server Server-Prozess bekommt alle Requests des Main Window  ein einziges Socket zum Empfangen von Requests Für jeden neuen Client wird neues Socket und ein eigener Kommunikations-Thread erzeugt  eigener Kanal für jeden Client Kommunikations-Thread erzeugt für jeden Client ein gesondertes Verzeichnis (um Daten für Client abzulegen)

Implementierung(4) Kommunikations-Thread Empfängt zwei Arten von Messages vom Client: den Code Stop-Requests Sendet drei Arten von Messages zurück: Liste von Objekten, die animiert werden können URL zur Class-Datei Kompilierungs-Fehler, der vom Parser, vom Code-Generator oder vom Java Compiler stammen kann

Implementierung(5) Der Animator Modul, das Animation zeigt Kleiner Server für Requests aus dem generierten Code: Methodenaufrufe zum Senden von Requests an den Animator sind in generierten Code eingebunden Typische animierte Operation: Vergleich oder Zuweisung Während Operation animiert wird, ist GUI blockiert. Dann kehrt Kontrolle zurück an GUI/Applet Animator besteht aus: director, stages, Kommunikation zw. director und stages, GUI.

Implementierung(6) Animation - Nachrichtenaustausch Requests der Role-Instanzen kommen bei Director an Director verteilt Requests an alle vorhandenen Stage-Instanzen Jeder Stage prüft, ob die Rolle bei ihm visualisiert werden soll Falls ja und falls eine Actor-Instanz gefunden wurde  Request geht an Actor (Darsteller), der Grafik-Routinen auf JAPI-Instanz aufruft (bei Start der Animation) Antworten aller Stages werden gesammelt, gehen dann an director

Nachrichtenaustausch während der Animation :

Implementierung(8) Realisierung von selbstanimierenden Datentypen geteilt in Role- und Actor- Klassen visuelle Datentypen sind Role-Instanzen, senden Visualisierungs- Requests an Actor-Instanz (Actor als entsprechendes Gegenstück) falls Actor den Request erhält, macht er Aufrufe auf JAPI-Instanz (Jeliot Animation Primitive Interface) Korrektur zum Vortrag: Im Gegensatz zum Vorgänger Eliot werden hier keine Polka-Zeichenroutinen mehr benutzt. JAPI-Klasse enthält nur Java

Offene Probleme Jeliot zeigt nicht, wie Werte berechnet werden (Problem besonders für didaktisches Ziel, Lern-Tool...) Läuft nur unter Windows einwandfrei Komplexere ADTs können nicht visualisiert werden Wünschenswert: Interface für Jeliot-ADTs, das der User nutzen kann, um eigene Visualisierungen für ADTs zu schreiben

Jeliot im Vergleich mit Tango, Leonardo, DDD Tango: flexibler, dafür aufwändiger (von Hand coden!), mit Tango prinzipiell alles möglich. Leonardo: Deklarationen – aufwändiger als Jeliot, da auf sehr unabstrakten Ebene, evtl. weniger aufwändig als Tango DDD: Nutzer braucht sich nicht um low-level-Ebene zu kümmern, DDD kann im Gegensatz zu Jeliot Querbeziehungen visualisieren(!) (  Entfalten von verschachtelten ADTs)

Jeliot im Vergleich mit Tango, Leonardo, DDD - Fortsetzung DDD bietet keine abstrakte Sicht auf Programme/Algorithmen, da nur vorhandene Datenstrukturen visualisiert werden können, jedoch keine abstrakten Datentypen wie z.B. Graphen wie in Jeliot fehlt Möglichkeit, eigene Visualisierungen zu schreiben Vergleich von Jeliot und DDD interessant, da beide den Ansatz verfolgen, Visualisierung für den Nutzer möglichst einfach zu gestalten da DDD sich zum Ziel gesetzt hat, in Zukunft abstraktere Sicht auf Programm/Algorithmus zu ermöglichen + Unterstützung eigener Visualisierungen (User)

Jeliot2000 Verbesserungen zu Jeliot: kann Beziehungen visualisieren (z.B. Berechnungen, Auswertung von Unterausdrücken) wichtig für die Intention von Jeliot, Anfängern das Verständnis von Algorithmen zu erleichtern! Schwäche: auf Sprachelemente und Kontrollstrukturen beschränkt, keine ADTs visualisierbar

Jeliot2000 Screenshot

Literatur E. Sutinen, J. Tarhio, S.-P. Lahtinen, A.-P. Tuovinen, E. Rautama, V. Meisalo: Eliot – an Algorithm Animation Environment. No. A-1997-4, Series of Publications A, Department of Computer Science, University of Helsinki, 1997. J. Haajanen, M. Pesonius, E. Sutinen, J. Tarhio, T. Teräsvirta, P. Vannine: Animation of User Algorithms on the Web. In Proceedings of VL´ 97 IEEE Symposium on Visual Languages, pages 360-367, 1997. R. Ben-Bassat Levy, M. Ben-Ari, P.A. Uronen: The Jeliot 2000 Program Animation System. Journal of Visual Languages and Computing, 2001. Andreas Zeller: Datenstrukturen visualisieren und animieren mit DDD. Informatik Forschung und Entwicklung 16, 65-75, Springer-Verlag 2001. Jeliot Homepage http://cs.joensuu.fi/~jeliot/www/ AAPS Homepage http://www.cs.helsinki.fi/research/aaps/