Search

The presence of anti-patterns and code smells can affect adversely software evolution and quality. Recent work has shown that code smells that appear together in the same file (i.e., collocated smells) can interact with each other, leading to various types of maintenance issues and/or to the intensification of negative effects. It has also been found that code smell interactions can occur across coupled files (i.e., coupled smells), with comparable negative effects as the interaction of same-file (collocated) smells. Different inter-smell relations have been described in previous work, yet only few studies have evaluated them empirically. This study attempts to replicate the findings from previous work on inter-smell relations by analyzing larger systems, and by including both industrial and open source ones. We also include the analysis of coupled smells in addition to collocated smells, to achieve a more complete picture of inter-smell relations. Our results suggest that if coupled smells are not considered, one may risk increasing the number of false negatives when analysing inter-smells. A major finding is that patterns of inter-smell relations vary between open source and industrial systems, suggesting that contextual variables should be considered in further studies on code smells.

Code smells can be used to capture symptoms of code decay and potential maintenance problems that can be avoided by applying the right refactoring. They can be seen as a source of technical debt. However, tools for code smell detection often provide far too many and different results, and identify many false positive code smell instances. In fact, these tools are rooted on initial and rather informal code smell definitions. This represents a challenge to interpret their results in different ways. In this paper, we provide an Intensity Index, to be used as an estimator to determine the most critical instances, prioritizing the examination of smells and, potentially, their removal. We apply Intensity on the detection of six well known and common smells and we report their Intensity distribution from an analysis performed on 74 systems of the Qualitas Corpus, showing how Intensity could be used to prioritize code smells inspection.

We can evaluate software architecture quality using a plethora of metrics proposed in the literature, but interpreting and exploiting in the right way these metrics is not always a simple task. This is true for both fixing the right metric threshold values and determining the actions to be taken to improve the quality of the system. Instead of metrics, we can detect code or architectural anomalies that give us useful hints on the possible architecture degradation. In this paper, we focus our attention on the detection of code smells and in particular on their relations and co-occurrences, with the aim to evaluate technical debt in an architectural context. We start from the assumption that certain patterns of code anomalies tend to be better indicators of architectural degradation than simple metrics evaluation.

Code smells are archetypes of design shortcomings in the code that can potentially cause problems during maintenance. One known approach for detecting code smells is via detection rules: a combination of different object-oriented metrics with pre-defined threshold values. The usage of inadequate thresholds when using this approach could lead to either having too few observations (too many false negatives) or too many observations (too many false positives). Furthermore, without a clear methodology for deriving thresholds, one is left with those suggested in literature (or by the tool vendors), which may not necessarily be suitable to the context of analysis. In this paper, we propose a data-driven (i.e., benchmark-based) method to derive threshold values for code metrics, which can be used for implementing detection rules for code smells. Our method is transparent, repeatable and enables the extraction of thresholds that respect the statistical properties of the metric in question (such as scale and distribution). Thus, our approach enables the calibration of code smell detection rules by selecting relevant systems as benchmark data. To illustrate our approach, we generated a benchmark dataset based on 74 systems of the Qualitas Corpus, and extracted the thresholds for five smell detection rules.

When we develop a software project of a certain complexity, source code maintainability could become a problem, in particular if developers do not use a consolidate development process that simplifies the management of the entire project. When source code becomes very complex, it is difficult for developers to share and modify it. We can improve internal software qualities such as reusability, maintainability and readability through refactoring. Refactoring can be applied to remove possible problems in the code, as code smells. Identifying code smells and removing them through refactoring results in better code maintainability, but it can be an overwhelming task. In this paper, we describe our experimentation on using four refactoring tools to remove code smells in four systems, with the aim to outline advantages and disadvantages of the tools with respect to the accomplishment of this task, and to identify the smells easier to be removed among the ones we considered in this paper.

Refactoring is one of the key practices in Extreme Programming and other agile methods. Duplicated code is one of the most pervasive and pungent smells to remove from source code through refactoring. Duplicated code has been largely studied in the literature, and different types of duplications, or “clones”, have been identified. Some studies analyzed in details the problems caused by clones in the code, others outlined also the difficulties in removing clones, and the cases in which it could be better not removing them. The refactoring cost for removing clones can be very high, also due to the different choices on the possible refactoring steps. In this paper, we describe our approach and tool developed with the aim to suggest the best refactorings to remove clones in Java code. Our approach is based on the classification of the clones in terms of their location in a class hierarchy, and allows to choose among a restricted set of refactorings, which are then evaluated using multiple criteria. We provide a validation of the effectiveness of the approach.

The detection of design patterns is a useful activity giving support to the comprehension and maintenance of software systems. Many approaches and tools have been proposed in the literature providing different results. In this paper, we extend a previous work regarding the application of machine learning techniques for design pattern detection, by adding a more extensive experimentation and enhancements in the analysis method. Here we exploit a combination of graph matching and machine learning techniques, implemented in a tool we developed, called MARPLE-DPD. Our approach allows the application of machine learning techniques, leveraging a modeling of design patterns that is able to represent pattern instances composed of a variable number of classes. We describe the experimentations for the detection of five design patterns on 10 open source software systems, compare the performances obtained by different learning models with respect to a baseline, and discuss the encountered issues.

In the development of a fuzzy logic programming language fuzzy uni cation assumes a central role Several proposals have been made to give a formal and complete de nition of this operation In this paper we propose three di erent kinds of uni cation in the fuzzy context A fuzzy uni cation algorithm is presented ex tending through similarity relations the uni cation algorithm of Martelli Montanari used in the classical case An alternative ap proach is proposed through a Quotient Uni cation based on an equivalence relation which gives rise to equivalences classes that can be used in logic programming to identify similar objects Then Uni cation as Negotiation is described based on a more exible form of uni cation with semantic constraints Finally three fuzzy resolution rules are de ned based on the corresponding kinds of fuzzy uni cation introduced