Gustavo Vale

A review-based comparative study of bad smell detection tools

Bad smells are symptoms that something may be wrong in the system design or code. There are many bad smells defined in the literature and detecting them is far from trivial. Therefore, several tools have been proposed to automate bad smell detection aiming to improve software maintainability. However, we lack a detailed study for summarizing and comparing the wide range of available tools. In this paper, we first present the findings of a systematic literature review of bad smell detection tools. As results of this review, we found 84 tools; 29 of them available online for download. Altogether, these tools aim to detect 61 bad smells by relying on at least six different detection techniques. They also target different programming languages, such as Java, C, C++, and C#. Following up the systematic review, we present a comparative study of four detection tools with respect to two bad smells: Large Class and Long Method. This study relies on two software systems and three metrics for comparison: agreement, recall, and precision. Our findings support that tools provide redundant detection results for the same bad smell. Based on quantitative and qualitative data, we also discuss relevant usability issues and propose guidelines for developers of detection tools.

A Method to Derive Metric Thresholds for Software Product Lines

A software product line (SPL) is a set of software systems that share a common and variable set of components (features). Software metrics provide basic means to quantify several quality aspects of SPL components. However, the effectiveness of the SPL measurement process is directly dependent on the definition of reliable thresholds. If thresholds are not properly defined, it is difficult to actually know whether a given metric value indicates a potential problem in the component implementation. There are several methods to derive thresholds for software metrics. However, there is little understanding about their appropriateness for the context of SPLs. This paper aims to propose a method to derive thresholds in the SPL context. Our method is evaluated in terms of recall and precision using two code smells (God Class and Lazy Class) detection strategies. The evaluation of our method is performed based on a benchmark of 33 SPLs and the results were compared with a method (baseline) with the same purpose used in the context of SPLs (not proposed). The results show that our method has better recall when compared with baseline.

Software Variability Management: An Exploratory Study with Two Feature Modeling Tools

Software Product Line (SPL) is becoming widely adopted in industry due to its capability of minimizing costs and improving quality of software systems through systematic reuse of software artifacts. An SPL is a set of software systems sharing a common, managed set of features that satisfies the specific needs of a particular market segment. A feature represents an increment in functionality relevant to some stakeholders. There are several tools to support variability management by modeling features in SPL. However, it is hard for a developer to choose the most appropriate feature modeling tool due to the several options available. This paper presents the results of an exploratory study aiming to support SPL engineers choosing the feature modeling tool that best fits their needs. This exploratory study compares and analyzes two feature modeling tools, namely FeatureIDE and SPLOT, based on data from 56 participants that used the analyzed tools. In this study, we performed a four-dimension qualitative analysis with respect to common functionalities provided by feature modeling tools: (i) Feature Model Editor, (ii) Automated Analysis of Feature Models, (iii) Product Configuration, and (iv) Tool Notation. The main issues we observed in SPLOT are related to its interface. FeatureIDE, on the other hand, revealed some constraints when creating feature models.

Bad Smells in Software Product Lines: A Systematic Review

Software product line (SPL) is a set of software systems that share a common, managed set of features satisfying the specific needs of a particular market segment. Bad smells are symptoms that something may be wrong in system design. Bad smells in SPL are a relative new topic and need to be explored. This paper performed a Systematic Literature Review (SLR) to find and classify published work about bad smells in SPLs and their respective refactoring methods. Based on 18 relevant papers found in the SLR, we identified 70 bad smells and 95 refactoring methods related to them. The main contribution of this paper is a catalogue of bad smells and refactoring methods related to SPL.

Metrics for feature-oriented programming

Feature-oriented programming (FOP) is a programming technique to implement software product lines based on composition mechanisms called refinements. A software product line is a set of software systems that share a common, managed set of features satisfying the specific needs of a particular market segment. The literature reports various software metrics for software product lines developed using object-oriented and aspect-oriented programming. However, after a literature review, we observed that we lack the definition of FOP-specific metrics. Based on this observation, this paper proposes a set of eight novel metrics for feature-oriented programming. These metrics were derived both from our experience in FOP and from existing software metrics. We demonstrate the applicability of the proposed metrics by applying them to a software product line.

TDTool: threshold derivation tool

