Analysis of Evolving Software with Visual Software Analytics

1
Analysis of Evolving Software withVisual
Software Analytics SQuAVisiT
2
Software Evolves!
The stages of software evolution (adapted from
Tom Mens Serge Demeyer. Springer-Verlag 2008)
Any change is costly but the system is still
valuable legacy system
Architecture decay significant changes are costly
Architecture is (still) preserved normal
change
Migrate buy? Outsource?
Maintain
Refactor?
3
Goal Maintainability assessment during SW
evolution

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

4
Rationale behind analysis

• What to measure if you want to
• Maintain critical areas, quality, expected
  effort, learning curve, priorities
• Refactor critical areas, quality and expected
  effort
• Migrate technical risks, critical areas,
  quality and expected effort
• Outsource the quality and expected effort
• Insource the quality, expected effort,
  learning curve
• Not only figures but understanding and real
  errors too

5
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

6
Approaches

• Typical approaches
• Analyze
• Visualize
• Analyze Visualize
• Problems with Analyze Visualize
• Pretty pictures what do you visualize?
• Ugly pictures do not scale
• One to rule them all rigid tool bundles
• Different tools provide different insights!

7
Our approach
Visual Software Analytics Measurement
Visualisation Flexibility
Name, Class Count, Abstract Class Count, Ca, Ce,
A, I, D, V bsh,0,0,1,0,0,0,1,1 com.caucho.burlap.
client,0,0,1,0,0,0,1,1 com.caucho.burlap.io,0,0,1,
0,0,0,1,1 com.caucho.burlap.server,0,0,1,0,0,0,1,1
com.caucho.hessian.client,0,0,1,0,0,0,1,1 com.cau
cho.hessian.io,0,0,1,0,0,0,1,1 com.caucho.hessian.
server,0,0,1,0,0,0,1,1 com.ibatis.common.util,0,0,
1,0,0,0,1,1 oracle.toplink.essentials.sessions,0,0
,1,0,0,0,1,1 oracle.toplink.exceptions,0,0,2,0,0,0
,1,1 oracle.toplink.expressions,0,0,1,0,0,0,1,1 or
acle.toplink.internal.databaseaccess,0,0,1,0,0,0,1
,1 oracle.toplink.jndi,0,0,1,0,0,0,1,1 oracle.topl
ink.logging,0,0,1,0,0,0,1,1 oracle.toplink.publici
nterface,0,0,2,0,0,0,1,1 oracle.toplink.queryframe
work,0,0,1,0,0,0,1,1 oracle.toplink.sessionbroker,
0,0,1,0,0,0,1,1 oracle.toplink.sessions,0,0,2,0,0,
0,1,1 oracle.toplink.threetier,0,0,1,0,0,0,1,1 ora
cle.toplink.tools.sessionconfiguration,0,0,1,0,0,0
,1,1 oracle.toplink.tools.sessionmanagement,0,0,1,
0,0,0,1,1 org.aopalliance.aop,0,0,9,0,0,0,1,1 org.
aopalliance.intercept,0,0,24,0,0,0,1,1 org.apache.
axis.encoding.ser,0,0,1,0,0,0,1,1 org.apache.catal
ina.loader,0,0,1,0,0,0,1,1 org.aspectj.weaver,0,0
,2,0,0,0,1,1 org.aspectj.weaver.ast,0,0,1,0,0,0,1,
1 org.aspectj.weaver.bcel,0,0,1,0,0,0,1,1 org.aspe
ctj.weaver.internal.tools,0,0,1,0,0,0,1,1 org.aspe
ctj.weaver.loadtime,0,0,1,0,0,0,1,1 org.quartz.sp
i,0,0,1,0,0,0,1,1 org.quartz.utils,0,0,1,0,0,0,1,1
org.quartz.xml,0,0,1,0,0,0,1,1 org.springframework
.aop,24,20,17,6,0,83,0,26,0,09,1 org.springframewo
rk.aop.aspectj,39,7,3,24,0,18,0,89,0,07,1 org.spri
ngframework.aop.aspectj.annotation,27,3,0,19,0,11,
1,0,11,1 org.springframework.aop.aspectj.autoproxy
,3,0,1,8,0,0,89,0,11,1 org.springframework.aop.con
fig,17,3,1,15,0,18,0,94,0,11,1 org.springframework
.aop.framework,37,9,22,18,0,24,0,45,0,31,1 org.spr
ingframework.jdbc.core,53,20,6,20,0,38,0,77,0,15,1
org.springframework.jdbc.core.metadata,22,2,1,10,
0,09,0,91,0,1 org.springframework.jdbc.core.namedp
aram,10,4,3,12,0,4,0,8,0,2,1 org.springframework.j
dbc.core.simple,17,6,0,12,0,35,1,0,35,1 org.spring
framework.jdbc.core.support,8,5,2,14,0,62,0,88,0,5
,1 org.springframework.jdbc.datasource,27,7,13,14,
0,26,0,52,0,22,1 org.springframework.jdbc.datasour
ce.lookup,8,2,2,13,0,25,0,87,0,12,1 org.springfram
ework.jdbc.object,14,8,0,12,0,57,1,0,57,1 org.spri
ngframework.jdbc.support,15,5,12,16,0,33,0,57,0,1,
1 org.springframework.jdbc.support.incrementer,15,
4,0,8,0,27,1,0,27,1 org.springframework.jdbc.suppo
rt.lob,18,5,5,12,0,28,0,71,0,02,1 org.springframew
ork.jdbc.support.nativejdbc,10,2,2,7,0,2,0,78,0,02
,1 org.springframework.jdbc.support.rowset,4,2,2,6
,0,5,0,75,0,25,1 org.springframework.jdbc.support.
xml,7,6,0,7,0,86,1,0,86,1 org.springframework.web.
servlet.view.xslt,4,2,0,17,0,5,1,0,5,1 org.springf
ramework.web.struts,16,5,0,22,0,31,1,0,31,1 org.sp
ringframework.web.util,24,6,26,15,0,25,0,37,0,38,1
org.w3c.dom,0,0,12,0,0,0,1,1 org.xml.sax,0,0,3,0,
0,0,1,1
(2)
AV Repository
(3)
(1)
(4)
8
SQuAVisiT

