V isualisierung von Java-Programmenhomepage.lnu.se/staff/akemsi/courses/seminar/ss05/papers/...von V...

Seminar “Softwarevisualisierung”

Technische Universität Kaiserslautern

Betreuer: Dr. Andreas Kerren

Visualisierung von Java-Programmen

von

Samuel Strupp

Visualisierung von Java-Programmen! 27.08.2005

Samuel Strupp (349495)! 1

Inhaltsangabe

1. Einführung! ! ! ! ! ! ! ! ! ! ! ! Seite 3

2. Programmvisualisierung - eine Definition! ! ! ! ! Seite 3

! 2.1 Visualisierung! ! ! ! ! ! ! ! ! ! ! Seite 3! 2.2 Softwarevisualisierung!! ! ! ! ! ! ! ! ! Seite 3! ! 2.2.1 Algorithmusvisualisierung!! ! ! ! ! ! ! Seite 4! ! 2.2.2 Programmvisualisierung! ! ! ! ! ! ! ! Seite 5

3. Was kann man visualisieren?! ! ! ! ! ! ! ! Seite 6

! 3.1 Visualisierungsideen! ! ! ! ! ! ! ! ! ! Seite 6! 3.2 Probleme! ! ! ! ! ! ! ! ! ! ! ! Seite 8

4. JIVE! ! ! ! ! ! ! ! ! ! ! ! ! ! Seite 10

! 4.1 Über JIVE! ! ! ! ! ! ! ! ! ! ! ! Seite 10! 4.2 Anforderungen an JIVE! ! ! ! ! ! ! ! ! Seite 10! 4.3 Lösungen in JIVE! ! ! ! ! ! ! ! ! ! Seite 11! ! 4.3.1 Verschiedene Ansichten! ! ! ! ! ! ! ! Seite 11! ! 4.3.2 Kontursemantiken für Java! ! ! ! ! ! ! Seite 13! 4.4 Die Architektur von JIVE! ! ! ! ! ! ! ! ! Seite 15! 4.5 Kurzer Ausblick in die Zukunft! ! ! ! ! ! ! ! Seite 17

5. JOVE!! ! ! ! ! ! ! ! ! ! ! ! ! Seite 18

! 5.1 Über JOVE!! ! ! ! ! ! ! ! ! ! ! Seite 18! 5.2 Anforderungen an JOVE! ! ! ! ! ! ! ! ! Seite 18! 5.3 Lösungen in JOVE! ! ! ! ! ! ! ! ! ! Seite 18! 5.4 Die Architektur von JOVE! ! ! ! ! ! ! ! ! Seite 20! 5.5 Kurzer Ausblick in die Zukunft! ! ! ! ! ! ! ! Seite 24

6. Zusammenfassung und eigene Meinung!! ! ! ! ! Seite 24

7. Literaturangaben! ! ! ! ! ! ! ! ! ! ! Seite 25



1. Einführung

Dieses Dokument beschäftigt sich mit der Programmvisualisierung, also der grafischen Darstellung von Programmzuständen und Programmabläufen. Zunächst wird der Begriff der “Programmvisualisierung” erklärt, was darunter genau zu verstehen ist und wo der Unterschied zu anderen Visualisierungen besteht. Im darauf folgenden Abschnitt werden verschiedene Ideen der Programmvisualisierung besprochen und welche Probleme bei der Visualisierung häufig auftreten. Danach werden die zwei Visualisierungswerkzeuge JIVE und JOVE für Java-Programme vorgestellt. Das Interesse liegt dabei auf deren Fähigkeiten die Programmabläufe und Programmstrukturen aufzunehmen und über geeignete Grafiken sinnvoll darzustellen. Es wird also speziell die Visualisierung von objekt-orientierter Software betrachtet, welche in der Sprache Java geschrieben wurde!

2. Programmvisualisierung - eine Definition

Zunächst wird der Begriff der „Visualisierung” erläutert, um danach über die Software-visualisierung auf die „Programmvisualisierung” und den Unterschied zur „Algorithmus-visualisierung” zu kommen.

2.1 Visualisierung

Eine Gemeinsamkeit aller Visualisierungen ist, Informationen unter einem bestimmten Gesichtspunkt zu transformieren, um sie in einer geeigneten Sicht dem Anwender in einer möglichst nützlichen Form zu präsentieren.

Die Transformation beinhaltet hierbei oft das geschickte Sichtbarmachen von nicht sichtbaren Vorgängen, Ereignissen oder Zuständen. Im wesentlichen gibt es drei Arten von Visualisierungen: die Visualisierung als Verschriftlichung, die Visualisierung als Übersetzung ins Nonverbal-Optische und schließlich die Visualisierung als Illustration.Das Ziel jeder Visualisierung ist die Bildung eines mentalen Modells.

2.2 Software-Visualisierung

Die Softwarevisualisierung hat das Ziel, die Funktionsweise einer Software, also deren Arbeitsweise und Struktur, verständlich zu machen. Dies wird hauptsächlich über Techniken der Typographie oder der Kinematographie zu erreichen versucht. Dabei beschreibt die Typographie das Darstellen von Text. Die Kinematographie bezeichnet die Verfahren zur Aufnahme und Wiedergabe von bewegten Bildern, bei denen man in rascher Folge Bildreihen erzeugt und dann zur Betrachtung in analoger Weise wiedergibt. Es werden also hauptsächlich Text und animierte Grafiken für die Visualisierungen von Software benutzt.

Im wesentlichen gibt es zwei Arten von Softwarevisualisierung: die Algorithmen-visualisierung und die Programmvisualisierung [8] (siehe Abbildung 2.1).



statische Algorithmen-Visualisierung

dynamische Algorithmen-Visualisierung

Algorithmen-Visualisierung

statische Code-

Visualisierung

dynamische Code-

Visualisierung

Programm-Visualisierung

statische Daten-

Visualisierung

dynamische Daten-

Visualisierung

Software-Visualisierung

Abbildung 2.1: Aufteilung der einzelnen Software-Visualisierungs-Gebiete

2.2.1 Algorithmusvisualisierung

Im wesentlichen findet man bei der Visualisierung von Algorithmen nur strukturelle Ähnlichkeiten zwischen den Darstellungselementen und dem tatsächlich implementierten Verfahren. Die Algorithmusvisualisierung ist also die Darstellung von Software auf einem hohen Abstraktionsgrad. Das Teilgebiet lässt sich weiter in statische- und dynamische Algorithmenvisualisierung untergliedern, wobei letzterer Visualisierungstyp auch als Algorithmenanimation bezeichnet wird. Es gibt zum Beispiel eine Menge Algorithmen-Animationen, welche die Arbeitsweise verschiedener Sortierverfahren mit Hilfe einfacher animierter Darstellungen erläutern.

Ein einfaches Beispiel für eine statische Algorithmenvisualisierung ist ein Programmablaufplan (Flussdiagramm), welcher in groben Zügen die Funktionsweise des Programms bzw. des Algorithmus beschreibt. In der Regel werden nur wesentliche Verfahrensschritte in statischer Form unter Verwendung einer grafischen Symbolik dargestellt. Jeder Bezug auf eine konkrete Programmiersprache oder Implementier-ungsvariante wird dabei vermieden.

In Lehrbüchern findet dieser Visualisierungstyp oft Anwendung in statischer Form. Werkzeuge, welche Algorithmusvisualisierungen dynamisch darstellen, sind meist unflexibel im Bezug auf Verbesserungen oder Änderungen des Algorithmus, da dieser meist fest im Werkzeug selber implementiert ist und nur selten über eine Beschreibungssprache interpretiert wird. Die meisten Algorithmusvisualisierungen können daher auch nur mit unterschiedlichen Daten arbeiten die normalerweise auch in einer be-stimmten Struktur vorliegen müssen. Das Anwend-ungsgebiet dieses Visualisierungstyps dient deswegen auch hauptsächlich zum Verstehen des visualisierten Algorithmus und wird somit haupt-sächlich in der Lehre genutzt.



Abbildung 2.3: Beispiel einer Code-Visualisierung

2.2.2 Programmvisualisierung

Der Unterschied zwischen der Programmvisualisierung und der Algorithmusvisualisierung soll durch eine Definition des Begriffes Algorithmus verdeutlicht werden: Algorithmen sind exakt formulierte Rechenvorschriften bzw. Vorgehensweisen, die auf Computern als ausführbare Programme implementiert und auf diese Art für die Lösung von Aufgaben angewandt werden können.

Ein Algorithmus besteht somit aus einer wohldefinierten endlichen Folge von elementaren Rechenoperationen und Entscheidungen, um aus einer bestimmten Menge von Eingabegrößen das gewünschte Resultat zu erzeugen.

Programme sind also nichts anderes als Implementierungsvarianten von bestimmten Algorithmen. Bei der Programmvisualisierung geht es also um die Darstellung einer konkreten Implementierung eines oder mehreren Algorithmen. Der wesentliche Unterschied der beiden Visualisierungstypen liegt also im Abstraktionsgrad. Die Programmvisualisierung hat in den meisten Fällen eine geringere Abstraktion, da sie ja die konkrete Implementierung und nicht die Idee eines Algorithmus darstellen muss.

Die Programmvisualisierung kann man in zwei weitere Gruppen aufteilen, nämlich die Codevisualisierung und die Datenvisualisierung. Diese Unterscheidung macht Sinn, da zur Berechnung von Daten oft charakteristische Datenstrukturen im Programm verwendet werden. Diese Strukturen kann man wiederum auf spezielle Weisen darstellen, um die Funktionsweise einer solchen Berechnung bei der konkreten Implementierung noch besser vermitteln zu können.

