SeeSys Visualization System

1. SeeSys Visualization System ICS 280 Information Visualization 5/1/2001 By Wan Sze Ng

2. Overview • Motivation • SeeSys characteristics • Big 5 questions • Design Rationale • Uses • Comments

3. Motivation • Problem statement: Increase complexity of software -> limit size of system • Solution: Software Visualization • However, current methods (1994) ineffective • Too much information -> illegible • Display complicated • => Use space-filling technique for displaying source code related software statistics

4. SeeSys Characteristics • Visualize statistics of program source code in files, directories and subsystems • Fits up to 50,000 lines of code • Overseeing the whole system provide information about the real problem of the system

5. SeeSys Characteristics (cont’d) Directory area is proportional to directory’s NCSL (Non-commentary source lines) 5 1 X Y 3 2 4 Gray area a amount of new code Z At Subsystem level

6. SeeSys Characteristics (cont’d) Y File 1 Newly developed code in File 1 (In fact, gray area can represent anything such as number of comments in the code, etc. File 2 File 3 File 4 File 5 At Directory level

7. Big-five Questions • “Which subsystems are the largest? Where is the new development activity?” • “Where are the large directories? Are the large and small directories distributed evenly throughout the subsystems? Is the new development distributed evenly between directories? Which directories are stable and which have the most activity?” • “Which subsystems are unusually complex or error-prone? Are there any problematic directories? How is the development activity apportioned between fixing bugs and adding new functionality?” • “Are bug fixes a reoccurring problem? What components would make good candidates for code restructuring projects?” • “Which were the major software releases? Have any subsystems shrunk or disappeared? What is the rate for growth of different subsystems? Which subsystems are growing at the fastest rates? Have any subsystems remained at the same size or grown at a steady rate? Where has the development work been done historically?”

8. #1 Question • “Which subsystems are the largest? Where is the new development activity?”

9. #2 Question • “Where are the large directories? Are the large and small directories distributed evenly throughout the subsystems? Is the new development distributed evenly between directories? Which directories are stable and which have the most activity?”

10. #3 Question • “Which subsystems are unusually complex or error-prone? Are there any problematic directories? How is the development activity apportioned between fixing bugs and adding new functionality?”

11. #4 Question • “Are bug fixes a reoccurring problem? What components would make good candidates for code restructuring projects?”

12. #5 Question • “Which were the major software releases? Have any subsystems shrunk or disappeared? What is the rate for growth of different subsystems? Which subsystems are growing at the fastest rates? Have any subsystems remained at the same size or grown at a steady rate? Where has the development work been done historically?”

13. Design Rationale • User Interaction • Users can choose a particular subsystem they want to look at by using mouse. • Screen real-estate • Rectangles are placed next to each other so that 100% of the display area is utilized (space-filling) • Zoom in is possible when the subsystem is too small

14. Design Rationale (cont’d) • Spatial relationships • Number of rows used can be optimally determined by users with a slide bar • Algorithm used to equalize heights of rectangles • Color • Used to redundantly encode size

15. Uses • Project managers: track the evolution of the code • Feature engineers: determine which components of the system will be impacted by planned enhancements • Software Developers: identify error-prone subsystems for reengineering

16. Comments • General information is provided but system could be confusing • Any others?