• Flexible
• Plug-in architecture
• Languages
• C, Cobol, Java, JavaScript, PL/SQL, Delphi,
• Analysis tools (third party and our own)
• dependency extractors, duplication detectors,
  error detectors, metrics calculators, parsers,
  code style checkers
• Visualization tools
• MetricsView, Gemini, GraphViz, ExTraVis ,
  MatrixZoom

9
Real life industrial systems

• They are often
• OO and 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, )

10
Industrial cases

• Range from 150 KLOC to 1.7 MLOC
• Homogeneous and heterogeneous
• Customers usually report problems experienced
• Need to migrate due to discontinuation of support
• Lack of knowledge about the system due to high
  degree of staff rotation
• Danger of architecture deterioration due to
  extensive changes
• 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)

14
Dependencies Model Extravis

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

15
Code duplication model CCFinder/Gemini

• 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 but
• JavaScript two-tiered architecture could cause
  serious maintenance problems in the future
• Code polluted by duplication
• Low impact if no major changes are expected
• Conclusions
• Maintain for limited amount of time (3-5 years)
• Develop overview documentation

17
Industrial case Embedded System

• What kind of code do we have?
• Component system with compile-time binding via
  make files
• C with embedded Assembler
• Complete
• Modules of interest can be parsed
• Medium size 150 KLOC
• No documentation
• Problems reported
• Extensive change. Is architectural purity still
  preserved?
• Developers assumption
• Layered architecture

18
Dependencies Structure

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

19
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 application (Spring Framework Hibernate
  used)
• Recently developed by a third party
• No documentation
• Code was not available for our inspection (black
  box)

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

• Install locally.
• Perform measurements.

• Tune

results

• Analyse, interpret

report
21
Understandability Documentation

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

22
Quality of architecture

• Object-Oriented Metrics for Packages (JDepend)
• 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
• Other tools compute Ce and Ca slightly
  differently

23
Modification Abstractness and Instability
Imbalance is significant
Implementation packages
Zone of uselessness lack of dependency on them
1
Instability (I)
0
Interface packages
Zone of pain hard to change
0
1
Abstractness (A)
24
How significant is the imbalance?
Application
Spring Framework
25
Object-Oriented Metrics for Classes (CKJM
MetricsView)

• 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

26
What have we seen?

• Architecture is suboptimal
• Documentation should be reassessed

27
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
  

28
Dead code?

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

29
Results of Analysis effort
Halstead metrics
Time to understand (T) is proportional to
Halstead Effort T E / 18 /3600
Time to understand, hours
30
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!