This document presents a methodology for tracking code smells over time in software systems. The methodology involves using a "nose" tool to detect god classes, analyzing the evolution of smells, and identifying patterns. The analysis of two systems found that most god classes remained constant, some degraded over time with the addition of new code, and improvements were less frequent than deletions and hard to classify. Prevention may involve rules about refactoring when classes grow beyond a certain size.

1. BackgroundBackground
Work on the detection of bad smells
Idea is that when something smells bad,
it should be changed
02/08/10 1WCRE2009 - S. Vaucher et al.

2. Open IssuesOpen Issues
Identify factors that cause these smells to
guide engineering efforts for :
Prevention
Detection
Correction
02/08/10 2WCRE2009 - S. Vaucher et al.

3. How to Track SmellsHow to Track Smells
Use a nose
Follow the evolution of a smell
02/08/10 3WCRE2009 - S. Vaucher et al.

4. Overview of the PresentationOverview of the Presentation
• Nose
• Systems
• Analysis
• Results
• Thoughts on prevention and correction
02/08/10 WCRE2009 - S. Vaucher et al. 4

5. The Nose
02/08/10 WCRE2009 - S. Vaucher et al. 5

6. The NoseThe Nose –– In two slides (1)In two slides (1)
We built one in previous work
[QSIC2009]
Works with God classes
Probability of a God class given
symptoms:
Cohesion
Naming
Size
Presence of data classes
02/08/10 6WCRE2009 - S. Vaucher et al.

7. NoseNose –– In Two Slides (2)In Two Slides (2)
Size Lexical Little
Cohesion
Deals with
data
classes
Large
Controller
Class?
God class?
MAX MAX MAX MAX
47%
Conditional
probabilities
02/08/10 7WCRE2009 - S. Vaucher et al.

8. Systems
02/08/10 8WCRE2009 - S. Vaucher et al.

9. Xerces-J Eclipse JDT
02/08/10 9WCRE2009 - S. Vaucher et al.

10. System statisticsSystem statistics
Xerces-J Eclipse JDT
10-15% god classes
70% start as god
classes
30% of god classes
are deleted
2% god classes
61% start as god
classes
19% of god classes
are deleted
02/08/10 10WCRE2009 - S. Vaucher et al.

11. Analysis
02/08/10 WCRE2009 - S. Vaucher et al. 11

12. 3 Step Program3 Step Program -- AnalysisAnalysis
• Find patterns in the evolution of the smell
• Label these patterns
• Analyse the commonalities of these
patterns
02/08/10 12WCRE2009 - S. Vaucher et al.

13. DataData
02/08/10 13WCRE2009 - S. Vaucher et al.

14. TimeTime--independent Analysisindependent Analysis
• Use DTW to compare time-independent
signals
• Apply clustering to discover patterns
• Apply classification to group and analyse
02/08/10 14WCRE2009 - S. Vaucher et al.

15. Finding PatternsFinding Patterns
Hierarchical agglomerative
clustering using DTW as a
distance measure
Constant (smelly)
Gradual
improvement
Sharp
improvement
Gradual
degradation
Sharp
degradation
Temporary
Relief
Temporary
badness
Time
Signal
02/08/10 15WCRE2009 - S. Vaucher et al.

16. Classifying PatternsClassifying Patterns
02/08/10 16WCRE2009 - S. Vaucher et al.

17. Pattern DistributionPattern Distribution
Xerces-J Eclipse JDT
02/08/10 17WCRE2009 - S. Vaucher et al.

18. Constant PatternConstant Pattern
~65% are always smelly
Questions: Quick and dirty design or
willful decision?
◦ Look for signs of design effort
◦ Ask the developers
02/08/10 18WCRE2009 - S. Vaucher et al.

19. Constant PatternConstant Pattern -- ResultsResults
Xerces main developer mentioned that
problems were complex and required
complex design
Similarly, 82% of classes play a role in a
design pattern
The code is not a hack
02/08/10 19WCRE2009 - S. Vaucher et al.

20. DegradationDegradation
~18% of smelly classes were okay
initially
In most cases, sharp degradation occurs
when developers add data classes to
already large class
Degradation always requires new code to
be added
02/08/10 20WCRE2009 - S. Vaucher et al.

21. DegradationDegradation –– growth trends ingrowth trends in
XercesXerces
02/08/10 21WCRE2009 - S. Vaucher

22. ImprovementsImprovements
More classes are removed than are
corrected (30% in Xerces)
Reason justifying the study of antipatterns
is to find some standard solutions
Were they used?
02/08/10 22WCRE2009 - S. Vaucher et al.

23. ImprovementsImprovements ––resultsresults
Eclipse, lots of added responsibility to
data classes (rebalancing)
Xerces, few textbook refactorings
Not obvious since design correction often
occurs with enhancements
02/08/10 WCRE2009 - S. Vaucher et al. 23

24. PreventionPrevention
Rule mining:
When large amounts of code are added to a
class, the probability of it being a god class
increases
Inputs:
◦ Use code/method change metrics
(added/removed/modified)
◦ Current state (clean, borderline, smelly)
Output:
◦ Increase, stable, decrease probability of god class
02/08/10 WCRE2009 - S. Vaucher et al. 24

25. RulesRules
02/08/10 WCRE2009 - S. Vaucher et al. 25

26. Correcting god classesCorrecting god classes
Gap between theoretical refactorings and
their applications.
Too little cohesion (LCOM5): should lead
to an extract class refactoring, but almost
never used (and metric change not
reflected)
Responsibility distribution: move
methods. Done more regularly, but
almost never from god to data class
02/08/10 WCRE2009 - S. Vaucher et al. 26

27. What was saidWhat was said
Methodology to track smells in systems
Discussed the introduction and removal of
smells in two open-source systems
02/08/10 WCRE2009 - S. Vaucher et al. 27

28. What to rememberWhat to remember
Most god classes tends to be god classes
from the start and do not improve
More deletions than improvements
Improvements are hard to classify
Degradation is the result of significant
growth (>100%), or because
responsibilities are unbalanced
02/08/10 WCRE2009 - S. Vaucher et al. 28
et al.