Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 2012/13 Überblick I Software-Visualisierung
Software-Visualisierung I Software-Visualisierung Über diese Folien Lernziele Reengineering-Kontext Programm-Visualisierung Statische Programm-Visualisierung Graphen mit Metriken Klassenblaupause Dynamische Programm-Visualisierung Evolutionäre Aspekte Zusammenfassung Wiederholungsfragen 3 / 58 Über diese Folien Diese Folien entstammen einer Präsentation von Michele Lanza (Universität Lugano), mit dessen freundlicher Genehmigung. Die Unterschiede zum Original sind: Übersetzung ins Deutsche Kleinere Restrukturierungen und Verkürzungen Weitere Visualisierungen hinzugefügt 4 / 58
Lernziele und Kontext Lernziele Software-Visualisierung in einem Reengineering-Kontext Statische Code-Visualisierung Dynamische Code-Visualisierung Visualisierung von Metriken Visualisierung der Evolution Leichtgewichtige Ansätze Kontext Reengineering ist meist interaktiv Große Datenmengen müssen verstanden werden 5 / 58 Definitionen zu Software-Visualisierung Software Visualization is the use of the crafts of typography, graphic design, animation, and cinematography with modern human-computer interaction and computer graphics technology to facilitate both the human understanding and effective use of computer software. Price, Baecker and Small, Introduction to Software Visualization Software is intangible, having no physical shape or size. Software visualisation tools use graphical techniques to make software visible by displaying programs, program artifacts and program behaviour. Thomas Ball 6 / 58
SV im Reengineering-Kontext Ziele: Reduktion der Komplexität Herausforderungen: Skalierbarkeit Aufgabenabhängigkeit der Visualisierung Art der Visualisierung Begrenzte Ressourcen 7 / 58 Programm-Visualisierung Program visualization is the visualization of the actual program code or data structures in either static or dynamic form. [Price, Baecker und Small] Gebiete Statische Programm-Visualisierung Dynamische Programm-Visualisierung Aufgaben Verschiedene Sichten generieren Inferenzen ermöglichen Spezifische Probleme (aktives Forschungsgebiet) Effiziente Ausnutzung des Platzes, Kantenüberschneidungen, Layout-Probleme, Fokus, Human-Computer-Interaction,... Keine Konventionen (Farben, Symbole, Interpretation,... ) Granularität? Ganze System, Subsysteme, Module, Klassen, Hierarchien,... Wofür, wie und wann anzuwenden? 8 / 58
Statische Programm-Visualisierung Visualisierung von Information, die statisch abgeleitet ist. Hängt von Sprache und Sprachparadigma ab: objektorientierte Sprachen: Klassen, Methoden, Attribute, Vererbung,... prozedurale Sprachen: Prozeduren, Aufrufe,...... Mittel: Quellcode Bäume Graphen Metaphern 9 / 58 Visualisierung von Code: SeeSoft (Eick u. a. 1992) 10 / 58
Bäume: Klassen-Hierarchien Jun/OpenGL Smalltalk Klassenhierarchie Probleme: Keine weitere Bedeutung der Farbe Überladen 11 / 58 Bäume Euklidische Kegel Vorteile: Nutzen dritte Dimension Nachteile: Mangelnde Tiefe Navigation Hyperbolische Bäume Vorteile: Fokus ist wählbar Dynamisch Nachteile: Copyright 12 / 58
Ba ume mit Metriken: Tree Maps Vorteile: hierarchisch (m.e.) 100% Raumnutzung skaliert Nachteile: Grenzen Wirres Bild Interpretation Nur Bla tter 13 / 58 Treemap fu r Klone 14 / 58
Ba ume mit Metriken: Tree Maps mit Texturen Quelle: Danny Holten http://www.win.tue.nl/ dholten/ 15 / 58 Klassendiagramme 16 / 58
Klassendiagramme (wie von herkömmlichen CASE-Werkzeugen dargestellt... ) Vorteile: Stellen objektorientierte Konzepte dar Geeignet für kleine Ausschnitte Nachteile: Skalieren nicht Benötigen Filter für relevante Informationen Nur voreingestellte Sichten 17 / 58 Klassendiagramme mit visuellen Attributen Quelle: Alexandru Telea http://www.win.tue.nl/ alext/archiview/ 18 / 58
Klassendiagramme mit Soft Shapes Quelle: Alexandru Telea http://www.win.tue.nl/ alext/archiview/ 19 / 58 Allgemeine Graphen: Rigi Entity-Relationship- Visualisierung generische Präsentation durch typisierte Graphen Probleme: Filterung Navigation Skalierbarkeit 20 / 58
Allgemeine Graphen: Rigi Entities können gruppiert werden Vorteile: Skaliert besser generisch Nachteile: Wenig Programmiersprachensemantik 21 / 58 Gebündelte Kanten Quelle: Danny Holten http://www.win.tue.nl/ dholten/ 22 / 58
Gebu ndelte Kanten Quelle: Danny Holten http://www.win.tue.nl/ dholten/ 23 / 58 Gebu ndelte Kanten mit Metriken 24 / 58
Graphen mit Metriken (Lanza 2003; Lanza und Ducasse 2003) Kombination von Metriken und Software-Visualisierung Graph-Repräsentation Bis zu fünf Metriken bestimmen die Visualisierung der Knoten: Größe (1+2) Farbe/Farbton (3) Position (4+5) Element X Koordinate Relation Y-Koordinate Farbton Höhe Breite 25 / 58 System Complexity View 26 / 58
Method Efficiency Correlation View 27 / 58 Inheritance Classification View 28 / 58
Added: Ganz neue Methoden. Overridden: Ererbt und redefinierte Methoden. Extended: Overridden + Aufruf der gleichen Methode via super (Smalltalk), d.h. Aufruf zur entsprechenden Methode, die überschrieben wurde. Data Storage Class Detection View 29 / 58
Von links nach rechts nach Breite (Number of Methods) geordnet. Dieselbe Metrik (Number of Methods) wird hier auf dreifache Weise dargestellt: Breite, Position innerhalb der Ordnung und Farbe. Dadurch kann ein verstärkender Effekt erzeugt werden. Innereien und Abhängigkeiten 30 / 58
Klassenblaupause (Ducasse und Lanza 2005) 31 / 58 Die Einteilung hängt etwas von der Ausdruckskraft der Programmiersprache ab, auch von dem, was der Benutzer tatsächlich sehen möchte: aus Sicht der Spezifikation bzw. aus Sicht der tatsächlichen Verhältnisse. Initialization: Kontruktoren (soweit die Programmiersprache sie explizit darstellt, auch: Methoden, die Init und ähnliche Zeichenketten im Namen enthalten oder solche, die einen new-operator für die Klasse enthalten Interface: öffentliche Methoden; auch: solche, die tatsächlich von außerhalb aufgerufen werden (Accessors sind in einer anderen Kategorie; siehe unten) Implementation: versteckte Methoden bzw. solche, die von außerhalb nicht benutzt werden Accessors: Öffentliche Methoden, die nichts weiter tun als ein Attribut zu setzen bzw. zu lesen Attribute: versteckte Attribute
Semantische Information Kategorisierung von Klassen Basiert auf Klassenblaupausen Zwei Perspektiven: Einzelne Klasse Vererbungskontext Klassenblaupause für jede einzelne Klasse Sind als Baum angeordnet 32 / 58
Klassenblaupause: Data Storage Viele Attribute Kann viele Zugriffsoperationen haben (Accessors) Harmloses Verhalten 33 / 58 Klassenblaupause: Wide Interface Viele Methoden in der Schnittstelle 34 / 58
Klassenblaupause: Large Implementation Geschachtelte Aufrufstruktur Viele Methoden Hohe Komplexität Breite Schnittstelle 35 / 58 Metaphorische Visualisierung Quelle: Richard Wettel http://www.inf.usi.ch/phd/wettel/codecity-wof.html 36 / 58
Dynamische Programm-Visualisierung Visualisierung dynamischen Verhaltens Ausführungs-Trace Ressourcenverbrauch (Speicher/Laufzeit) Objekt-Interaktion... Schritte: 1 Code-Instrumentierung 2 Gewinnung der Laufzeitinformation 3 Auswertung der Laufzeitinformation 4 Visualisierung der Auswertung 37 / 58 Dynamische SV: Probleme Code-Instrumentierungsproblem Logging, erweiterte Virtual Machines, Method-Wrapping Skalierbarkeitsproblem Fülle der Details Traces werden sehr schnell enorm groß Vollständigkeitsproblem Information gilt nur für betrachtete Szenarien 38 / 58
Beispiel 1: JInsight (http://www.research.ibm.com/jinsight) Visualisierung von Ausführungs-Traces 39 / 58 Visualisiert Sequenzdiagramme; jeder vertikale Streifen repräsentiert ein Objekt; die Farbe des Streifens kodiert die Klasse. Die Zeit schreitet von oben nach unten fort. Aufrufe sind durch Kanten zwischen Objekten dargestellt und haben die aufgerufene Methode als Label. Die zeitlichen Bereiche, in denen ein Objekt tatsächlich aktiv sind (d.h. nicht nur eine andere Methode aufrufen, sondern tatsächlich selbst rechnen), sind im Streifen etwas heller dargestellt. JInsight erlaubt es auch, wiederkehrende Aufrufmuster automatisch zu erkennen und darzustellen. Ähnliche, aber leicht unterschiedliche Muster können dabei übereinandergelegt werden, um so die Unterschiede darzustellen.
Heatmap 40 / 58 Beispiel 2: Aufrufmatrix für Klassen (Heatmap) einfach skaliert reproduzierbar 41 / 58
Inter-Class Call Matrix: This view provides an overview of the communication between classes. The matrix plots which classes call which other classes. Classes are arranged along both axes in the order they are instantiated. The color of the dots indicate the frequency of that communication. Evolutionäre Aspekte Die Gegenwart ist oft verständlicher, wenn man die Vergangenheit kennt. Betrachtung von Aspekten des Systems über die Zeit. Metrikwerte können besser eingeschätzt werden. Erlaubt, Trends auszumachen. 42 / 58
Evolutionsmatrix 43 / 58 Kategorisierung von Klassen anhand der Evolutionsmatrix Dargestellte Metriken für Klassen: NOM (number of methods) NOA (number of attributes) Kategorisierung anhand der individuellen Evolution und der System-Evolution : Pulsar Supernova Weißer Zwerg Roter Riese Dornröschen Eintagsfliege Methusalem 44 / 58
Pulsar Definition Pulsar: wiederholte Änderungen, die Element größer und kleiner werden lassen. System-Hotspot: Jede neue Version verlangt Anpassungen. 45 / 58 Supernova Definition Supernova: Plötzlicher Anstieg. Mögliche Gründe: massive Restrukturierung Datenspeicher für Daten, die plötzlich hinzugekommen sind Schläfer: Stumpf, der mit Funktionalität gefüllt wird 46 / 58
Weißer Zwerg, Roter Riese, Dornröschen 47 / 58 Eintagsfliege & Methusalem 48 / 58
Fallstudie MooseFinder (38 Versionen) 49 / 58 Spektrograph x-achse: Zeit; y-achse: Softwareeinheit; Farbe: #commits 50 / 58
Courtesy Jingwei Wu, Richard C. Holt, Ahmed Hassan, University of Waterloo, Canada Färbung im Spektrograph linearer Gradient exponentieller Gradient Stufen
Evostreets (Steinbrückner 2013) 51 / 58 Quelle der Bilder: Dr. Frank Steinbrückner
Software-Visualisierung (SV) I SV ist unabdingbar im Reengineering-Kontext Match-Mismatch-Hypothese: problem-solving performance depends on whether the structure of a problem is matched by the structure of a notation Gilmore und Green Jede SV betont bestimmte Information und vernachlässigt andere Information. Geeignete SV ist abhängig von der zu lösenden Aufgabe. 54 / 58 Software-Visualisierung (SV) II Alphabetismus der SV Wie drücke ich es aus? Wie interpretiere ich es? Vieles noch in der Forschung, wenig in kommerziellen Werkzeugen Software-Wahrnehmung: Andere menschliche Sinne werden genutzt 55 / 58
Wiederholungs- und Vertiefungsfragen I Wofür eignen sich Tree Maps und wie sind sie zu interpretieren? Welche Probleme gibt es bei der Visualisierung dynamischer Daten? Wie lassen sich Metriken visualisieren? Was ist eine Klassenblaupause? Wie lassen sich damit Klassen charakterisieren? Welche zusätzlichen Aspekte lassen sich durch die Visualisierung evolutionärer Daten gewinnen? Was sagt die Match-Mismatch-Hypothese (Gilmore und Green) aus? 56 / 58 1 Ducasse und Lanza 2005 Ducasse, Stephane ; Lanza, Michele: The Class Blueprint: Visually Supporting the Understanding of Classes. In: IEEE Computer Society Transactions on Software Engineering 31 (2005), Januar, Nr. 1, S. 75 90 2 Eick u. a. 1992 Eick, Stephen G. ; Steffen, Joseph L. ; Sumner, Eric E.: Seesoft A Tool for Visualizing Line Oriented Software Statistics. In: IEEE Computer Society Transactions on Software Engineering 18 (1992), November, S. 957 968 3 Lanza 2003 Lanza, Michele: Object-Oriented Reverse Engineering - Coarse-grained, Fine-grained, and Evolutionary Software Visualization. http://www.inf.unisi.ch/faculty/ lanza/downloads/lanz03b.pdf, University of Bern, Dissertation, 2003 4 Lanza und Ducasse 2003 Lanza, Michele ; Ducasse, Stephane: Polymetric Views A Lightweight Visual Approach to Reverse Engineering. In: IEEE Computer Society Transactions on Software Engineering 29 (2003), Nr. 9, S. 782 795 57 / 58
5 Steinbrückner 2013 Steinbrückner, Frank: Consistent Software Cities Supporting Comprehension of Evolving Software Systems, Brandenburgische Technische Universität Cottbus, Dissertation, 2013 58 / 58