Es gibt viele Möglichkeiten, Daten intuitiver darzustellen. Zum Beispiel kann man Listen-Einträge durch Rechtecke, deren Inhalt durch die entsprechenden Inhalte gefüllt sind, darstellen. Die Verkettung der einzelnen Elemente wird dabei einfach durch Pfeile gekennzeichnet (siehe Abbildung 2.2). Wird jetzt an der Liste etwas hinzugefügt, gelöscht oder vertauscht, kann dieser Vorgang bei der dynamischen Datenvisualisierung durch entsprechende Animationen, farbige Kennzeichnungen oder Symbole leicht verständlich dargestellt werden.

3 6 8 2 12 5

Abbildung 2.2: Beispiel einer Daten-Visualisierung

Die Codevisualisierung kann zum Beispiel das Darstellen des entsprechenden Programmcodes sein (siehe Abbildung 2.3). Das farbige Hervorheben des gerade aktiven Programmteils kann als Code-Animation interpretiert werden. Aber auch die Darstellung von Rekursionsbäumen bei rekursiven Verfahren oder die Darstellung eines Sequenz-Diagramms kann zu diesem Visualisierungstyp gehören. Oft ist es aber auch nicht eindeutig, zu welchem Teilgebiet eine Visualisierung gehört, da sich die beiden Gebiete bei solchen Darstellungen überschneiden. Zum Beispiel das Darstellen von Klassenbeziehungen mit konkreten Instanzen und Werten kann sowohl der Code- als auch der Datenvisualisierung zugeordnet werden, denn zum einen wird die Struktur des Programms, also dessen Objekte und ihre Beziehungen, dargestellt und zum anderen werden auch die einzelnen instanziierten Objekte mit deren Daten angezeigt. Ob die Objekte jetzt spezielle Datenstrukturen repräsentieren oder Funktionsteile des Programms sind, wird in solch einem Fall nicht unterschieden.



In den folgenden Kapiteln werden hauptsächlich nur noch Programmvisualisierung von Java-Programmen betrachtet und dabei anhand zweier Beispiele (Kapitel 4 und 5) vor allem auf Eigenschaften wie Objekt-Orientierung und Threads eingegangen.

3. Was kann man visualisieren?

In diesem Kapitel werden verschiedene Ideen vorgestellt, welche Teile eines Programms visuell repräsentiert werden können, was man dabei beachten sollte und was es für Probleme bei der Visualisierung auftreten können.

3.1 Visualisierungsideen

Wie im vorhergehenden Kapitel beschrieben, gibt es bei der Programmvisualisierung zwei unterschiedliche Arten von Visualisierungen, die Datenvisualisierung und die Code-visualisierung. Die Idee bei der Visualisierung ist es, die Struktur und Art des Programms auf sinnvolle Weise grafisch darzustellen. Es ist z.B. möglich, jede Instanz eines Objektes in Java einzig und allein durch das Füllen eines Kästchen in einem Gitterfeld zu repräsentieren. Allerdings ist dies wohl eher wenig aussagekräftig, da man zwar eine grafische Darstellung der instanziierten Objekte hat, aber aus dieser Darstellung nicht viel Informationen entnehmen kann. Der Informationsgehalt einer Darstellung ist mit ausschlaggebend für die Qualität einer Visualisierung. Der zweite wichtige Punkt ist die Interpretierbarkeit der Visualisierung. Eine Visualisierung, die zwar viele wertvolle Informationen beinhaltet, dies aber auf eine Weise darstellt, die vom Menschen gar nicht oder nur sehr mühsam interpretiert werden kann, ist wertlos. Es ist also wichtig, sich Gedanken darüber zu machen, was man darstellen kann, was sinnvoll ist, dargestellt zu werden und vor allem, wie man es dann darstellt.

Es gibt viele Ideen für die Visualisierung von Programmen. Zunächst werden einige Ideen betrachtet, welche eher der Codevisualisierung zuzuordnen sind:

Die Darstellung des Quellcodes ist sicher eine der einfachsten und geläufigsten Programmvisualisierungen. Viele statische Programmvisualisierungen bauen ihre Darstellungen des Programms anhand des Quellcodes auf (siehe Abbildung 2.3).

Die Darstellung von Objekt-strukturen wird auch häufig eingesetzt, um zum Beispiel die Objektstruktur eines Programms in UML wieder-zugeben. Solche Diagramme lassen sich relativ einfach anhand des Quellcodes erzeugen. Eine gut struk-turierte und somit lesbare Darstellung dieser Diagramme wird al lerdings um so komplizierter, je komplexer die Objektstruktur wird (Beispiel siehe Abbildung 3.1).

Instanzen von Objekten können auch visualisiert werden. Dies ist bei der dynamischen Codevisualisierung sehr sinnvoll, um das Verständnis für den Ablauf des aktuellen

Abbildung 3.1: Mögliche Visualisierung einer Objektstruktur als UML-Diagramm



Programms zu erhöhen. Auch für das Debuggen von Programmen kann eine solche Visualisierung gut genutzt werden. Instanzen können auf verschiedene Weisen dargestellt werden, zum Beispiel durch einen einfachen Zähler der Instanzen eines bestimmten Objekts oder wieder durch ein Diagramm, in dem durch Pfeile auch aktuelle Objektverknüpfungen dargestellt werden können (siehe beispielsweise Abbildung 4.3 in Kapitel 4).

Die bildliche Repräsentation von Methodenaufrufen sind oft hilfreich, um die Kommunikation zwischen Objekten nachvollziehen zu können. Eine mögliche Visualisierung von Methodenaufrufen zwischen verschiedenen Klassen und deren Instanzen ist in der Abbildung 3.2 dargestellt. Sie stammt aus dem Visualisierungswerkzeug „Jinsight“ [4] von Wim de Pauw und weiteren. Ob dies jetzt eine sinnvolle Visualisierung ist oder nicht, hängt immer vom Kontext sowie dem Betrachter ab.

Den Ablauf eines Programms festzuhalten und gleich-zeitig visuell darzustellen, erleichtert es enorm, die Entstehung von Fehlern nachvollziehen zu können oder den Ablauf im allgemeinen zu verstehen (Beispiel in Abbildung 4.1). Oft werden hierfür Sequenzdiagramme gezeichnet. Nicht nur der Ablauf des Programms selbst kann interessant sein, sondern auch, was daraus abgelesen werden kann. So kann das Visualisierungs-werkzeug „JaVis” [3], das von Katharina Mehner an der Universität von Paderborn entwickelt wurde, Deadlocks im Programm erkennen und diese selbstverständlich auch visualisieren (Abbildung 3.3).

Eine recht interessante Sache ist die Darstellung von Threads. (Beispiel in Abbildung 4.1, 4.5 oder 5.1) Die Darstellung von Threads in einer Visualisierung ist sehr wichtig, da ohne diese Komponente wichtige Teile, die zum Verständnis der Entstehung der Visualisierung beitragen, fehlen. Man kann nicht nur Threads als Instanzen darstellen, sondern zum Beispiel auch zu jedem Thread seine Ablaufgeschichte im Programm.

Eine weitere Möglichkeit, um Informationen über ein Programm zu bekommen, ist das Visualisieren von Kommunikationen zwischen Betriebssystem und dem Programm. Dies kann die Inanspruchnahme fremder Ressourcen durch das Programm verdeutlichen und zudem den Grad der Abhängigkeit zur Laufzeit.

Ideen von Datenvisualisierungen:

Die Visualisierung von Daten, die in einem Programm genutzt werden bzw. vorhanden sind, kann auch sehr nützlich sein. Man kann sich zum Beispiel vorstellen, dass man Variablenwerte wie numerische Werte sowie Zeichen und Texte aber auch komplexe Datenstrukturen wie Bilder, Videos und sogar Töne visualisiert, um den Ablauf eines Programms, das mit diesen Daten arbeitet, besser verstehen zu können. Allerdings ist hier die Frage, ob dies wirklich noch zur Programmvisualisierung gehört. Bei der Darstellung von Variablen-Werten ist das weniger die Frage, aber bei der Darstellung von Bildern,

Abbildung 3.2: Jinsight Visualisieung von Methodenaufrufen (Linien)

Abbildung 3.3: Deadlock in JaVis



Tönen und Videos wohl schon, da dies sehr spezielle Anforderungen sind und vielleicht eher in den Bereich der Algorithmusvisualisierung fallen. Klar abgrenzen kann man dies allerdings nicht, da auch spezialisierte Visualisierungen ihren Platz in allgemeineren Visualisierungs-Umgebungen haben sollten.

Datenstrukturen können auch anhand des Quellcodes erkannt werden und somit spezielle Darstellungsformen gewählt werden. Einfache Beispiele hierfür sind zum Beispiel einfach und doppelt verkettete Listen (Abbildung 2.2), Bäume (Abbildung 4.3) oder auch der Aufbau des Stacks.

Die exakte Darstellung des vom Programm zugeteilten Speichers und dessen Belegung kann auch sehr Informativ sein, wenn Interesse an der Low-Level-Ebene des Programms besteht. Allerdings wird diese Verteilung der Daten und die Speicherzuweisung zum Großteil vom Betriebssystem erledigt und ist zudem bei heutigen Systemen sehr dynamisch. Das hat zur Folge, dass die Informationen darüber erstens nur schwer zugänglich sind und zweitens sich die Struktur nur schwer exakt abbilden lässt.

