Code smells are symptoms of poor design and implementation choices. Previous studies empirically assessed the impact of smells on code quality and clearly indicate their negative impact on maintainability, including a higher bug-proneness of components affected by code smells. In this paper, we capture previous findings on bug-proneness to build a specialized bug prediction model for smelly classes. Specifically, we evaluate the contribution of a measure of the severity of code smells (i.e., code smell intensity) by adding it to existing bug prediction models based on both product and process metrics, and comparing the results of the new model against the baseline models. Results indicate that the accuracy of a bug prediction model increases by adding the code smell intensity as predictor. We also compare the results achieved by the proposed model with the ones of an alternative technique which considers metrics about the history of code smells in files, finding that our model works generally better. However, we observed interesting complementarities between the set of buggy and smelly classes correctly classified by the two models. By evaluating the actual information gain provided by the intensity index with respect to the other metrics in the model, we found that the intensity index is a relevant feature for both product and process metrics-based models. At the same time, the metric counting the average number of code smells in previous versions of a class considered by the alternative model is also able to reduce the entropy of the model. On the basis of this result, we devise and evaluate a smell-aware combined bug prediction model that included product, process, and smell-related features. We demonstrate how such model classifies bug-prone code components with an F-Measure at least 13 percent higher than the existing state-of-the-art models.

Different indexes have been proposed to evaluate software quality and technical debt. Usually these indexes take into account different code level issues and several metrics, well known software metrics or new ones defined ad hoc for a specific purpose. In this paper we propose and define a new index, more oriented to the evaluation of architectural violations. We describe in detail the index, called Architectural Debt Index, that we integrated in a tool developed for architectural smell detection. The index is based on the detection of architectural smells, their criticality and their history. Currently only dependency architectural smells have been considered, but other architectural debt indicators can be considered and integrated in the index computation.

Static source code analysis is an increasingly important activity to manage software project quality, and is often found as a part of the development process. A widely adopted way of checking code quality is through the detection of violations to specific sets of rules addressing good programming practices. SonarQube is a platform able to detect these violations, called Issues. In this paper we described an empirical study performend on two industrial projects, where we used Issues extracted on different versions of the projects to predict changes in code through a set of machine learning models. We achieved good detection performances, especially when predicting changes in the next version. This result paves the way for future investigations of the interest in an industrial setting towards the prioritization of Issues management according to their impact on change-proneness.

Software development is more and more influenced by the usage of FLOSS (Free, Libre and Open Source Software) projects. These software projects are developed in web collaborative environments hosted on web platforms, called code forges. Many code forges exist, with different capabilities. GitHub is perhaps the largest code forge available, and many projects have been migrated from different code forges to GitHub. Given its success, we want to understand if its adoption has effect on the projects' internal quality. To consider objective measures of internal quality, we apply four known tools performing static analysis to extract metrics and code anomalies. These data is extracted on six versions of six FLOSS projects, and compared to understand if the migration to GitHub had any consistent effect over any of the considered measures.

To better understand and exploit the knowledge necessary to comprehend and evolve an existing system, different models can be extracted from it. Models represent the extracted information at various abstraction levels, and are useful to document, maintain, and reengineer the system. The Knowledge Discovery Metamodel (KDM) has been defined by the object management group as a meta-model supporting a large share of reverse engineering activities. Its specification has also been adopted by the ISO in 2012. This paper explores and describes alternative meta-models proposed in the literature to support reverse engineering, program comprehension, and software evolution activities. We focus on the similarity and differences of the alternative meta-models with KDM, trying to understand the potentials of reciprocal information interchange. We describe KDM and other five meta-models, plus their extensions available in the literature and their diffusion in the reverse engineering community. We also investigate the approaches using KDM and the five meta-models. In the paper, we underline the limited reuse of models for reverse engineering, and identify potential directions for future related research, to enhance the existing models and ease the exchange of information among them.

Code smells represent well known symptoms of problems at code level, and architectural smells can be seen as their counterpart at architecture level. If identified in a system, they are usually considered more critical than code smells, for their effect on maintainability issues. In this paper, we introduce a tool for the detection of architectural smells that could have an impact on the stability of a system. The detection techniques are based on the analysis of dependency graphs extracted from compiled Java projects and stored in a graph database. The results combine the information gathered from dependency and instability metrics to identify flaws hidden in the software architecture. We also propose some filters trying to avoid possible false positives.

