Visualisierungen für Programmcode

Inhaltsverzeichnis

1 Einleitung
1.1 Zweck des Dokuments
1.2 Leserkreis

2 Aufgabenstellung
2.1 Ziel der Diplomarbeit

3 Verwandte Arbeiten
3.1 Taxonomien
3.2 Abgrenzung

4 Lösungsweg
4.1 Abgrenzung des Betrachtungsraumes
4.1.1 Definition von Visualisierung für Programmcode
4.1.2 Dynamische Visualisierungen zur Darstellung von Laufzeitverhalten
4.2 Schema zur Erfassung existierender Visualisierungen
4.3 Beschreibungsschema
4.4 Bewertungsschema
4.5 Katalogisierung
4.6 Resultate der Katalogisierung

5 Beschreibungsschema
5.1 Struktur
5.2 Klassifizierung
5.3 Ebene 1 - Kategorien von Eigenschaften
5.4 Ebene 2 - Eigenschaften
5.4.1 Darstellung
5.4.2 Interaktion
5.4.3 Anbindung
5.5 Anwendung des Beschreibungsschemas
5.5.1 Anwendung zur Beschreibung einer Visualisierung
5.5.2 Anwendung zur Suche einer Visualisierung
5.6 Erweiterbarkeit des Beschreibungsschemas
5.6.1 Erweiterung um eine Eigenschaft
5.6.2 Erweiterung um eine Kategorie
5.6.3 Erweiterung um einen Eigenschaftstyp
5.6.4 Erweiterung um eine Klasse

6 Bewertungsschema
6.1 Zielorientierung
6.2 Komponenten von Programmcode
6.3 Darstellungsebene
6.4 Zuordnung von Komponenten zu Tätigkeiten
6.5 Bewertung einer Visualisierung
6.5.1 Bewertungskriterien
6.5.2 Bewertungsskala

7 Katalogisierung
7.1 Tätigkeitsanalyse
7.1.1 Kategorien von Tätigkeiten eines Programmierers
7.1.2 Feindesign erstellen
7.1.3 Programmieren
7.1.4 Fehler suchen
7.1.5 Dokumentation
7.1.6 Unit Test
7.1.7 Kommentieren
7.1.8 Code Review
7.2 Analyse existierender Visualisierungen
7.3 Basisvisualisierungen
7.4 Omondo UML Klassendiagramm
7.4.1 Beschreibung
7.4.2 Bewertung
7.5 SeeSoft Conditional nesting complexity
7.5.1 Beschreibung
7.5.2 Bewertung
7.6 G SEE Inheritance Relationship
7.6.1 Beschreibung
7.6.2 Bewertung
7.7 Creole Nested View
7.7.1 Beschreibung
7.7.2 Bewertung
7.8 sv3D
7.8.1 Beschreibung
7.8.2 Bewertung
7.9 IMSOVision
7.9.1 Beschreibung
7.9.2 Bewertung
7.10 Alternative zur Visualisierung - Metrics
7.10.1 Beschreibung
7.10.2 Bewertung
7.11 Zuordnung von Visualisierungen zu Tätigkeiten
7.11.1 Zuordnung von Visualisierungen zur Tätigkeit ,,Dokumentation ei- ner Klasse erstellen“
7.11.2 Zuordnung von Visualisierungen zur Tätigkeit ,,Erstellung von Test- fällen für komplexe Methoden“
7.11.3 Zuordnung von Visualisierungen zur Tätigkeit ,,Einsetzen externer Bibliotheken“
7.11.4 Zuordnung von Visualisierungen zur Tätigkeit ,,Vervollständigen der Kommentierung von Klassen“

8 Resultate der Katalogisierung
8.1 Analyse der katalogisierten Visualisierungen
8.2 Werkzeugkasten
8.3 Entwurf der Visualisierung SimplyView
8.3.1 Dargestellte Informationen
8.3.2 Aussagen über das analysierte Projekt

9 Fazit
9.1 Rückblick
9.2 Inhaltliches Fazit
9.3 Zukünftige Arbeiten

Abbildungsverzeichnis

3.1 Beispiel für einen generierten Flowchart, entnommen aus dem Artikel von Haibt (1959)
3.2 Grafische Darstellung der Taxonomie von Brad A. Myers (1990)
3.3 Anwendung der Charakterisierung von John T. Stasko auf ausgewählte Untergruppen von Programm-Visualisierungen, entnommen aus Stasko and Patterson (1993)
3.4 Überblick über die Taxonomie von Price et al. (1992)
3.5 Detail-Ansicht der Kategorie ”Form“

5.1 Grafische Darstellung der Struktur des Beschreibungsschemas
5.2 Grafische Darstellung der Klassifizierung
5.3 Grafische Darstellung der Eigenschaften der Kategorie Darstellung
5.4 Grafische Darstellung der Eigenschaften der Kategorie Interaktion
5.5 Grafische Darstellung der Eigenschaften der Kategorie Anbindung

7.1 Beispiel eines Omondo UML Klassendiagramms
7.2 Ansicht der SeeSoft Conditional nesting complexity Visualisierung
7.3 Ansicht der G SEE Inheritance Relationship Visualisierung
7.4 Beispiel der Creole Nested View Visualisierung
7.5 Abbildung von Relationen in der Creole Nested View Visualisierung
7.6 Beispiel der sv3D Visualisierung
7.7 Beispiel IMSOVision Visualisierung
7.8 Metrics in der Anwendung auf ein Java-Projekt mit ungefähr 14 000 Pro- grammzeilen

8.1 Anwendung der Visualisierung SimplyView auf den eigenen Programmcode (3087 Zeilen Programmcode)
8.2 SimplyView-Darstellung ohne Filter
8.3 SimplyView-Darstellung mit Filter

Tabellenverzeichnis

5.1 Klassifizierung - Benennung der Klassen
5.2 Kategorien des Beschreibungsschemas
5.3 Typen von Eigenschaften
5.4 “Null“-Werte
5.5 Beispielwerte der Eigenschaft Visualisierungstyp
5.6 Werte der Eigenschaft Farbe
5.7 Werte der Eigenschaft Echtzeit
5.8 Werte der Eigenschaft Visualisierungssystem
5.9 Werte der Eigenschaft Informationsquelle
5.10 Werte der Eigenschaft Einbindung
5.11 Werte der Eigenschaft Auswirkungen auf Ausführung