Eine Darstellung von Pufferzuständen oder Streamdaten kann, wenn es in geeigneter Weise erfolgt, auch sehr zu dem Verständnis eines Programmablaufs dienen. Allerdings sind auch hier wieder sehr spezielle Anforderungen an das Visualisierungs-Werkzeug zu stellen, und die Menge an Daten eines Streams ist auch sehr schwer auf geeignete Weise zu visualisieren.

Eine weitere Möglichkeit der Visualisierung liegt in der Möglichkeit, externe Kommunikation, die über das Betriebssystem hinaus geht, darzustellen. Zum Beispiel könnte man Netzwerkverbindungen und die damit verbundenen Datenflüsse visualisieren. Das Programm Azureus [9] beinhaltet zum Beispiel solch eine Visualisierung. Dabei handelt es sich um ein File-Sharing-Programm auf Java-Basis, welches es erlaubt, gleichzeitig von mehreren Quellen eine Datei herunter zu laden. Die Verbindungsstruktur ist in der Abbildung 3.4 repräsentiert.

Dies ist natürlich nur ein kleiner Ausschnitt von Ideen, welche Teile eines Programms visualisiert werden können. Zudem ist die Vielfalt der Darstellungsmöglichkeiten enorm.

3.2 Probleme

Es gibt natürlich auch Probleme bei der Programmvisualisierung, welche nicht so einfach zu lösen sind. In diesem Kapitel werden ein paar typische Probleme beschrieben.

1. Skalierbarkeit der DarstellungenViele Ansichten von Visualisierungen sind sehr detailliert und umfangreich. Das hat zur Folge, dass bei der Visualisierung von sehr großen Systemen die Darstellungen sehr komplex, umfangreich und für den Betrachter oft unüberschaubar werden. Es ist beispielsweise wenig sinnvoll, einen Benutzer in einem Objektdiagramm, welches 20 Bildschirme füllen könnte, nach einem bestimmten Objekt suchen zu lassen. Dieser würde eine solche Darstellung zudem sehr schnell als unbrauchbar deklarieren, wenn er die für ihn interessanten Informationen nicht finden kann. Eine Lösung für dieses Problem könnte

Abbildung 3.4: Visualisierung von Netzwerkverbindungen + Datenübertragungen in Azureus



es sein, interessante Informationen zu filtern und nur diese darzustellen. Allerdings ist dies nicht unbedingt immer realisierbar.

2. GeschwindigkeitVisualisierungen benötigen oft viel Rechenleistung, um die Grafiken zu erzeugen. Aber auch das Sammeln von Daten, welche für die Visualisierung benötigt werden, kann sehr aufwändig sein. Externe Visualisierungs-Werkzeuge verlangsamen so den Ablauf eines Programms oft erheblich. Das kann zur Folge haben, dass manche Programme nicht korrekt funktionieren können, da sie eine gewisse Grundperformance benötigen, um ihre Aufgaben korrekt durchführen zu können, z.B. Multimediaprogramme, die Ton- oder Videodaten in Echtzeit verarbeiten müssen. Desweiteren können Programme, die stark von Benutzereingaben abhängen, so extrem verlangsamt werden, dass eine sinnvolle Nutzung nicht mehr gegeben ist. Bei der Visualisierung ist also immer darauf zu achten, dass die benötigte Performance des zu visualisierenden Programms nicht zu sehr eingeschränkt wird.

3. SpezialisierungDie Spezialisierung von Programmvisualisierungssystemen auf bestimmte Plattformen oder Programmiersprachen ist kein eigentliches Problem. Allerdings macht es deutlich, dass es nicht einfach, wahrscheinlich sogar unmöglich ist, generelle Visualisierungs-Werkzeuge für alle Programme zu erstellen, welche gleichzeitig sinnvolle Abstraktionen des Programms darstellen. So kann ein Visualisierungs-Werkzeug, das auf das Darstellen von objektorientierten Programmen spezialisiert ist, natürlich nicht viel mit einem rein prozeduralem Programm anfangen.

4. SpeicherplatzbedarfViele Visualisierungen basieren auf einer enormen Datenmenge, welche zum einen im Speicher gehalten werden muss und auf die zum anderen möglichst schneller Zugriff möglich sein muss. So kann z.B. bei einer Visualisierung, welche die komplette Ablaufgeschichte eines Programms speichern soll, der Speicherbedarf riesig sein. Deshalb sollte man immer darauf achten, dass nur benötigte Daten gespeichert werden und dass eventuell redundante Daten optimiert gespeichert werden.

5. ImplementierungsartEs gibt natürlich zwei verschiedene Wege, um die Abläufe innerhalb eines Programms darzustellen. Entweder das Programm liefert selbst Visualisierungen zu seinem Ablauf oder die Daten werden von einem externen Programm bezogen und dann visualisiert. Die erste Variante ist oft recht aufwändig, da sie beinhaltet, dass evtl. der komplette Quellcode verändert werden muss, um Programmvisualisierungen zu implementieren. Das externe Programm hingegen muss auf irgendeinem Wege an Daten über das Programm heran kommen. Dies kann bei Java zum Beispiel über die JPDA (Java Plattform Debugger Architektur) erfolgen.

6. Vergänglichkeit von EingabenNicht alle Programme eigenen sich zur Visualisierung. Wie schon erwähnt, verlangsamen Visualisierungen ein Programm manchmal sehr stark. Wenn dieses Programm, dann von vergänglichen Daten, wie zum Beispiel einem Live-Video-Stream abhängt, diese Daten aber nicht schnell genug verarbeiten kann, dann liefert die Visualisierung natürlich auch keine Darstellung eines korrekten Ablauf des Programms. Zudem können viele Situationen, die durch eine bestimmte Datenkonstellation erzeugt werden, nicht wieder hergestellt werden, da genau diese Daten so nicht mehr zur Verfügung stehen. Dies macht das Analysieren oder Vergleichen von Programmzuständen sehr schwierig bis unmöglich, da die entsprechenden Situationen nicht reproduziert werden können.



4. JIVE

4.1 Über JIVE

Der Name JIVE bedeutet „Java Interaktive Visualization Environment” also in Deutsch etwa „interaktive Java Visualisierungs-Umgebung” [1]. Es gibt leider sehr viele Programme, die den Namen „JIVE” tragen. Das JIVE, über welches hier gesprochen wird, wurde von Paul Gestwicki und Bharat Jayaraman an der Universität von Buffalo entwickelt. Es handelt sich dabei um ein Programmvisualisierungswerkzeug, welches objektorientierte Java-Programme visualisiert.

Objektorientierte Programme unterscheiden sich von prozeduralen Programmen in zwei wesentlichen Punkten: (1) Objekte sind nicht nur Datenstrukturen, sondern dienen auch als Umgebungen, in denen Prozeduraufrufe stattfinden. (2) Objektorientierte Programme verlangen die Nutzung von mehreren kleineren Methoden. Daraus resultieren dann kompliziertere Wechselbeziehungen zwischen den Objekten. Das Ablaufverständnis eines objektorientierten Java-Programms wird durch das zur Verfügung stellen von Darstellungen der Objektstruktur sowie der Geschichte der Objektinteraktionen verbessert. Obwohl diese Ansichten grundlegend für das Verständnis sind, gibt es laut Gestwicki und Jayaraman kein Visualisierungssystem für objektorientierte Programme, welches diese grundlegenden Kriterien realisiert. Die Visualisierungen aus JIVE sind generell anwendbar auf alle objektorientierten Sprachen nicht nur auf Java im speziellen. Allerdings gibt es bei jeder Sprache Komplikationen und kleine Nuancen, welche bewältigt werden müssen, so auch bei Java.

4.2 Anforderungen an JIVE

Gestwicki und Jayaraman haben sieben Hauptanforderungen für ein System, das Laufzeitzustände von Java visualisieren soll, aufgestellt:

1. Bildliche Darstellung von Objekten als Umgebungen. Es gibt bereits mehrere Werkzeuge, welche die Methodenaufrufsequenz bildlich darstellen können, was wiederum die Inspektion von objektinternen Details unterstützt. Allerdings stellen diese Werkzeuge weder die gesamte Struktur des Objektes, noch die Methodenaufrufe in diesen Objekten dar, und folglich fehlen wichtige Beziehungen in der Visualisierung.

2. Das zu Verfügung stellen von mehreren Ansichten der Laufzeitzustände. Der momentane Ablaufzustand des Programms sollte auf verschiedenen Detailstufen wahrnehmbar sein, um besser Vergleich durchführen zu können. Die Ansichten sollten sowohl dem Anfänger zum Verstehen und Lernen dienen, wie auch einem Profi, der die Visualisierungen zum Debuggen benutzt.

3. Festhalten der Ablaufgeschichte und Methodeninteraktion. Die Geschichte des Programmablaufs sollte wahrnehmbar sein, indem Notationen wie Zeitsequenzdiagramme oder Interaktionsdiagramme benutzt werden. Die Visualisierung der Programm-Geschichte sollte interaktiv sein, sodass der Benutzer einen Punkt der Programmgeschichte auswählen kann, den er betrachten will. Zum Beispiel sollte das Auswählen eines Methodenaufrufes in einem Sequenzdiagramm das Visualisierungs-Werkzeug veranlassen, den Laufzeitzustand, an dem die Methode aufgerufen wurde, darzustellen.

