This document summarizes a presentation by Dr. S. Ducasse on dedicated tools and research for software business intelligence at Tisoca 2014. It discusses: - The need for dedicated tools tailored to specific problems to aid in maintenance, decision making, and reducing costs. - The Moose technology for building custom analysis tools through its language-independent meta-model and ability to import different data sources. - Examples of how analysis tools built with Moose have helped companies with challenges like migration, reverse engineering, and decision support. - The benefits of an inventive toolkit approach that allows building multi-level dashboards, code analyzers, impact analyzers, and other custom tools to address specific

1. Dedicated tools and
research for
Software Business
intelligence
@ Tisoca 2014
Dr. S. Ducasse
rmod.lille.inria.fr
stephane.ducasse.free.fr
1

2. stephane.ducasse.free.fr
• Leader of RMOD Inria team
• Co-founder of http://www.synectique.eu
•
•
•
•
Co-creator of Moose http://www.moosetechnology.org
Leader of http://www.pharo.org
Coder and object-designer
Traits co-father

4. Software is
Complex

5. Software is a living entity...
•Early decisions were certainly good at that time
•But the context changes
•Customers change
•Technology changes
•People change

6. Maintenance = Success!!

7. We only
maintain
useful
successful
software

8. Maintenance is continuous
Development
4% Other
20%
80%
18% Adaptive
(new platforms or OS)
Between 50% and 90% of
global effort is spent on
“maintenance” !
4%
18%
18%
60%
18% Corrective
(fixing reported errors)
60% Perfective
(new functionality)
“Maintenance”

9. 50% of development time
is lost trying to understand code !
20%
20%
80%
Between 50% and 80% of the
overall cost is spent in the
evolution
40%
40%
We lose a lot of time with inappropriate and
ineffective practices

10. We need
dedicated
tools!

11. Pragmatic researchers in action

12. Dedicated tools tailored to your
problems
Profitable in terms of cost
http://www.synectique.eu

13. RMOD
RMoD: code analysis, metamodeling, software metrics, program
understanding, program visualization, evolution analysis,
refactorings, legacy code, quality, ...
Current focus
Remodularization analyses
Reverse
Engineering
Quality models (PSA-Airfrance)
Towards semantic merge
Old and odd language analyses Representation
Rule and bug assessment
Collaborations
Soft-VUB (Belgium), Pleiad (Chile)
UFMG (Brazil), SCG (Swiss), LIRMM
Analyses
Transformations
Evolution
13

14. Understanding Large Systems
Static/Dynamic Information
Feature Analysis
Class Understanding
Reverse
Package Blueprints
Engineering
Distribution Maps
Analyses
Representation
Software Metrics
Quality Models
Duplicated Code Identification
Test Generation
Cycle and Layer Identification
Merging technics
Rules assessment
Transformations
Evolution
Language Independent Meta
Model (FAMIX)
An Extensible Reengineering
Environment
S.Ducasse
Language Independent
Refactorings
Reengineering Patterns
Version Analyses
HISMO metamodel
14
LSE

15. Java
C
/
C++
Smalltalk
.NET

16. ols
d To
cate
edi
D
Data
Develop
Analysis
Model
Analysis
Take decision
“an analysis should lead to a decision”

17. Example : Who is behind package X ?
(4) Visualisation
(3) Analyses
(2) Modèle
(1) Extraction

18. Step 1 - Model Creation/Import
(4) Visualisation
(3) Analyses
(2) Modèle
(1) Extraction
Definition of a model to represent entities
Data Extraction (CVS...)

19. Step 2 - Analyses
(4) Visualisation
(3) Analyses
(2) Modèle
(1) Extraction
Who wrote how many lines of code?

20. Step : 3 - Creating the Map

27. JBoss at a glance
Interactive tool
Data in perspective
(4) Visualisation
(3) Analyses
(2) Modèle
(1) Extraction

28. data
importers
models
engines
m o o se
techno
l
ogy.org
analyses

29. Naviga3on
in
the
Model

30. Queries
reduce
the
analysis
Query

31. So@ware
Metrics

32. Metrics
in
Moose

33. Metrics Dashboard

34. Evolution Dashboard

35. Evolution Matrix

36. Moose
Meta-­‐Model
To
represent
program
informa3on
Java
Smalltalk
C/C++
.NET
...

37. Custom rules can be captured and checked
daily for you.

38. Dedicated Analysis reports with Moose provide pertinent
analysis for software elements

39. Reports can integrated into software process:
Automated, continuous reports with integration servers

40. Custom Rules
Rule followers and breakers
green: followers
orange: break < 2 rules
Red: break > 2 rules

41. Tudor Gîrba

42. Tools
Design
With
Moose

43. Modeling of Eclipse Plugins

44. Contextual Visualization of
Plugins
Core: Blue
Uml: Red

45. Visualization of Plugins
& Dependencies
All incoming dependencies for a
package in green

46. Analysis
of bugs

47. Dedicated Analyses
...

48. Dedicated Tools
Rich
Compact
Best Focus

