DECOR: A Method for the Specification and Detection of Code and Design Smells

Triskell Team, Univ. de Rennes 1, Rennes, France
IEEE Transactions on Software Engineering (Impact Factor: 1.61). 01/2010; 36(1):20-36. DOI: 10.1109/TSE.2009.50
Source: IEEE Xplore


Code and design smells are poor solutions to recurring implementation and design problems. They may hinder the evolution of a system by making it hard for software engineers to carry out changes. We propose three contributions to the research field related to code and design smells: 1) Decor, a method that embodies and defines all the steps necessary for the specification and detection of code and design smells, 2) Detex, a detection technique that instantiates this method, and 3) an empirical validation in terms of precision and recall of Detex. The originality of Detex stems from the ability for software engineers to specify smells at a high level of abstraction using a consistent vocabulary and domain-specific language for automatically generating detection algorithms. Using Detex, we specify four well-known design smells: the antipatterns Blob, Functional Decomposition, Spaghetti Code, and Swiss Army Knife, and their 15 underlying code smells, and we automatically generate their detection algorithms. We apply and validate the detection algorithms in terms of precision and recall on Xerces v2.7.0, and discuss the precision of these algorithms on 11 open-source systems.

Download full-text


Available from: Yann-Gaël Guéhéneuc, Apr 30, 2014
77 Reads
  • Source
    • ". This study was based on the detection rules proposed by Moha et al. [36] for the identification of the Blob antipattern. As an example, they suggest that classes with more than 90% of accessor methods can be characterized as data classes. "
    [Show abstract] [Hide abstract]
    ABSTRACT: Source code bad smells are usually resolved through the application of well-defined solutions, i.e., refactorings. In the literature, software metrics are used as indicators of the existence and prioritization of resolving bad smells. In this paper, we focus on the long method smell (i.e. one of the most frequent and persistent bad smells) that can be resolved by the extract method refactoring. Until now, the identification of long methods or extract method opportunities has been performed based on cohesion, size or complexity metrics. However, the empirical validation of these metrics has exhibited relatively low accuracy with regard to their capacity to indicate the existence of long methods or extract method opportunities. Thus, we empirically explore the ability of size and cohesion metrics to predict the existence and the refactoring urgency of long method occurrences, through a case study on java open-source methods. The results of the study suggest that one size and four cohesion metrics are capable of characterizing the need and urgency for resolving the long method bad smell, with a higher accuracy compared to the previous studies. The obtained results are discussed by providing possible interpretations and implications to practitioners and researchers.
    11th International Conference on Predictive Models and Data Analytics in Software Engineering (PROMISE 2015), Beijing, China; 10/2015
  • Source
    • "We decided to focus our attention on these code-smells because they are among the most related to faults or change proneness (Khomh et al., 2009) and the most common in the literature and frequently targeted for detection and correction in recent studies (see, for example, Kessentini et al., 2011; Ouni et al., 2013a,b,c; Moha et al., 2010). Hence, various approaches and tools supporting codesmells detection have been proposed in the literature such as JDeodorant (Tsantalis et al., 2008), infusion (Infusion hydrogen 2012), Décor (Moha et al., 2010), iPasma (iPlasma, 0000) Kessentini et al. (2011), Ouni et al. (2013a). The vast majority of these tools provide different environments and methods to detect code-smells. "
    [Show abstract] [Hide abstract]
    ABSTRACT: One of the widely used techniques to improve the quality of software systems is refactoring. Software refactoring improves the internal structure of the system while preserving its external behavior. These two concerns drive the existing approaches to refactoring automation. However, recent studies demonstrated that these concerns are not enough to produce correct and consistent refactoring solutions. In addition to quality improvement and behavior preservation, studies consider, among others, construct semantics preservation and minimization of changes. From another perspective, development history was proven as a powerful source of knowledge in many maintenance tasks. Still, development history is not widely explored in the context of automated software refactoring. In this paper, we use the development history collected from existing software projects to propose new refactoring solutions taking into account context similarity with situations seen in the past. We propose a multi-objective optimization-based approach to find good refactoring sequences that (1) minimize the number of code-smells, and (2) maximize the use of development history while (3) preserving the construct semantics. To this end, we use the non-dominated sorting genetic algorithm (NSGA-II) to find the best trade-offs between these three objectives. We evaluate our approach using a benchmark composed of five medium and large-size open-source systems and four types of code-smells (Blob, spaghetti code, functional decomposition, and data class). Our experimental results show the effectiveness of our approach, compared to three different state-of-the-art approaches, with more than 85% of code-smells fixed and 86% of suggested refactorings semantically coherent when the change history is used.
    Journal of Systems and Software 07/2015; 105. DOI:10.1016/j.jss.2015.03.040 · 1.35 Impact Factor
    • "Although, Extract Method could be possible solution, However if problem of scattering persists , it can accumulate many design anomalies [27]. Alternatively, the code could be moved into an aspect to get rid of fragility as aspects are known to modularize code cutting across the whole software architecture [35]. Similarly, we present our motivating example of God Class in Listing 2. where aspect-oriented re-factoring (AOR) seems better solution. "
    [Show description] [Hide description]
    DESCRIPTION: Publication was recommended minor revision and sent into Int'l Journal of Software Engineering and Knowledge Engineering, for another review.
Show more