3D-Visualisierung von objektorientierten Code-Strukturen

Präsentation zum Thema: "3D-Visualisierung von objektorientierten Code-Strukturen"—  Präsentation transkript:

1

2 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

3 Überblick Software-Engineering und Reverse-Engineering
Die Rolle von Visualisierungen Programmverständnis Von 2D nach 3D Anwendungen Forschungshypothesen Empirische Untersuchungen

4 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

5 Visualisierung durch UML
Kondensat aus verschiedenen Methoden seit etwa Anfang 1990er Jahre de facto-Standard Wieso eigentlich? Ist das Zeug wirklich so gut?

6 Visualisierung durch UML
Unterstützt phasenorientierte Entwicklung Anwendungsfalldiagramme Verteilungs-, Komponentendiagramme Paket-, Kollaborationsdiagramme Klassen-, Sequenzdiagramme Ermöglicht Codeerzeugung Hilft bei Kommunikation

7 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)

8 Also: Konstruktion Wartung Diagramme entwickeln Code erzeugen
Code vorhanden Diagramme veraltet Diagramme fehlen

9 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

10 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?

11 Archetypus? Von Visualisierung zum Code: Vom Code zur Visualisierung:
Verstandenes realisieren Vom Code zur Visualisierung: Unbekanntes verstehen

12 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

13 Spannungsgefüge Reverse-Engineering Software-Wartung Programmverstehen

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

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

16 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

17 „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

18 Praxis

19 Praxis

20 Praxis

21 Praxis

22 Anwendungen Qualitätskontrolle Komplexitätseinschätzung
Finden verbesserungswürdiger Stellen Metrikbasiert, Data Mining

23 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

24 Forschungshypothese Unser Ansatz trägt zum Code-Verständnis bei!
„Ansatz“: Visualisierungskonzept + Werkzeug

25 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 …

26 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

27 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

28 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

29 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.

30 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 …

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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

39 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

40 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

41 Zentrale Fragen Experimentklassen Diagrammgröße Aufgaben
Zeitbeschränkung vs. Zeitmessung Interpretation der Ergebnisse

42 Ausblick Experimente präzisieren und durchführen
Heuristische Expertenevaluation Zweite Phase Debugging-Studie Ähnliche Experimente Web-basiertes Interface zum Durchführen der Experimente