Presentation is loading. Please wait.

Presentation is loading. Please wait.

Reviewed By: Paul Varcholik University of Central Florida EEL 6883 – Software Engineering II Spring 2009 Marc Eaddy, Thomas Zimmermann,

Similar presentations


Presentation on theme: "Reviewed By: Paul Varcholik University of Central Florida EEL 6883 – Software Engineering II Spring 2009 Marc Eaddy, Thomas Zimmermann,"— Presentation transcript:

1 Reviewed By: Paul Varcholik University of Central Florida pvarchol@ist.ucf.edu EEL 6883 – Software Engineering II Spring 2009 Marc Eaddy, Thomas Zimmermann, Kaitlin Sherwood, Vibhav Garg, Gail Murphy, Nachiappan Nagappan, Alfred Aho IEEE Transactions on Software Engineering July-Aug. 2008

2 What is Crosscutting?  Implementation, of a concern, that is scattered across the program  A concern is any consideration that can impact the implementation of a program.  Features from a feature list  Requirements  Design patterns and design elements for a UML design document  Low-level programming concerns  Language  Coding Style  Algorithms

3 Research Question  How much does the amount that a concern is crosscutting affect the number of defects in a program?  Hypothesis The more scattered a concern’s implementation is, the more defects it will have, regardless of the implementation size.  Examined through three extensive case studies

4 Why Might Crosscutting Concerns Cause Defects?  A crosscutting concern is: Harder to implement and modify ○ Multiple – possibly unrelated – locations in the code have to be found and updated simultaneously Harder to understand ○ Developers must mentally untangle the code

5 Why Might Crosscutting Concerns Cause Defects?  Crosscutting first emerges when the developer creates – perhaps without realizing it – a concern implementation plan.  Maintainers may proceed without a full understanding of the scattered nature of the implementation.

6 Prior Work  Several empirical studies  Evidence that crosscutting concerns degrade code quality because they negatively impact internal quality metrics Program size Coupling Separation of concerns (modularization)

7 Additional Terminology  A concern is scattered if it is related to multiple target elements.  A concern is tangled if both it and at least one other concern are related to the same target element.

8 Model  Concern – an item from a program’s non-executable specification  Program Elements Classes Fields Methods  Defect – a software bug

9 Concern Metrics Bug CountNumber of unique bugs associated with the concern. Program Element Contribution (CONT) Lines of code in the program element associated with the concern. Lines of Concern Code (LOCC) Total number of LOC that contribute to the implementation of the concern. Concern Diffusion over Components (CDC) Number of classes that contribute to the implementation of a concern and other classes and aspects with access them. Concern Diffusion over Operations (CDO) Number of methods which contribute to a concern’s implementation plus the number of other methods and advice accessing them. Degree of Scattering across Classes (DOSC) Degree to which the concern code is distributed across classes (0 to 1). 0 – all code is in one class 1 – codes is equally divided among all classes Degree of Scattering across Methods (DOSM) Degree to which the concern code is distributed across methods (0 to 1).

10 Methodology 1. Reverse Engineer the concern-code mapping (subjective) 2. Mine the bug-code mapping 3. Infer the bug-concern mapping

11 Case Studies  Mylyn-Bugzilla Eclipse plug-in  Rhino JavaScipt/ECMAScript interpreter and compiler  iBATIS Object-Relational mapping

12 Spearman Correlation Coefficients Range: -1.0 (a perfect negative correlation) to 1.0 (a perfect positive correlation)

13 Conclusion  All three studies showed a moderate-to- strong correlation between the degree of scattering and the number of defects. Concern scattering is correlated with defects.  But does it cause defects? Three criteria for causality: 1. Cause must precede the effect 2. A correlation must exist 3. The correlation must not be spurious

14 Strengths  Novel (appears to be first empirical study to examine crosscutting-defect correlation)  Well written  Solid statistical analysis  Technically sound methodology  Simple, but important, hypothesis

15 Weaknesses  Small study size (3 projects)  Human analyst for estimating concern- code mapping  Questionable techniques for identifying concerns (requirements)  Some misstatements in the paper  Do these results generalize? (e.g. across languages)

16 Final Thoughts  Study needs to be replicated  Can defects be reduced by reducing crosscutting?  Why does crosscutting occur? Programming technology Developer aptitude Inherent complexity of the concern

17 Marc Eaddy, Thomas Zimmermann, Kaitlin Sherwood, Vibhav Garg, Gail Murphy, Nachiappan Nagappan, Alfred Aho IEEE Transactions on Software Engineering July-Aug. 2008 Reviewed By: Paul Varcholik University of Central Florida pvarchol@ist.ucf.edu EEL 6883 – Software Engineering II Spring 2009


Download ppt "Reviewed By: Paul Varcholik University of Central Florida EEL 6883 – Software Engineering II Spring 2009 Marc Eaddy, Thomas Zimmermann,"

Similar presentations


Ads by Google