6.1 Komponenten von Programmcode
6.2 Darstellungsebenen des Bewertungsschemas
6.3 Arten der Zuordnung von Komponenten zu Tätigkeiten
6.4 Werte der Bewertungsskala der allgemeinen Bewertung von Visualisierungen

7.1 Kategorien von Tätigkeiten eines Programmierers
7.2 Beschreibung der Visualisierung Omondo UML Klassendiagramm
7.3 Komponenten der Visualisierung Omondo UML Klassendiagramm
7.4 Allgemeine Bewertung der Visualisierung Omondo UML Klassendiagramm
7.5 Beschreibung der Visualisierung SeeSoft Conditional nesting complexity .
7.6 Komponenten der Visualisierung SeeSoft Conditional nesting complexity
7.7 Allgemeine Bewertung der Visualisierung SeeSoft Conditional nesting com- plexity
7.8 Durch die Visualisierung SeeSoft Conditional nesting complexity unter- stützte Tätigkeiten
7.9 Beschreibung der Visualisierung G SEE Inheritance Relationship
7.10 Komponenten der Visualisierung G SEE Inheritance Relationship
7.11 Komponenten der Visualisierung G SEE Inheritance Relationship
7.12 Beschreibung der Visualisierung Creole Nested View
7.13 Komponenten der Visualisierung Creole Nested View
7.14 Allgemeine Bewertung der Visualisierung Creole Nested View
7.15 Beschreibung der Visualisierung sv3D
7.16 Komponenten der Visualisierung sv3D
7.17 Allgemeine Bewertung der Visualisierung sv3D
7.18 Beschreibung der Visualisierung IMSOVision
7.19 Komponenten der Visualisierung IMSOVision
7.20 Allgemeine Bewertung der Visualisierung IMSOVision
7.21 Allgemeine Bewertung von Metrics
7.22 Durch Metrics dargestellte Komponenten von Programmcode
7.23 Allgemeine Bewertung von Metrics
7.24 Ergebnisliste zur Tätigkeit Dokumentation einer Klasse erstellen“
7.25 Ergebnisliste zur Tätigkeit ” stellung von Testfällen für komplexe Metho- Er den“
7.26 Ergebnisliste zur Tätigkeit ”Einsetzen externer Bibliotheken“

8.1 “Werkzeugkasten“ der Visualisierungen für Programmcode
8.2 SimplyView: In der Darstellung einer Klasse abgebildete Informationen .
8.3 SimplyView: Bestandteile der Formel zur Berechnung der Breite der Klassen
8.4 SimplyView: Bestandteile der Formel zur Berechnung der Stärke der Rela- tionen

1 Einleitung

Visualisierungen bilden ein wichtiges Hilfsmittel bei der Erstellung und Wartung von Software. Das Lesen und Verstehen von Programmcode, das Konzipieren und Designen von Software-Systemen sowie die Überwachung zur Laufzeit - all diese Aktivitäten, und noch zahlreiche mehr, können durch Visualisierungen erleichtert werden. Hierbei helfen besonders folgende Haupteigenschaften von Visualisierungen:

- Grafische Darstellung der Informationen,
- Abstraktion der gebotenen Informationen,
- Schwerpunktlegung auf die Darstellung der benötigten Informationen.

Diese Eigenschaften von Visualisierungen werden von anderen Berufszweigen wie den Ma- schinenbauern, den Chemikern, den Physikern und den Medizinern, seit langem genutzt. Hierbei finden durch Software generierte Visualisierungen großen Einsatz.

In der Softwareentwicklung selber werden jedoch, wie im Buch Software Visualization“ von Diehl (2007) beschrieben, bisher nur im geringen Maß Visu ”sierungen eingesetzt.

Während für die Planung und das Design von Software-Systemen ausgefeilte Vi- sualisierungen zur Verfügung stehen (siehe beispielsweise Borland (2008)) erfolgt die eigentliche Umsetzung des Programms - die Entwicklung, der Test und die Wartung des Programmcodes - im großen Maß ohne Visualisierung direkt durch Lesen, Schreiben und Editieren von Programmcode.

Ein gewichtiger Grund hierfür ist die fehlende Übersicht über existierende Visuali- sierungen für Programmcode und ihre Einsatzmöglichkeiten. In den oben genannten Berufszweigen und der Planung und dem Design von Software-Systemen haben sich über die Zeit Standards in Spezifikationen und Applikationen herausgebildet, wie beispielsweise UML (spezifiziert von der Object Management Group (2007)). Diese Standardisierung fand im Bezug auf Visualisierungen für Programmcode bisher noch nicht statt - mit dem Effekt, dass zwar zahlreiche Visualisierungen existieren, diese jedoch kaum genutzt werden.

Ziel dieser Diplomarbeit ist die Analyse der Anwendbarkeit von Visualisierungen zur Un- terstützung von Tätigkeiten im Zusammenhang mit der Arbeit an Programmcode.

Hierzu werden Schemata entworfen, welche die Beschreibung und Bewertung von Vi- sualisierungen von Programmcode ermöglichen. Diese Schemata werden verwendet, um bestehende Visualisierungen zu katalogisieren.

Zusätzlich erfolgt eine Analyse ausgewählter Tätigkeiten. Anhand dieser Tätigkeiten wird die Auswahl unterstützender Visualisierungen auf dem durch das Bewertungsschema beschriebenen Weg demonstriert.

Die durch die Katalogisierung gewonnenen Informationen werden analysiert und füh- ren zu einer Übersicht über die Anwendbarkeit der existierenden Visualisierungen für Programmcode. Auf Basis dieser Übersicht erfolgt der Entwurf einer Visualisierung für Programmcode, welche die existierenden Visualisierungen sinnvoll ergänzt.

1.1 Zweck des Dokuments

Dieses Dokument beschreibt den Ablauf und die Ergebnisse der Diplomarbeit Visualisie- rungen für Programmcode“. Es enthält eine ausführliche Beschreibung der g” onnenen Resultate sowie Anleitungen, wie diese Resultate anzuwenden sind. Zudem enthält es einen Rückblick über den Ablauf der Diplomarbeit.

