Fehmi Fehmi Jaafar Jaafar, Yann , Yann- -Gal Gal Guhneuc - - PowerPoint PPT Presentation

Fehmi Fehmi Fehmi Fehmi Jaafar Jaafar Jaafar Jaafar, Yann , Yann , Yann , Yann-

• Gaël

Gaël Gaël Gaël Guéhéneuc Guéhéneuc Guéhéneuc Guéhéneuc, Sylvie Hamel, and , Sylvie Hamel, and , Sylvie Hamel, and , Sylvie Hamel, and Foutse Foutse Foutse Foutse Khomh Khomh Khomh Khomh

Université de Montréal École Polytechnique de Montréal Quebec Canada

1

1. 1. 1.

• 1. Introduction

Introduction Introduction Introduction 2. 2. 2.

• 2. Related

Related Related Related Work Work Work Work 3. 3. 3.

• 3. Problem

Problem Problem Problem Statement Statement Statement Statement 4. 4. 4.

• 4. Empirical

Empirical Empirical Empirical Study Study Study Study 4. 4. 4.

• 4. Empirical

Empirical Empirical Empirical Study Study Study Study 5. 5. 5.

• 5. Research

Research Research Research Questions Questions Questions Questions 6. 6. 6.

• 6. Results

Results Results Results 7. 7. 7.

• 7. Ongoing

Ongoing Ongoing Ongoing Work Work Work Work 8. 8. 8.

• 8. Conclusion

Conclusion Conclusion Conclusion

2

Anti-patterns describe poor solutions to design and implementation problems which are claimed to make object oriented systems hard to maintain. Anti-patterns indicate weaknesses in design that may slow down development

• r increase the risk of faults or failures in the future.

Classes in anti-patterns have some dependencies, such as static elationships, that may propagate potential problems to other classes.

3

Ostrand et al. [3] found that 20% of classes contains 80% of faults. At the same Change-Log Approaches[1] use process metrics extracted from the versioning system, assuming that recently or frequently changed classes are the most probable source of faults. Code-Metrics approaches[2] use source code metrics, assuming that complex

• r larger classes are more fault-prone.

Ostrand et al. [3] found that 20% of classes contains 80% of faults. At the same time, these 20% of classes accounted for 50% of the source code. Assuming that all classes are considered to have the same likelihood for fault- proneness is not realistic. We conjecture that, dependencies with design defects can impact the fault- proneness of classes.

4 [1] A. E. Hassan, “Predicting faults using the complexity of code changes,” in Proceedings of the 31st International Conference on Software Engineering, 2009. [2] R. Moser, W. Pedrycz, and G. Succi, “A comparative analysis of the efficiency of change metrics and static code attributes for defect prediction,” in Proceedings of the 30th international conference on Software engineering, 2008 [3] T. Ostrand, E. Weyuker, and R. Bell, “Predicting the location and number of faults in large software systems,” Software Engineering, IEEE Transactions, 2005.

Most previous fault prediction approaches were proposed to analyse fault- proneness using complexity code metrics and-or change metrics. While existing work has shown that anti-patterns are problematic, we believe that more attention should be focused on static and co-change relationships between anti-patterns classes and other classes without antipatterns. We conjecture that, static and co-change relationships with anti-patterns can We conjecture that, static and co-change relationships with anti-patterns can impact the fault-proneness classes without anti-patterns.

5

The class GoClassToNavigableClass. java belongs to a Blob anti-pattern in ArgoUML0.26. Concurrently, this class is co-changed with the class GoClassToAssociatedClass.java. Yet, in the Bugzilla database of ArgoUML, the bug ID55057 confirms that the two classes are related to the same fault.

6

Given a java program, we extracted its class diagrams using an existing tool PADL [3]. We use the DEtection for CORrection approach DÉCOR [4] , to specify and detect anti- patterns. We use the Ptidej tool suite to detect anti-patterns static relationships.

