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

Object-Oriented Reengineering Patterns

3. Software Visualization

Selected slides courtesy Tudor GirbaSelected 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



3.3

Roadmap




3.4

A picture is worth a thousand words

1854, London cholera epidemic



3.5

A picture is worth a thousand words

UML took it literally :)UML took it literally :)



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”



3.7

Roadmap




3.8

Class Hierarchies

> Jun/OpenGL —The Smalltalk Class Hierarchy

> Problems:— Colors are meaningless— Visual Overload



3.9

Tree Maps

> Pros—100% screen—Large data—Scales well

> Cons—Boundaries—Cluttered display—Interpretation—Leaves only

> Useful for the display of HDDs



3.10

More dimensions

> Euclidean cones—Pros:

– More info than 2D

—Cons: – Lack of depth– Navigation

> Hyperbolic trees—Pros:

– Good focus– Dynamic

—Cons: – Copyright



3.11

Polymetric views show up to 5 metrics

ColorMetric

PositionMetrics

Width Metric

Height Metric



3.12

System Complexity View

lines

attributes

methods

Lanza & Ducasse 2003, doi.ieeecomputersociety.org/10.1109/TSE.2003.1232284Lanza & Ducasse 2003, doi.ieeecomputersociety.org/10.1109/TSE.2003.1232284



3.13

Class Blueprint

Initialize Interface Internal Accessor Attribute

invocation and access direction

Lanza & Ducasse 2003, doi.acm.org/10.1145/504282.504304Lanza & Ducasse 2003, doi.acm.org/10.1145/504282.504304



3.14

Class Blueprint has a rich vocabulary

Regular

Overriding

Extending

Abstract

Constant

Delegating

Setter

Getter

Method

invocations

lines

Attribute

internal access

externalaccess

Access

Invocation



3.15

Class Blueprint shows class internals



3.16

Roadmap




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



3.18

Visualization of Runtime Behavior

Problem of

Large traces

De Pauw et al., 1993, doi.acm.org/10.1145/165854.165919De Pauw et al., 1993, doi.acm.org/10.1145/165854.165919



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.



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 scenario2. A non-exhibiting scenario

• Compare the traces. • Browse the source code.



3.25

Dividing a trace into features

Feature 1 Feature 2 Feature n



3.26

Feature-Centric Analysis:3 Complementary Perspectives

F1

F3

F2

F4

F5

Features Perspective

Features RelationshipsPerspective

Classes Perspective



3.27

Feature Views of Phonesim Classes

PhoneButtonEventBackSpace

PhoneStateContactPhoneStateContactFormEditableTextCustomTextArea…



3.28

Feature Views of Phonesim Methods



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



3.30

Roadmap




3.31

Butterfly Views



3.32

Butterflies



3.33

Evaluation of Butterfly Views

> Focus on packages> Entities as objects> Patterns> Shape easily recognisable> Lot of information condensed> Problems with value normalisation



3.34

Sahraoui et al, doi.acm.org/10.1145/1101908.1101941Sahraoui et al, doi.acm.org/10.1145/1101908.1101941

Cities



3.35

Boxes = Packages

> Height> Color> Twist

> 2D +



3.37

Evolution



3.38

Evaluation

> Interesting use of pseudo-3D> Limited mapping possibility> Good overview> Good spotting facility

> Limit of metaphor— Are shanty towns that bad?



3.39

Distribution Map shows properties in an order

Ducasse et al., 2006, doi.ieeecomputersociety.org/10.1109/ICSM.2006.22Ducasse et al., 2006, doi.ieeecomputersociety.org/10.1109/ICSM.2006.22



3.40

Roadmap




3.44

The Evolution Matrix

Last Version

First Version

Major Leap

Removed Classes

TIME (Versions)

Growth Stabilisation

Added Classes



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.



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.



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.



3.48

Example: MooseFinder (38 Versions)



3.49

Evaluation

> Easy to draw> Scalable via other grouping entities (packages)> Good overview of history> Limit of the metaphor…



3.50

What happens with inheritance?



3.52

History contains too much data

A is persistent, B is stable, C was removed, E is newborn ...



3.53

Hierarchy Evolution encapsulates time

A is persistent, B is stable, C was removed, E is newborn ...

age

changedmethods

changedlines

Removed

Removed

Girba et al., 2005, doi.ieeecomputersociety.org/10.1109/CSMR.2005.15Girba et al., 2005, doi.ieeecomputersociety.org/10.1109/CSMR.2005.15



3.54

Hierarchy Evolution View reveals patterns



3.58

Ownership Map orders histories

Girba et al., 2005, doi.ieeecomputersociety.org/10.1109/IWPSE.2005.21Girba et al., 2005, doi.ieeecomputersociety.org/10.1109/IWPSE.2005.21



3.59

(john 23.06.03) public boolean stillValid (ToDoItem I, Designer dsgr) {(bill 09.01.05) if (!isActive()) {(bill 09.01.05) return false(bill 09.01.05) }(steve 16.02.05) List offs = i.getOffenders();(john 23.06.03) Object dm = offs.firstElement();(steve 16.02.05) ListSet newOffs = computeOffenders(dm);(john 23.06.03) boolean res = offs.equals(newOffs);(john 23.06.03) return res;


(george 13.02.05) public boolean stillValid (ToDoItem I, Designer dsgr) {(bill 11.13.05) if (!isActive()) {(bill 11.13.05) return false(bill 11.13.05) }(steve 16.02.05) List offs = i.getOffenders();(george 13.02.05) Object dm = offs.firstElement();(steve 16.02.05) ListSet newOffs = computeOffenders(dm);(george 13.02.05) boolean res = offs.equals(newOffs);(george 13.02.05) return res;


Example: Who duplicated the code?



3.60





What is useless?



3.61

13.02.05 public boolean stillValid (ToDoItem I, Designer dsgr) {11.13.05 if (!isActive()) {11.13.05 return false11.13.05 }16.02.05 List offs = i.getOffenders();13.02.05 Object dm = offs.firstElement();16.02.05 ListSet newOffs = computeOffenders(dm);13.02.05 boolean res = offs.equals(newOffs);13.02.05 return res;




When did changes happen?



3.62

Clone Evolution shows how developers copy

Balint et al., doi.ieeecomputersociety.org/10.1109/ICPC.2006.25Balint et al., doi.ieeecomputersociety.org/10.1109/ICPC.2006.25

Documents

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