3D-Visualisierung vonobjektorientierten Code-Strukturen

Ein Projekt amLehrstuhl für Software-Technologie

Universität Dortmundin Zusammenarbeit mit dem Institut für Arbeitsphysiologie

Universität Dortmund

Alexander Fronk

Überblick

• Software-Engineering und Reverse-Engineering• Die Rolle von Visualisierungen• Programmverständnis

• Von 2D nach 3D• Anwendungen

• Forschungshypothesen• Empirische Untersuchungen

Software-Engineering

Disziplin zur Konstruktion, Einführung, Wartung und Betrieb großer Softwaresysteme

– Konstruktion:» Anforderungen

» Architektur

» Spezifikation

» Entwurf

» Implementierung

» Test

» Dokumentation

– Wartung:» Korrektur

» Verbesserung

» Ergänzung

Visualisierung durch UML

• Kondensat aus verschiedenen Methoden

• seit etwa Anfang 1990er Jahre

• de facto-Standard

Wieso eigentlich?

Ist das Zeug wirklich so gut?

Visualisierung durch UML

Unterstützt phasenorientierte Entwicklung– Anwendungsfalldiagramme– Verteilungs-, Komponentendiagramme– Paket-, Kollaborationsdiagramme– Klassen-, Sequenzdiagramme

Ermöglicht Codeerzeugung

Hilft bei Kommunikation

Forward-Engineering:Von der Visualisierung zum Code

Schrittweises Erarbeiten eines Softwaresystems– Konzepte graphisch erfassen

» kleine Diagramme (3-10 Entitäten)

– Kommunikation von Ideen» kleine Diagramme (um die 5 Entitäten)

– Erzeugung von Codefragmenten» kleine Diagramme (20 Entitäten)

Also:

Konstruktion– Diagramme entwickeln– Code erzeugen

Wartung– Code vorhanden

– Diagramme veraltet– Diagramme fehlen

Reverse-Engineering

Disziplin innerhalb der Software-Technik zur Analyse eines existierenden Systems mit dem Ziel, Entwurf oder Spezifikation wiederzugewinnen

Tätigkeiten zur Wiedergewinnung von Informationen über ein Software-System aus dessen Quellcode

Reverse-Engineering: Vom Code zur Visualisierung

Eindringen in (unbekannten) (Legacy-) Code– Dokumentation anpassen

» wie groß sollten Diagramme werden?

– Funktionen ausnutzen» was muss dazu visualisiert werden?

– Software warten» was gehört zum Wartungsumfang?

Archetypus?

Von Visualisierung zum Code:– Verstandenes realisieren

Vom Code zur Visualisierung:– Unbekanntes verstehen

Programmverstehen

Existierendes Softwaresystem technisch/funktional durchdringen– Aufbau / Statik / Übersetzungszeit

» funktional-logische Zusammenhänge

– Ablauf / Dynamik / Laufzeit» Steuerung, Algorithmik

• = Reverse-Engineering• Tätigkeiten des Reverse-Engineering als Zugang

• kognitive Modelle zur Maximierung des Zielerreichungsgrades

Spannungsgefüge

Revers

e-Enginee

ring Software-Wartung

Programmverstehen

ViSE-3D

Revers

e-Enginee

ring Software-Wartung

Programmverstehen

Aufbau undStrukturinformationen

GroßeLegacy-Systeme

3D-Visualisierungskonzepte

Back to „Standards“

Eindringen in unbekannte Code-Strukturen– wie groß sollten

Diagramme werden?– was muss dazu

visualisiert werden?– was gehört zum

Wartungsumfang?

BeobachtungStrukturverständnis

erfordert– schnelle, präzise Übersicht

über Beziehungen– korrekte Interpretation

„UML-Defect“– schwer überschaubar

» Symbole zu ähnlich» Layout beliebig

– schlecht skalierbar– kaum Diagrammintegration

„Theorie“

