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