Prof. Dr. Rainer Koschke · Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe...

Vorlesung Software-Reengineering

Prof. Dr. Rainer Koschke

Arbeitsgruppe SoftwaretechnikFachbereich Mathematik und Informatik

Universitat Bremen

Wintersemester 2009/10

Uberblick I

1 Software-Visualisierung

Software-Visualisierung

Software-Visualisierung I

1 Software-VisualisierungUber diese FolienLernzieleReengineering KontextProgramm-VisualisierungStatische Programm-VisualisierungDynamische Programm-VisualisierungVisualisierung von MetrikenKlassenblaupauseEvolutionare AspekteZusammenfassungWiederholungsfragen

Rainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/2010 3 / 52


Uber diese Folien

Diese Folien entstammen einer Prasentation von Michele Lanza(Universitat Lugano), mit dessen freundlicher Genehmigung.Die Unterschiede zum Original sind:

Ubersetzung ins Deutsche

Kleinere Restrukturierungen und Verkurzungen

Weitere Visualisierungen hinzugefugt



Software-Visualisierung I

Lernziele

Software-Visualisierung in einem Reengineering-KontextStatische Code-VisualisierungDynamische Code-VisualisierungVisualisierung von MetrikenVisualisierung der EvolutionLeichtgewichtige Ansatze

Kontext

Reengineering ist meist interaktivGroße Datenmengen mussen verstanden werden



Software-Visualisierung II

Software Visualization is the use of the crafts of typography,graphic design, animation, and cinematography with modernhuman-computer interaction and computer graphics technologyto facilitate both the human understanding and effective use ofcomputer 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 makesoftware visible by displaying programs, program artifacts andprogram behaviour.

– Thomas BallRainer Koschke (Univ. Bremen) Vorlesung Software-Reengineering WS 2009/2010 6 / 52


SV im Reengineering-Kontext

Ziele: Reduktion der Komplexitat

Herausforderungen:

SkalierbarkeitAufgabenabhangigkeit der VisualisierungArt der VisualisierungBegrenzte Ressourcen



Programm-Visualisierung

Program visualization is the visualization of the actualprogram code or data structures in either static or dynamic form.

– [Price, Baecker und Small]

GebieteStatische Programm-VisualisierungDynamische Programm-Visualisierung

AufgabenVerschiedene Sichten generierenInferenzen ermoglichen

Spezifische Probleme (aktives Forschungsgebiet)Effiziente Ausnutzung des Platzes, Kantenuberschneidungen,Layout-Probleme, Fokus, Human-Computer-Interaction, . . .Keine Konventionen (Farben, Symbole, Interpretation, . . . )

Granularitat?Ganze System, Subsysteme, Module, Klassen, Hierarchien,...

Wofur, wie und wann anzuwenden?



Statische Programm-Visualisierung

Visualisierung von Information, die statisch abgeleitet ist.

Hangt von Sprache und Sprachparadigma ab:

objektorientierte Sprachen: Klassen, Methoden, Attribute, Vererbung,. . .prozedurale Sprachen: Prozeduren, Aufrufe, . . .. . .



Klassendiagramme



Klassendiagramme

(wie von herkommlichen CASE-Werkzeugen dargestellt. . . )

Vorteile:

Stellen objektorientierte Konzepte darGeeignet fur kleine Ausschnitte

Nachteile:

Skalieren nichtBenotigen Filter fur relevante InformationenNur voreingestellte Sichten



Klassendiagramme mit visuellen Attributen

– Quelle: Alexandru Teleahttp://www.win.tue.nl/~alext/ARCHIVIEW/


http://www.win.tue.nl/~alext/ARCHIVIEW/


Klassendiagramme mit Soft Shapes

– Quelle: Alexandru Teleahttp://www.win.tue.nl/~alext/ARCHIVIEW/


http://www.win.tue.nl/~alext/ARCHIVIEW/


Allgemeine Graphen: Rigi

Entity-Relationship-Visualisierung

generische Prasentationdurch typisierte Graphen

Probleme:

FilterungNavigationSkalierbarkeit



Allgemeine Graphen: Rigi

Entities konnen gruppiertwerden

Vorteile:

Skaliert bessergenerisch

Nachteile:

Wenig Programmier-sprachensemantik



Gebundelte Kanten

– Quelle: Danny Holten http://www.win.tue.nl/~dholten/


http://www.win.tue.nl/~dholten/


Gebundelte Kanten





Baume: Klassen-Hierarchien

Jun/OpenGL

