Assessing Software Maintainability with Visual Analytics: SQuAVisiT Experience

1
Assessing Software Maintainability with Visual
Analytics SQuAVisiT Experience

• Alexander Serebrenik, Serguei Roubtsov
• LaQuSo SET

2
Real life industrial systems

• They are often
• Not only OO (e.g., legacy systems)
• Heterogeneous (C/Assembler, Cobol/PL SQL,)
• Incomplete (some code is in libraries and
  third-party components)
• Not compilable and executable within analysis
  environment ( weird OS, proprietary development
  environment, )

3
Goal Maintainability assessment

• Maintenance is a problem
• 2007, US companies spent 100 billion US
• In some Dutch companies 60-80 of the budget

http//www.cs.jyu.fi/koskinen/smcosts.htm
4
What code is hard to maintain?

• Badly understandable
• not documented
• cluttered or inconsistently used/developed code
• too big
• Badly modifiable
• code is duplicated
• code is intertwined
• code is non-extendable
• code is non-portable
• Badly testable / analysable
• code is too complex

5
Approaches

• Typical approaches
• Analyze
• Visualize
• Analyze Visualize
• Problems with Analyze Visualize
• Pretty pictures do not convey meaning
• Ugly pictures do not scale
• One to rule them all rigid architectures
• Different tools provide different insights!

6
Our approach
Visual Software Analytics Analysis
Visualisation Flexibility
7
SQuAVisiT

• Flexible
• Plug-in architecture
• Languages
• C, Cobol, Java, JavaScript, PL/SQL
• Analysis tools
• dependency extractors, duplication detectors,
  error detectors, metrics calculators, parsers,
  style checkers
• Visualization tools
• Gemini, GraphViz, ExTraVis (thank you Danny!),
  MatrixZoom, MetricsView

8
Case studies

• 1000 facets of visual analytics
• based on LaQuSo case studies

9
LaQuSo?
10
Industrial cases

• Usually up to 2 weeks analysis time
• Range from 150 KLOC to 1.7 MLOC
• Homogeneous and heterogeneous
• Customers usually report problems experienced
• Need to migrate due to discontinuation of support
  by a third party
• Danger of architecture deterioration due to
  extensive change
• Lack of knowledge due to high degree of staff
  rotation
• Maintenance (dis)continuation decision
• As an illustration we discuss only some of the
  analyses carried out in each case.

11
Overview of industrial cases
12
Expert system
Industrial case Insurance companys expert system

• What kind of system do we have?
• Heterogeneous Javascript, PL/SQL, C, Java,
  Cobol
• Medium size 300 KLOC
• 15 years old
• Scarce documentation
• Oracle DB
• Problem reported
• Maintenance (dis)continuation decision

13
Dependencies Model Matrix View
Data layer

• (Almost) layered good design
• BUT data layer is accessed from several layers
• Layers affected by calls from top layer are
  visible (red squares)
• What are the maintenance implications of this
  figure?

14
Dependencies Model Extravis

• Absence of dedicated data access layer is
  confirmed
• HTTP is called only internally
• Green bubbles controversial coding approach
• Parameters as names f(1,3) -gt f_1_3
  

15
Code duplication model CCFinder/Gemini

• PL/SQL part
• Code is polluted with duplication restructuring
  would improve maintainability but may change the
  architecture

16
What can we conclude?

• Layered architecture
• System is well-structured
• Controversial coding practices
• But locally well-documented (not shown here)
• Code polluted by duplication
• Low impact if no major changes are expected
• Conclusions
• Maintain for limited amount of time (3-5 years)
• Encourage knowledge sharing
• Develop overview documentation

17
Case conclusions

• Assessment required multiple analyses and
  visualizations
• Dependencies
• Code duplication
• and in fact even more

Different techniques provide different insights!
18
Industrial case Embedded System

• What kind of code do we have?
• C with embedded Assembler
• Complete
• Modules of interest can be parsed
• Medium size 150 KLOC
• No documentation
• Problems reported
• Danger of architecture deterioration due to
  extensive change.
• Developers assumption
• Layered architecture

19
Dependencies Structure

• system is poorly layered
• unexpected cross-dependencies exist between
  components

20
Expert system
Industrial case Insurance companys front-end

• What kind of system do we have?
• Technical data
• Homogeneous Java
• Large 750 KLOC
• Oracle DB
• J2EE (Spring Framework)
• Recently developed by a third party
• No documentation
• Code was not available for our inspection (black
  box)

21
Code not available? What can we do?
Customer
SQuAVisiT

• Install locally.
• Perform measurements.

• Tune

results

• Analyse, interpret.

report
22
Understandability Documentation

• No technical documentation available.
• Comments percentage
• Average 43
• Ranging from 0 to 1500. Why?
• large repeated header blocks of comments
• commented out code
• Javadoc
• 85260 violations
• Missing or malformed declarations
• Documentation generation is impossible, or
• Documentation quality is compromised
• Documentation quality should be reassessed!

23
Object-Oriented Metrics for Packages

• Abstractness of a package P ease of inheritance
• A abstract classes in P/classes in P
• Instability of a package P ease of change
• I Ce/(Ce Ca)
• Efferent coupling (Ce)
• packages P depends upon
• Afferent coupling (Ca)
• packages dependent upon P

24
Modification Abstractness and Instability

• Imbalance is
• significant

Implementation classes
Zone of uselessness lack of dependencies on them
1
Instability (I)
0
Interface classes
Zone of pain hard to change
0
1
Abstractness (A)
25
Modification Abstractness and Instability

• Normalized distance Abstractness Instability
  1
• Purple the application, yellow Spring
• The application is better!

26
Object-Oriented Metrics for Classes

• WMC here number of methods per class
• DIT depth of inheritance tree
• NOC number of children
• CBO number of classes related to a given class
• RFC number of different methods that can be
  executed when a method of the class is invoked

27
Closer look Depth of Inheritance

• 50of classes with inheritance depth 0.
• Lack of reuse via inheritance.

28
Closer look coupling between objects

• CBO Average classes related to the given

NASA High Quality
NASA Low Quality
Spring Framework
Loan Path
1.25
2.48
4.45
6.83

• Average coupling is too high!
• Reduce dependencies

29
What have we seen?

• Architecture is suboptimal
• Documentation should be reassessed

30
Case conclusions

• Recall we have not seen the code!
• Black box analysis
• Metrics provide valuable insights in software
  quality
• Assessment results were confirmed by the customer

31
Industrial case Pension fund

• What kind of system do we have?
• Homogeneous Cobol
• Large 1.7 MLOC
• 17 years old
• Oracle DB
• Problem reported
• Need to migrate due to discontinuation of support
  

32
Dead code?

• Empty spaces in the visualization
• 1216 modules not called by other modules
• Dead code?
• Other (sub)systems?
• 600 are dead
• Confirmed by the developers

33
Conclusions

• Visual software analytics assessment supported
  by visualization, analysis and tool flexibility
• SQuAVisiT is a flexible tool allowing
• To analyse different languages
• To address different maintainability aspects
• To combine different analysis and visualization
  techniques
• In practice, SQuAVisiT supported analysis of
• Middle-size to large systems (150 KLOC 1.7
  MLOC)
• Short amount of time 10-14 days
• Even black box!