Design Defects

Code smells [44] and antipatterns [23], collectively called in the following de- sign defects, are poor solutions to recurring software design problems. They occur generally in object-oriented systems when developers lack knowledge and–or expe- rience to solve a design problem or apply a design pattern [47].

2.3.1 Specification of Design Defects

Several books relate to design defects. Webster [136] wrote the first book on anti-patterns in object-oriented development; his contribution covers conceptual, political, coding, and quality-assurance problems. Riel [117] defined 61 heuristics characterising “good” object-oriented programming. These heuristics deal with classes, objects, and relations. They allow developers to assess the quality of their systems manually and provide a basis to improve designs and implementations. Fowler [44] defined 22 code smells that are low-level design defects in the source code of systems, suggesting that developers should apply refactorings. Code smells are described in an informal style and associated with methods to locate them through manual inspection of the source code. M¨antyl¨a [95] and Wake [135] proposed classifications of code smells. Brown’s book [23] is more focused on the design and implementation of object-oriented systems than Webster’s. Brown et al. described about 40 anti-patterns textually, which are general object-oriented design defects and include well-known antipatterns, such as Blob.

These books provide in-depth views on heuristics, code smells, and anti-patterns aimed at a wide academic and industrial audience. However, it is difficult to build detection and correction algorithms from their textual descriptions, because they lack precision and are prone to misinterpretations. We build upon this work to propose an approach to characterise design defects and identify classes with similar characteristics. We use the term defect to acknowledge that, in certain contexts, a smell or an antipattern may be unavoidable and the best way to design and–or implement (part of) a system. For example, parsers are often Spaghetti Code.

2.3.2 Detection of Design Defects

Several approaches to specify and detect design defects have been proposed in the literature. They range from manual approaches, based on inspection tech- niques [131], to metric-based heuristics [96, 99, 102], where smells are detected according to sets of rules and thresholds defined on various metrics. Manual ap- proaches were defined, for example, by Travassos et al. [131], who introduced man- ual inspections and reading techniques to detect code smells.

Marinescu [96] presented a metric-based approach to detect smells with detec- tion strategies, which capture deviations from good design principles and consist of combining metrics with set operators and comparing their values against absolute and relative thresholds. Similarly to Marinescu, Munro [102] proposed metric-based heuristics to detect code smells; the heuristics are derived from template similar to the one used for design patterns [47]. He also performed an empirical study to justify the choice of metrics and thresholds.

Moha et al. [99] proposed the DECOR method to specify and automatically generate detection algorithms. DECOR includes a domain-specific language based on a literature review of existing work. It also includes algorithms and a platform to automatically convert specifications into detection algorithms and apply these algorithms on any system. DECOR produces detection algorithm with good pre- cision and perfect recall while allowing quality assurance personnel to adapt the specifications to their context.

Khomh et al. [77] argued that threshold-based approaches do not handle the uncertainty of the detection results and, therefore, miss borderline classes, i.e., classes with characteristics of design smells “surfacing” slightly above or “sinking” slightly below the thresholds because of minor variations in their characteristics. Consequently, they proposed a Bayesian Belief Network (BBN) for the detection of design smells in systems, which output the probability that a class exhibiting the characteristics of a smell truly concerns a smell. Thus, their approach handles the degree of uncertainty for a class to be a smell. They also showed that BBNs can be calibrated using historical data both from a similar and from a different context.

Oliveto et al. [118] proposed ABS, an approach to detect design smells in sys- tems using signatures of the classes and of the smells. ABS is based on a similarity

22 computed via a numerical analysis technique using B-splines. The basis of ABS is the building of signatures of classes based on quality metrics, as in [59], using specific interpolation curves (i.e., B-splines [37]) of plots mapping metrics and their values for the class. They computed the similarity of a given class to an antipattern by calculating the distance between the curve of the class and the curves of classes previously classified as antipatterns. They reported a case study and claimed that ABS outperforms previous approaches in precision and recall while being simpler in practice.

Some visualisation techniques [124], were used to find a compromise between fully-automatic detection techniques, which are efficient but lose track of the con- text, and manual inspections, which are slow and subjective. Other approaches perform fully-automatic detection and use visualisation to present the detection results [85, 132].

Catal et al. [32] used several machine learning algorithms to predict the defective modules. They investigated the effects of dataset size, metrics set, and feature selection techniques for software fault prediction problem. They employed several algorithms based Artificial Immune Systems.

Kessentini et al. [75] independently used an Artificial Immune System to es- timate the risks of classes to deviate from “normality”, i.e., a set of classes rep- resenting a “good” design. They used structural data to describe a design, i.e., classes, fields and methods. They showed that 90% of the most risky classes in GanttProject and Xerces contained defects.

2.3.3 Impact of Design Defects

Despite the above studies on design defects, only a few studies empirically anal- ysed the impact of design defects on source code-related phenomena, in particular class change- and fault-proneness.

Bois et al. [18] showed that the decomposition of God Classes into a number of collaborating classes using well-known refactorings can improve comprehension. They did not consider source code evolution phenomena.

Wei and Shatnawi [91] investigated the relation between the probability of a class being faulty and some antipatterns based on three versions of Eclipse, showed

that classes with the antipatterns God Class, Shotgun Surgery, and Long Method have a higher probability to be faulty than other classes. They concluded that there was a need for broader studies to validate their results.

Olbrich et al. [107] analysed the historical data of Lucene and Xerces over several years and concluded that God Classes and Shotgun Surgery have a higher change frequency than other classes; with God Classes featuring more changes. They neither performed an analysis to control the effect of the size on their results nor studied the kinds of changes affecting these antipatterns.

Khomh et al. [76, 78] studied the impact of classes with design defects (code smells and antipatterns) on change proneness and fault proneness. They showed that classes participating in design defects are more change- and fault-prone than classes not participating in design defects.

2.3.4 Discussion

Previous approaches advanced the state-of-the-art in the specification and de- tection of design defects but all require expert knowledge and interpretation. More- over, they focus on detecting one kind of design defect at a time, while some design defects are similar and classes with characteristics similar but no identical to some design defects are also of interest to developers and quality assurance personnel. In Chapter 5, we propose an immune-inspired approach for the detection of de- sign defects. We use object-oriented metrics [34] computed on instances of smells as input to our algorithm following our parallel between object-oriented software systems and living bodies. We analyses our approach in two distinct, industrial- like scenarios. We also discuss all the advantages of our approach over previous approaches, including precision and recall.

This previous work raised the community awareness regarding the impact of code smells and antipatterns on software development. We build on this previous work and propose a more detailed and extensive empirical study of the impact of design defects on design decay phenomena (see Chapter 3).