Eduardo Fernandes

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.

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.

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.

FindSmells: flexible composition of bad smell detection strategies

Bad smells are symptoms of problems in the source code of software systems. They may harm the maintenance and evolution of systems on different levels. Thus, detecting smells is essential in order to support the software quality improvement. Since even small systems may contain several bad smell instances, and considering that developers have to prioritize their elimination, its automated detection is a necessary support for developers. Regarding that, detection strategies have been proposed to formalize rules to detect specific bad smells, such as Large Class and Feature Envy. Several tools like JDeodorant and JSpIRIT implement these strategies but, in general, they do not provide full customization of the formal rules that define a detection strategy. In this paper, we propose FindSmells, a tool for detecting bad smells in software systems through software metrics and their thresholds. With FindSmells, the user can compose and manage different strategies, which run without source code analysis. We also provide a running example of the tool. Video: https://youtu.be/LtomN93y6gg.

How does refactoring affect internal quality attributes?: A multi-project study

Refactoring is a technique commonly applied by developers along the software maintenance and evolution. Software refactoring is expected to improve the internal quality attributes of a software project, such as coupling and cohesion. However, there is limited understanding on to what extent developers achieve this expectation when refactoring their source code This study investigates how refactoring operations affect five well-known internal quality attributes: cohesion, coupling, complexity, inheritance, and size. For this purpose, we analyze the version history of 23 open source projects with 29,303 refactoring operations. Our analysis revealed interesting observations. First, we noticed that developers apply more than 94% of the refactoring operations to code elements with at least one critical internal quality attribute, as opposed to previous work. Second, 65% of the refactoring operations improve their related internal quality attributes and the remaining 35% operations keep the quality attributes unaffected. Third, whenever pure refactoring operations are applied (the so-called root-canal refactoring), we confirm that internal quality attributes are either frequently improved or at least not worsened. Finally, while refactoring operations often reach other specific aims, such as adding a new feature or fixing a bug, 55% of these operations surprisingly improve internal quality attributes against only 10% of quality decline.

Investigating how features of online learning support software process education

Online courses are a method of lecturing whose application in education is not bounded by space and location constraints. They include features such as video lectures and online questionnaires. There are a few online courses to teach subjects related to Software Engineering. However, for the best of our knowledge, there is no online course to teach software process, which is a key area of Software Engineering. More important, there is no systematic study to investigate whether this way of teaching is efficient and viable to teach software process. This paper presents an empirical study to evaluate whether and how online features support the learning of software process in the light of an online Software Engineering course with 61 video lectures, 16 online questionnaires, and a discussion forum. This study relies on data of 100 undergraduate students over three consecutive years: 2014, 2015, and 2016. Data of this study suggest that students answer online questionnaires in order to review for face-to-face exams. Our results also show that videos and online questionnaires contribute to the improvement of up to 15% of student grades in software process questions when compared with students who neither watch videos nor answer online questionnaires. However, based on two exam questions that repeated over the three years, we verify that the grade improvement seems to be mostly related to video lectures watched, rather than to online questionnaires answered.

Poster: The Buggy Side of Code Refactoring: Understanding the Relationship Between Refactorings and Bug

Code refactoring is widely practiced by software developers. There is an explicit assumption that code refactoring improves the structural quality of a software project, thereby also reducing its bug proneness. However, refactoring is often applied with different purposes in practice. Depending on the complexity of certain refactorings, developers might unconsciously make the source code more susceptible to have bugs. In this paper, we present a longitudinal study of 5 Java open source projects, where 20,689 refactorings, and 1,033 bug reports were analyzed. We found that many bugs are introduced in the refactored code as soon as the first immediate change is made on it. Furthermore, code elements affected by refactorings performed in conjunction with other changes are more prone to have bugs than those affected by pure refactorings.

On the proposal and evaluation of a benchmark-based threshold derivation method

Software-intensive systems have been growing in both size and complexity. Consequently, developers need better support for measuring and controlling the software quality. In this context, software metrics aim at quantifying different software quality aspects. However, the effectiveness of measurement depends on the definition of reliable metric thresholds, i.e., numbers that characterize a metric value as critical given a quality aspect. In fact, without proper metric thresholds, it might be difficult for developers to indicate problematic software components for correction, for instance. Based on a literature review, we have found several existing methods for deriving metric thresholds and observed their evolution. Such evolution motivated us to propose a new method that incorporates the best of the existing methods. In this paper, we propose a novel benchmark-based method for deriving metric thresholds. We assess our method, called Vale’s method, using a set of metric thresholds derived with the support of our method, aimed at composing detection strategies for two well-known code smells, namely god class and lazy class. For this purpose, we analyze three benchmarks composed of multiple software product lines. In addition, we demonstrate our method in practice by applying it to a benchmark composed of 103 Java open-source software systems. In the evaluation, we compare Vale’s method to two state-of-the-practice threshold derivation methods selected as a baseline, which are Lanza’s method and Alves’ method. Our results suggest that the proposed method provides more realistic and reliable thresholds, with better recall and precision in the code smell detection, when compared to both baseline methods.

Detection Strategies for Modularity Anomalies: An Evaluation with Software Product Lines

A Software Product Line (SPL) is a configurable set of systems that share common and varying features. SPL requires a satisfactory code modularity for effective use. Therefore, modularity anomalies make software reuse difficult. By detecting and solving an anomaly, we may increase the software quality and ease reuse. Different detection strategies support the identification of modularity anomalies. However, we lack an investigation of their effectiveness in the SPL context. In this paper, after an evaluation of existing strategies, we compared four strategies from the literature for two modularity anomalies that affect SPLs: God Class and God Method. In addition, we proposed two novel detection strategies and compared them with the existing ones, using three SPLs. As a result, existing strategies showed high recall but low precision. In addition, when compared to detection strategies from the literature, our strategies presented comparable or higher recall and precision rates for some SPLs.

Identification and Prioritization of Reuse Opportunities with JReuse

Software reuse aims to decrease the development efforts by using existing software components in the development of new systems. Previous work propose tools to support the identification of reuse opportunities. Such tools apply different techniques, such as software design and source code analyses. However, none of them combines lexical analysis with prioritization and identification of reuse opportunities in several systems of a single domain. To fill this gap, this paper proposes JReuse, a tool that computes naming similarity for classes and methods of Java systems. Based on naming similarity, JReuse identifies reuse opportunities and prioritizes them by their frequency among systems. We evaluate JReuse with 35 e-commerce systems collected from GitHub by assessing the agreement among the JReuse recommendations and the opinion of a group of experts. We observe agreements of 89% and 72% for classes and methods, respectively. Therefore, our data suggest that JReuse is able to recommend reusable classes and methods in a given domain.