4. Unterstützen von Vorwärts- und Rückwärtsausführungen. Es sollte möglich sein, interaktiv vorwärts und rückwärts durch den Programmablauf zu schreiten. Diese Fähigkeit



ist besonders für das Debuggen wichtig, weil das Auftreten eines Fehlers normalerweise erst nach einem gewissen Punkt erkannt wird. Auch sollte die Schrittgröße variabel sein, (Statement-Ebene, Methoden-Ebene oder Breakpoints). Desweiteren sollten diese Möglichkeiten auch bei Multithread-Programmen unterstützt werden.

5. Unterstützen von Abfragen des Laufzeitzustandes. Eine der wichtigsten Anforderungen für das Programmdebuggen ist das Verständnis, wie sich die Variablenwerte ändern. Es sollte möglich sein, den Laufzeitzustand nach Eigenschaften von Variablen abzufragen (wurde Variable geändert oder hat die Variable einen bestimmten Wert angenommen?). Aus dieser Anforderung resultiert eine abfragbare Datenbank von Laufzeitzuständen.

6. Erzeugen von klaren und lesbaren Zeichnungen. Die Visualisierungsumgebung sollte automatisch Diagrammkomponenten anordnen, damit Objektstrukturen und Methodenaufrufsequenzen dargestellt werden können. Individuelle Visualisierungen von oft benutzten Typen, wie z.B. Arrays, Listen und Tabellen, sollten zur Verfügung stehen.

7. Die existierende Java Virtual Machine benutzen. Es ist wichtig, dass das Visualisierungsystem auf der existierenden Java Virtual Machine (JVM) läuft und dass keine extra Implementierung eines Java Interpreters benötigt wird. Eine angepasste JVM-Implementierung wäre sehr schwer auf dem aktuellen Stand zu halten. Zusätzlich sollte es möglich sein, Programme mit einer grafischen Benutzeroberfläche zu visualisieren, welche mit Bibliotheken wie Swing oder AWT erstellt wurden.

4.3 Lösungen in JIVE

Ein grundlegendes Problem bei Visualisierungs-werkzeugen ist die Frage, was eigentlich genau visualisiert werden soll, und vor allem, wie es einfach und verständlich dargestellt werden kann. JIVE bietet dazu verschiedene Visualisierungen, welche die verschiedenen Aspekte eines Programms darstellen sollen. Diese verschiedenen Ansichten werden in 4.3.1 besprochen. Im Punkt 4.3.2 werden die Besonderheiten von Java in Augenschein genommen, um die Kontursemantiken dieser objektorientierten Sprache visualisieren zu können.

4.3.1 Verschiedene Ansichten

Kompakte Ansichten (Compact Views)Die kompakte Ansicht wird anhand eines gegebenen rekursiv strukturierten binären Suchbaumes bildhaft erläutert. Jeder Zweig des Baumes sei selbst wieder ein Unterbaum. Abbildung 4.1 gibt eine mögliche Visualisierung eines Zustandes der Programm-ausführung. Der obere Teil des Bildschirmfotos zeigt eine Konturdiagrammvisualisierung der Objektstruktur. Dies wird „kompakte Ansicht” genannt, da nicht alle Details von jeder Kontur angezeigt werden. Die Knotenpunkte des Baumes werden als dunkel um-



Abbildung 4.1: Kompakte Ansicht und Sequenzdiagramm

randete Instanz-Konturen angezeigt. Jeder ist nach der Klasse benannt, in der er instanziiert wurde (in diesem Fall DupTree) und ein Instanzenzähler wurde hinzugefügt, um individuelle Objekte unterscheiden zu können. Es gibt eine statische Kontur für jede Klasse, die von dem Java-System geladen wurde. Eine statische Kontur ist eingebettet in die statische Kontur ihrer Superklasse, und da alle Klassen in Java Unterklassen von java.lang.object sind, sind alle statischen Konturen eingebettet in die statische Kontur von java.lang.object. Die Pfeile im Diagramm sind strukturelle Verknüpfungen, welche anzeigen sollen, dass eine Referenz von einem Objekt zum anderen besteht. Diese Verknüpfungen stellen die Verbindung zwischen den Knotenpunkten der binären Baumstruktur dar und entsprechen genau den linken und rechten Referenzvariablen des binären Suchbaumes.

SequenzdiagrammeDer untere Teil von Abbildung 4.1 zeigt das Sequenzdiagramm des visualisierten Programms. Sowohl die statischen Konturen als auch die Objekt-Konturen werden als Kontext am oberen Ende des Sequenzdiagramms angezeigt. Die Methodenaktivierungen werden als Rechtecke auf den vertikalen Lebenslinien ihres entsprechenden Kontextes angezeigt. Die main-Methode ist die ganz links dargestellte Methodenaktivierung. Die Methoden welche mit „<init>” benannt sind, kennzeichnen die Erzeugung eines neuen Kontextes durch den Aufruf des jeweiligen Konstruktors. Java benutzt dieses Symbol intern, um auf den Konstruktor zu verweisen und den Initializeraufruf zu instanziieren, deshalb wird diese Notation auch hier benutzt. Der Benutzer kann durch das Sequenzdiagramm scrollen und Kontexte oder Methodenaktivierungen auszuwählen. JIVE wird daraufhin zu dem entsprechenden Konturendiagramm springen, welches diesen Zustand repräsentiert.

Detaillierte AnsichtenEine detailierte Ansicht zeigt den kompletten Zustand eines Objekts, und beinhaltet alle Elemente und Methoden, von denen geerbt wurde. Die Element-Tabellen zeigen die definierten Variablen innerhalb des Konturenkontextes. Die Tabellen können so konfiguriert werden, dass sie auch Methodendefinitionen anzeigen. Es ist nicht generell nötig, die Element-Tabellen für jede Kontur anzuzeigen. Das Bildschirmfoto in Abbildung 4.2 zeigt, wie strukturelle Verknüpfungen zwischen Konturen dargestellt werden. Die Verknüpfung startet bei der Zelle der entsprechenden Variable und wird hin zu der referenzierten Kontur gezeichnet. Dies erlaubt strukturelle Verknüpfungen zu dem richtigen implementierten statischen Variablenbereich bei Vererbung. Methoden-Konturen repräsentieren Methoden-Aufrufe. Methoden-Konturen haben Element-Tabellen, welche die lokalen Variablen einschliesslich der Parameter der Methode beinhalten. Die Element-Tabellen von Methoden-Konturen oder Instanz- und statischen Konturen können auf Wunsch versteckt oder angezeigt werden. Methoden-Konturen sind in ihrem statischen Kontext eingebettet. JIVE zeigt den Quellcode für die aktuelle Methode an, und die

Abbildung 4.2: Detaillierte Ansicht aus einer älteren Version von JIVE (0.21)



momentan aktive Quellcodezeile wird sichtbar markiert. Es werden Markierungsfarben für jeden Thread benutzt, um den momentanen Ausführungszustand klar ablesen zu können.

Aufruf-Pfad-Ansichten und minimierte Ansichten

Wenn Konturen minimiert sind, dann werden sie als einfache Punkte dargestellt, wie in Abblidung 4.3 gezeigt. In einer Aufruf-Pfad-Ansicht werden Konturen mit Methodenaufrufen in der Kompakt-Ansicht, und die ohne Methodenaufrufe in der minimierten Ansicht angezeigt. Eine Aufruf-Pfad-Ansicht ist geeignet, um sich auf einen bestimmten Methodenaufruf oder eine ganze Reihe von Methodenaufrufen konzentrieren zu können. Die allumfassende Struktur ist immer sichtbar, aber visuell komplexe Details werden ausgeblendet. Wenn manche Details uninteressant sind für den Benutzer, dann kann er oder sie die komplette Kontur aus der Ansicht ausblenden.Es gibt Funktionen, welche alle Konturen expandieren, alle Konturen minimieren oder die Aufruf-Pfad-Ansicht anzeigen. Zusätzlich kann der Benutzer die einzelnen

Konturen auswählen und wählen, ob er sie expandieren, minimieren oder die Element-Tabelle ein- oder ausblenden möchte. Abbildung 4.3 zeigt ein Kontur-Diagramm, das komplett minimiert wurde. Die komplett minimierte Ansicht ist sinnvoll, wenn man nur die Gesamtstruktur betrachten will, ohne irgendwelche internen Details.

4.3.2 Kontursemantiken für Java

Java hat ein paar spezielle Eigenheiten, die nicht bei allen objektorientierten Sprachen zu finden sind. JIVE muss allerdings auch diese speziellen Eigenschaften korrekt behandeln, um sie korrekt darstellen zu können:

Statische KontexteIn Java gibt es die Notation von statischen Elementen, welche bei dem objektorientierten Standard-Kontur-Modell nicht vorgesehen ist. Variablen, Methoden und innere Klassen können als statisch deklariert werden, und diese statischen Elemente werden mit einer Klasse und nicht mit der Instanz einer Klasse assoziiert. Wenn nur eine statische Kontur zu einer Klasse existiert, so wird kein Instanzenzähler benötigt. Der Aufruf einer statischen Methode wird repräsentiert durch das Einsetzen einer Methoden-Kontur in die zugehörige statische Kontur.

Abbildung 4.3:Minimierte Ansicht



