Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

3D-Visualisierung von objektorientierten Code-Strukturen Ein Projekt am Lehrstuhl für Software-Technologie Universität Dortmund in Zusammenarbeit mit.

Ähnliche Präsentationen


Präsentation zum Thema: "3D-Visualisierung von objektorientierten Code-Strukturen Ein Projekt am Lehrstuhl für Software-Technologie Universität Dortmund in Zusammenarbeit mit."—  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 Universität Dortmund 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 –Diagramme entwickeln –Code erzeugen Wartung –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: –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

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 –schnelle, präzise Übersicht über Beziehungen –korrekte Interpretation UML-Defect –schwer überschaubar »Symbole zu ähnlich »Layout beliebig –schlecht skalierbar –kaum Diagrammintegration

17 Theorie 1.Benutze unterschiedliche geometrische Arrangements für unterschiedliche Beziehungsarten 2.Benutze angemessenes Layout 3.Integriere Arrangements explizit 4.Nutze 3 räumliche Dimensionen für besseren visuellen Zugang Verbessere visuelle Datenexploration und damit den Zugang zum Strukturverständnis

18 Praxis

19

20

21

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: 1.Preliminary Survey zum Hypothesentesten –Subjekte: Studierende 2.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 –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 »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


Herunterladen ppt "3D-Visualisierung von objektorientierten Code-Strukturen Ein Projekt am Lehrstuhl für Software-Technologie Universität Dortmund in Zusammenarbeit mit."

Ähnliche Präsentationen


Google-Anzeigen