Software metrics provide basic means to quantify quality of software systems. However, the effectiveness of the measurement process is directly dependent on the definition of reliable thresholds. If thresholds are not properly defined, it is difficult to know, for instance, whether a given metric value indicates a potential problem in a class implementation. There are several methods proposed in literature to derive thresholds for software metrics. However, most of these methods (i) do not respect the skewed distribution of software metrics and (ii) do not provide a supporting tool. Aiming to fill the second gap, we propose a tool, called TDTool, to derive metric thresholds. TDTool is open source and supports four different methods for threshold derivation. This paper presents TDTool architecture and illustrates how to use it. It also presents the thresholds derived using each method based on a benchmark of 33 software product lines.

Systematic literature review supported by information retrieval techniques: A case study

Systematic Literature Review (SLR) is a means to synthesize relevant and high quality studies related to a specific topic or research questions. In general, a SLR has three phases, and the first one is the Primary Selection in which the selection of studies is usually performed manually reading title, abstract and keywords of each study. The number of published scientific studies has grown, increasing effort in carrying out this review. In this paper, we proposed two strategies to rank studies in decreasing order of importance, for a SLR, regarding the terms in the search string. These strategies are based on the Information Retrieval technique Vector Model. We implemented those strategies and conducted a case study to evaluate their applicability. As results, the second strategy presents 50% of precision on a recall of 80%. Among the contributions of this study, two strategies to rank relevant documents in a SLR, regarding the search string, were proposed and analyzed.

No Code Anomaly is an Island

A software product line (SPL) is a set of systems that share common and varying features. To provide large-scale reuse, the components of a SPL should be easy to maintain. Therefore, developers have to identify anomalous code structures – i.e., code anomalies – that are detrimental to the SPL maintainability. Otherwise, SPL changes can eventually propagate to seemly-unrelated features and affect various SPL products. Previous work often assume that each code anomaly alone suffices to characterize SPL maintenance problems, though each single anomaly may represent only a partial, insignificant, or even inexistent view of the problem. As a result, previous studies have difficulties in characterizing anomalous structures that indicate SPL maintenance problems. In this paper, we study the surrounding context of each anomaly and observe that certain anomalies may be interconnected, thereby forming so-called anomaly agglomerations. We characterize three types of agglomerations in SPL: feature, feature hierarchy, and component agglomeration. Two or more anomalies form an agglomeration when they affect the same SPL structural element, i.e. a feature, a feature hierarchy, or a component. We then investigate to what extent non-agglomerated and agglomerated anomalies represent sources of a specific SPL maintenance problem: instability. We analyze various releases of four feature-oriented SPLs. Our findings suggest that a specific type of agglomeration indicates up to 89% of sources of instability, unlike non-agglomerated anomalies.

Evaluating domain-specific metric thresholds: an empirical study

Software metrics and thresholds provide means to quantify several quality attributes of software systems. Indeed, they have been used in a wide variety of methods and tools for detecting different sorts of technical debts, such as code smells. Unfortunately, these methods and tools do not take into account characteristics of software domains, as the intrinsic complexity of geo-localization and scientific software systems or the simple protocols employed by messaging applications. Instead, they rely on generic thresholds that are derived from heterogeneous systems. Although derivation of reliable thresholds has long been a concern, we still lack empirical evidence about threshold variation across distinct software domains. To tackle this limitation, this paper investigates whether and how thresholds vary across domains by presenting a large-scale study on 3,107 software systems from 15 domains. We analyzed the derivation and distribution of thresholds based on 8 well-known source code metrics. As a result, we observed that software domain and size are relevant factors to be considered when building benchmarks for threshold derivation. Moreover, we also observed that domain-specific metric thresholds are more appropriated than generic ones for code smell detection.

Applying Information Retrieval Techniques to Detect Duplicates and to Rank References in the Preliminary Phases of Systematic Literature Reviews

Systematic Literature Review (SLR) is a means to synthesize relevant and high quality studies related to a specific topic or research questions. In the Primary Selection stage of an SLR, the selection of studies is usually performed manually by reading title, abstract, and keywords of each study. In the last years, the number of published scientific studies has grown increasing the effort to perform this sort of reviews. In this paper, we proposed strategies to detect non-papers and duplicated references in results exported by search engines, and strategies to rank the references in decreasing order of importance for an SLR, regarding the terms in the search string. These strategies are based on Information Retrieval techniques. We implemented the strategies and carried out an experimental evaluation of their applicability using two real datasets. As results, the strategy to detect non-papers presented 100% of precision and 50% of recall; the strategy to detect duplicates detected more duplicates than the manual inspection; and one of the strategies to rank relevant references presented 50% of precision and 80% of recall. Therefore, the results show that the proposed strategies can minimize the effort in the Primary Selection stage of an SLR.