Innere KlassenEine innere Klasse ist eine Klasse, die im Kontext einer anderen Klasse definiert ist. Genauso werden anonyme innere Klassen verarbeitet und es wird das interne Nummerierungssystem von Java benutzt, um anonyme Klassen zu identifizieren. Nicht statische innere Klassen sind immer in genau einer umschliessenden Instanz enthalten und so wird in diesem Fall die Instanz-Kontur der inneren Klasse in die Instanz-Kontur der umschliessenden Instanz eingebettet. Nicht statische innere Klassen dürfen keine statischen Elemente definieren. Statische innere Klassen werden assoziiert mit dem statischen Klassen-Kontext und so wird die Instanz-Kontur einer statischen inneren Klasse in das Innere der statischen Kontur der umschliessenden Klasse eingebettet. Statische innere Klassen haben statische Elemente, und so hat jede statische innere Klasse eine statische Kontur. Die statischen Konturen von statischen inneren Klassen brauchen keine spezielle Behandlung und werden wie jede andere statische Kontur behandelt. In Abbildung 4.4 sieht man ein Kontur-Diagramm bei dem die Klasse „BST2” eine nicht statische innere Klasse „Node” definiert. Diese innere Klasse instanziiert wiederum rekursiv eine weitere Instanz von „BST2”.

Überschreiben und ÜberdeckenDie Element-Tabelle jeder Instanz-Kontur besitzt in dem traditionellen Kontur-Modell für objekt-orientierte Sprachen zwei interne Verknüpfungen. Eine this (oder self)-Verknüpfung, welche zu dem innersten Objekt eines Stapels von Konturen führt und einen super-Pointer, welcher auf die Kontur der Superklasse einer Kontur verweist, wenn eine existiert. Der Sinn von this ist das Überschreiben von Methoden und das Überdecken von Variablen zu zeigen. Eine this.print()-Anweisung wird immer die print()-Methode, welche in der Klassenhierachie am tiefsten verankert ist, aufrufen. Es ist nicht möglich, die Methode oder Variable zu erhalten, die von this referenziert wird. Deshalb hat JIVE eine this-Referenz in der Element-Tabelle, die immer auf die innerste Instanz-Kontur zeigt, in einer Kollektion von eingebetteten Konturen. Die detaillierte Erklärung von Überschreiben und Überdecken wird so einem Dritten überlassen.

Abbildung 4.4: Kontur-Diagramm mit nicht statischer innerer Klasse



ThreadsThreads sind ein elementarer Bestandteil von Java. Mehrere gleichzeitige Threads implizieren viele simultane Pfade von Methodenaufrufen. Das ist ganz einfach im Konturenmodell repräsentiert mit visuellen Stichwörtern bei Methoden und ihren Return-Verknüpfungen. Jeder Threadpfad, der gerade ausgeführt wird, wird in einer anderen Farbe gezeichnet. Selbst wenn die selbe Methodendefinition von verschiedenen Threads aufgerufen wird, hat jeder Thread seinen eigene Methodenkontur, da jeder Thread seinen eigenen Stack besitzt. Um die verschiedenen Threads zu markieren, werden die selben Farben benutzt, sowohl im Kontur-Diagramm als auch im Sequenz-Diagramm als auch im Quellcode. Ein von JIVE erzeugtes Sequenzdiagramm ist in Abbildung 4.5 dargestellt. Das Programm startet einfach zwei Threads und lässt sie bis zur Endbedingung laufen.

4.4 Die Architektur von JIVE

Nachdem Gestwicki und Jayaraman in vorhergehenden Projekten versucht haben, Programmvisualisierungen durch Programm-Transformation darzustellen, haben sie diese Methode zugunsten einer Zwei-Prozess-Architektur aufgegeben. Der Grund hierfür liegt darin, dass bei jeder Weiterentwicklung von Java die selbstgeschriebenen Compiler und Interpreter auch wieder umgeschrieben werden müssen. Bei der in JIVE eingesetzten Zwei-Prozess-Architektur läuft die Visualisierungsumgebung selbst als ein Prozess. Der Benutzer gibt JIVE das Programm an, welches er visualisieren möchte, und JIVE startet das Programm in einem zweiten Prozess, dem so genannten „Client Prozess”. Die Kommunikation zwischen den beiden Prozessen wird durch die Java Plattform Debugger Architektur möglich gemacht (JPDA). Um den Quellcode anzeigen und markieren zu können, muss der Quellcode des Programms geladen werden, aber JIVE kann auch Visualisierungen von kompilierten Klassen erzeugen, solange diese noch Debugger-Informationen bereit halten. JIVE unterstützt Multithread-Programme, welche für den Einprozessor-Betrieb ausgelegt sind, aber das System unterstützt momentan keine verteilten oder Multiprozessor-Programme. Wenn JIVE erst einmal den Client-Prozess gestartet hat, registriert es Event-Listeners via JPDA und wartet auf Benachrichtigungen. Wenn sich der Clientzustand ändert, wird der Client-Prozess angehalten und die Benachrichtigung des Ereignisses wird an JIVE gesendet. Wenn das Datenmodell und die verschiedenen Ansichten aktualisiert wurden, kehrt JIVE wieder zum Client-Programm zurück und wartet auf neue Ereignisse. Die Menge von Schritten, die der Client ausführt, bevor er wieder angehalten wird, ist abhängig von den Benutzereinstellungen. JIVE erlaubt verschiedene Schrittgrößen, welche einzelne Quellcodezeilen, Methodenaufrufe oder traditionelle Breakpoints im Quellcode beinhalten. Es ist auch möglich, die Eventsperre zu deaktivieren, in diesem Fall werden die Ereignisse ununterbrochen an JIVE gesendet, welches diese dann sequenziell abarbeitet.

Abbildung 4.5: Mehrere Threads in einem Sequenzdiagramm



JIVE JIVE GUI

Client Prozess

JPDAAusführungs

Protokoll

Ausführungs Datenbank

Programm Zustands

Model

Objekt Diagramm

Interaktives Interface

Anfrage Interface

Programm Geschichts

Model

Sequenz Diagramm

Abbildung 4.6: JIVE Architektur. Die Boxen repräsentieren JIVE-Module und die Pfeile repräsentieren Daten- und Kontrollfluss

Die Ablaufstruktur von JIVE ist wie folgt: Wenn das Client-Programm läuft, wird es auf Veränderungen überwacht. Die Änderungen werden in das Ausführungs-Protokoll aufgenommen, wie in Abbildung 4.6 dargestellt. Das Protokoll ist gekoppelt mit einer Datenbank, in der die Ausführungsgeschichte gespeichert wird. Ausführungs-Ereignisse, die vom Client empfangen werden, werden als einfachere Menge von Ereignissen von JIVE interpretiert. JIVE benutzt die folgenden Ereignisse: statische Kontext-Erzeugung, Objekt-Erzeugung, Methodenaufruf, Methodenreturn, ausgelöste und abgefangene Exceptions, Änderung in der Quellcodezeile, Änderung eines Variablenwertes. Jedes dieser Ereignisse ist gekapselt als ein Objekt, und jedes dieser Objekte enthält genug Informationen über das Ereignis, um entscheiden zu können, ob es sich selbst an das Ausführungs-Protokoll übergibt oder nicht. Im Wesentlichen enthält jedes Ereignis Informationen über die Änderungen, welches es an dem Ausführungszustand vornehmen wird.

Werden in JIVE ältere Ausführungszustände betrachtet, hat dies keinen Effekt für das Client-Programm, sondern nur für die aktuellen Visualisierungen. Das Client-Programm wird angehalten, während der Benutzer vergangene Zustände begutachtet, und es wird erst wieder fortgesetzt, wenn es nötig ist. Da das Modell die Möglichkeit von sich ändernden Programm-eingaben verhindert, meidet es auch das Problem der beibehaltenen Synchronisation von externen Ressourcen, wie Datenströmen oder Ein-/Ausgabe Geräten. Wenn zum Beispiel ein Programm mit einer grafischen Benutzer-oberfläche in JIVE ausgeführt wird und der Benutzer in der Ausführungsgeschichte zurück geht, wird das Interface nicht reagieren, da der Client-Prozess angehalten wurde. Da JIVE auf Einprozessor-Systeme beschränkt wurde, gibt es auch immer nur eine Instruktion, die zu einer bestimmten Zeit aufgeführt wird. Deshalb können auch Multithread-Programme ohne Probleme visualisiert werden. JIVE weiß, welches Ereignis von welchem Thread kommt. Der aktive Thread ist im Ausführungsprotokoll verzeichnet und das wird in der Visualisierung reflektiert (siehe Abbildung 4.5).

Es ist möglich, Kontur-Diagramme in Multigraphen zu konvertieren. Verschiedene Gewichte können zu den verschiedenen Typen von Verknüpfungen zugeordnet werden. Durch Experimente fanden Gestwicki und Jayaraman heraus, dass strukturelle Verknüpfungen permanenter als Methoden-Return-Verknüpfungen sind, und deshalb werden strukturelle Verknüpfungen höher gewichtet bei der Umwandlung in einen Multigraph. Der resultierende Graph wird dann unterteilt von einer modifizierten Coffman-



Graham Unterteilung [7] für Multigraphen und das Kreuzen wird minimiert [6]. Das Ergebnis ist eine unterteilte Graphenzeichnung. Eine „Inverse Transformation” wird angewandt, um aus dem Multigraph wieder das Kontur-Diagramm zu erhalten. Dies funktioniert sehr gut für einfache Strukturen, wie Bäume oder grafische Benutzeroberflächen-Kompositionen. JIVE unterstützt viele Ansichten mit vielen verschiedenen Detailstufen. Es gibt verschiedene Modelle, um Visualisierungen zu filtern. Zum Beispiel kann man einen Filter erzeugen, der alle Klassen von der Visualisierung ausnimmt, welche mit „java” beginnen.