SmalltalkKlassenhierarchie

Probleme:

Keine weitereBedeutung der FarbeUberladen



Baume mit Metriken: Tree Maps

Vorteile:

hierarchisch (m.E.)100% Raumnutzungskaliert

Nachteile:

GrenzenWirres BildInterpretationNur Blatter



Baume mit Metriken: Tree Maps mit Texturen





Baume

Euklidische KegelVorteile:

Nutzen dritteDimension

Nachteile:

Mangelnde TiefeNavigation

Hyperbolische BaumeVorteile:

Fokus ist wahlbarDynamisch

Nachteile: Copyright



Metaphorische Visualisierung

– Quelle: Richard Wettelhttp://www.inf.usi.ch/phd/wettel/codecity-wof.html


http://www.inf.usi.ch/phd/wettel/codecity-wof.html


Dynamische Programm-Visualisierung

Visualisierung dynamischen Verhaltens

Ausfuhrungs-TraceRessourcenverbrauch (Speicher/Laufzeit)Objekt-Interaktion. . .

Schritte:1 Code-Instrumentierung2 Gewinnung der Laufzeitinformation3 Auswertung der Laufzeitinformation4 Visualisierung der Auswertung



Beispiel 1: JInsight(http://www.research.ibm.com/jinsight)

Visualisierung von Ausfuhrungs-Traces


http://www.research.ibm.com/jinsight

Visualisiert Sequenzdiagramme; jeder vertikale Streifen reprasentiert ein Objekt; die Farbe des Streifens kodiert dieKlasse. Die Zeit schreitet von oben nach unten fort. Aufrufe sind durch Kanten zwischen Objekten dargestellt undhaben die aufgerufene Methode als Label. Die zeitlichen Bereiche, in denen ein Objekt tatsachlich aktiv sind (d.h.nicht nur eine andere Methode aufrufen, sondern tatsachlich selbst rechnen), sind im Streifen etwas hellerdargestellt.JInsight erlaubt es auch, wiederkehrende Aufrufmuster automatisch zu erkennen und darzustellen. Ahnliche, aberleicht unterschiedliche Muster konnen dabei ubereinandergelegt werden, um so die Unterschiede darzustellen.


Beispiel 2: Aufrufmatrix fur Klassen

einfach

skaliert

reproduzierbar


Inter-Class Call Matrix: This view provides an overview of the communication between classes. The matrix plotswhich classes call which other classes. Classes are arranged along both axes in the order they are instantiated. Thecolor of the dots indicate the frequency of that communication.


Dynamische SV: Probleme

Code-Instrumentierungsproblem

Logging, erweiterte Virtual Machines, Method-Wrapping

Skalierbarkeitsproblem

Fulle der DetailsTraces werden sehr schnell enorm groß

Vollstandigkeitsproblem

Information gilt nur fur betrachtete Szenarien



Visualisierung von Metriken (Lanza 2003; Lanza undDucasse 2003)

Kombination von Metriken undSoftware-Visualisierung

Graph-ReprasentationBis zu funf Metrikenbestimmen die Visualisierungder Knoten:

Große (1+2)Farbe/Farbton (3)Position (4+5)

X−Koordinate Relation

Element

Y-KoordinateFarbton Hohe

Breite



System Complexity View



Method Efficiency Correlation View



Inheritance Classification View


Added: Ganz neue Methoden.Overridden: Ererbt und redefinierte Methoden.Extended: Overridden + Aufruf der gleichen Methode via super (Smalltalk), d.h. Aufruf zur entsprechendenMethode, die uberschrieben wurde.


Data Storage Class Detection View


Von links nach rechts nach Breite (Number of Methods) geordnet.Dieselbe Metrik (Number of Methods) wird hier auf dreifache Weise dargestellt: Breite, Position innerhalb derOrdnung und Farbe. Dadurch kann ein verstarkender Effekt erzeugt werden.


Granularitatsproblem

Hubsch . . . aber was verbirgt sich dahinter?



Klassenblaupause (Ducasse und Lanza 2005)


Die Einteilung hangt etwas von der Ausdruckskraft der Programmiersprache ab, auch von dem, was der Benutzertatsachlich sehen mochte: aus Sicht der Spezifikation bzw. aus Sicht der tatsachlichen Verhaltnisse.

• Initialization: Kontruktoren (soweit die Programmiersprache sie explizit darstellt, auch: Methoden, die Init und ahnlicheZeichenketten im Namen enthalten oder solche, die einen new-Operator fur die Klasse enthalten

• Interface: offentliche Methoden; auch: solche, die tatsachlich von außerhalb aufgerufen werden (Accessors sind in eineranderen Kategorie; siehe unten)

• Implementation: versteckte Methoden bzw. solche, die von außerhalb nicht benutzt werden

• Accessors: Offentliche Methoden, die nichts weiter tun als ein Attribut zu setzen bzw. zu lesen

• Attribute: versteckte Attribute


Semantische Information



Kategorisierung von Klassen

Basiert aufKlassenblaupausen

Zwei Perspektiven:

Einzelne KlasseVererbungskontext

Klassenblaupausefur jede einzelneKlasseSind als Baumangeordnet



Klassenblaupause: Data Storage

Viele Attribute

Kann vieleZugriffsoperationen haben(Accessors)

Harmloses Verhalten



Klassenblaupause: Wide Interface

Viele Methoden in derSchnittstelle



Klassenblaupause: Large Implementation

GeschachtelteAufrufstruktur

Viele Methoden

Hohe Komplexitat

Breite Schnittstelle



Evolutionare Aspekte (Lanza 2003)

Die Gegenwart ist oft verstandlicher, wenn man die Vergangenheitkennt.

Betrachtung von Aspekten des Systems uber die Zeit.

Metrikwerte konnen besser eingeschatzt werden.Erlaubt, Trends auszumachen.



Evolutionsmatrix



Kategorisierung von Klassen anhand der Evolutionsmatrix

Dargestellte Metriken fur Klassen:

NOM (number of methods)NOA (number of attributes)

Kategorisierung anhand der”individuellen Evolution“ und der

”System-Evolution“:

PulsarSupernovaWeißer ZwergRoter RieseDornroschenEintagsfliegeMethusalem



Pulsar

Definition

Pulsar: wiederholte Anderungen, die Element großer und kleiner werdenlassen.→ System-Hotspot: Jede neue Version verlangt Anpassungen.



Supernova

Definition

Supernova: Plotzlicher Anstieg. Mogliche Grunde:

massive Restrukturierung

Datenspeicher fur Daten, die plotzlich hinzugekommen sind

Schlafer: Stumpf, der mit Funktionalitat gefullt wird



Weißer Zwerg, Roter Riese, Dornroschen



Eintagsfliege & Methusalem



Fallstudie MooseFinder (38 Versionen)



Spektrograph

x-Achse: Zeit; y-Achse: Softwareeinheit; Farbe: #commits


Courtesy Jingwei Wu, Richard C. Holt, Ahmed Hassan, University of Waterloo, Canada


Farbung im Spektrograph

linearer Gradient

exponentieller Gradient

Stufen



Software-Visualisierung (SV) I

SV ist unabdingbar im Reengineering-Kontext

Match-Mismatch-Hypothese:

problem-solving performance depends on whether thestructure of a problem is matched by the structure of anotation

– Gilmore und Green

Jede SV betont bestimmte Information und vernachlassigt andereInformation.

Geeignete SV ist abhangig von der zu losenden Aufgabe.



Software-Visualisierung (SV) II

”Alphabetismus“ der SV

Wie drucke ich es aus?

Wie interpretiere ich es?

Vieles noch in der Forschung, wenig in kommerziellen Werkzeugen

Software-Wahrnehmung: Andere menschliche Sinne werden genutzt



Wiederholungs- und Vertiefungsfragen I

Wofur 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 zusatzlichen Aspekte lassen sich durch die Visualisierungevolutionarer Daten gewinnen?

Was sagt die Match-Mismatch-Hypothese (Gilmore und Green) aus?



1 Ducasse und Lanza 2005 Ducasse, Stephane ; Lanza, Michele: TheClass Blueprint: Visually Supporting the Understanding of Classes. In:IEEE Computer Society Transactions on Software Engineering 31(2005), Januar, Nr. 1, S. 75–90

2 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

3 Lanza und Ducasse 2003 Lanza, Michele ; Ducasse, Stephane:Polymetric Views—A Lightweight Visual Approach to ReverseEngineering. In: IEEE Computer Society Transactions on SoftwareEngineering 29 (2003), Nr. 9, S. 782–795


http://www.inf.unisi.ch/faculty/lanza/Downloads/Lanz03b.pdf

http://www.inf.unisi.ch/faculty/lanza/Downloads/Lanz03b.pdf

Prof. Dr. Rainer Koschke · Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe...

Documents

Transcript of Prof. Dr. Rainer Koschke · Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe...