OORPT Object-Oriented Reengineering Patterns and Techniques 5. Software Visualization Prof. O. Nierstrasz.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

8. Static Single Assignment Form Marcus Denker. © Marcus Denker SSA Roadmap  Static Single Assignment Form (SSA)  Converting to SSA Form  Examples.
8. Introduction to Denotational Semantics. © O. Nierstrasz PS — Denotational Semantics 8.2 Roadmap Overview:  Syntax and Semantics  Semantics of Expressions.
Abstraction Lecture-4. ADT example: London Underground Map.
ESE Einführung in Software Engineering 6. Modeling Objects and Classes Prof. O. Nierstrasz.
ESE Einführung in Software Engineering 7. Modeling Behaviour Prof. O. Nierstrasz.
Introduction to Software Engineering 7. Modeling Behaviour.
Introduction to Databases
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
OORPT Object-Oriented Reengineering Patterns and Techniques 7. Problem Detection Prof. O. Nierstrasz.
© S. Demeyer, S. Ducasse, O. Nierstrasz Reverse Engineering.1 2. Reverse Engineering What and Why Setting Direction  Most Valuable First First Contact.
Object-Oriented Analysis and Design
Object-Oriented Reengineering Patterns and Techniques Prof. O. Nierstrasz Prof. S. Ducasse T.
12. Summary, Trends, Research. © O. Nierstrasz PS — Summary, Trends, Research Roadmap  Summary: —Trends in programming paradigms  Research:...
ESE Einführung in Software Engineering N. XXX Prof. O. Nierstrasz Fall Semester 2009.
© S. Demeyer, S. Ducasse, O. Nierstrasz Duplication.1 7. Problem Detection Metrics  Software quality  Analyzing trends Duplicated Code  Detection techniques.
The Software Composition Group Prof. O. Nierstrasz
13. Summary, Trends, Research. © O. Nierstrasz PS — Summary, Trends, Research Summary, Trends, Research...  Summary: functional, logic and object-oriented.
ESE Einführung in Software Engineering X. CHAPTER Prof. O. Nierstrasz Wintersemester 2005 / 2006.
File Systems and Databases
Metamodeling Seminar X. CHAPTER Prof. O. Nierstrasz Spring Semester 2008.
7. Duplicated Code Metrics Duplicated Code Software quality
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.1 5. Software Visualization Introduction  SV in a Reengineering Context Static Code Visualization.
ESE Einführung in Software Engineering X. CHAPTER Prof. O. Nierstrasz Wintersemester 2005 / 2006.
N. XXX Prof. O. Nierstrasz Thanks to Jens Palsberg and Tony Hosking for their kind permission to reuse and adapt the CS132 and CS502 lecture notes.
7. Fixed Points. © O. Nierstrasz PS — Fixed Points 7.2 Roadmap Overview  Representing Numbers  Recursion and the Fixed-Point Combinator  The typed.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
OORPT Object-Oriented Reengineering Patterns and Techniques X. CHAPTER Prof. O. Nierstrasz.
Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Unified Modeling Language Visual language.
12. Summary, Trends, Research. © O. Nierstrasz PS — Summary, Trends, Research Roadmap  Summary: —Trends in programming paradigms  Research:...
© S. Demeyer, S. Ducasse, O. Nierstrasz Visualization.1 3. Software Visualization Introduction SV in a Reengineering Context Static Code Visualization.
An Introduction to Software Visualization Dr. Jonathan I. Maletic Software DevelopMent Laboratory Department of Computer Science Kent State University.
9 1 Chapter 9 Database Design Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
© S. Demeyer, S. Ducasse, O. Nierstrasz Chapter.1 MakeMoney Corp. C*O of MakeMoney Corp. Our Vision  We invest in software  We do not know software 
OORPT Object-Oriented Reengineering Patterns and Techniques X. CHAPTER Prof. O. Nierstrasz.
CP — Concurrent Programming X. CHAPTER Prof. O. Nierstrasz Wintersemester 2005 / 2006.
12. eToys. © O. Nierstrasz PS — eToys 12.2 Denotational Semantics Overview:  … References:  …
Object-Oriented Reengineering Patterns 3. Software Visualization Selected slides courtesy Tudor Girba.
1 User Interface Design CIS 375 Bruce R. Maxim UM-Dearborn.
The Re-engineering and Reuse of Software
The chapter will address the following questions:
CASE Tools And Their Effect On Software Quality Peter Geddis – pxg07u.
Objects What are Objects Observations
A Survey of Software Refactoring Tom Mens, Tom Tourwé
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
Chapter 7 Structuring System Process Requirements
Introduction to UML By: Prof. Aiman Hanna Department of Computer Science, Concordia University, Montreal, Canada.
Glyph Visualization and Yet Another Tree Visualization Matt Williams InfoVis 533c April 3, 2003.
Unit 2: Engineering Design Process
1 Introduction to Software Engineering Lecture 1.
Lucian Voinea Visualizing the Evolution of Code The Visual Code Navigator (VCN) Nunspeet,
1 Class Diagrams: Advanced Concepts. 2 Overview Class diagrams are the most commonly used diagrams in UML. Class diagrams are the most commonly used diagrams.
Computer Systems & Architecture Lesson 4 8. Reconstructing Software Architectures.
PROC-1 1. Software Development Process. PROC-2 A Process Software Development Process User’s Requirements Software System Unified Process: Component Based.
SBD: Information Design
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Concepts and Realization of a Diagram Editor Generator Based on Hypergraph Transformation Author: Mark Minas Presenter: Song Gu.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Lecture VIII: Software Architecture
Introduction to Object Oriented Programming Lecture-3.
Michele Lanza Software Visualization. 2 Software Visualization - Outline  Introduction  Software Visualization in a Reengineering Context  Static Code.
WELCOME TO OUR PRESENTATION UNIFIED MODELING LANGUAGE (UML)
Object-Oriented Analysis and Design
Unified Modeling Language
Methodology Overview 2 basics in user studies Lecture /slide deck produced by Saul Greenberg, University of Calgary, Canada Notice: some material in this.
Visual Perception.
OORPT Object-Oriented Reengineering Patterns and Techniques
Applying Use Cases (Chapters 25,26)
UML  UML stands for Unified Modeling Language. It is a standard which is mainly used for creating object- oriented, meaningful documentation models for.
Presentation transcript:

OORPT Object-Oriented Reengineering Patterns and Techniques 5. Software Visualization Prof. O. Nierstrasz

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.2 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 OORPT — Software Visualization 5.3 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 OORPT — Software Visualization 5.4 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 OORPT — Software Visualization 5.5 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 OORPT — Software Visualization 5.6 (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 OORPT — Software Visualization 5.7 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 OORPT — Software Visualization 5.8 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 OORPT — Software Visualization 5.9 The Reengineering Life-cycle Requirements Designs Code (0) requirement analysis (1) model capture (2) problem detection (3) problem resolution (4) program transformation (2) problem detection issues Tool support Scalability Efficiency (2) problem detection issues Tool support Scalability Efficiency

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.10 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 OORPT — Software Visualization 5.11 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 OORPT — Software Visualization 5.12 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 OORPT — Software Visualization 5.13 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 OORPT — Software Visualization 5.14 Example 1: Class Hierarchies  Jun/OpenGL  The Smalltalk Class Hierarchy  Problems: —Colors are meaningless —Visual Overload

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.15 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 OORPT — Software Visualization 5.16 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 OORPT — Software Visualization 5.17 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 OORPT — Software Visualization 5.18 Nesting Level

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.19 Control Flow

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.20 Evaluation  Simple to draw  Good overview  Limited semantics  Patterns difficult to identify because of line breaks

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.21 One Case for 3D  Most of the time 3D is not worth the trouble but…

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.22 Usual Problems with 3D  No spatial semantics (is above better than below?)  Scalability  Extra effort  Space localization

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.23 Quantitative Information  3D useful for quantitative information

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.24 Accessing Hidden Information

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.25 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 OORPT — Software Visualization 5.26 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 OORPT — Software Visualization 5.27 Class Diagram Examples

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.28 Example 5a: Rigi  Scalability problem  Entity- Relationship visualization  Problems: —Filtering —Navigation

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.29 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 OORPT — Software Visualization 5.30 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 OORPT — Software Visualization 5.31 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 OORPT — Software Visualization 5.32 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 OORPT — Software Visualization 5.33 Example 1: JInsight  Visualization of execution trace

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.34 Example 2: Inter-class call matrix  Simple  Reproducible  Scales well  Excel?

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.35 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 OORPT — Software Visualization 5.36 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 OORPT — Software Visualization 5.37 Class View  Smith, Munro, Runtime Visualization of Object Oriented Software, Vissoft 02

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.38 A Class  Methods/#invocation

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.39 Method Calling Counts

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.40 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 OORPT — Software Visualization 5.41 Evaluation  Can handle large amounts of data  Not useful for all kinds of data

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.42 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 OORPT — Software Visualization 5.43 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 OORPT — Software Visualization 5.44 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 OORPT — Software Visualization 5.45 Butterfly View

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.46 Butterflies

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.47 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 OORPT — Software Visualization 5.48 Cities  Houari et al

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.49 Boxes = Packages  Height  Color  Twist  2D +

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.50

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.51 Evolution

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.52 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 OORPT — Software Visualization 5.53 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 OORPT — Software Visualization 5.54 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 OORPT — Software Visualization 5.55 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 OORPT — Software Visualization 5.56 Revision Tower (II)  Simple  Entire file  File based  Few information revealed

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.57 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 OORPT — Software Visualization 5.58 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 OORPT — Software Visualization 5.59 TimeWheel (1)  Displays trends for a number of attributes at a time  Maintain “Objectedness” through Gestalt principals

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.60 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 OORPT — Software Visualization 5.61 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 OORPT — Software Visualization 5.62 InfoBug

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.63 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 OORPT — Software Visualization 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 OORPT — Software Visualization 5.65 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 OORPT — Software Visualization 5.66 Infobug Head  Different types of code  Type is color coded  Relative size is shown by antenna length

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.67 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 OORPT — Software Visualization 5.68 Infobug Body  Bar in the middle — Number of changed files  Spots — Number of children

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.69 Interface  Colors: file types  Time scale

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.70 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 OORPT — Software Visualization 5.71 The Evolution Matrix

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.72 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 OORPT — Software Visualization 5.73 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 Foo Bar

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.74 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 OORPT — Software Visualization 5.75 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 OORPT — Software Visualization 5.76 Example: MooseFinder (38 Versions)

© Stéphane Ducasse, Serge Demeyer, Oscar Nierstrasz OORPT — Software Visualization 5.77 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 OORPT — Software Visualization 5.78 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 OORPT — Software Visualization 5.79 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 OORPT — Software Visualization 5.80 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 OORPT — Software Visualization 5.81 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 OORPT — Software Visualization 5.82 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.