3D-Visualisierung von objektorientierten Code-Strukturen Ein Projekt am Lehrstuhl für Software-Technologie Universität Dortmund in Zusammenarbeit mit dem Institut für Arbeitsphysiologie 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 Wartung Diagramme entwickeln Code erzeugen 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: Vom Code zur Visualisierung: 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 Reverse-Engineering Software-Wartung Programmverstehen

ViSE-3D Reverse-Engineering Software-Wartung Programmverstehen Aufbau und Strukturinformationen Große Legacy-Systeme 3D-Visualisierungskonzepte Programmverstehen

Back to „Standards“ Eindringen in unbekannte Code-Strukturen wie groß sollten Diagramme werden? was muss dazu visualisiert werden? was gehört zum Wartungsumfang?

Beobachtung Strukturverständnis erfordert „UML-Defect“ schnelle, präzise Übersicht über Beziehungen korrekte Interpretation „UML-Defect“ schwer überschaubar Symbole zu ähnlich Layout beliebig schlecht skalierbar kaum Diagrammintegration

„Theorie“ Benutze unterschiedliche geometrische Arrangements für unterschiedliche Beziehungsarten Benutze angemessenes Layout Integriere Arrangements explizit 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: Parallel dazu: Materna-Studie „Preliminary Survey“ zum Hypothesentesten Subjekte: Studierende 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 Ohne 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 Erinnerung Panorama Was wenn Alles fließt „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