Code smells are symptoms of poor design and implementation choices. Previous studies empirically assessed the impact of smells on code quality and clearly indicate their negative impact on maintainability, including a higher bug-proneness of components affected by code smells. In this paper we capture previous findings on bug-proneness to build a specialized bug prediction model for smelly classes. Specifically, we evaluate the contribution of a measure of the severity of code smells (i.e., code smell intensity) by adding it to existing bug prediction models and comparing the results of the new model against the baseline model. Results indicate that the accuracy of a bug prediction model increases by adding the code smell intensity as predictor. We also evaluate the actual gain provided by the intensity index with respect to the other metrics in the model, including the ones used to compute the code smell intensity. We observe that the intensity index is much more important as compared to other metrics used for predicting the buggyness of smelly classes.

Anti-patterns and code smells are archetypes used for describing software design shortcomings that can negatively affect software quality, in particular maintainability. Tools, metrics and methodologies have been developed to identify these archetypes, based on the assumption that they can point at problematic code. However, recent empirical studies have shown that some of these archetypes are ubiquitous in real world programs, and many of them are found not to be as detrimental to quality as previously conjectured. We are therefore interested in revisiting common anti-patterns and code smells, and building a catalogue of cases that constitute candidates for "false positives". We propose a preliminary classification of such false positives with the aim of facilitating a better understanding of the effects of anti-patterns and code smells in practice. We hope that the development and further refinement of such a classification can support researchers and tool vendors in their endeavour to develop more pragmatic, context-relevant detection and analysis tools for anti-patterns and code smells.

Architecture erosion constitutes the most visible effect of the degradation of design. It is a major reason to address the design debt, often caused by architectural mismatch problems. Today, the identification of design erosion is a major concern for designers and software maintainers. Adequate tools are necessary to identify and repair the debt. This paper describes our experience on identifying architectural erosion problems on existing open source software applications through the support of two well known tools. Moreover, we outline if the tools provide useful hints in repairing some of the detected problems.

Many tools for code smell detection have been devel- oped, providing often different results. This is due to the informal definition of code smells and to the subjective interpretation of them. Usually, aspects related to the domain, size, and design of the system are not taken into account when detecting and analyzing smells. These aspects can be used to filter out the noise and achieve more relevant results. In this paper, we propose different filters that we have identified for five code smells. We provide two kind of filters, Strong and Weak Filters, that can be integrated as part of a detection approach.

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.

Version Control Systems (VCSs) provide historical information that can be used to perform deep analyses on the evolution of a software project, with the aim of enhancing the quality of the system and predicting software evolution.

Previous research determined that the analysis of file changes in software repositories is useful for maintenance activities, like defect prediction. Changes rarely modify the entire file contents, but are usually localized in specific code regions.

In this paper, an approach for information systems reverse engineering is proposed and applied. The aim is to support a unified perspective to the reverse engineering process of both data and software. At the state of the art, indeed, many methods, techniques, and tools for software reverse engineering have been proposed to support program comprehension, software maintenance, and software evolution. Other approaches and tools have been proposed for data reverse engineering, with the aim, for example, to provide complete and up-to-date documentation of legacy databases. However, the two engineering communities often worked independently, and very few approaches addressed the reverse engineering of both data and software as information system's constituencies. Hence, a higher integration is needed to support a better co-evolution of databases and programs, in an environment often characterized by high availability of data and volatility of information flows. Accordingly, the approach we propose leverages the detection of object-relational mapping design patterns to build a conceptual schema of the software under analysis. Then, the conceptual schema is mapped to the domain model of the system, to support the design of the evolution of the information system itself. The approach is evaluated on two large-scale open-source enterprise applications. Copyright © 2014 John Wiley & Sons, Ltd.

Several code smells detection tools have been developed providing different results, because smells can be subjectively interpreted and hence detected in different ways. Usually the detection techniques are based on the computation of different kinds of metrics, and other aspects related to the domain of the system under analysis, its size and other design features are not taken into account. In this paper we propose an approach we are studying based on machine learning techniques. We outline some common problems faced for smells detection and we describe the different steps of our approach and the algorithms we use for the classification.