49. b := GLMTabulator new.
b column: #namespaces;
column: #classes;
column: #methods.
b transmit to: #namespaces;
andShow: [:a |
a tree
display: [ :model |
model allNamespaces
select: #isRoot ];
children: #childScopes;
format: #name ].
b transmit to: #classes;
from: #namespaces;
andShow: [:a |
a list
display: #classes;
format: #name ].
b transmit to: #methods;
from: #classes;
andShow: [:a |
a list
display: #methods;
format: #signature ].
b transmit
toOutsidePort: #class;
from: #classes.
b transmit to: #methods;
from: #methods.
B := GLMTabulator new.
B title: 'Code Browser'.
B row: #nav;
row: #details.
B transmit to: #nav;
andShow: [:a |
a custom: b ].
B transmit to: #details;
from: #nav port: #class;
andShow: [:a |
a text
display: #sourceText ].
B transmit to: #details;
from: #nav port: #method;
andShow: [:a |
a text
display: #sourceText ].

50. One picture is worth one thousand
words
Which one?
How could it be that simple?
50

51. Program visualization is difficult
Limited number of colors: 12
Blur and color emergence
Limited screen size
Limited context, edges crossing
Limited short-term memory (three to nine)
Difficult to remember too many symbols/semantics
Culture, Colorblind
51

52. Our constraints
Lot of existing and advanced solutions
ICPC is full of them
HEB
Plenty of works on information visualization
Simple but not simplistic
Ideally, solutions that an engineer could reproduce in a
couple of days
52

53. Understanding large systems
•
•
•
•
Understanding code is difficult!
Systems are large
Code is abstract
Should I really convinced you?
• Some existing approaches
-Metrics: you often get meaningless results once combined
-Visualization: often beautiful but with little meaning
• Polymetric view is an idea of M. Lanza [WCRE,TSE]

54. System
Complexity
Class
Blueprint
Classes
and
their
hierarchy
Height
=
NOM
Width
=
NOA
Color
=
LOC
Outer
Rectangles
=
Classes
Inner
=
methods/aVributes
Demonstrates
class
layers
and
class
interac3ons
Chronia
X-­‐axis
=
3me
Y-­‐axis
=
files
Colors
=
authors
Distribu2on
Map
Rectangles
=
A
reference
Par33on
(Example:
Packages)
Color
=
Some
property
(words)
Code
City
Districts
=
Packages
Towers
=
Classes
Tower
Height
=
NOM
Tower
width
=
NOA
Trace
Signal
Lines
=
execu3on
of
methods

55. System Complexity shows class hierarchies.
attributes
methods
lines

56. Polymetric views condense information
To get a feel of the inheritance
semantics: adding vs. reusing
Classes+Inheritance
W: # of Added Methods
H: # of Overridden Methods
C: # of Method Extended
methods
LOC
# statements
# parameters
S.Ducasse
56
LSE

57. Understanding Classes: Easier?
• Public and non public methods
• No predefined reading order
• Inheritance
• Class blueprint is an idea of M. Lanza [OOPSLA]

58. Understanding Changes

59. Introducing a feature
Introduced PopupChoice / RequestDialog
59

60. How to understand changes
• Torch is the work of V. Uquillas-Gomez

62. Package Structure

64. Removing a feature (I)
Removed Pen and PenPointRecorder
64

65. Editing comments

66. Lessons learned
• Program visualization is difficult
• Squares and little symbols are just
squares and little symbols
• Glancing at code is still efficient

67. Omnipresent code + visualization is
excellent

68. Dedicated tools tailored to your problems
Profitable in terms of cost
http://www.synectique.eu

69. Inven3ve
Toolkit
• Multi-language
• Meta-tool: An environment
to build tools
• Any kind of data: logs, authors, bugs,
…

70. Example of
dedicated tools
http://www.synectique.eu

71. Analysis and Migration Support
Problem: Since 30 years company X develops insurance
solution. The old compiler costs more and more.
Which part to migrate first?
How to reduce the migration cost (duplicated code, screen
numbers)?
How to control the migration?
Solution :
Build a specific analysis tools (2 cycles of 6 weeks)
Domain and problem analysis
Engineer formation

72. Reverse engineering and support new generation
Problem: Since 15 years company X develops
missile shooting systems. The most of original team
left. Other foreign code to maintain.
Understanding current message driven architecture.
Extracting domain model
Mapping concepts back to code.
Supporting testing components
Solution :
Domain and problem analysis
Build a specific analysis tools (3-4 months)
Engineer formation

73. Decision Making Support
Problem: Since 20 years company X develops
insurance solution. The old compiler costs more
and more.
Which part depends on which other one?
Duplicated code?
Dead code?
Solution :
Domain and problem analysis
Build a specific analysis tools (2 cycles of 6 weeks)
Engineer formation

74. : #isGod
ses select
clas
00
,0
53
7
McCabe
= 21 C =
LO
...
Inventive Toolkit
/59

75. Multi levels
Dashboard
Code
analyzer
Impact
analyzer
/59
Duplica3on
inspector

76. Dashboard
• Metrics:
o Method projets
o Forms
o Tables
• Quality
• Debt
• Reports
/59

77. Code Analyzer
/59
• Code Browser
• Dependencies
• Filters

78. Duplication Inspector
• Duplication
detector
• Customizable
/59

79. Impact
Analyzer
• Global
dependencies
• Interactif
• Cyclic dependencies
/59

80. Rule Checker
/59
Automated rule
checking
Specific client driven
rules

81. http://stephane.ducasse.free.fr
http://www.synectique.eu

82. Interested by your problems
- Migration support
- Decision making support
- Extraction and definition of rules
- Software architecture Verification
- Visualizations
- Cost prediction
- Impact change
- Service-oriented architecture
- Software analysis