1. Benutze unterschiedliche geometrische Arrangements für unterschiedliche Beziehungsarten

2. Benutze angemessenes Layout3. Integriere Arrangements explizit4. Nutze 3 räumliche Dimensionen für besseren

visuellen Zugang Verbessere visuelle Datenexploration

und damit den Zugang zum Strukturverständnis

Praxis

Praxis

Praxis

Praxis

Anwendungen

• Qualitätskontrolle

• Komplexitätseinschätzung

• Finden verbesserungswürdiger Stellen– Metrikbasiert, Data Mining

Gegenüberstellung• UML Diagramme nutzen

– ähnliche Ikonen für unterschiedliche Relationsarten– kein Layout– keine Farben– nur 2 Raumdimensionen– lediglich konzeptionelle Integration der Diagramme– Fokussierung auf technische Detailinformation

• 3D Relationen-Diagramme (3DRD) nutzen– beziehungsspezifische geometrische Arrangements– verschiedene situationsspezifische Layouts– Farben zur unmittelbaren Identifizierung von Enitäten oder Relationen– 3 Raumdimensionen für besseres Layout– visuelle Integration von Diagrammen– Fokussierung auf aggregierte Information

Forschungshypothese

Unser Ansatz trägt zum Code-Verständnis bei!

„Ansatz“: Visualisierungskonzept + Werkzeug

Forschungshypothese

Im Vergleich zu UML-Diagrammen, erlauben 3DRDs

– mehr strukturelle Aspekte im Gedächtnis zu speichern

– mehr Änderungen an Code-Strukturen in kürzerer Zeit zu erkennen

– mehr spezielle Strukturen leichter und präziser (wieder) zu entdecken

– die Qualität von Strukturen präziser zu bewerten

– die Quantität von Abhängigkeiten besser einzuschätzen

– …

Hypothesen testen

Aus Theorie abgeleitete Aussagen oder Hypothesen müssen bewiesen werden– Mathematik, Logik: formaler Beweis– Experimentelle Physik, Chemie: wiederholbare

Versuche– Medizin, Psychologie: Empirische Studien

Empirie im Software-Engineering

• Journal of Empirical Software Engineering

• nicht unbekannt: ≥ 10 Jahre

• divergent in Durchführung, Qualität der Aussagen

• bisher kein Einzug in die Ausbildung

Empirie im Software-Engineering

• Methoden: Experiment, Fallstudie– weniger: Korrelationsstudien, Metaanalysen, Surveys, ex post

facto-Studien– fehl: Langzeitstudien

• Subjekte: etwas mehr professionelle Entwickler als Studierende

• Hauptthemen: Metriken und Werkzeuge (Methoden, Frameworks)

• Kaum betrachtet: Programmiersprachen, MDD, formale Methoden

breites Tätigkeitsspektrum konterkariert Untersuchungsgegenstände

Empirie im Reverse-Engineering

• Interesse an Experimenten– Planung, Durchführung, konkrete Inhalte

– Benchmarks

– Experimentklassen

– Verallgemeinerung

– Größe von Versuchsdaten

VisMOOS: bietet ideale Plattform und ist als Untersuchungsgegenstand zentral positionierbar.

Forschungshypothesen

Im Vergleich zu UML-Diagrammen, erlauben 3DRDs

– mehr strukturelle Aspekte im Gedächtnis zu speichern

– mehr Änderungen an Code-Strukturen in kürzerer Zeit zu erkennen

– mehr spezielle Strukturen leichter und präziser (wieder) zu entdecken

– die Qualität von Strukturen präziser zu bewerten

– die Quantität von Abhängigkeiten besser einzuschätzen

– …

Studien

Zweiphasiges Vorgehen:1. „Preliminary Survey“ zum Hypothesentesten

– Subjekte: Studierende

2. Studie zum Entdecken der Ursachen– Hinweise darauf aus Phase 1

Parallel dazu: Materna-Studie– Langezeit-Fallstudie

Studien