Die Geschichtsdatenbank speichert alle bisher aufgetretenen Ereignisse im Programm. So repräsentiert sie den kompletten Ablauf des Programms seit dem Programmstart. Das bietet den Vorteil, dass man im Ablauf des Programms interaktiv vor und zurück gehen kann. Die Speicherstruktur der Geschichtsdatenbank kann aufgefasst werden als eine objekt-orientierte Datenbank von Laufzeitzustandsinformationen. In dieser Laufzeitzustandsdatenbank werden Anfragen auf die Geschichte der Laufzeitausführung durchgeführt oder auf Teile davon und die Ergebnisse sind Werte, Mengen von Zuständen oder Teile der Programmgeschichte. So können Anfrage und Ergebnis visualisiert werden. Ein Grund für das Benutzen einer Laufzeitdatenbanken ist das Verfolgen von Variablenwerten. Eine Variable wird in JIVE ausgewählt und deren Wert wird auf Änderungen überwacht. Der Benutzer spezifiziert eine Bedingung für die Variable wie: Wert wurde geändert oder Wert liegt innerhalb einer bestimmten Wertemenge. Das Ergebnis der Variablenverfolgung wird in der JIVE-Benutzeroberfläche angezeigt. Die Geschichtsdatenbank erlaubt es auch, die Ausführungsdaten in eine Datei zu schreiben. Ein Programm-Geschichts-Datei kann wieder geladen und visualisiert werden. Diese Serialisierung der Ausführungsgeschichte macht es auch möglich, verschiedene Abläufe des selben Programms zu vergleichen. Wenn viele Ausführungsgeschichten existieren, können kleine Veränderungen im Ablauf unterschiedlicher Programmversionen visualisiert werden.

4.5 Kurzer Ausblick in die Zukunft

Probleme gibt es bei JIVE vor allem noch bei der guten Darstellung von strukturierten Diagrammen. Wie kann man z.B. ein dynamisch wachsendes Sequenzdiagramm möglichst effektiv strukturieren? Auch die Struktur der Objektdiagramme kann sicher noch verbessert werden. Zudem wäre es wünschenswert, wenn man nicht nur Einzelschritte vorwärts und rückwärts gehen könnte, sondern auch von einem Zustand in einen weiter entfernten Zustand wechseln könnte, ohne dass alle dazwischen liegenden Zustände ausgeführt werden müssen. Das ist mit diesem Modell allerdings nicht möglich! Eine weitere Idee ist das Analysieren von Quellcodedateien, um Abhängigkeiten zwischen Methoden und Daten zu ermitteln und so für verschiedene Arten von Programmen die besten Ergebnisse zu liefern. Auch die Anfragen an die Geschichtsdatenbank können noch verbessert und erweitert werden. Die Daten aus der Geschichtsdatenbank könnten auch von anderen Programmen genutzt werden, um Programmanalysen durchzuführen. Zum Beispiel, wenn es um die Sicherheit geht. Wenn man ein Programm mehrmals laufen lässt, ist es vielleicht möglich, eine mathematische Beschreibung zu extrahieren, was ein „normaler” Ablauf ist. Verhält sich ein Programm dann extrem anders, kann es so als potenzielles Risiko eingestuft werden. Das Ergebnis eines solchen Vergleichs kann wiederum mit JIVE dargestellt werden.



5. JOVE

5.1 Über JOVE

JOVE wird von Steven P. Reiss und Emmanuel Manos Renieris am „Department of Computer Science” an der Brown Universität entwickelt [2]. JOVE ist ein Java Visualisierungswerkzeug, welches Darstellungen eines Java Programms auf Statement-Ebene bietet, während dieses ausgeführt wird. JOVE profitierte bei der Entwicklung von dem vorhergehenden Projekt Namens JIVE, das ein anderes Visualisierungswerkzeug für Java Programme ist (dieses JIVE ist nicht das selbe JIVE, das von Gestwicki und Jayaraman entwickelt und in Kapitel 4 beschrieben wird).

5.2 Anforderungen an JOVE

Das ältere System JIVE erfüllte bereits ein paar wesentliche Anforderungen:

• Einen minimalen Overhead, so dass das System von jedem Programm benutzt werden konnte, und das zu jeder Zeit.

• Das Maximale an gesammelten Daten darzustellen und zwar so, dass komplexe, miteinander agierende Muster erkennbar sind und somit auch das Verhalten besser zu verstehen ist.

• Eine Ausführungsgeschichte bereitzustellen, damit der Benutzer sich den Ablauf des Programms noch einmal ansehen kann oder interessante Ausführungszustände inspizieren kann.

• Die Darstellungen so anzeigen, dass verschiedene Arten von Verhalten des Programms, welche von besonderer Bedeutung sein könnten, besonders hervorgehoben werden, beispielsweise durch Farbe und Größe.

• Dem Benutzer die Möglichkeit geben, die Darstellung an seine speziellen Probleme anzupassen.

Allerdings gibt es auch ein paar Punkte, die JIVE nicht erfüllen konnte, welche aber von JOVE erfüllt werden sollen:

• Informationen darüber, wo im Quellcode sich die Ausführung gerade befindet, um feststellen zu können, in welchen Bereichen das Programm viel Zeit verbringt.

• Informationen darüber, welche Instruktionsausführungen mit welchem Thread in Verbindung stehen, so dass nachvollzogen werden kann, was ein Thread gerade macht und nicht nur, in welchem Zustand er sich befindet.

Alle diese Punkte sind Anforderungen, die JOVE erfüllen soll. Das Konzept für JOVE konzentriert sich also vor allem auf die Datensammlung über den Programmablauf, welche zudem threadspeziefisch aufgeschlüsselt wird.

5.3 Lösungen in JOVE

JOVE unterteilt die subjektive Programmausführung in Intervalle von etwa 10 Millisekunden. In jedem Intervall registriert JOVE, was das Programm in jedem seiner



Threads macht. Um dies realisieren zu können, benutzt JOVE so genannte Basisblöcke, um spätere Rechen- und Performance-Analysen durchführen zu können. Ein Basisblock ist ein Segment von reinem Zeilencode ohne interne Verzweigungen. Das bedeutet, wenn solch ein Block gestartet wird, dann werden auch alle Instruktionen des Blocks ausgeführt. Man kann jetzt zählen, wie oft einzelne Instruktionen ausgeführt werden, indem man einfach zählt, wie oft der zugehörige Block durchlaufen wurde. Aus diesen Informationen und aus den Informationen vom Debugger, welche Ausdrücken, welche Instruktionen welchen Zeilen im Code entsprechen, können dann die Basisblock-Zählungen benutzen werden, um die Häufigkeit der Ausführung bestimmter Zeilen und deren Anzahl der Maschinen-Instruktionen pro Zeile zu ermitteln. Die Messwerte, die JOVE registriert, sind Tupel der Form <I,T,B,c>, wobei I das Intervall identifiziert, T den Thread, B den Basisblock und c die Anzahl der Ausführungen des Basisblocks B durch den Thread T im Intervall I. JOVE erweitert die Basisblock Zählungen um Zählungen von Allokationen und ausgeführten Instruktionen durch eine statische Analyse der Basisblöcke. Es ordnet diese Statistiken auf verschiedene Weisen, zum Beispiel nach Datei oder nach Thread und bildet die Ergebnisse auf visuelle Elemente in einer informationsverdichteten Darstellung ab.

Abbildung 5.1: Beispiel einer JOVE-Visualisierung

Das Visualisierungsfenster von JOVE ist in mehrere vertikale Regionen unterteilt. Jede Region entspricht dabei einer Datei des zu visualisierenden Systems. Jede Dateivisualisierung ist wieder unterteilt in einen oberen Teil, in welchem die Threadinformationen dargestellt werden, und in einen unteren Teil für die Blockinformationen (siehe Abbildung 5.1). In der unteren Region ist ein horizontales Rechteck für jeden Basisblock. Diese Rechtecke sind geordnet nach der Nummer der entsprechenden Quellcodezeilen. Diese zwei Regionen der Darstellung müssen dynamisch geändert werden können entsprechend den gesammelten Daten des kompletten letzten Intervalls. Das Ergebnis ist dementsprechend eine Animation des laufenden Programms.

Der größte Teil der Visualisierung bezieht sich immer auf das letzte Intervall. Die Breite der entsprechenden Dateispalte reflektiert allerdings den kompletten Ablauf für diese Datei bis zum momentanen Intervall und entspricht dem prozentualen Anteil der Anzahl von Instruktionen, welche in dieser Datei über den gesamten Ablauf ausgeführt wurden. Der obere Teil jeder Dateidarstellung enthält ein Kreisdiagramm. Das Innere des Kreisdiagramms stellt die gesamte Ablaufzeit des momentanen Intervalls innerhalb der