7 [3] Y.-G. Guéhéneuc and G. Antoniol, “DeMIMA: A multilayered framework for design pattern identification,” Transactions on Software Engineering (TSE), vol. 34, no. 5, pp. 667–684, 2008. [4] Naouel Moha, Y.-G. Guéhéneuc, L. Duchien, and A.-F. Le Meur, “DECOR: A method for the specification and detection of code and design smells,” Transactions on Software Engineering (TSE), 2010. [5] F. Jaafar, Y. Guéhéneuc, S. Hamel, and G. Antoniol, “An exploratory study of macro co-changes,” in Working Conference on Reverse Engineering (WCRE). IEEE, 2011,

We use the Ptidej tool suite to detect anti-patterns static relationships. We use Macocha [5] to mine software repositories and identify classes that are co- changing with anti-patterns.

8

RQ1: Are classes that have static relationships with anti-patterns more fault- prone than other classes? We test whether the proportion of classes in ArgoUML, JFreeChart, and XercesJ that have static relationships with anti-patterns classes have (or do not have) significantly

9

more faults than those that do not have static relationships with anti-patterns classes. RQ2: Are classes that co-change with anti-patterns more fault-prone than other classes? We test whether the proportion of co-changed classes with anti-patterns in ArgoUML, JFreeChart, and XercesJ have (or do not have) significantly more faults than the other classes.

HRQ10: The proportions of faults carried by classes having static relationships with anti-patterns and other classes are the same. We use Fisher’s exact test to check two hypothesis. We also compute the odds ratio that indicates the likelihood for an event to occur.

10

HRQ20: The proportions of faults involving classes having co-change dependencies with anti-patterns and other classes are the same. with anti-patterns and other classes are the same.

11

12

13

RQ1: Are classes that have static relationships with anti-patterns more fault-prone than other classes? For the three systems, the p-value is less then 0.05 and the likelihood that a class with static relationship(s) with anti-patterns experiences a fault (i.e.,

• dds ratio) is about two times higher than the likelihood that other classes
• dds ratio) is about two times higher than the likelihood that other classes

experience faults. We can answer positively to RQ1 as follows: classes having static relationships with anti-patterns are significantly more fault-prone than other classes.

14

RQ2: Are classes that co-change with anti-patterns more fault-prone than

• ther classes?

The result of Fisher’s exact test and odds ratios when testing HRQ20 are

• significant. For all the three systems, the p-value is less than 0.05 and the

likelihood that a class co-changing with anti-patterns experiences a fault likelihood that a class co-changing with anti-patterns experiences a fault (i.e., odds ratios) is about two and half times higher than the likelihood that

• ther classes experience faults.

We can answer positively to RQ2 as follows: classes co-changing with anti- patterns are significantly more fault-prone than other classes.

15

Other observations: We do not detect any class having static dependencies (use, association, aggregation, and composition relationships) or co-changed with SpaghettiCode. We observe that classes having static relationships with Blob, ComplexClass, We observe that classes having static relationships with Blob, ComplexClass, and SwissArmyKnife are significantly more fault prone than other classes with similar complexity, change history, and code size. Many anti-patterns’ relationships were with classes playing roles in design patterns. We found that classes that are co-changing with anti-patterns classes are significantly more fault prone than other classes with similar complexity, change history, and code size.

16

Relating anti-patterns dependencies and change-proneness.

17

Using these results to improve faults detection tools. Prevent change in anti-patterns classes. Replicating our study on other systems to assess the generalizability of our results, Studying the effect of knowing and using the relationships of anti-patterns and design patterns in maintenance tasks and comprehension effort.

We provide empirical evidence of the relationships between anti-patterns dependencies and fault proneness. We found that: We found that: We found that: We found that:

• Having static relationships with anti-patterns can significantly increase

fault-proneness.

• Classes having co-change dependencies with anti-patterns are more

fault prone than others.

18

We provide a basis for future research to understand the causes and the eventual consequences of these findings.