1 / 23

Predicting Classes in Need of Refactoring: An Application of Static Metrics

Predicting Classes in Need of Refactoring – An Application of Static Metrics Liming Zhao Jane Hayes lzhao2@uky.edu hayes@cs.uky.edu 23 September 2006 2006 International PROMISE Workshop. Predicting Classes in Need of Refactoring: An Application of Static Metrics. Motivation Related work

lydie
Download Presentation

Predicting Classes in Need of Refactoring: An Application of Static Metrics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Predicting Classes in Need of Refactoring – An Application of Static MetricsLiming Zhao Jane Hayeslzhao2@uky.eduhayes@cs.uky.edu23 September 2006 2006 International PROMISE Workshop

  2. Predicting Classes in Need of Refactoring: An Application of Static Metrics • Motivation • Related work • Design of the tool • Study design • Study results • Conclusions and future work

  3. Motivation • Cost of software maintenance • Refactoring • Importance of refactoring planning • Need for improving multiple classes • Deadlines, human resources, budgets

  4. Refactoring steps • Identify code segments • Evaluate possible costs and benefits • Develop refactoring plan • Apply the refactorings

  5. Why use a class-based approach? • Common programmer(s) • Cohesive code • Learning effect • Comprehension overhead

  6. Proposed approach Maintainability Measurement & Prediction Component (MMPC) Visualizer Code Repository Analysis Complexity Size Coupling History Maintainability Prediction Model Candidate Classes Cost-Benefits Estimation Cost Benefits Refactoring Planning PrioritizedClassList Managers Cost & Benefit Estimation Component (CBEC)

  7. Design of the tool Code Repository Analysis Complexity Size Coupling History Maintainability Prediction Model CandidateClasses RefactoringPlanning

  8. Related work: Maintainability assessment • OO metrics – Chidamber and Kemerer [1994] • MI – Welker [1995] • PM and MP – Hayes et al. [2004] • Assessment of UML artifacts - Hassan et al. [2005] • RDC ratio – Hayes and Zhao [2005]

  9. Related work: Refactoring • Preconditions – Opdyke [1992] • Bad smells – Fowler et al. [1999] • Detecting bad smells – Mens et al. [2003] • Member similarity – Simon et al. [2001]

  10. Metrics examined • Halstead metrics • Cyclomatic complexity • Weighted method per class • Maintainability index

  11. Class-based rank • Cost concern • Priority class list • Individual rank • Comprehensive rank

  12. Code repository analysis and metrics collection • Code repository analyzer • Java front end • Abstract syntax tree • Metrics • Complexity • Size • Other • Weighted maintainability rank (WMR)

  13. Initial validation on student projects • Objective of the study • Measures examined • Tool’s performance • Programmers’ decisions • Tool vs. programmer • Time spent

  14. Study design • Participants: Graduate students in computer science • Subjects: Java source code (20 classes) from software engineering class project • Pre-reading: Questionnaire about background, smell-list, etc.

  15. Study design: procedure • Procedure instructed: • Fill in the questionnaire and read about the smell list • Read the code and look for “bad smells”; select a smell from a provided list or fill in a problem observed that was not in the list • Find the class with the most serious problems that should be refactored first • Record the time spent reviewing/reading each class

  16. Study Result: Compare reviewers’ selection with tool’s selection • Legend of class name abbreviations: A - AnimationScreen, F-FileOutPut, L-LoginScreen, P- PitchAnalyzer, S- SessionReport, E- ErrorWindow, G-Graphic, LO - LoudnessAnalyzer, R- RegistrationScreen, T - TestScreen, F- FileInputHandler, H - HistoryReport, M - MenuScreen, W- Welcome, I1 – ImagePanel1, I2 – ImagePanel2, L – LoginScreen

  17. Class Animation • Noted by 67% of the reviewers and the tool (ranked 1st by 50% of the reviewers and the tool) • Largest halstead_effort and smallest MI • Long method per class (LMC) and Complex method per class (CMC) above average (Slide 43)

  18. Metrics of class animation

  19. Study results • Tool and half of reviewers noted class Animation as worst • Reviewers spent a significant amount of time (1-3 hours) • More “easy” problems found (90%) • Reviewers looked for different smells (28% not in list)

  20. Conclusions • Complexity and size are among the major factors making comprehension hard • Reviewers are looking for different problems • Code reviewing is time-consuming • Automation can help consistency, efficiency, and effectiveness

  21. Future work • Predict the possible cost of the refactoring and its impact on code maintainability • Use metrics from evolution history • Use metrics reflecting inter-class relationships

  22. Acknowledgements • Thanks to Edison Design Group for providing JFE • Thanks to the graduate student volunteers for participating in the study

  23. Questions?

More Related