Phase 1 gleichzeitig Hypothesen-generierend» Codegröße beeinflusst Fragestellungen» Spezifische Blick beeinflusst Qualität der Aussagen» Farbe und Layout beeinflusst Effizienz» Geometrische Arrangements beeinflusst Effektivität» Werkzeugeigenschaften beeinflusst Motivation» 3D beeinflusst Gehirnleistung

• Verallgemeinerung auf Visualisierungswerkzeuge angestrebt

Experimente

• Setting und Co-Faktoren– Studierende aus Vor- und Hauptstudium

» unterschiedliche Kenntnisse in UML, keine in 3DRD

» Erfahrungen mit 3D-Spielen

» Männer/Frauen möglichst gemischt

– Gruppennivellierung» Kurze Schulung in UML and 3DRD

– Zwei Gruppen» Omondo, VisMoos

Experimente

• Mit Zeitbeschränkung– Aufgabe unter Zeitdruck erfüllen– Qualität messen

• Ohne Zeitbeschränkung– Aufgabe erfüllen– Qualität im Verhältnis zur Zeit messen

Experimente

„Gedächtnis“• Situation: Ein komplexes Diagramm liegt vor• Aufgabe: „Betrachten Sie folgendes Diagramm und sammeln Sie

soviel Wissen über den Quellcode wie möglich“– Falle:

» „Wissen“ absichtlich offen gelassen» nichts aufschreiben

• Pause!• Aufgabe: „Schreiben Sie auf, woran Sie sich erinnern“

Erwarteter Effekt:– UML: technische Details– 3DRD: strukturelle Auffälligkeiten

Experimente

„Erinnerung“• Situation: Ein komplexes Diagramm liegt vor• Aufgabe: „Sammeln Sie Informationen über Klassen und

ihre Zugehörigkeit zu Paketen und Hierarchien“• Pause!• Aufgabe: „Ordnen Sie die folgenden Klassen ihren

Paketen und Hierarchien zu“

Erwarteter Effekt:– UML: Durch Details verwischtes Erinnern– 3DRD: Mehr Zuordnungen, weniger falsch

Experimente

„Panorama”• Situation: 9 komplexe Diagramme liegen vor, je 3

zu einem Projekt• Aufgabe: „Sortieren Sie die Diagramme nach

ihren Projektzugehörigkeiten“

Erwarteter Effekt:– UML: ohne Label fast unmöglich– 3DRD: gute Trefferquote, selbst falls geraten

Experimente

„Was wäre wenn…“• Situation: Ein komplexes Diagramm liegt vor• Aufgabe: „Welche Auswirkung hat das Löschen

der Klasse XYZ?“

Erwarteter Effekt:– UML: Bewertung auf Ebene von Methoden, technisch– 3DRD: Bewertung auf Ebene von Komponenten,

konzeptionell

Experimente

„Alles fließt“• Situation: Ein komplexes Diagramm liegt vor• Aufgabe: „Schätzen Sie die Kosten für die

Einbringung der Funktionalität XYZ“• Aufgabe: „Schlagen Sie eine Änderungsstrategie

vor“

Erwarteter Effekt:– UML: Verloren in Details– 3DRD: konzeptionelle Strategie

Verallgemeinerung

– Gedächtnis» „Mal sehen, was Sie sehen“

– Erinnerung» „Mal sehen, was/wieviel Sie noch wissen “

– Panorama» Zusammenhänge entdecken

– Was wenn» Effekte abschätzen

– Alles fließt» Quantitative, qualitative Bewertung

Zentrale Fragen

Experimentklassen

Diagrammgröße

Aufgaben

Zeitbeschränkung vs. Zeitmessung

Interpretation der Ergebnisse

Ausblick

• Experimente präzisieren und durchführen• Heuristische Expertenevaluation• Zweite Phase

• Debugging-Studie– Ähnliche Experimente– Web-basiertes Interface zum Durchführen der

Experimente