OORPT
Object-Oriented Reengineering Patterns
and Techniques
5. Software Visualization
Prof. O. Nierstrasz
OORPT — Software Visualization
Roadmap
>
Introduction
— SV in a Reengineering Context
>
Static Code Visualization
— Examples
>
Dynamic Code Visualization
— Examples
Understanding Packages
> Understanding Evolution
> Conclusion
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.2
OORPT — Software Visualization
Roadmap
>
Introduction
— SV in a Reengineering Context
>
Static Code Visualization
— Examples
>
Dynamic Code Visualization
— Examples
Understanding Packages
> Understanding Evolution
> Conclusion
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.3
OORPT — Software Visualization
Program Visualization
> Reduction of complexity
> Generate different views on software system
> Visualization is powerful. But
—Can be complex (active research area),
– Efficient space use, crossing edges, focus...
—Colors are nice but there is no convention
—Nice pictures do not imply valuable information
—Where to look? What is important?
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.4
OORPT — Software Visualization
A Bit of Vocabulary
>
Visualization
— Information Visualization
>
Software Visualization
— Algorithm Visualization
— Program Visualization
–
–
>
Static Code Visualization
Dynamic Code Visualization
The overall goal is to reduce complexity
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.5
OORPT — Software Visualization
(Information) Visualization
> Bertin assessed three levels of questions
— Lower perception (one element)
— Medium perception (several elements)
— Upper perception (all elements/the complete picture)
> In Information Visualization it’s all about the reduction of
complexity
> Information Collection
> What to visualize
> How to visualize
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.6
OORPT — Software Visualization
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”
2 main fields:
— Algorithm Visualization
— Program Visualization
The main conceptual problem:
“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]
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.7
OORPT — Software Visualization
In a Reengineering Context
> Work on old systems, dialects
> New tools are not processing your (C++) dialect
> Approaches
—Scalability is crucial
—Efficient (time/information obtained)
—Need a clear focus
> Solutions
—Minimize tools support
—Use existing proven tools (Rigi, CodeCrawler, Jinsight)
—Do it yourself but simple thing first
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.8
OORPT — Software Visualization
The Reengineering Life-cycle
(0) requirement
analysis
Requirements
(2) problem
detection
Designs
(1) model
capture
(3) problem
resolution
(2) problem detection
issues
• Tool support
• Scalability
• Efficiency
Code
(4) program transformation
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.9
OORPT — Software Visualization
Program Visualization
“Program visualization is the visualization of the actual program
code or data structures in either static or dynamic form”
[Price, Baecker and Small]
Static code visualization
> Dynamic code visualization
> Generate different views of a system and infer knowledge based on
the views
> Complex problem domain (current research area)
>
— Efficient space use, edge crossing problem, layout problem, focus, HCI
issues, GUI issues, …
— Lack of conventions (colors, symbols, interpretation, …)
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.10
OORPT — Software Visualization
Program Visualization II
>
Level of granularity?
— Complete systems, subsystems, modules, classes,
hierarchies,...
>
When to apply?
— First contact with a unknown system
— Known/unknown parts?
— Forward engineering?
>
Methodology?
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.11
OORPT — Software Visualization
Roadmap
>
Introduction
— SV in a Reengineering Context
>
Static Code Visualization
— Examples
>
Dynamic Code Visualization
— Examples
Understanding Packages
> Understanding Evolution
> Conclusion
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.12
OORPT — Software Visualization
Static Code Visualization
> The visualization of information that can be extracted
from the static structure of a software system
> Depends on the programming language and paradigm:
— Object-Oriented PL:
– classes, methods, attributes, inheritance, …
— Procedural PL:
– procedures, invocations, …
—…
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.13
OORPT — Software Visualization
Example 1: Class Hierarchies
Jun/OpenGL
> The Smalltalk Class
Hierarchy
> Problems:
>
— Colors are
meaningless
— Visual Overload
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.14
OORPT — Software Visualization
Example 2: 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
5.15
OORPT — Software Visualization
Examples 3 & 4
> 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
5.16
OORPT — Software Visualization
Kind of Code Maps
>
>
>
>
>
From Marcus,Feng, Maletic Software Visualization’03
Simple
Overview
File-based
One “Dot” = one line
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.17
OORPT — Software Visualization
Nesting
Level
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.18
OORPT — Software Visualization
Control Flow
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.19
OORPT — Software Visualization
Evaluation
Simple to draw
> Good overview
> Limited semantics
> Patterns difficult to identify because of line breaks
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.20
OORPT — Software Visualization
One Case for 3D
>
Most of the time
3D is not worth
the trouble but…
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.21
OORPT — Software Visualization
Usual Problems with 3D
No spatial semantics (is above better than below?)
> Scalability
> Extra effort
> Space localization
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.22
OORPT — Software Visualization
Quantitative Information
>
3D useful for quantitative information
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.23
OORPT — Software Visualization
Accessing Hidden Information
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.24
OORPT — Software Visualization
Evaluation
Worthwhile for representing quantitative information
> Spatial information is not really sexy
> Requires more work
> Requires more tooling
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.25
OORPT — Software Visualization
Class Diagram Approaches
> For example UML diagrams…
> Pros:
— OO Concepts
— Good for small parts
> Cons:
— Lack of scalability
— Require tool support
— Requires mapping rules to reduce noise
— Preconceived views
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.26
OORPT — Software Visualization
Class Diagram Examples
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.27
OORPT — Software Visualization
Example 5a: Rigi
> Scalability
problem
> EntityRelationship
visualization
> Problems:
—Filtering
—Navigation
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.28
OORPT — Software Visualization
Example 5b: Rigi
Entities can be grouped
> Pros:
>
— Scales well
— Applicable in other
domains
>
Cons:
— Not enough code
semantics
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.29
OORPT — Software Visualization
Evaluation
>
Pros
— Intuitive approaches
— Aesthetically pleasing results
>
Cons
— Several approaches are orthogonal to each other
— Too easy to produce meaningless results
— Scaling up is sometimes possible, however at the expense of
semantics
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.30
OORPT — Software Visualization
Roadmap
>
Introduction
— SV in a Reengineering Context
>
Static Code Visualization
— Examples
>
Dynamic Code Visualization
— Examples
Understanding Packages
> Understanding Evolution
> Conclusion
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.31
OORPT — Software Visualization
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
5.32
OORPT — Software Visualization
Example 1: JInsight
>
Visualization of execution trace
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.33
OORPT — Software Visualization
Example 2: Inter-class call matrix
> Simple
> Reproducible
> Scales well
> Excel?
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.34
OORPT — Software Visualization
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
5.35
OORPT — Software Visualization
The Algorithm
1) for each i,j set mural_array[i][j] to zero
2) for each element m,n of information
a) compute x = m / M * I, y = n / N * J
b) determine the proportion of this point that lies in each of the
four surrounding mural_array entries (totals to 1.0):
mural_array[floor(x)][floor(y)]
mural_array[floor(x)][ceil(y)]
mural_array[ceil(x)][floor(y)]
mural_array[ceil(x)][ceil(y)]
c) add each of the proportions determined in the previous step to
the existing values of each corresponding mural_array entry
i) update max_mural_array_value to keep track of the maximum
mural_array[][] value
3) for each i,j in the mural_array
a) map the value mural_array[i][j] / max_mural_array_value to a
grayscale or color intensity varying scale, or to pixel size, depending
on the type of mural being created
b) color and draw the pixel at i,j of the mural based on mapping
computed in the previous step
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.36
OORPT — Software Visualization
Class View
>
Smith, Munro, Runtime Visualization of Object Oriented
Software, Vissoft 02
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.37
OORPT — Software Visualization
A Class
>
Methods/#invocation
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.38
OORPT — Software Visualization
Method Calling Counts
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.39
OORPT — Software Visualization
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
5.40
OORPT — Software Visualization
Evaluation
Can handle large amounts of data
> Not useful for all kinds of data
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.41
OORPT — Software Visualization
Dynamic SV: Evaluation
> 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
5.42
OORPT — Software Visualization
Roadmap
>
Introduction
— SV in a Reengineering Context
>
Static Code Visualization
— Examples
>
Dynamic Code Visualization
— Examples
Understanding Packages
> Understanding Evolution
> Conclusion
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.43
OORPT — Software Visualization
Butterfly for Package
Important: first level of structure
> Package are complex entities
>
— Not always have to be cohesive (subclasses of a framework
grouped together)
— Team-oriented
— Contain intent of structure and deployment
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.44
OORPT — Software Visualization
Butterfly View
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.45
OORPT — Software Visualization
Butterflies
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.46
OORPT — Software Visualization
Evaluation
>
>
>
>
>
>
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
5.47
OORPT — Software Visualization
Cities
>
Houari et al
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.48
OORPT — Software Visualization
Boxes = Packages
Height
> Color
> Twist
>
>
2D +
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.49
OORPT — Software Visualization
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.50
OORPT — Software Visualization
Evolution
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.51
OORPT — Software Visualization
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
5.52
OORPT — Software Visualization
Roadmap
>
Introduction
— SV in a Reengineering Context
>
Static Code Visualization
— Examples
>
Dynamic Code Visualization
— Examples
Understanding Packages
> Understanding Evolution
> Conclusion
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.53
OORPT — Software Visualization
Understanding Evolution
Information is in the history!
> Overwhelming complexity
> How can we detect and understand changes?
> Solutions:
>
— Revision Towers
— TimeWheel, Infobug
— The Evolution Matrix
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.54
OORPT — Software Visualization
Revision Tower
> Taylor, Munro, Revision Towers, Vissoft02
> Past is at the bottom
> Middle section represents release
> Side section represents history
> Here .c files compared with .h files
> Authors are color typed
> File changed often: lots of rectangle inside a release
period
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.55
OORPT — Software Visualization
Revision Tower (II)
Simple
> Entire file
> File based
> Few information revealed
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.56
OORPT — Software Visualization
Definitions
>
Glyph: A symbol, such as a stylized figure or arrow on a
public sign, that imparts information nonverbally.
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.57
OORPT — Software Visualization
How can we represent time?
>
Animation?
— Good for easily perceived outliers
>
Time Series graph?
— Good for comparing trends
>
Timewheel
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.58
OORPT — Software Visualization
TimeWheel (1)
Displays trends for a number of attributes at a time
> Maintain “Objectedness”
through Gestalt
principals
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.59
OORPT — Software Visualization
Timewheel (II)
Multiple time series ordered in a circle
> Data attributes are color coded
> Easy recognition of two trends
>
— Increasing trend
— Tapering trend
>
Helps to examine different trends within one object
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.60
OORPT — Software Visualization
Time Series Problems
>
In row
— More time to spot them
— Less local patterns
>
In circle
— Weakens reading order implications
— Rotation invariant
>
Example
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.61
OORPT — Software Visualization
InfoBug
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.62
OORPT — Software Visualization
Infobug
>
>
>
>
>
Look like an insect
Show many properties while still maintaining
“objectedness”
Certain patterns preattentively pop out
Interactive
Represent four classes of software data
— Code lines, errors (wings)
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.63
OORPT — Software Visualization
4 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
5.64
OORPT — Software Visualization
Infobug Wings
Time series
> Lines of code vs. Lines of Errors
> Red line is current selection
(update other aspects)
> Code quality
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.65
OORPT — Software Visualization
Infobug Head
Different types of code
> Type is color coded
> Relative size is shown by antenna length
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.66
OORPT — Software Visualization
Infobug Tail
Triangle shaped
> Number of deleted lines (height)
> Number of added lines (width)
>
— Errors in red
— New function in green
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.67
OORPT — Software Visualization
Infobug Body
Bar in the middle — Number of changed files
> Spots — Number of children
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.68
OORPT — Software Visualization
Interface
>
Colors: file
types
>
Time scale
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.69
OORPT — Software Visualization
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
5.70
OORPT — Software Visualization
The Evolution Matrix
Removed Classes
Last Version
First Version
Added
Classes
Major Leap
Growth
Stabilisation
TIME (Versions)
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.71
OORPT — Software Visualization
Dayfly & Persistent
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
Dayflies: Exists
during only one or
two versions.
Perhaps an idea
which was tried out
and then dropped.
5.72
OORPT — Software Visualization
Visualizing Classes Using Metrics
> Object-Oriented Programming is about
“state” and “behavior”:
— State is encoded using attributes
— Behavior is encoded with methods
> We visualize classes as rectangles using
Foo
for width and height the following metrics:
— NOM (number of methods)
— NOA (number of attributes)
Bar
> The Classes can be categorized according
to their “personal evolution” and to their
“system evolution”: Pulsar, Supernova,
Red Giant, Stagnant, DayflyPersistent
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.73
OORPT — Software Visualization
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
5.74
OORPT — Software Visualization
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
5.75
OORPT — Software Visualization
Example: MooseFinder
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
(38 Versions)
5.76
OORPT — Software Visualization
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
5.77
OORPT — Software Visualization
Roadmap
>
Introduction
— SV in a Reengineering Context
>
Static Code Visualization
— Examples
>
Dynamic Code Visualization
— Examples
Understanding Packages
> Understanding Evolution
> Conclusion
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.78
OORPT — Software Visualization
Do It Yourself Considerations
>
A decent graph layout can be a hard task...
—
—
—
—
>
Algorithmic aspects may be important
Efficient space use (physical limits of a screen)
Colours are nice, but... there are no conventions!
Trade-off between usefulness and complexity
Keeping a focus is hard:
— Beautiful graphs are not always meaningful
— Where should we look?
— What should we look for?
>
Which approach be reproduced by reengineers in work
context and provides useful information?
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.79
OORPT — Software Visualization
Conclusions
SV is very useful when used correctly
> An integrated approach is needed, just having nice
pictures is not enough
> In general: only people that know what they see can
react on that: SV is for expert/advanced developers
> The future of software development is coming…and
SV is part of it
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.80
OORPT — Software Visualization
Lessons Learned
>
Visualization is not just smoke and mirrors!
— Complexity reduction, abstraction
>
But it should be adapted to
— your goal (first contact, deep understanding),
— time (2 days - a month),
— size (a complete system or 3 classes)
Minimize tool support if you are not familiar
> Simple approaches give 80%,
the last 20% are hard to get
>
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.81
OORPT — Software Visualization
License
>
http://creativecommons.org/licenses/by-sa/2.5/
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.
© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz
5.82