Object-Oriented Reengineering Patterns 3. Software Visualization Selected slides courtesy Tudor Girba

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.2 Roadmap  Introduction  Static Code  Dynamic Code  Packages  Evolution

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.3 Roadmap  Introduction  Static Code  Dynamic Code  Packages  Evolution

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.4 A picture is worth a thousand words 1854, London cholera epidemic

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.5 A picture is worth a thousand words UML took it literally :)

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.6 Software Visualization “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”

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.7 Roadmap  Introduction  Static Code  Dynamic Code  Packages  Evolution

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.8 Class Hierarchies  Jun/OpenGL —The Smalltalk Class Hierarchy  Problems: —Colors are meaningless —Visual Overload

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.9 Tree Maps  Pros —100% screen —Large data —Scales well  Cons —Boundaries —Cluttered display —Interpretation —Leaves only  Useful for the display of HDDs

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.10 More dimensions  Euclidean cones —Pros: – More info than 2D —Cons: – Lack of depth – Navigation  Hyperbolic trees —Pros: – Good focus – Dynamic —Cons: – Copyright

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.11 Polymetric views show up to 5 metrics Color Metric Position Metrics Width Metric Height Metric

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.12 System Complexity View lines attributes methods Lanza & Ducasse 2003, doi.ieeecomputersociety.org/ /TSE

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.13 Class Blueprint InitializeInterfaceInternalAccessorAttribute invocation and access direction Lanza & Ducasse 2003, doi.acm.org/ /

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.14 Class Blueprint has a rich vocabulary Regular Overriding Extending Abstract Constant Delegating Setter Getter Method invocations lines Attribute internal access external access Access Invocation

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.15 Class Blueprint shows class internals

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.16 Roadmap  Introduction  Static Code  Dynamic Code  Packages  Evolution

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.17 Dynamic Code Visualization Visualization of dynamic behaviour of a software system —Code instrumentation —Trace collection —Trace evaluation —What to visualize – Execution trace – Memory consumption – Object interaction – …

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.18 Visualization of Runtime Behavior Problem of Large traces De Pauw et al., 1993, doi.acm.org/ /

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.19 Inter-class call matrix  Simple  Reproducible  Scales well  Excel?

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.20 Mural View  The algorithm takes an image of M x N elements and scales it into a mural of I x J pixels.

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.21 Method Calling Counts

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.22 Evaluation  Entities as objects  Quickly spot the important methods  For complete scenario may be difficult to reproduce  Requires interactivity  Layout can be a problem

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.23 Evaluation  Can handle large amounts of data  Not useful for all kinds of data

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.24 Feature Identification “A feature is an observable unit of behavior of a system triggered by the user” [Eisenbarth etal. 2003] Software Reconnaissance [Wilde and Scully] Run: 1.A feature exhibiting scenario 2.A non-exhibiting scenario Compare the traces. Browse the source code.

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.25 Dividing a trace into features Feature 1 Feature 2 Feature n

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.26 Feature-Centric Analysis: 3 Complementary Perspectives F1 F3 F2 F4 F5 Features Perspective Features Relationships Perspective Classes Perspective

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.27 Feature Views of Phonesim Classes PhoneButtonEventBackSpace PhoneStateContact PhoneStateContactForm EditableText CustomTextArea …

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.28 Feature Views of Phonesim Methods

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.29 Evaluation of dynamic visualization  Code instrumentation problem —Logging, Extended VMs, Method Wrapping, C++ preprocessing is heavy  Scalability problem —Traces quickly become very big (1Mb/s)  Completeness problem: scenario driven  Pros: —Good for fine-tuning, problem detection  Cons: —Tool support crucial —Lack of abstraction without tool support

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.30 Roadmap  Introduction  Static Code  Dynamic Code  Packages  Evolution

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.31 Butterfly Views

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.32 Butterflies

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.33 Evaluation of Butterfly Views  Focus on packages  Entities as objects  Patterns  Shape easily recognisable  Lot of information condensed  Problems with value normalisation

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.34 Sahraoui et al, doi.acm.org/ / Cities

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.35 Boxes = Packages  Height  Color  Twist  2D +

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.37 Evolution

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.38 Evaluation  Interesting use of pseudo-3D  Limited mapping possibility  Good overview  Good spotting facility  Limit of metaphor —Are shanty towns that bad?

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.39 Distribution Map shows properties in an order Ducasse et al., 2006, doi.ieeecomputersociety.org/ /ICSM

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.40 Roadmap  Introduction  Static Code  Dynamic Code  Packages  Evolution

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.41 InfoBug

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.42 Four Classes of Software Data  Head (Type of code)  Wings (Lines of codes, errors)  Body (bar - file changes, Spots - number of subsystems)  Tails (added, removed lines)

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.43 Evaluation  Pros: —Large datasets in small space —Entities as objects —Easy to recognize patterns —Trends identification —Easy to compare and analyze —Interactive  Cons: —Learning (but is there something we should not learn?) —Main focus on Error/Loc ratio —Could include more information

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.44 The Evolution Matrix

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.45 Dayfly & Persistent Dayflies: Exists during only one or two versions. Perhaps an idea which was tried out and then dropped. Persistent: Has the same lifespan as the whole system. Part of the original design. Perhaps holy dead code which no one dares to remove.

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.46 Pulsar & Supernova Pulsar: Repeated Modifications make it grow and shrink. System Hotspot: Every System Version requires changes. Supernova: Sudden increase in size. Possible Reasons: Massive shift of functionality towards a class. Data holder class for which it is easy to grow. Sleeper: Developers knew exactly what to fill in.

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.47 White Dwarf, Red Giant, Idle White Dwarf: Lost the functionality it had and now trundles along without real meaning. Possibly dead code. Red Giant: A permanent god class which is always very large. Idle: Keeps size over several versions. Possibly dead code, possibly good code.

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.48 Example: MooseFinder (38 Versions)

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.49 Evaluation  Easy to draw  Scalable via other grouping entities (packages)  Good overview of history  Limit of the metaphor…

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.50 What happens with inheritance?

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.51 History contains too much data

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.52 History contains too much data A is persistent, B is stable, C was removed, E is newborn...

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.53 Hierarchy Evolution encapsulates time A is persistent, B is stable, C was removed, E is newborn... age changed methods changed lines Removed Girba et al., 2005, doi.ieeecomputersociety.org/ /CSMR

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.54 Hierarchy Evolution View reveals patterns

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.55 Example: CVS shows activity

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.56 Who did this?

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.57 Alphabetical order is no order Kuhn

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.58 Ownership Map orders histories Girba et al., 2005, doi.ieeecomputersociety.org/ /IWPSE

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.59 (john ) public boolean stillValid (ToDoItem I, Designer dsgr) { (bill ) if (!isActive()) { (bill ) return false (bill ) } (steve ) List offs = i.getOffenders(); (john ) Object dm = offs.firstElement(); (steve ) ListSet newOffs = computeOffenders(dm); (john ) boolean res = offs.equals(newOffs); (john ) return res; (john ) public boolean stillValid (ToDoItem I, Designer dsgr) { (bill ) if (!isActive()) { (bill ) return false (bill ) } (steve ) List offs = i.getOffenders(); (john ) Object dm = offs.firstElement(); (steve ) ListSet newOffs = computeOffenders(dm); (john ) boolean res = offs.equals(newOffs); (john ) return res; (george ) public boolean stillValid (ToDoItem I, Designer dsgr) { (bill ) if (!isActive()) { (bill ) return false (bill ) } (steve ) List offs = i.getOffenders(); (george ) Object dm = offs.firstElement(); (steve ) ListSet newOffs = computeOffenders(dm); (george ) boolean res = offs.equals(newOffs); (george ) return res; (george ) public boolean stillValid (ToDoItem I, Designer dsgr) { (bill ) if (!isActive()) { (bill ) return false (bill ) } (steve ) List offs = i.getOffenders(); (george ) Object dm = offs.firstElement(); (steve ) ListSet newOffs = computeOffenders(dm); (george ) boolean res = offs.equals(newOffs); (george ) return res; Example: Who duplicated the code?

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.60 (john ) public boolean stillValid (ToDoItem I, Designer dsgr) { (bill ) if (!isActive()) { (bill ) return false (bill ) } (steve ) List offs = i.getOffenders(); (john ) Object dm = offs.firstElement(); (steve ) ListSet newOffs = computeOffenders(dm); (john ) boolean res = offs.equals(newOffs); (john ) return res; (john ) public boolean stillValid (ToDoItem I, Designer dsgr) { (bill ) if (!isActive()) { (bill ) return false (bill ) } (steve ) List offs = i.getOffenders(); (john ) Object dm = offs.firstElement(); (steve ) ListSet newOffs = computeOffenders(dm); (john ) boolean res = offs.equals(newOffs); (john ) return res; (george ) public boolean stillValid (ToDoItem I, Designer dsgr) { (bill ) if (!isActive()) { (bill ) return false (bill ) } (steve ) List offs = i.getOffenders(); (george ) Object dm = offs.firstElement(); (steve ) ListSet newOffs = computeOffenders(dm); (george ) boolean res = offs.equals(newOffs); (george ) return res; (george ) public boolean stillValid (ToDoItem I, Designer dsgr) { (bill ) if (!isActive()) { (bill ) return false (bill ) } (steve ) List offs = i.getOffenders(); (george ) Object dm = offs.firstElement(); (steve ) ListSet newOffs = computeOffenders(dm); (george ) boolean res = offs.equals(newOffs); (george ) return res; What is useless?

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization public boolean stillValid (ToDoItem I, Designer dsgr) { if (!isActive()) { return false } List offs = i.getOffenders(); Object dm = offs.firstElement(); ListSet newOffs = computeOffenders(dm); boolean res = offs.equals(newOffs); return res; public boolean stillValid (ToDoItem I, Designer dsgr) { if (!isActive()) { return false } List offs = i.getOffenders(); Object dm = offs.firstElement(); ListSet newOffs = computeOffenders(dm); boolean res = offs.equals(newOffs); return res; public boolean stillValid (ToDoItem I, Designer dsgr) { if (!isActive()) { return false } List offs = i.getOffenders(); Object dm = offs.firstElement(); ListSet newOffs = computeOffenders(dm); boolean res = offs.equals(newOffs); return res; public boolean stillValid (ToDoItem I, Designer dsgr) { if (!isActive()) { return false } List offs = i.getOffenders(); Object dm = offs.firstElement(); ListSet newOffs = computeOffenders(dm); boolean res = offs.equals(newOffs); return res; When did changes happen?

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.62 Clone Evolution shows how developers copy Balint et al., doi.ieeecomputersociety.org/ /ICPC

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz ASWEC 2007, Melbourne — OORP Tutorial — Software Visualization 3.63 License > Attribution-ShareAlike 2.5 You are free: to copy, distribute, display, and perform the work to make derivative works to make commercial use of the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. Attribution-ShareAlike 2.5 You are free: to copy, distribute, display, and perform the work to make derivative works to make commercial use of the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above.