Datei dar. Das Kreisdiagramm ist in Sektoren aufgeteilt. Jeder Sektor entspricht dabei der prozentual verbrachten Zeit in einem bestimmten Thread. Die Standardhintergrundfarbe für jede vertikale Region kodiert drei verschiedene Statistiken. Der Farbton stellt die Anzahl der Instruktionen, die im letzten Intervall ausgeführt wurden, über ein grün zu gelb Farbmodell da. Die Sättigung gibt die Anzahl der Ausführenden Threads im aktuellen Intervall wieder. Und die Helligkeit die Anzahl der Allokationen, die von Blöcken in dieser Datei im aktuellen Intervall gemacht wurden. Wenn kein Code in der Datei während dem Intervall ausgeführt wurde, wird der Hintergrund grau dargestellt. Die Basisblöcke einer Datei werden jeweils im unteren Teil der Dateiregion durch ein horizontales Rechteck dargestellt. Die Höhe des Rechtecks entspricht der Anzahl von Quellcodezeilen. Die Breite des Rechtecks korrespondiert zu der Anzahl von Instruktionen, die in dem Basisblock im letzten Intervall ausgeführt wurden. Die Linie ist aufgeteilt in viele farbige Regionen, bei der jede einem Thread entspricht. Die Farbgebung entspricht dabei der des Kreisdiagramms.

Abbildung 5.2: Dialogboxen um JOVE zu konfigurieren

Jeder Benutzer kann JOVE so einstellen, dass er eine geeignete Ansicht seiner Applikation bekommt. Innerhalb von JOVE kann der Benutzer Dialogboxen benutzen, welche in Abbildung 5.2 gezeigt sind, um die verschiedenen Kommandozeilenargumente einzustellen, um die Intervallgrößen zu ändern, um Klassen zu definieren, welche dynamisch geladen werden und nicht statisch auffindbar sind, aber überwacht werden sollen, und um festzulegen, welche Pakete und Klassen überwacht werden sollen und welche ignoriert werden sollen. Der Benutzer kann auch kontrollieren, welche Statistiken angezeigt werden sollen und auf welche Weise (Abbildung 5.2, rechte Dialogbox). Er kann auch zwischen totalen oder sofortigen Werten wählen für alle statistischen Eigenschaften. Desweiteren kann der Benutzer zwischen linearer, Quadratwurzel- oder logarithmischer Skalierung wählen, um die verschiedenen Aufteilungen dieser Werte mit diesen Eigenschaften zu betrachten. Zudem sind weiter Darstellungsdetails, wie z.B. Farbmodelle veränderbar.

5.4 Die Architektur von JOVE

Die Kontrollkomponente von JOVE stellt dem Benutzer ein einfaches Interface zu Verfügung. Dort kann der Benutzer definieren, welches Programm überwacht werden soll, Argumente können eingestellt oder geändert werden, die sich auf den Java-Interpreter



oder den Benutzercode beziehen. Zudem ist es möglich, einzustellen, welche Klassen oder Pakete überwacht und welche ignoriert werden sollen.

Die Aufbaukomponente ist ein unabhängiger Prozess, welche alle Klassen, die überwacht werden sollen, identifiziert und welche diesen Klassendateien den benötigten Code für die Überwachung hinzufügt. Dieser „Patcher” benutzt das IBM JikesBT byte code Toolkit [5]. Diese Komponente produziert zwei Ausgaben. Die erste ist eine jar-Datei, welche die modifizierten Klassen beinhaltet. Dieses wird benutzt, um die originalen Klassendateien zu ersetzen, wenn das Programm abläuft. Die zweite Ausgabe ist eine Beschreibungsdatei, welche Informationen über jeden Basisblock auflistet: zu welcher Methode und Klasse der Block gehört, die entsprechende Quellcodezeile, die Anzahl der Instruktionen und Allokationen in diesem Block und die Typen der Objekte, die von den Allokationen erzeugt werden. Die zweite Datei wird vom Visualisierer benutzt, die Zähldaten der Basisblöcke in aussagekräftigere Informationen für den Benutzer umzuwandeln.

Die Information-Sammlungs-Komponente ist eine kleine Bibliothek, die mit dem Benutzerprogramm geladen wird. Die Bibliothek wird zu Beginn von dem veränderten Code aufgerufen. Sie ist zuständig für die Zählungen und das dynamische zur Verfügung stellen der passenden Daten für den Visualisierer. Der Schlüssel zu einem erfolgreichen dynamischen Echt-Zeit-Visualisierungssystem ist Sammeln der angemessenen Verfolgungsdaten mit einem minimalen Overhead. Für JOVE bedeutet das zu zählen, wie oft jeder Basisblock in jedem Thread in einem Intervall ausgeführt wurde. Es ist kein Nachteil, Informationen auf Basisblockebene statt auf Methodenebene zu sammeln. Auf Methodenebene muss nicht nur jeder Methodeneintritt und -austritt verändert werden, sondern es müssen auch Allokationen oder unnormale Austritte durch Exceptions beachten werden. Diese Erfordernisse müssen auf der Basisblockebeneverfolgung nicht berücksichtigt werden, da Informationen über Allokationen in den Basisblock Informationen enthalten sind, da davon ausgegangen werden kann, dass in fast allen Fällen feststeht, welche Objekte alloziert werden, wenn ein Block ausgeführt wird. Zweitens, falls ein Block einen Exception-Handler repräsentiert, kann diese Exception über die Ausgabesequenz festgestellt werden. Ein Problem ist, wie man an Basisblock-informationen kommt, in denen die Zählungen mit den aktuellen Thread assoziiert werden. Die Lösung des Problems ist das Hinzufügen eines zusätzlichen Parameters zu jeder Routine, welcher den aktuellen Kontext beinhaltet, welcher wiederum den aktuellen Thread und die Zählinformationen für diesen Thread beinhaltet. Reiss und Renieris realisierten dies durch das Erzeugen einer Schatten-Routine für jede Routine, die überwacht werden soll. Der Name der Original-Routine wird geändert, der Kontext-Parameter hinzugefügt genauso wie der Code, welcher die entsprechende Methode für den Basisblockeintritt aufruft. Dann wird eine neue Routine mit dem Original-Namen und Parametern erzeugt. Die neue Routine errechnet den Kontext (indem sie den aktuellen Thread findet und dann den Kontext bei diesem nachsieht) und ruft danach die modifizierte Original-Routine auf. Alle Aufrufe von Routinen des veränderten Codes werden dann noch so verändert, dass die korrespondierenden umbenannten Routinen aufgerufen werden. Diese Lösung bedeutet, dass beinahe alle Aufrufe, die im modifizierten Code gemacht werden, die modifizierten Original-Routinen benutzen und nicht einen neuen Kontext berechnen müssen. Außerdem können korrekte Aufrufe von unmodifiziertem Code und Routinen, welche Interfaces oder abstrakte Methoden implementieren behandelt werden. Um Blöcke in einem Thread effizient zählen zu können, braucht man den Kontext von jedem Thread vorallokierte Zählpuffer für Zählungen jedes enthalten Basisblocks in der überwachten Quelle. Der Code beim Basisblockeintritt



inkrementiert einfach den entsprechenden Zähler für den aktuellen Kontext. Ein Kontexttriple puffert diese Zählungen. Der erste Puffer enthält die aktuellen Zählungen. Ein zweiter Puffer wird benutzt, um die Daten zu halten, welche momentan verarbeitet werden, um an das Visualisierungs-Front-End gesendet zu werden. Ein dritter Puffer, welcher das vorhergehende Intervall repräsentiert, ist verfügbar, um Vergleiche mit dem zweiten durchführen zu können. Die aktuelle Sammlung und das Melden der Daten zu dem Visualisierungs-Front-End wird durch einen seperaten Thread erledigt, welcher einen Timer ablaufen lässt, der wiederum die Intervalle errechnet. Dieser Thread behandelt auch das Puffer-Swapping, produziert eine XML-Nachricht, welche die nicht Null Zählungen zusammen fasst und sendet diese Nachricht über ein Socket zum Visualisierer.

Die Visualisierungskomponente stellt zwei Ansichten zur Verfügung. Eine ist eine Mitschrift der Ein- und Ausgaben des Programms. Die zweite ist die Hauptansicht der gesammelten Informationen wie in 5.3 beschrieben. Diese Komponente ist zuständig für das Speichern und Zugreifen auf die dynamischen Informationen, für das Erzeugen von angemessenen Ansichten, die auf den Benutzereinstellungen basieren, für das dynamische Aktualisieren dieser Ansicht, während das Programm abläuft, und für das Bereitstellen eines zeitbasierten Zugriffs auf die Daten. Informationssammlungen ergeben Basisblock Zählungen für jedes Intervall für jeden Thread oder Kontext. Für die Darstellung werden diese Informationen nach dem Kontext und global für jede Quelldatei gesammelt. Wie werden die Informationen jetzt effizient dargestellt? Wie schon erwähnt gibt es 3 Basistypen an Informationen, welche dargestellt werden können:

1. Informationen über die individuellen Basisblöcke und daraus resultierende Quellzeilen:! - Anzahl der Ausführungen!! ! ! ! für jeden individuellen Thread! - Anzahl der gemachten Allokationen !! ! für jeden individuellen Thread! - Anzahl der ausgeführten ByteCodes! ! für jeden individuellen Thread! - Anzahl der Ausführungen!! ! ! ! für alle Threads zusammen! - Anzahl der gemachten Allokationen !! ! für alle Threads zusammen! - Anzahl der ausgeführten ByteCodes! ! für alle Threads zusammen

2. Informationen über Dateien: ! - totale Zählungen der verschiedenen Statistiken von allen Blöcken! ! ! ! ! ! ! ! ! ! für jeden individuellen Thread! - totale Zählungen der verschiedenen Statistiken von allen Blöcken! ! ! ! ! ! ! ! ! ! für alle Threads zusammen

3. verschiedene Statistiken geordnet nach Threads

