Page 1
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.1
5. Software Visualization• Introduction
SV in a Reengineering Context
• Static Code VisualizationExamples
• Dynamic Code VisualizationExamples
• Understanding Packages• Understanding Evolution• Conclusion
Page 2
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.2
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 conventionNice pictures do not imply valuable
informationWhere to look? What is important?
Page 3
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.3
A Bit of Vocabulary• Visualization
Information Visualization
• Software VisualizationAlgorithm VisualizationProgram Visualization
• Static Code Visualization• Dynamic Code Visualization
• The overall goal is to reduce complexity
Page 4
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.4
(Information) Visualization• Bertin assessed three levels of
questionsLower 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
Page 5
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.5
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]
Page 6
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.6
In a Reengineering Context•Work on old systems, dialects
•New tools are not processing your (C++) dialect
•Approaches Scalability is crucialEfficient (time/information obtained)Need a clear focus
•SolutionsMinimize tools supportUse existing proven tools (Rigi, CodeCrawler, Jinsight)
Do it yourself but simple thing first
Page 7
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.7
The Reengineering Life-cycle
Requirements
Designs
Code
(0) requirementanalysis
(1) modelcapture
(2) problemdetection (3) problem
resolution
(4) program transformation
(2) problem detectionissues• Tool support• Scalability• Efficiency
Page 8
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.8
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, …)
Page 9
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.9
Program Visualization II• Level of granularity?
Complete systems, subsystems, modules, classes, hierarchies,...
• When to apply?First contact with a unknown systemKnown/unknown parts?Forward engineering?
• Methodology?
Page 10
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.10
RoadMap• Introduction
SV in a Reengineering Context
• Static Code VisualizationExamples
• Dynamic Code VisualizationExamples
• Understanding Packages• Understanding Evolution• Conclusion
Page 11
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.11
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, …
…
Page 12
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.12
Example 1: Class Hierarchies
• Jun/OpenGL• The Smalltalk
Class Hierarchy
• Problems:Colors are
meaninglessVisual
Overload
Page 13
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.13
Example 2: Tree Maps• Pros
100% screenLarge dataScales well
• ConsBoundariesCluttered
display InterpretationLeaves only
• Useful for the display of HDDs
Page 14
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.14
Examples 3 & 4• Euclidean cones
Pros:• More info than
2DCons:
• Lack of depth• Navigation
• Hyperbolic treesPros:
• Good focus• Dynamic
Cons: • Copyright
Page 15
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.15
Kind of Code Maps• From Marcus,Feng, Maletic
Software Visualization’03• Simple• Overview• File-based• One “Dot” = one line
Page 16
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.16
Nesting Level
Page 17
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.17
Control Flow
Page 18
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.18
Evaluation• Simple to draw• Good overview• Limited semantics• Patterns difficult to identify
because of line breaks
Page 19
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.19
One Case for 3D• Most of the time 3D is not worth
but…
Page 20
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.20
Usual Problems with 3D• No spatial semantics (is above
better than below)• Scalability• Extra effort• Space localization
Page 21
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.21
Quantitative Information• 3D useful for quantitative
information
Page 22
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.22
Accessing Hidden Information
Page 23
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.23
Evaluation• Worth to represent quantitative
information• Spatial information is not really
sexy• Requires more work• Requires more tooling
Page 24
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.24
Class Diagram Approaches• For example UML diagrams…• Pros:
OO ConceptsGood for small parts
• Cons:Lack of scalabilityRequire tool support Requires mapping rules to reduce
noisePreconceived views
Page 25
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.25
Class Diagram Examples
Page 26
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.26
Example 5a: Rigi• Scalability
problem• Entity-
Relationship visualization
• Problems:FilteringNavigation
Page 27
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.27
Example 5b: Rigi• Entities can
be grouped• Pros:
Scales wellApplicable in
other domains
• Cons:Not enough
code semantics
Page 28
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.28
Evaluation• Pros
Intuitive approachesAesthetically pleasing results
• ConsSeveral approaches are orthogonal to
each otherToo easy to produce meaningless
resultsScaling up is sometimes possible,
however at the expense of semantics
Page 29
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.29
RoadMap• Introduction
SV in a Reengineering Context
• Static Code VisualizationExamples
• Dynamic Code VisualizationExamples
• Understanding Packages• Understanding Evolution• Conclusion
Page 30
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.30
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• …
Page 31
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.31
Example 1: JInsight• Visualization of execution trace
Page 32
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.32
Example 2: Inter-class call matrix
• Simple• Reproducible• Scales well• Excel?
Page 33
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.33
Mural View• The algorithm takes an
image of M x N elements and scales it into a mural of I x J pixels.
Page 34
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.34
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
Page 35
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.35
Class View• Smith, Munro, Runtime
Visualization of Object Oriented Software, Vissoft 02
Page 36
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.36
A Class• Methods/#invocation
Page 37
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.37
Method Calling Counts
Page 38
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.38
Evaluation• Entities as objects• Spot fast the important methods• For complete scenario may be
difficult to reproduce• Requires interactivity• Layout can be a problem
Page 39
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.39
Evaluation• Useful not for any kinds of data• Handling of large amount of data
Page 40
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.40
Dynamic SV: Evaluation• Code instrumentation problem
Logging, Extended VMs, Method Wrapping, C++ preprocessing is heavy
• Scalability problemTraces quickly become very big (1Mb/s)
• Completeness problem: scenario driven• Pros:
Good for fine-tuning, problem detection
• Cons:Tool support crucialLack of abstraction without tool support
Page 41
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.41
RoadMap• Introduction
SV in a Reengineering Context
• Static Code VisualizationExamples
• Dynamic Code VisualizationExamples
• Understanding Packages• Understanding Evolution• Conclusion
Page 42
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.42
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-orientedContain intent of structure and
deployement
Page 43
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.43
Butterfly View
Page 44
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.44
Butterflies
Page 45
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.45
Evaluation• Focus on packages• Entities as objects• Patterns• Shape easily recognisable• Lot of information condensed• Problems with value normalisation
Page 46
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.46
Cities• Houari et al
Page 47
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.47
Boxes = Packages• Height• Color• Twist
• 2D +
Page 48
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.48
Page 49
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.49
Evolution
Page 50
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.50
Evaluation• Interesting use of pseudo-3D• Limited mapping possibility• Good overview• Good spotting facility
• Limit of metaphorAre shanty towns that bad?
Page 51
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.51
RoadMap• Introduction• SV in a Reengineering Context• Static Code Visualization
Examples
• Dynamic Code VisualizationExamples
• Understanding Packages• Understanding Evolution• Conclusion
Page 52
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.52
Understanding Evolution• Information is in the history!• Overwhelming complexity• How can we detect and understand
changes?• Solutions:
Revision TowersTimeWheel, InfobugThe Evolution Matrix
Page 53
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.53
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: lot of rectangle inside a release period
Page 54
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.54
Revision Tower (II)
• Simple• Entire file• File based• Few information revealed
Page 55
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.55
Definitions• Glyph: A symbol, such as a stylized figure or
arrow on a public sign, that imparts information nonverbally.
Page 56
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.56
How can we represent time?
• Animation?Good for easily perceived outliers
• Time Series graph?Good for comparing trends
• Timewheel
Page 57
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.57
TimeWheel (1)• Displays trends for a number of
attributes at a time• Maintain “Objectedness”
through Gestalt principals
Page 58
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.58
Timewheel (II)• Multiple time series ordered in a
circle• Data attributes are color coded• Easy recognition of two trends
Increasing trendTapering trend
• Helps to examine different trends within one object
Page 59
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.59
Time Series Problems• In row
More time to spot themLess local patterns
• In circleWeakens reading order implicationsRotation invariant
• Example
Page 60
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.60
InfoBug
Page 61
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.61
Infobug• Look like an insect• Show many properties while still
maintaining “objectedness”• Certain patterns preattentively pop
out• Interactive• Represent four classes of software
dataCode lines, errors (wings)
Page 62
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.62
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)
Page 63
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.63
Infobug Wings• Time series• Lines of code vs. Lines of
Errors• Red line is current
selection (update other aspects)
• Code quality
Page 64
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.64
Infobug Head
• Different types of code• Type is color coded• Relative size is shown by antenna
length
Page 65
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.65
Infobug Tail• Triangle shaped• Number of delected
lines (height)• Number of added
lines (width)Errors in redNew function in green
Page 66
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.66
Infobug Body
• Bar in the middle - Number of changed files
• Spots - Number of children
Page 67
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.67
Interface• Colors:
file types
• Time scale
Page 68
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.68
Evaluation• Pros:
Large datasets on little space Entities as objects Easy to recognise patterns Trends identification Easy to compare and analyse Interactive
• Cons: Learning (but is there something we should not
learn?) Main focus on Error/Loc ratio Could include more information
Page 69
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.69
The Evolution Matrix
Last Version
First Version
Major Leap
Removed Classes
TIME (Versions)
Growth Stabilisation
Added Classes
Page 70
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.70
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.
Page 71
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.71
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 for width and height the following metrics: NOM (number of methods) NOA (number of attributes)
• The Classes can be categorized according to their “personal evolution” and to their “system evolution”: Pulsar, Supernova,Red Giant, Stagnant,DayflyPersistent
FooFoo
BarBar
Page 72
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.72
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.
Page 73
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.73
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.
Page 74
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.74
Example: MooseFinder (38 Versions)
Page 75
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.75
Evaluation• Easy to draw• Scalable via other grouping
entities (packages)• Good overview of history• Limit of the metaphor…
Page 76
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.76
RoadMap• Introduction• SV in a Reengineering Context• Static Code Visualization
Examples
• Dynamic Code VisualizationExamples
• Understanding Packages• Understanding Evolution• Conclusion
Page 77
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.77
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?
Page 78
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.78
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
Page 79
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.79
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
Page 80
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.80
License• http://creativecommons.org/licenses/by-sa/2.5/
Attribution-ShareAlike 2.5You 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.5You 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.