Abgeschlossen wird das Dokument durch eine Analyse der möglichen Fortführungen des betrachteten Themas.

Dieses Dokument bildet zudem die Grundlage für die Bewertung der Diplomarbeit.

1.2 Leserkreis

Diese Dokument richtet sich an folgende Personen:

- den Bearbeiter der Diplomarbeit,
- den Betreuer der Diplomarbeit,
- den Prüfer der Diplomarbeit,
- Personen, welche an Visualisierungen für Programmcode interessiert sind.

2 Aufgabenstellung

An einem Projekt zur Entwicklung eines Software-Systems arbeiten generell mehrere Per- sonen in verschiedenen Rollen, wie beispielsweise Entwickler, Tester und Wartungsinge- nieure. Hierbei ist es unvermeidlich, dass fremder Programmcode verstanden werden muss. Selbst wenn dieser Programmcode ausführlich kommentiert ist und gute Dokumentation existiert, ist es in komplexen Systemen ausgesprochen schwer, diesen Programmcode in seiner Bedeutung, seinen Zusammenhängen und seinen Seiteneffekten zu verstehen. In der Realität sind die Bedingungen meist noch deutlich schlechter, da oft mißverständlich oder gar nicht kommentiert wird und Dokumentation - wenn sie überhaupt vorhanden ist - meist stark veraltet ist.

Eine Schwierigkeit für das menschliche Gehirn bei der Wahrnehmung der Bedeutung eines vorliegenden Programmcodes liegt dabei in der textuellen Darstellung. Während ein Compiler ein Programm Zeile für Zeile liest, benötigt das menschliche Gehirn Analogien zur realen Welt“ in Form von Metaphern und grafischen Darstellungen.

Wie Diehl (2007) in seinem Buch Software Visualization“ beschreibt ist die Verwen- dung von Metaphern in der Softwar ” twicklung stark ausgeprägt. A utomaten sortieren die Blätter von Bäumen, die daraus resultierenden Daten werden in Dateien (zusam- mengesetzt aus Da ten und Kar tei) gespeichert, welche in Or dnern gespeichert werden.

Allein dieser eine Satz aus der Informatik enthält fünf aus der realen Welt“ entliehene Metaphern und zeigt, wie stark sich der Wortschatz der Inform ” k an den Objekten des Alltags orientiert.

Die Verwendung von grafischen Darstellungen jedoch ist in der Softwareentwicklung noch kaum vorangeschritten. Es existieren zahlreiche Implementierungen von Visualisie- rungen, und mit UML wurde eine allgemein akzeptierte Spezifikation zur visuellen Be- schreibung eines Software-Systems entwickelt. UML wird jedoch meist zur Darstellung des Programmcodes in externen Dokumenten verwendet, und die meisten Implementierungen von Visualisierungen für Programmcode kommen aufgrund mangelnder Bekanntheit kaum zum Einsatz.

2.1 Ziel der Diplomarbeit

Ziel dieser Diplomarbeit ist es nun, Visualisierungen für Programmcode greifbar zu ma- chen. Zum Erreichen dieses Ziels werden die folgenden Fragen beantwortet:

- Was ist eine Visualisierung für Programmcode?
- Welche Arten von Visualisierungen für Programmcode existieren?
- Welche Qualität, welchen Nutzen und welche Mängel haben die existierenden Vi- sualisierungen für Programmcode?
- Wie können Visualisierungen für Programmcode formal erfasst und damit vergleich- bar gemacht werden?
- Welche Tätigkeiten können durch Visualisierungen für Programmcode unterstützt werden? Wie kann eine Zuordnung von Visualisierungen zu Tätigkeiten erfolgen, ohne explizit eine Verbindung zwischen jeder zu einer Tätigkeit passenden Visuali- sierung erstellen zu müssen?
- Welche Visualisierungen bilden einen optimalen ” Werkzeugkasten“ für eine mit Pro- grammcode arbeitende Person? Gibt es Unterschiede in den optimalen Visualisie- rungen für unterschiedliche Rollen wie Entwickler, Tester oder Wartungsingenieur?
- Welche Schwachstellen haben die existierenden Visualisierungen für Programmcode? Wie sieht eine Visualisierung für Programmcode aus, welche den ” Werkzeugkasten“ neben den existierenden Visualisierungen ergänzt?

Eine Übersicht über den in diesem Bericht gegangenen Weg zur Beantwortung dieser Fra- gen ist in Kapitel 4 gegeben. Eine ausführliche Beschreibung erfolgt in den darauffolgenden Kapiteln.

3 Verwandte Arbeiten

