Search

In software maintenance and evolution, it is important to assess both code and architecture in order to identify issues to be solved to improve software quality. Different tools provide some kind of index giving us an overall evaluation of a project to be used when managing its technical debt. In this paper, we outline how the indexes, that we call in general Technical Debt Indexes, provided by five different tools are computed. We describe their principal features and differences, what aspects they are missing, and we outline if (and how) the indexes take into account architectural problems that could have a major impact on the architectural debt. We show that the indexes rely on different information sources and measure different quantities.

During software development, maintenance and evolution, we can assess the quality of code, design and architecture to capture hints of possible problems and face them as soon as possible. We can capture signals of architecture erosion in different ways by exploiting several tools with the aim to identify architectural violations, architectural smells or other relevant features. In this paper, we provide our experience report in using three known tools to capture information that can be useful to identify and evaluate the architectural debt of an application. We outline the main differences among these tools and the results they produce.

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.

We can improve software quality in different ways and by removing different kinds of problems. In this paper, we focus our attention on architectural problems, as architectural smells or antipatterns represent, we remove some of these problems through refactoring steps and we check the impact that the refactoring has on different quality metrics. In particular, we focus our attention on some Quality Indexes computed by four tools. These tools are used also for the detection of the architectural problems. We present the results and outline different issues related to the impact of the refactoring of these architectural problems on the Quality Indexes and the difficulties in the choice of the problems to be refactored.

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.

Several code smell detection tools have been developed providing different results, because smells can be subjectively interpreted, and hence detected, in different ways. In this paper, we perform the largest experiment of applying machine learning algorithms to code smells to the best of our knowledge. We experiment 16 different machine-learning algorithms on four code smells (Data Class, Large Class, Feature Envy, Long Method) and 74 software systems, with 1986 manually validated code smell samples. We found that all algorithms achieved high performances in the cross-validation data set, yet the highest performances were obtained by J48 and Random Forest, while the worst performance were achieved by support vector machines. However, the lower prevalence of code smells, i.e., imbalanced data, in the entire data set caused varying performances that need to be addressed in the future studies. We conclude that the application of machine learning to the detection of these code smells can provide high accuracy (>96 %), and only a hundred training examples are needed to reach at least 95 % accuracy.

Th…e paper analyses the ritual practices recorded in the Tas-Silġ sanctuary, in the island of Malta, focusing on what features can be retraced for the historical phases prior to the Late republican age, between 8th and 2nd century BC. …e ‡rst period (8th-5th century BC) refers to the Phoenician phase of the site: the new structures do not seem to interfere with the prehistoric temple, which is kept unaltered. …e worshipped deity – known from the inscriptions – is Astarte: the complex personality of the goddess, featuring traits belonging to the local tradition, has marked chthonian characters, as testi‡ed by the existence of the recently explored hypogeum structures. …e new elements added in the sacri‡cial area over the timespan between 4th and 2nd century BC reveal a new openness towards Mediterranean inˆuences; the hypogeum is not used for rituals anymore, and the chthonian traits of the cult clearly lose strenghth, probably under the inˆuence of the new cultural context.

Network analysis views complex systems as networks with well-defined structural properties that account for their complexity. These characteristics, which include scale-free behavior, small worlds and communities, are not to be found in networks such as random graphs and lattices that do not correspond to complex systems. They provide therefore a robust ground for claiming the existence of “complex networks” as a non-trivial subset of networks. The theory of complex networks has thus been successful in making systematically explicit relevant marks of complexity in the form of structural properties, and this success is at the root of its current popularity. Much less systematic has been, on the other hand, the definition of the properties of the building components of complex networks. The obvious assumption is that these components must be nodes and links. Generally, however, the internal structure of nodes is not taken into account, and links are serendipitously identified by the perspective with which one looks at the network to be analyzed. For instance, if the nodes are Web pages that contain information about scientific papers, one point of view will match the relevant links with hyperlinks to similar Web pages, and another with citations of other articles. We intend to contribute here a systematic approach to the identification of the components of a complex network that is based on information theory. The approach hinges on some recent results arising from the convergence between the theory of complex networks and probabilistic techniques for content mining. At its core there is the idea that nodes in a complex network correspond to basic information units from which links are extracted via methods of machine learning. Hence the links themselves are viewed as emergent properties, similarly to the broader structural properties mentioned above. Indeed, beside rounding up the theory, this approach based on learning has clear practical benefits, in that it makes

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.

Contemporary large software systems rely on complex software ecosystems for managing infrastructural tasks. While these ecosystems facilitate software development, the software architect must put care in not relying on assumptions on behaviors and policies of the ecosystem that may change with platform evolution. Based on our experience with developing analyses within MARPLE, a framework for software comprehension and architecture reconstruction, we propose an abstract, context-aware style for specifying software. In the spirit of decoupling computation from coordination, this style decouples the specification of the computations to be performed from the specification of the contexts where they must take place. Software described in this way exposes its primitives at a level of abstraction closer to that of the framework, enabling better reasoning on the features of the design, easing correct implementation, and fostering a better interaction between the software and the framework it relies on.

Code smells help to discover and describe deeper problems in software design. Several automated methods of smell detection are based the analysis of a combination of code-related metrics relevant for a given flaw. However, some smells reflect more complex issues and require a holistic perspective that woudl cover a number of different sources of data. In this paper we experimentally verify the usefulness of including structural factors into a metrics-based detection of God Class and Brain Class code smells.

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.