DTEX : A GQM-based Bayesian approach for the detection of antipatterns

The presence of antipatterns can have a negative impact on the quality of a program. Consequently, their efficient detection has drawn the attention of both researchers and practitioners. However, most aspects of antipatterns are loosely specified because quality assessment is ultimately a human-centric process that requires contextual data. Consequently, there is always a degree of uncertainty on whether a class in a program is an antipattern or not. None of the existing automatic detection approaches handle the inherent uncertainty of the detection process. First, we present BDTEX (Bayesian Detection Expert), a Goal Question Metric (GQM) based approach to build Bayesian Belief Networks (BBNs) from the definitions ntipatterns etection of antipatterns. We discuss the advantages of BBNs over rule-based models and illustrate BDTEX on the Blob antipattern. Second, we validate BDTEX with three antipatterns: Blob, Functional Decomposition, and Spaghetti code, and two open-source programs: GanttProject v1.10. 2 and Xerces v2.7. 0. We also compare the results of BDTEX with those of another approach, DECOR, in terms of precision, recall, and utility. Finally, we also show the applicability of our approach in an industrial context using Eclipse JDT and JHotDraw and introduce a novel classification of antipatterns depending on the effort needed to map atic d their definitions to autom . Context and problem Software quality is important because of the complexity and ervasiveness of software systems. Moreover, the current trend n outsourcing development and maintenance requires means o measure quality with great details. Object-oriented quality is dversely impacted by antipatterns (Brown et al., 1998); their early etection and correction would ease development and mainteance. Antipatterns are “poor” solutions to recurring implementation nd design problems that impede the maintenance and evolution f programs. They are described using a template which describe heir general forms, their symptoms, their consequences, and some efactored solutions. The symptoms are often code smells (Fowler, 999). Even though a class in a program can present all symptoms f a given antipattern, it is not necessarily an antipattern. Moreover, hen discussing antipatterns, we do not exclude that, in a particPlease cite this article in press as: Khomh, F. , et al., BDTEX: A GQM-b Software (2011), doi:10.1016/j.jss. 2010.11. 921 lar context, an antipattern could be the best way to implement or esign a (part of a) program. For example, automatically generated arsers present many symptoms of Spaghetti Code, i.e., very large lasses with very long and complex methods. Only a quality analyst ∗ Corresponding author at: Department of Electrical and Computer Engineering, ueen’s University, Canada. Tel. : +1 613 533 6000x75542. E-mail address: foutse.khomh@queensu.ca (F. Khomh). 164-1212/$ – see front matter © 2010 Elsevier Inc. All rights reserved. oi:10.1016/j.jss. 2010.11. 921 etection approaches. © 2010 Elsevier Inc. All rights reserved. can evaluate the impact of antipatterns on their program in their context. All aspects of an antipattern are loosely specified because quality assessment is ultimately a human-centric process that requires contextual data. Consequently, there is always a degree of uncertainty on whether a class in a program is an antipattern or not. Therefore, detection results should be reported with the degree of uncertainty of the detection process. This uncertainty accounts for the loose definitions and the similarity of classes with the antipattern. There exist many approaches to specify and detect antipatterns. Some of these approaches are manual (Travassos et al., 1999), others are based on rules (Marinescu, 2004). Manual detection approaches avoid the problem of uncertainty, but do not scale up to the inspection of large systems. To the best of our knowledge, none of the existing automatic approaches provide a way to deal with the uncertainty of the detection. They provide quality analysts with an unsorted set of candidates classes with no indication of which one(s) should be inspected first for confirmation and correction. This paper builds on our previous work (Khomh et al., 2009) in which we illustrated the use of a Bayesian Belief Network (BBN) to specify the Blob antipattern and to detect its occurrences in proased Bayesian approach for the detection of antipatterns. J. Syst. grams. A Blob, also called God class (Riel, 1996), is a class that centralises functionality and has too many responsibilities. Brown et al. (1998) characterise its structure as a large controller class that depends on data stored in several surrounding data classes. Table 1 ARTICLE IN PRESS G Model JSS-8619; No. of Pages 14 2 F. Khomh et al. / The Journal of Systems and Software xxx (2011) xxx–xxx Table 1 List of detected antipatterns. The Blob (called also God class (Riel, 1996)) corresponds to a large controller class that depends on data stored in surrounded data classes. A large class declares many fields and methods with a low cohesion. A controller class monopolises most of the processing done by a system, takes most of the decisions, and closely directs the processing of other classes. We identify controller classes using suspicious names such as ‘Process’, ‘Control’, ‘Manage’, ‘System’, and so on. A data class contains only data and performs no processing on these data. It is composed of highly cohesive fields and accessors The Functional Decomposition antipattern may occur if experienced procedural developers with little knowledge of object-orientation implement an object-oriented system. Brown describes this antipattern as “a ‘main’ routine that calls numerous subroutines”. The Functional Decomposition design defect consists of a main class, i.e., a class with a procedural name, such as ‘Compute’ or ‘Display’, in which inheritance and polymorphism are scarcely used, that is associated with small classes, which declare many private fields and implement only few methods