WCRE09b.ppt
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
213
On Slideshare
189
From Embeds
24
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 24

http://www.ptidej.net 24

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Background Work on the detection of bad smells Idea is that when something smells bad, it should be changed 02/08/10 WCRE2009 - S. Vaucher et al. 1
  • 2. Open Issues Identify factors that cause these smells to guide engineering efforts for : Prevention Detection Correction 02/08/10 WCRE2009 - S. Vaucher et al. 2
  • 3. How to Track Smells Use a nose Follow the evolution of a smell 02/08/10 WCRE2009 - S. Vaucher et al. 3
  • 4. • Nose• Systems• Analysis• Results• Thoughts on prevention and correctionOverview of the Presentation 02/08/10 WCRE2009 - S. Vaucher et al. 4
  • 5. The Nose 02/08/10 WCRE2009 - S. Vaucher et al. 5
  • 6. The Nose – 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 WCRE2009 - S. Vaucher et al. 6
  • 7. Nose – In Two Slides (2) God class? 47% Conditional probabilities Large Controller Class? MAX MAX MAX MAXDeals with Size Lexical Littledata Cohesionclasses 02/08/10 WCRE2009 - S. Vaucher et al. 7
  • 8. Systems 02/08/10 WCRE2009 - S. Vaucher et al. 8
  • 9. Xerces-J Eclipse JDT 02/08/10 WCRE2009 - S. Vaucher et al. 9
  • 10. Xerces-J Eclipse JDT 10-15% god classes 2% god classes 70% start as god 61% start as god classes classes 30% of god classes 19% of god classes are deleted are deletedSystem statistics 02/08/10 WCRE2009 - S. Vaucher et al. 10
  • 11. Analysis 02/08/10 WCRE2009 - S. Vaucher et al. 11
  • 12. • Find patterns in the evolution of the smell• Label these patterns• Analyse the commonalities of these patterns3 Step Program - Analysis 02/08/10 WCRE2009 - S. Vaucher et al. 12
  • 13. Data 02/08/10 WCRE2009 - S. Vaucher et al. 13
  • 14. • Use DTW to compare time-independent signals• Apply clustering to discover patterns• Apply classification to group and analyseTime-independent Analysis 02/08/10 WCRE2009 - S. Vaucher et al. 14
  • 15. Hierarchical agglomerative clustering using DTW as a distance measureSignal Constant (smelly) Gradual Gradual Temporary improvement degradation Relief Time Sharp Sharp Temporary improvement degradation badness Finding Patterns 02/08/10 WCRE2009 - S. Vaucher et al. 15
  • 16. Classifying Patterns 02/08/10 WCRE2009 - S. Vaucher et al. 16
  • 17. Xerces-J Eclipse JDTPattern Distribution 02/08/10 WCRE2009 - S. Vaucher et al. 17
  • 18. ~65% are always smelly Questions: Quick and dirty design or willful decision? ◦ Look for signs of design effort ◦ Ask the developersConstant Pattern 02/08/10 WCRE2009 - S. Vaucher et al. 18
  • 19. 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 hackConstant Pattern - Results 02/08/10 WCRE2009 - S. Vaucher et al. 19
  • 20. ~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 addedDegradation 02/08/10 WCRE2009 - S. Vaucher et al. 20
  • 21. Degradation – growth trends inXerces 02/08/10 WCRE2009 - S. Vaucher 21
  • 22. More classes are removed than are corrected (30% in Xerces)Reason justifying the study of antipatterns is to find some standard solutionsWere they used?Improvements 02/08/10 WCRE2009 - S. Vaucher et al. 22
  • 23. Eclipse, lots of added responsibility to data classes (rebalancing) Xerces, few textbook refactorings Not obvious since design correction often occurs with enhancementsImprovements –results 02/08/10 WCRE2009 - S. Vaucher et al. 23
  • 24. 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 classPrevention 02/08/10 WCRE2009 - S. Vaucher et al. 24
  • 25. Rules 02/08/10 WCRE2009 - S. Vaucher et al. 25
  • 26. 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 classCorrecting god classes 02/08/10 WCRE2009 - S. Vaucher et al. 26
  • 27. Methodology to track smells in systems Discussed the introduction and removal of smells in two open-source systemsWhat was said 02/08/10 WCRE2009 - S. Vaucher et al. 27
  • 28. 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 et al.What to remember 02/08/10 WCRE2009 - S. Vaucher et al. 28