Visualisierungen wurden bereits in den Anfängen der Softwareentwicklung zur Unter- stützung der Programmierer herangezogen. Bereits von Neumann und Goldstine (1947) beschrieben Flowcharts, ein Verfahren zur grafischen Darstellung der Abläufe innerhalb eines Programms (siehe Abbildung 3.1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Beispiel für einen generierten Flowchart, entnommen aus dem Artikel von Haibt (1959)

3.1 Taxonomien

Mit den Jahren nahm die Zahl an Visualisierungen für Programmcode stark zu. Zur Ver- waltung dieser Menge von Visualisierungen entwickelte Myers (1990) eine Taxonomie zur eindeutigen Einordnung von Programm-Visualisierungen“, wie sie von ihm genannt wer- den. Myers unterscheidet Pr ” ramm-Visualisierungen dabei nach statischen und dynami- schen Visualisierungen und ordnet sie einer Kategorie - Data“, - zu (siehe Abbildung 3.2). ” Code“ oder ” Algorithm“ ” Myers ermöglicht mit seiner Taxonomie eine grobe Einordnung von Programm- Visualisierungen in eine von sechs Klassen. Diese Einordnung erfolgt rein auf objektiven Eigenschaften der Visualisierungen, eine qualitative Bewertung der Visualisierung erfolgt nicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Grafische Darstellung der Taxonomie von Brad A. Myers (1990)

Basierend auf der Taxonomie von Myers entwickelten Stasko and Patterson (1993) ein System zur Beurteilung von Programm-Visualisierungen nach den vier Kriterien aspect“, ” abstractness“, ” animation“ und ” automation“. Hierbei verfolgen sie jedoch - im Gegen- ” satz zu Myers - nicht das Ziel einer eindeutigen Zuordnung von Visualisierungen zu Klassen. Vielmehr geht es um eine Charakterisierung der Untergruppen von Programm- Visualisierungen wie beispielsweise der Visualisierungen zur Darstellung von Programm- zuständen oder Visualisierungen von Algorithmen. Dementsprechend grob fällt auch die Wertebelegung der Kriterien aus - zur Verfügung stehen low“, ” medium“ und ” high“. ”

Die Anwendung der Charakterisierung von Stasko auf ausgewählte Untergruppen ist in

Abbildung 3.3 zu sehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3: Anwendung der Charakterisierung von John T. Stasko auf ausgewähl- te Untergruppen von Programm-Visualisierungen, entnommen aus Stasko and Patterson (1993)

Price et al. (1992) entwickelten eine komplexere Taxonomie zur Klassifizierung von Software-Visualisierungen“, da ihnen die existierenden Taxonomien zur Beschreibung von ” Software-Visualisierungen nicht ausreichten. Diese Taxonomie bietet 30 Bewertungskrite- durch das Bewertungskriterium rien in den sechs in Abbildung 3.4 dargestellten Kategorien. Die Bewertungskriterien umfassen objektive Eigenschaften der Visualisierungen - unter anderem in abgewandel- ter Form die Kriterien von Myers - und in geringem Maß auch eine subjektive Bewertung Appropriateness and Clarity“, welches Teil der Kategorie F: Effectiveness ist. Zur subjek ” en Bewertung werden jedoch keine Anhaltspunkte oder tiv Vorgehen definiert, selbst in den gebotenen Beispielen wird das Kriterium allgemein mit subjective“ belegt. Im Endeffekt ist die Taxonomie damit - wie die Taxonomie von Myers ” - auch als reine Beschreibung der objektiven Eigenschaften von Software-Visualisierungen zu sehen.

In Price et al. (1993) verfeinern die Autoren ihre Taxonomie durch die Einführung von Unterkategorien zu den 30 Kategorien sowie durch die Möglichkeit der rekursiv fortge- setzten Unterkategorisierung dieser Unterkategorien (auch beschrieben in Stasko et al. (1998)). Diese fortgesetzte Unterkategorisierung ist dargestellt in Abbildung 3.5. Beide

3.2 Abgrenzung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.4: Überblick über die Ta-xonomie von Price et al.

(1992)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.5: Detail-Ansicht der Katego-rie “Form”

Abbildungen der Taxonomie wurden dem bereits erwähnten Artikel von Price et al. (1993) entnommen. Damit entwickelten die Autoren ein nahezu beliebig erweiterbares Beschrei- bungsschema für Software-Visualisierungen, basierend auf ihrem oben beschriebenen An- satz.

Durch diese Erweiterbarkeit wurde die Taxonomie von Price et al. zur Grundlage für zahlreiche weitere, spezifischere Taxonomien für Software-Visualisierungen. Ein Bei- spiel hierfür ist die im Paper Towards a Taxonomy of Network Protocol Visualization Tools“ von Crescenzi and Inno ” ti (2002) beschriebene Taxonomie für Netzwerkprotokoll- Visualisierungen.

3.2 Abgrenzung

Die vorgestellten Systeme ermöglichen die Beschreibung und Klassifizierung von Pro- grammen in unterschiedlicher Komplexität. Eines haben sie jedoch gemeinsam - die Bewertung der Visualisierungen erfolgt nahezu vollständig durch objektive Eigenschaften. Einzig das Bewertungskriterium Appropriateness and Clarity“ von Price et al. (1992) bietet einen Ansatz zu einer quali ” tiven Bewertung. Diese wird jedoch in dem im Artikel beschriebenen Beispiel nicht durchgeführt.

Der in diesem Dokument vorgestellte Ansatz verbindet eine Beschreibung der ob- jektiven Eigenschaften einer Visualisierung für Programmcode mit einer subjektiven Bewertung. Diese Bewertung erfolgt zum einen durch eine Analyse der allgemeinen Qualität der Visualisierung - auf Verständlichkeit, Korrektheit, etc. - zum anderen durch die Erstellung von Profilen für Visualisierungen, mit dem Ziel der Zuordnung von unterstützenden Visualisierungen zu Tätigkeiten im Zusammenhang mit der Arbeit an Programmcode.

Insbesondere dieses zielorientierte Vorgehen - die Zuordnung von Visualisierungen zu Tätigkeiten - stellt eine Neuerung und einen erheblichen Mehrwert dar. Während die genannten existierenden Taxonomien und Beschreibungsschemata Visualisierungen zur reinen Beschreibung oder Klassifizierung analysieren, erfolgt die Betrachtung in dem im Folgenden beschriebenen Bewertungsschema aus der Sicht des Anwenders. Hierdurch wird eine Auswahl nach Nutzen ermöglicht. Visualisierungen können nicht mehr nur nach ih- rem äußeren Erscheinungsbild, sondern auch nach ihrer Anwendbarkeit im Allgemeinen und auch im speziellen Fall zur Unterstützung einer bestimmten Aufgabe ausgewählt wer- den. Hierdurch erfolgt der Brückenschlag von der theoretischen Einordnung hin zu einer praktischen Verwendbarkeit der Bewertung.

4 Lösungsweg

Die Lösung der in Kapitel 2 beschriebenen Aufgaben erfolgt in mehreren Schritten. Diese Schritte werden im Folgenden beschrieben, die Beschreibung ihrer Umsetzung erfolgt in den nachfolgenden Kapiteln.

4.1 Abgrenzung des Betrachtungsraumes

Diese Diplomarbeit befasst sich mit Visualisierungen für Programmcode. Die Bearbeitung dieses Themas zeigte, dass große Meinungsunterschiede darüber bestehen, wann eine Visualisierung eine Visualisierung für Programmcode“ ist. Insbesondere beim Umfang der dargestellten ”ten gehen die Meinungen stark auseinander - für die einen ist die Darstellung einer Testüberdeckung im Programmcode eine Visualisierung für Pro- grammcode, da die Darstellung im Programmcode erfolgt. Für andere gilt dies nicht, da als Kernaussage der Visualisierung keine Eigenschaft des Programmcodes dargestellt wird.

Aus diesem Grund wird in diesem Abschnitt eine Abgrenzung gezogen, welche Visualisie- rungen unter die Betrachtung fallen.

4.1.1 Definition von Visualisierung für Programmcode

Im Rahmen dieser Arbeit wird die folgende Definition für Visualisierung für Programm- code verwendet.

Definition 4.1.1 Eine Visualisierung fu ¨ r Programmcode ist eine visuelle Darstellung von einer oder mehreren Eigenschaften eines gegebenen Programmcodes, wobei die fu ¨ r die Darstellung notwendigen Informationen alleine aus dem Programmcode gewonnen werden.

Diese Definition schränkt die in dieser Arbeit betrachteten Visualisierungen ein. Es werden ausschließlich Visualisierungen betrachtet, die Eigenschaften von Programmcode darstellen. Zudem werden keine Visualisierungen betrachtet, die Informationen aus einer externen Informationsquelle benötigen, wie zum Beispiel einer Versionsverwaltung, einer Quelle für Testüberdeckungen oder einem Bugtracking Tool. Visual Programming“ dar. Beim Visual Programming ” wird in einem Editor eine grafische Darstellung des zu erstellenden Programms erstellt.

Aus dieser grafischen Darstellung wird anschließend oder fortlaufend Programmcode erzeugt. Zum Zeitpunkt direkt nach der Erstellung des Programmcodes stellt die grafische Darstellung eine Visualisierung des generierten Programmcodes dar.

Visual Programming wird im Rahmen dieser Diplomarbeit explizit von der Betrachtung ausgeschlossen. Das Ziel von Visual Programming ist die Generierung des Programmcodes, nicht die grafische Darstellung. Das grafische Modell dient primär als Mittel zur Definition des Programms.

Die Darstellung des Programms wird zudem im Fall von Visual Programming nicht aus dem Programmcode erzeugt. Aus diesem Grund liegt keine Visualisierung für Programm- code nach Definition 4.1.1 vor.

4.1.2 Dynamische Visualisierungen zur Darstellung von Laufzeitverhalten

Neben den externe Informationsquellen benötigenden Visualisierungen werden mit der im vorherigen Abschnitt getroffenen Definition auch Visualisierungen ausgeschlossen, wel- che Laufzeitverhalten durch Veränderungen am ausgeführten Programm, beispielsweise in Form von Programmcode- oder Bytecode-Instrumentierung, darstellen. Diese Visua- lisierungen widersprechen der Definition, da sie die benötigten Informationen nicht aus dem Programmcode selber erlangen, sondern erst durch die durchgeführten Änderungen. In dieser Diplomarbeit wird die im vorherigen Abschnitt gegebene Definition verwendet.

Die Diplomarbeit beschäftigt sich in den Abschnitten mit konkreter Anwendung der De- finition jedoch ausschließlich mit statischen Visualisierungen für Programmcode, so dass der in diesem Abschnitt beschriebene Grenzfall nicht zum Tragen kommt.

In anderen Anwendungsfällen kann es sinnvoll sein, die Definition in Bezug auf die Informationsbeschaffung hinsichtlich der Visualisierungen für Programmcode zur Darstel- lung von Laufzeitverhalten zu modifizieren, so dass Änderungen am Programmcode als Informationsquelle zulässig werden.

Im Folgenden wird darauf hingewiesen, wann eine solche Modifikation zu Veränderungen führen würde.

4.2 Schema zur Erfassung existierender Visualisierungen

Um die betrachteten Visualisierungen erfassen und vergleichen zu können, werden sie in eine einheitliche Form gebracht. Hierzu wird ein Schema entworfen, mit welchem die objektiv erfassbaren Eigenschaften sowie eine subjektive Bewertung der Visualisierungen standardisiert festgehalten werden können.

Dieses Schema besteht aus zwei Teilen. Der erste Teil - das Beschreibungsschema - dient der Erfassung der objektiven Eigenschaften der Visualisierungen. Der zweite Teil - das Bewertungsschema - erlaubt die Erfassung der subjektiven Bewertung.

4.3 Beschreibungsschema

Zur Erfassung der existierenden Visualisierungen wird ein Beschreibungsschema entwor- fen. Dieses Beschreibungsschema erlaubt eine objektive Beschreibung einer Visualisierung. Hierin enthalten sind die relevanten eindeutig feststellbaren Eigenschaften, wie zum Beispiel Farbigkeit, Interaktion oder Animation.

Das Beschreibungsschema ist in Kapitel 5 beschrieben.

4.4 Bewertungsschema

Im Gegensatz zur Beschreibung der objektiven Eigenschaften durch das Beschreibungs- schema ermöglicht das Bewertungsschema eine subjektive Sicht auf die Qualität und die Einsatzgebiete einer Visualisierung.

Das Bewertungsschema dient zur Verfolgung zweier Ziele. Zum einen definiert es ei- ne Zuordnungsvorschrift von Visualisierungen zu Tätigkeiten von mit Visualisierungen für Programmcode arbeitenden Personen. Anhand dieser Zuordnungvorschrift können zu einer Tätigkeit passende Visualisierungen gefunden werden, ohne dass eine direkte Ver- knüpfung definiert wurde.

Zum anderen erlaubt das Bewertungsschema eine qualitative Beurteilung der Visualisie- rung. Diese Bewertung umfasst eine Einstufung anhand von qualitativen Merkmalen wie Korrektheit und Lesbarkeit, aber auch eine abschließende Erörterung der Einsatzgebiete und Verwendbarkeit der Visualisierung basierend auf den Analysen und der Erfahrung des Bearbeiters.

Das Bewertungsschema ist in Kapitel 6 beschrieben.

4.5 Katalogisierung

Die beiden in den vorherigen Abschnitten beschriebenen Schemata finden in der Katalo- gisierung ihre Anwendung. Sie werden hier auf Visualisierungen angewandt, die jeweils stellvertretend für eine Art von Visualisierung für Programmcode stehen. Hierdurch wird das Feld der vorhandenen Visualisierungen für Programmcode aufgezeigt und ihre prominentesten Vertreter analysiert.

Die Katalogisierung umfasst die folgenden Visualisierungen:

- Omondo UML Klassendiagramm (Omondo Europa, Inc. (2008))
- SeeSoft Conditional Nesting Complexity (Ball and Eick (1996))
- G SEE Inheritance Relationship (Favre (2001))
- Creole Nested View (The CHISEL Group (2008))
- sv3D (Marcus et al. (2003))
- IMSOVision (Maletic et al. (2001b))
- Metrics (SourceForge.net (2008a))

Diese Visualisierungen decken einen Großteil der nach der Definition aus Abschnitt 4.1.1 möglichen Visualisierungen für Programmcode ab. Das Omondo UML Klassendiagramm dient als Stellvertreter der statischen UML Strukturdiagramme. SeeSoft Conditional Nesting Complexity repräsentiert die SeeSoft-charakteristische zeilenbasierte Darstellung von Programmcode mit der Abbildung von Eigenschaften des Programmcodes in einer Einfärbung der Zeilen. G SE E Inheritance Relationship stellt die Struktur des Programm- codes als Baum dar, mit den Klassen des Programmcodes als Knoten. Creole Nested View ist eine stark interaktive Visualisierung, welche den Anwender den Aufbau des Programmcodes durch Navigation durch diesen erforschen“ lässt. Sv3D hingegen nutzt die Möglichkeiten der dritten Dimension, um die ” mplexität großer Programme und die damit verbundenen Darstellungsprobleme zu entzerren. IMSOVision und Metrics bilden die Ausnahmen der Katalogisierung. IMSOVision bietet einen ” rtual Reality“-Ansatz zur Betrachtung von Programmcode. Ein Anwender Vi kann sich virtuell in einer den Programmcode repräsentierenden Welt bewegen und diesen erleben“. Im Gegensatz zu den restlichen betrachteten Visualisierungen gibt es von ” OVision jedoch keinen lauffähigen Prototyp, so dass die Beschreibung und Bewertung von IMSOVision ausschließlich auf den veröffentlichten Informationen und auf den per Email geführten Gesprächen des Bearbeiters dieser Arbeit mit dem Entwickler von IMSOVision basiert.

Den zweiten Ausnahmefall bildet Metrics. Metrics ist nach der Definition aus Abschnitt 4.1.1 keine Visualisierung für Programmcode, da keine grafische Darstellung von Eigen- schaften des Programmcodes erfolgt. Metrics stellt die ermittelten Kennzahlen des Pro- grammes ausschließlich textuell dar.

Metrics wird als Beispiel für eine Alternative zu Visualisierungen für Programmcode in die Katalogisierung aufgenommen. Es stellt, wie auch von den Visualisierungen gefordert, Eigenschaften von Programmcode dar, wobei die Informationen ausschließlich aus dem Programmcode selber gewonnen werden. Die kompakte textuelle Darstellung erlaubt da- bei, viele Informationen auf engem Raum übersichtlich darzustellen. Durch die Aufnahme von Metrics in die Katalogisierung wird ein Vergleich zwischen der grafischen und der textuellen Darstellung von Eigenschaften von Programmcode ermöglicht.

4.6 Resultate der Katalogisierung

Die Katalogisierung liefert umfangreiche Informationen über die vorhandenen Visualisie- rungen für Programmcode, insbesondere über deren Qualität, Einsatzmöglichkeiten und Mängel. Diese Informationen werden in Kapitel 8 ausgewertet und zu einer allgemeinen Übersicht über die vorhandenen Visualisierungen für Programmcode zusammengefasst.

Zudem wird eine Auswahl aus den katalogisierten Visualisierungen getroffen, mit wel- cher die Tätigkeiten von an Programmcode arbeitenden Personen bestmöglich unterstützt werden. Diese Auswahl stellt einenWerkzeugkasten“ für die Arbeit mit Programmcode dar und bildet einen Kompromiss ” schen der Menge der enthaltenen Visualisierungen zwi und den unterstützten Tätigkeiten.

Zuletzt wird auf Basis der gewonnenen Erkenntnisse über die Mängel der existierenden Visualisierungen eine neue Visualisierung entworfen. Diese neue Visualisierung bietet eine Sicht auf Programmcode, die von keiner der katalogisierten Visualisierungen geboten wird. Sie rundet damit den Werkzeugkasten“ ab. ”

5 Beschreibungsschema

In diesem Kapitel wird ein Schema beschrieben, welches die Erfassung der objektiven Ei- genschaften einer Visualisierung für Programmcode erlaubt. Dieses Beschreibungsschema bildet eine der beiden Grundlagen für die in Kapitel 7 durchgeführte Katalogisierung.

5.1 Struktur

Das Beschreibungsschema besteht aus zwei Teilen. Der erste Teil besteht aus einer Klas- sifizierung der Visualisierungen. Hierin wird eine Visualisierung eindeutig einer Klasse zugeordnet (siehe Abschnitt 5.2).

Abhängig von dieser Klassifizierung werden den Visualisierungen im zweiten Teil Eigen- schaften zugewiesen. Jede Klasse besitzt eine Menge von Eigenschaften, wobei sich diese Mengen der Klassen stark überschneiden.

Der zweite Teil - die Beschreibung der objektiven Eigenschaften einer Visualisierung - be- steht aus elf Eigenschaften, gruppiert in drei Kategorien. Diese Kategorien sind so gewählt, dass auch bei einer Erweiterung des Beschreibungsschemas um weitere Eigenschaften eine Zuordnung eindeutig möglich ist.

Die Beschreibung einer Visualisierung erfolgt durch eine Belegung der Eigenschaften mit Werten.

Abbildung 5.1 zeigt die Struktur des Beschreibungsschemas. Die gepunkteten Ele- mente stellen die Kategorien dar. Unter ihnen hängen, in der gleichen Farbe dargestellt, die zu ihnen gehörenden Eigenschaften.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5.1: Grafische Darstellung der Struktur des Beschreibungsschemas

Die Eigenschaften Echtzeit“,

” Ergebnis“, ” Einbindung“ und ” Auswirkungen auf Ausfüh- ” rung“ sind gestreift dargestellt. Dies bedeutet, dass sie ausschließlich zu den dynamischen Klassen gehören und nur für zu diesen Klassen gehörenden Visualisierungen mit Werten belegt werden. Alle anderen Eigenschaften werden generell bewertet, ungeachtet der Klas- se, zu der eine zu beschreibende Visualisierung gehört. Auf die Klassenzugehörigkeit einer Visualisierung wird im folgenden Abschnitt detaillierter eingegangen.

5.2 Klassifizierung

Bevor einer Visualisierung Eigenschaften zugeordnet werden können muss die Visualisie- rung klassifiziert werden. Aus dieser Klassifizierung ergeben sich die für die Visualisierung relevanten Eigenschaften.

Die erstellte Klassifizierung basiert auf der in Kapitel 3 vorgestellten Taxonomie von Myers (1990). Diese Taxonomie von Programmvisualisierungen stellt eine 2x3 Matrix dar, wobei auf der einen Achse die Dynamik der Visualisierung in den Werten ” atic“ und st dynamic“ abgebildet ist, die andere Achse den Fokus der Visualisierung in den Werten ” Data“, ” Code“ und ” Algorithm“ darstellt. Myers Taxonomie erlaubt damit die Einordnung ” jeder Programmvisualisierung in eine der sechs aus der Matrix resultierenden Klassen.

Da der Fokus des Beschreibungsschemas jedoch ausschließlich auf der Visualisierung von

Programmcode liegt entfällt die Achse Fokus“. Sie wird ersetzt durch ein neues Kriterium

- den Abstraktionslevel. Der Abstrakt ”nslevel enthält ebenfalls zwei Werte:
- Code
- Abstrakt

Eine Visualisierung hat genau dann den Abstraktionslevel Code, wenn ihre hauptsächliche Ausgabe im Quellcode selber stattfindet. Alle Visualisierungen, die ihre hauptsächliche Darstellung nicht im Quellcode haben, gehören zum Abstraktionslevel Abstrakt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5.2: Grafische Darstellung der Klassifizierung

Durch die Ergänzung um den Abstraktionslevel entsteht eine 2x2 Matrix. Diese Matrix ist dargestellt in Abbildung 5.2. Die Klassifizierung definiert damit vier Klassen. Die Klassen werden wie in Tabelle 5.1 beschrieben benannt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5.1: Klassifizierung - Benennung der Klassen

5.3 Ebene 1 - Kategorien von Eigenschaften

Die Kategorien stellen eine Gruppierung der Eigenschaften dar, die für das Beschrei- bungsschema erfasst werden. Jede Eigenschaft ist eindeutig einer Kategorie zugeordnet. Die Kategorien dienen der Übersichtlichkeit und ermöglichen es dem Benutzer des Beschreibungsschemas, bestimmte Eigenschaften schnell zu finden.

Das Beschreibungsschema definiert die in Tabelle 5.2 beschriebenen Kategorien.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5.2: Kategorien des Beschreibungsschemas

Die Eigenschaften und ihre Zuordnungen werden im folgenden Abschnitt 5.4 beschrieben.

5.4 Ebene 2 - Eigenschaften

In diesem Abschnitt werden sämtliche Eigenschaften definiert, die das Beschreibungs- schema umfasst. Die Eigenschaften sind in die in Abschnitt 5.3 definierten Kategorien gruppiert.

Jede Eigenschaft ist einer oder mehreren Klassen zugeordnet (siehe Abschnitt 5.2). Diese Zuordnung erfolgt über die Klassennamen. Ist eine Eigenschaft allen Klassen zugeordnet, so wird dies durch alle“ beschrieben. Jede Eigenschaft” at einen Typ. Dieser Typ gibt an, von welchem Wertetyp die Werte h der Eigenschaft sind und auf welche Weise sie in einer Umsetzung dargestellt werden können. Die Typen von Eigenschaften sind in Tabelle 5.3 definiert.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5.3: Typen von Eigenschaften

Zus¨atzlich zu den definierten Typen von Eigenschaften gibt es noch zwei ”null“-Werte. Diese Werte werden gesetzt, wenn eine Eigenschaft nicht bewertet werden kann oder soll. Die ”null“-Werte sind anwendbar bei jedem Eigenschaftstyp.

Die ”null“-Werte und ihre Bedeutung sind definiert in der folgenden Tabelle 5.4.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5.4: “Null“-Werte

Der ” ull“-Wert Nie ist Standardwert für alle Eigenschaften einer neu in die Katalogi- n sierung aufgenommene Visualisierung (siehe Abschnitt 5.5.1). Hierdurch wird vermieden, dass unvollständig beschriebene Visualisierungen in Ergebnislisten von Suchen auftreten, obwohl sie nicht den Suchkriterien entsprechen.

5.4.1 Darstellung

Die Eigenschaften der Kategorie Darstellung beinhalten die betrachteten Aspekte der grafischen Darstellung der Visualisierung. Die Kategorie umfasst die in Abbildung 5.3 dargestellten Eigenschaften.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5.3: Grafische Darstellung der Eigenschaften der Kategorie Darstellung

Visualisierungstyp

Die Eigenschaft Visualisierungstyp gibt an, um was für einen Typ von Visualisierung es sich handelt.

Klassen: alle

Typ: Suchbarer Freitext

Die in Tabelle 5.5 angegebenen Beispielwerte für die Eigenschaft Visualisierungtyp geben einen Anhaltspunkt für mögliche Belegungen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5.5: Beispielwerte der Eigenschaft Visualisierungstyp

Alternative:

Die Werte der Eigenschaft Visualisierungstyp werden als Auswahlliste angeboten. Dies ist zu empfehlen, wenn die Typen der Visualisierungen im Voraus bekannt sind. Die Liste sollte jedoch erweiterbar sein.

Farbe

Die Eigenschaft Farbe gibt an, ob die Darstellung der Visualisierung farbig erfolgt. Die Aussage bezieht sich hierbei ausschließlich auf die Darstellung, es ist unerheblich, ob durch die farbige Darstellung Informationen übermittelt werden.

Klassen: alle

Typ: Auswahlliste

Mögliche Werte:

Wert Beschreibung

Abbildung in dieser Leseprobe nicht enthalten

Schwarzweiß, Graustufen Die Darstellung der Visualisierung ist zweifarbig in

Schwarz und Weiß oder in Graustufen. Die Visualisie- rung (oder ein Standbild einer dynamischen Visualisie- rung) kann beispielsweise auf einem schwarzweißen Aus- druck dargestellt werden.

Abbildung in dieser Leseprobe nicht enthalten

Farbig Die Darstellung der Visualisierung ist mehrfarbig, nicht ausschließlich in Graustufen. Die Farbe stellt möglicher- weise Informationen dar, die beispielsweise bei einem Aus- druck in schwarzweiß verloren gehen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5.6: Werte der Eigenschaft Farbe

Die Eigenschaft Farbe ist von Interesse, wenn beispielsweise ein schwarzweißes Dokument mit Ausdrucken von Visualisierungen erstellt werden soll, oder wenn die Visualisierung einen farbenblinden Entwickler bei der Fehlersuche unterstützen soll.

Animation

Die Eigenschaft Animation gibt an, ob die Visualisierung animiert abläuft. Hierbei werden nur Animationen betrachtet, die für die Visualisierung relevante Informationen transpor- tieren.

Klassen: alle

Typ: Boolean

Animationen mit Informationsgehalt treten generell bei dynamischen Visualisierungen auf. Es ist jedoch auch möglich, dass sie bei statischen Visualisierungen zum Einsatz kommen. Dies ist genau dann gegeben, wenn die Hauptinformation der Visualisierung statisch dargestellt wird, durch Animation jedoch weitere Informationen geboten werden. Dies wäre beispielsweise der Fall bei einer Visualisierung, die durch Highlighting alle Vorkommnisse einer Variablen im Programmcode darstellt und als zusätzliche Information durch Farbwechsel die Gruppen von Vorkommnissen, die immer zusammen ausgeführt werden (weil sie beispielsweise in der gleichen Verzweigung einer IF-Bedingung liegen).

Echtzeit

Die Eigenschaft Echtzeit gibt an, ob die dynamische Visualisierung in Echtzeit abläuft.

Klassen: DC, DA

Typ: Auswahlliste

Mögliche Werte:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5.7: Werte der Eigenschaft Echtzeit

Ergebnis

Die Eigenschaft Ergebnis gibt an, ob am Ende der dynamischen Visualisierung eine Zu- sammenfassung angezeigt wird.

Klassen: DC, DA

Typ: Boolean

Ein Beispiel für eine dynamische Visualisierung mit Ergebnis stellt eine Visualisierung der Speicherallokation eines ausgeführten Programmes dar, bei der am Programm- oder Visualisierungsende eine Zusammenfassung der Werte und Ereignisse angezeigt wird. In dieser Zusammenfassung kann beispielsweise (auf einer Seite) ausgegeben werden, wieviel Speicher im Durchschnitt allokiert wurde, wie hoch die maximale Speicherallokation war, wie oft und in welchen Abständen ein im Voraus definierter Grenzwert überschritten wurde und ob die Speicherallokation über die Laufzeit des Programmes gesehen stetig zugenommen hat.

5.4.2 Interaktion

Die Kategorie Interaktion umfasst alle Eigenschaften, welche die Möglichkeiten der Interaktion des Benutzers mit der Visualisierung darstellen.

Die Kategorie umfasst die in Abbildung 5.4 dargestellten Eigenschaften.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5.4: Grafische Darstellung der Eigenschaften der Kategorie Interaktion

Interaktion

Die Eigenschaft Interaktion gibt an, ob der Benutzer auf die ausgeführte Visualisierung einwirken kann.

Interaktion beschreibt hier die manuelle Veränderung der Visualisierung zugrunde lie- gender Informationen, wie beispielsweise die betrachtete Klasse oder Komponente, den Zeitpunkt der Betrachtung etc. Nicht gemeint ist die Veränderung der Betrachtung wie eine Änderung des Detaillevels oder eine Veränderung der Perspektive. Diese Eigenschaf- ten sind im Folgenden separat beschrieben.

Klassen: alle

Typ: Boolean

Detaillevel

Die Eigenschaft Detaillevel gibt an, ob die Visualisierung Informationen in verschiedenen Detailleveln anzeigen kann. Dies ist beispielsweise gegeben, wenn in einem Klassendia- gramm auf die Klasse geklickt werden kann, so dass Details zu dieser Klasse angezeigt werden.

Klassen: alle

Typ: Boolean

Visualisierungssystem

Die Eigenschaft Visualisierungssystem gibt an, ob die Visualisierung mehrere Visuali- sierungen (Sichten) beinhaltet, oder ob sie mit anderen Visualisierungen verknüpft ist. Enthält die Visualisierung mehrere Sichten, so können diese innerhalb der Visualisie- rung umgeschaltet oder parallel betrachtet werden. Ist die Visualisierung mit anderen Visualisierungen verknüpft, so ist es möglich, von dieser Visualisierung auf eine andere Visualisierung zu wechseln.

Klassen: alle

Typ: Auswahlliste (mehrere Auswahlen möglich)

Mögliche Werte:

Wert Beschreibung

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5.8: Werte der Eigenschaft Visualisierungssystem

5.4.3 Anbindung

Die Kategorie Anbindung enthält die Eigenschaften, welche die Anbindung der Visuali- sierung an die Datenquellen, bei Visualisierungen von Programmcode also vor allem an den Programmcode bzw. das laufende Programm beschreiben.

Die Kategorie umfasst die in Abbildung 5.5 dargestellten Eigenschaften.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5.5: Grafische Darstellung der Eigenschaften der Kategorie Anbindung

Informationsquelle

Die Eigenschaft Informationsquelle gibt an, aus welchen Quellen die Visualisierung ihre Informationen bezieht. Damit gibt die Eigenschaft auch an, welche Informationen darge- stellt werden können.

Klassen: alle

Typ: Auswahlliste (mehrere Auswahlen möglich)

Mögliche Werte für die Belegung der Eigenschaft Informationsquelle sind in Tabelle 5.9 beschrieben.

Für eine Umsetzung des Beschreibungsschemas wird empfohlen, im Fall der Auswahl des Wertes Externe Applikationen, eine Möglichkeit bereit zu stellen, Namen und Beschrei- bungen der externen Applikationen zur Beschreibung der Visualisierung speichern zu können.

Anmerkung: In der Anwendung dieses Beschreibungsschemas auf Visualisierungen ausschließlich der Wert für Programmcode nach der Definition aus Abschnitt 4.1.1 kommt für diese Eigenschaft Java Compiler“ infrage. Diese Einschränkung ist bereits durch die Definition gegeben. ”

[...]