Alle drei Informationstypen sollen in der selben Ansicht dargestellt werden. Dabei muss sichergestellt sein, dass so viele Daten wie möglich dargestellt werden, und dass interessante Werte, besondere mögliche Performanceprobleme, Threadkonflikte und interessante Veränderungen im Verhalten hervorstechen. Wie in Kapitel 5.3 beschrieben ist die Ansicht in vertikalen Dateiregionen organisiert, bei der jede ein Kreisdiagramm für Kontexte beinhaltet, und eine Ansicht der Basisblöcke. Globale Dateiinformationen werden durch die Datei-Regionsgröße, Hintergrundfarbe, und den Bereich zwischen dunklem und hellen Hintergrund reflektiert. Die Rolle der Kontexte in der Datei innerhalb eines Intervalls wird durch das Kreisdiagramm wiedergespiegelt. Rechtecke in der Basisblockregion reflektieren den Kontext, Allokationen und die Anzahl der Instruktionen, welche während dem Intervall ausgeführt wurden. Das Entscheidende bei der JOVE-Darstellung ist die Möglichkeit, viele Dimensionen der Daten auf einem sinnvollen Weg darzustellen. Die



normale Dateiansicht zeigt fünf verschiedene Statistiken und benutzt dabei die Breite, den Farbton, die Sättigung, die Helligkeit und die Position von den Unterteilungslinien. Das Kreisdiagramm zeigt die verschiedenen Kontexte durch Farben und kann durch die Kreisabschnittsgröße verschiedene Statistiken über den Kontext reflektieren (z.B. Allokationen und Instruktionen). Die Basisblöcke können bis zu fünf Statistiken enthalten mit ihrer Breite, Höhe, Farbton, Sättigung und Helligkeit.

Da die Ansicht eine Menge an Informationen zu Verfügung stellt, muss der Programmierer sie mit dem Ursprungsprogramm in Verbindung setzen können. Anstatt den Daten Bezeichnungen zu geben (wo der Text oft zu klein zum Lesen wäre), werden Tooltips benutzt welche dem Benutzer detaillierte Informationen zur Verfügung zu stellen. Abblidung 5.3 zeigt einen solchen Tooltip, welcher angezeigt wird, wenn man die Maus über einer Fläche der Visualisierung platziert.

Datenstruktur

Bei einem lange laufenden Programm kann eine große Anzahl von Intervallen existieren, wobei jedes signifikante Daten enthält. Zum Beispiel in einem relativ einfachen Spiel existieren etwa 3000 Basisblöcke, die verfolgt werden müssen für jedes Intervall und für jeden der vierzehn aktiven Threads. Des weiteren wird die Möglichkeit des Zugriffs auf die zusammenfassenden Zähler für Dateien und Threads benötigt. Dies ist nicht einfach, da unterschiedliche Statistiken separat gesammelt werden müssen (Allokationen, Instruktionen und Blockzählungen), da diese nicht von den rohen Zählimpulsen direkt

abgeleitet werden können, wie es für die Basis-blöcke gemacht werden kann. Um diese Daten zu speichern, haben Reiss und Renieris einen Vektor von Intervallen kreiert. Jedes Intervall wird repräsentiert durch zwei Hash-Tabellen, eine für die lokalen Daten des Intervalls und eine für die totalen Daten bis und einschliesslich diesem Intervall. Jede Hash-Tabelle ist indiziert durch den Block oder Datei, wo der assoziierte Wert ein andere Hash-Tabelle ist. Für jedes individuelle Objekt, bildet diese zweite Hash-Tabelle den Kontext (Thread) auf einen Block von Statistischen Werten, welche die verschiedenen

Zählungen repräsentieren. Ein spezieller Kontextwert wird benutzt, um den globalen Kontext zu repräsentieren. Dies alles ist in Abbildung 5.4 dargestellt. Alle Zählungen des Informationssammlers auf Blockebene werden zuerst in die lokalen Tabellen eingetragen. Jede Zählung ungleich Null generiert einen Statistikeintrag für den entsprechenden Block und Thread (auf beiden Ebenen der Hash-Tabelle). Die Totalzählung für alle Threads wird als separate Statistik berechnet von den lokalen Totalen. Genauso wird jede Blockzählung in die entsprechenden Einträge für die Datei eingetragen, welche in der ersten Hash-Tabelle indiziert wurde. Zuletzt werden die Totalen von jedem Eintrag berechnet. Das Ergebnis ist eine komplettes Set von Statistiken ungleich Null für jedes Intervall. Dieses kann schnell indiziert werden, nach Block, Datei oder Thread. Für jeden Eintrag in den vorhergehenden Totalen die keinen entsprechenden lokalen Eintrag haben, wird einfach auf den vorhergehenden Block verwiesen. Andernfalls wird ein neuer Eintrag erzeugt

Abbildung 5.3: Tooltip in JOVE

Lokal

Block 1Block 2Block nDatei 1Datei 2

Total

Global

Block 1Block 2Block nDatei 1Datei 2

Total

Block i

Thread 1Thread 2

Total

Block i

Thread 1Thread 2

TotalStatistiken

<#Blöcke>

<#Instanzen>

<#Allokationen>

Statistiken

<#Blöcke>

<#Instanzen>

<#Allokationen>

Intervalle:

Abbildung 5.4: Datenstruktur um die Zähler-Informationen zu speichern



welcher die Summe von jedem vorhergehenden totalen Eintrag und die neuen lokalen Werte beinhaltet. Durch diese Methoden entsteht ein speichereffizienter Lagermechanismus, welcher zügigen Zugriff auf alle verfügbaren Statistiken bietet und die Tatsache in Betracht zieht, dass die meisten Zählungen Null ergeben.

5.5 Kurzer Ausblick in die Zukunft

Mit JOVE braucht ein Programm etwa drei bis viermal so viel Zeit wie normal. Eigentlich ist diese Verlangsamung akzeptabel, aber es kann vielleicht noch optimiert werden. Ein weiterer Punkt ist das Erheben von noch mehr Daten eines Programmdurchlaufs, was dann aber natürlich eine weitere Verlangsamung mit sich bringt. Oder das Beobachten des Speichers. In Java ist es relativ einfach, Allokationen zu registrieren, aber Deallokationen, die letztlich vom Garbage Collector durchgeführt werden, sind viel schwieriger. Und noch ein interessanter Punkt ist das Assoziieren des Programmverhaltens mit Ereignissen wie Eingaben oder generierten Ereignissen. So könnte man bestimmen, welche Prozesse ausgeführt werden bei einer bestimmten Eingabe.

6. Zusammenfassung und eigene Meinung

Die beiden vorgestellten Programme „JIVE” und „JOVE” sind also Javaprogramm-visualisierungswerkzeuge, welche ein paar der vorgestellten Ideen aus Abschnitt 3 umsetzen (Quellcode, Objektstrukturen, Instanzen, ...). Die Anforderungen, die an das jeweilige Projekt gestellt wurden, sind im Wesentlichen erfüllt worden. JIVE eignet sich, um in der Lehre die Struktur und Funktionsweise von objektorientierten Sprachen zu vermitteln. Es ist auch durchaus als visueller Debugger einsetzbar. JOVE erreicht auch sein Ziel, langsamen Quellcode zu identifizieren. Allerdings sind beide Werkzeuge nur für kleine, nicht so komplexe Programme geeignet, da schnell die Skalierbarkeit der Darstellung sowie der Datenerhebung und Datenverarbeitung erreicht ist und das jeweilige Programm so nicht mehr benutzbar wird. Ein weiteres Manko von Seiten der Entwickler ist, dass beide Programme im Moment nicht in der aktuellen Version im Netz verfügbar sind.



7. Literaturangaben

[1] ! Paul Gestwicki, Bharat Jayaraman! „Methodology and Architecture of JIVE”! ACM symposium on Software visualization (2005)

[2]! Steven P. Reiss, Emmanuel Manos Renieris! „JOVE: Java as it Happens”! ACM symposium on Software visualization (2005)

[3]! Katharina Mehner! „JaVis: A UML-Based Visualization and Debugging Environment for Concurrent Java! Programs” (2001)

[4]! Wim De Pauw, Erik Jensen, Nick Mitchell, Gary Sevitsky, John Vlissides, Jeaha Yang! „Visualizing the Execution of Java Programs” (2001)

[5]! Chris Laffra, Doug Lorch, Dave Streeter, FrankTip, John Field! „What is Jikes Bytecode Toolkit” http://www.alphaworks.ibm.com/tech/jikesbt (2000)

[6]! P. Eades, G. Di Battista, R. Tamassia, and I. G. Tollis.! „Graph Drawing: Algorithms for !the Visualisation of Graphs” (1999)

[7]! E. G. Coffman, Jr. und R. L. Graham! „Optimal scheduling for two-processor systems.” Acta Informatica (1972)

[8]! Blaine Price, Ronald Baecker, Ian Small! „An Introduction to Software Visualization”! Software Visualization – Programming as a Multimedia Experience (1998)

[9]! Azureus - Java BitTorrent Client! http://azureus.sourceforge.net

Hilfreiche Seiten waren außerdem:http://www.software-kompetenz.dehttp://www.wikipedia.de



V isualisierung von Java-Programmenhomepage.lnu.se/staff/akemsi/courses/seminar/ss05/papers/...von V...

Documents

Transcript of V isualisierung von Java-Programmenhomepage.lnu.se/staff/akemsi/courses/seminar/ss05/papers/...von V...