© s. demeyer, s. ducasse, o. nierstrasz visualization.1 3. software visualization introduction sv...
Post on 21-Dec-2015
220 views
TRANSCRIPT
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.1
3. Software Visualization• Introduction• SV in a Reengineering Context• Static Code Visualization
Examples
• Dynamic Code VisualizationExamples
• Lightweight ApproachesCombining Metrics and SV
• Understanding Evolution• Conclusion
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.2
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
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.3
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?
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.4
A Bit of Vocabulary• Visualization
Information Visualization
• Software VisualizationAlgorithm VisualizationProgram Visualization
• Static Code Visualization• Dynamic Code Visualization
• The overall goal is to reduce complexity
© 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]
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.6
In a Reengineering Context•Reengineering context constraints
Limited timeLimited resources
•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
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.7
Program Visualization
• 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, …)
“Program visualization is the visualization of the actual program code or data structures in either static or dynamic form”
[Price, Baecker and Small]
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.8
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?
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.9
RoadMap• Introduction• SV in a Reengineering Context• Static Code Visualization
Examples
• Dynamic Code VisualizationExamples
• Lightweight ApproachesCombining Metrics and SV
• Understanding Evolution• Conclusion
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.10
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, …
…
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.11
Example 1: Class Hierarchies
• Jun/OpenGL• The
Smalltalk Class Hierarchy
• Problems:Colors are
meaninglessVisual
Overload
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.12
Example 2: Tree Maps• Pros
100% screenLarge dataScales well
• ConsBoundariesCluttered
display InterpretationLeaves only
• Useful for the display of HDDs
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.13
Examples 3 & 4• Euclidean cones
Pros:• More info than
2DCons:
• Lack of depth• Navigation
• Hyperbolic treesPros:
• Good focus• Dynamic
Cons: • Copyright
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.14
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
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.15
Class Diagram Examples
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.16
Example 5a: Rigi• Scalability
problem• Entity-
Relationship visualization
• Problems:FilteringNavigation
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.17
Example 5b: Rigi• Entities can
be grouped• Pros:
Scales wellApplicable in
other domains
• Cons:Not enough
code semantics
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.18
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
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.19
RoadMap• Introduction• SV in a Reengineering Context• Static Code Visualization
Examples
• Dynamic Code Visualization Examples
• Lightweight Approaches Combining Metrics and SV
• Understanding Internal Call flow within classes
• Understanding Evolution• Conclusion
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.20
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• …
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.21
Example 1: JInsight• Visualization of execution trace
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.22
Example 2: Inter-class call matrix
• Simple• Reproducible• Scales well• Excel?
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.23
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
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.24
RoadMap• Introduction• SV in a Reengineering Context• Static Code Visualization
Examples
• Dynamic Code VisualizationExamples
• Lightweight ApproachesCombining Metrics and SV
• Understanding Evolution• Conclusion
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.25
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?
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.26
Solution: A lightweight approach
• A combination of metrics and software visualizationVisualize software using
colored rectangles for the entities and edges for the relationships
Render up to five metrics on one node:• Size (1+2)• Color (3)• Position (4+5)
Relationship
Entity
Y Coordinate
Height Color tone
Width
X Coordinate
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.27
Combining Metrics and Visualization
• MetricsScale wellSimple metrics simple extraction (perl
scripts)But numerical combination is
meaningless• Simple Graphs
Easy to drawScale wellBut not enough semantics
• CodeCrawler: www.iam.unibe.ch/~scg
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.28
Nodes: ClassesEdges: Inheritance RelationshipsWidth: Number of attributesHeight: Number of methodsColor: Number of lines of code
System Complexity View
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.29
LOC
NOS
Nodes: MethodsSize: Method parametersPosition X: Lines of codePosition Y: Statements
Method Assessment
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.30
Inheritance Classification View
Boxes: ClassesEdges: InheritanceWidth: Number of Methods AddedHeight: Number of Methods OverriddenColor: Number of Method Extended
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.31
Data Storage Class Detection View
Boxes: ClassesWidth: Number of Methods Height: Lines of CodeColor: Lines of Code
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.32
Industrial Validation
Nokia (C++ 1.2 MLOC >2300 classes)Nokia (C++/Java 120 kLOC >400 classes)MGeniX (Smalltalk 600 kLOC >2100classes)Bedag (COBOL 40 kLOC)...
Personal experience2-3 days to get something
Used by developers + Consultants
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.33
Evaluation• Pros
Quick insightsScalableMetrics add
semantics Interactivity
makes the code “come nearer”
Reproducible Industrial
Validation is the acid test
• ConsSimpleUseful in a first
approach phaseCode reading
neededLevel of
granularity
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.34
RoadMap• Introduction• SV in a Reengineering Context• Static Code Visualization
Examples
• Dynamic Code VisualizationExamples
• Lightweight ApproachesCombining Metrics and SV
• Understanding Evolution• Conclusion
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.35
Understanding Evolution• Information is in the history!• Overwhelming complexity• How can we detect and understand
changes?One solution: The Evolution Matrix
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.36
The Evolution Matrix
Last Version
First Version
Major Leap
Removed Classes
TIME (Versions)
Growth Stabilisation
Added Classes
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.37
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.
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.38
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
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.39
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.
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.40
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.
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.41
Example: MooseFinder (38 Versions)
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.42
RoadMap• Introduction• SV in a Reengineering Context• Static Code Visualization
Examples
• Dynamic Code VisualizationExamples
• Lightweight ApproachesCombining Metrics and SV
• Understanding Evolution• Conclusion
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.43
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
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.44
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