Isela Macia

Are automatically-detected code anomalies relevant to architectural modularity?: an exploratory analysis of evolving systems

As software systems are maintained, their architecture modularity often degrades through architectural erosion and drift. More directly, however, the modularity of software implementations degrades through the introduction of code anomalies, informally known as code smells. A number of strategies have been developed for supporting the automatic identification of implementation anomalies when only the source code is available. However, it is still unknown how reliable these strategies are when revealing code anomalies related to erosion and drift processes. In this paper, we present an exploratory analysis that investigates to what extent the automatically-detected code anomalies are related to problems that occur with an evolving systems architecture. We analyzed code anomaly occurrences in 38 versions of 5 applications using existing detection strategies. The outcome of our evaluation suggests that many of the code anomalies detected by the employed strategies were not related to architectural problems. Even worse, over 50% of the anomalies not observed by the employed techniques (false negatives) were found to be correlated with architectural problems.

Prioritization of Code Anomalies Based on Architecture Sensitiveness

Code anomalies are symptoms of software maintainability problems, particularly harmful when contributing to architectural degradation. Despite the existence of many automated techniques for code anomaly detection, identifying the code anomalies that are more likely to cause architecture problems remains a challenging task. Even when there is tool support for detecting code anomalies, developers often invest a considerable amount of time refactoring those that are not related to architectural problems. In this paper we present and evaluate four different heuristics for helping developers to prioritize code anomalies, based on their potential contribution to the software architecture degradation. Those heuristics exploit different characteristics of a software project, such as change-density and error-density, for automatically ranking code elements that should be refactored more promptly according to their potential architectural relevance. Our evaluation revealed that software maintainers could benefit from the recommended rankings for identifying which code anomalies are harming architecture the most, helping them to invest their refactoring efforts into solving architecturally relevant problems.

Blending and reusing rules for architectural degradation prevention

As software systems are maintained, their architecture often de-grades through the processes of architectural drift and erosion. These processes are often intertwined and the same modules in the code become the locus of both drift and erosion symptoms. Thus, architects should elaborate architecture rules for detecting occur-rences of both degradation symptoms. While the specification of such rules is time-consuming, they are similar across software projects adhering to similar architecture decompositions. Unfortu-nately, existing anti-degradation techniques are limited as they focus only on detecting either drift or erosion symptoms. They also do not support the reuse of recurring anti-degradation rules. In this context, the contribution of this paper is twofold. First, it presents TamDera, a domain-specific language for: (i) specifying rule-based strategies to detect both erosion and drift symptoms, and (ii) promoting the hierarchical and compositional reuse of design rules across multiple projects. The language was designed with usual concepts from programming languages in mind such as, inheritance and modularization. Second, we evaluated to what extent developers would benefit from the definition and reuse of hybrid rules. Our study involved 21 versions pertaining to 5 software projects, and more than 600 rules. On average 45% of classes that had drift symptoms in first versions presented inter-related erosion problems in latter versions or vice-versa. Also, up to 72% of all the TamDera rules in a project are from a pre-defined library of reusable rules. They were responsible for detecting on average of 73% of the inter-related degradation symptoms across the projects.

Automatically detecting architecturally-relevant code anomalies

Software architecture degradation is a longstanding problem in software engineering. Previous studies have shown that certain code anomalies - or patterns of code anomalies - are likely to be harmful to architecture design, although their identification is far from trivial. This study presents a system for not only detecting architecturally-relevant code anomalies, but also helping developers to prioritize their removal by ranking them. We detect code anomaly patterns based on static analysis that also exploit architecture information.

Enhancing the Detection of Code Anomalies with Architecture-Sensitive Strategies

Research has shown that code anomalies may be related to problems in the architecture design. Without proper mechanisms to support the identification of architecturally-relevant code anomalies, software systems will degrade and might be discontinued as a consequence. Nowadays, metrics-based detection strategy is the most common mechanism to identify code anomalies. However, these strategies often fail to detect architecturally-relevant code anomalies. A key limitation is that they solely exploit measurable static properties of the source code. This paper proposes and evaluates a suite of architecture-sensitive detection strategies. These strategies exploit information related to how fully-modularized and widely-scoped architectural concerns are realized by the code elements. The accuracy of the proposed detection strategies is assessed in a sample of nearly 3500 architecturally-relevant code anomalies and 950 architectural problems distributed in 6 software systems. Our findings show that more than the 60% of code anomalies detected by the proposed strategies were related to architectural problems. Additionally, the proposed strategies identified on average 50% more architecturally-relevant code anomalies than those gathered with using conventional strategies.

Detecting architecturally-relevant code anomalies: a case study of effectiveness and effort

Code anomalies are structural problems in the program. Even though they might represent symptoms of architecture degradation, several code anomalies do not contribute to this process. Source code inspection by developers might not support time-effective detection of architecturally-relevant anomalies in a program. Hence, they usually rely on multiple software metrics known to effectively detect code anomalies. However, there is still no empirical knowledge about the time effectiveness of metric-based strategies to detect architecturally-relevant anomalies. Given the longitudinal nature of this activity, we performed a first exploratory case study to address this gap. We compare metrics-based strategies with manual inspections made by the actual software developers. The study was conducted in the context of a legacy software system with 30K lines of code, 415 architectural elements, 210 versions, and embracing reengineering effort for almost 3 years. Effectiveness was assessed in terms of several quantitative and qualitative indicators. To measure the effort, we computed the amount of time used in several activities required to identify architecturally-relevant code anomalies. The results of our study shed light on potential effort reduction and effectiveness improvements of metrics-based strategies.

Modular specification and checking of structural dependencies

Checking a softwares structural dependencies is a line of research on methods and tools for analyzing, modeling and checking the conformance of source code w.r.t. specifications of its intended static structure. Existing approaches have focused on the correctness of the specification, the impact of the approaches on software quality and the expressiveness of the modeling languages. However, large specifications become unmaintainable in the event of evolution without the means to modularize such specifications. We present Vespucci, a novel approach and tool that partitions a specification of the expected and allowed dependencies into a set of cohesive slices. This facilitates modular reasoning and helps individual maintenance of each slice. Our approach is suited for modeling high-level as well as detailed low-level decisions related to the static structure and combines both in a single modeling formalism. To evaluate our approach we conducted an extensive study spanning nine years of the evolution of the architecture of the object-relational mapping framework Hibernate.

On the Impact of Aspect-Oriented Code Smells on Architecture Modularity: An Exploratory Study

Aspect-oriented programming (AOP) aims to improve software modularity, although developers can unwittingly intro-duce code smells in their programs. A code smell is any symptom in the source code that possibly indicates a deeper modularity problem. Several works have been concerned about code smell occurrences in aspect-oriented systems. However, there is little knowledge about their actual damage to the modularity of architectural designs. This gap makes it difficult for developers understand and manage the harmful architecture-level impact of recurring code smells. This paper presents an exploratory analysis that investigates the influence of aspect-oriented code smells on evolving architectural designs. We analyzed code smell occurrences in 14 versions of 2 applications designed using different architectural styles. The outcome of our evaluation suggests that code smell occurrences often entail architecture modularity problems in these systems. Even worse, our analysis revealed that certain architecturally-relevant code smells were not targeted by the refactoring strategies in place.

Defining and Applying Detection Strategies for Aspect-Oriented Code Smells

A code smell is any symptom in the source code that possibly indicates a bad design or programming problem. Many code smells in aspect-oriented programming (AOP) are very different from those in object-oriented programming. Therefore, new detection strategies should be conceived to identify whether a particular slice of aspect-oriented code is affected by a specific smell. Unfortunately, research on AOP usually focuses on providing abstract descriptions of code smells, without providing operational definitions of their detection strategies. Such strategies are becoming increasingly required due to the growing use of AOP in the development of long-living systems, including frameworks, libraries and software product lines. This paper presents a family of metric-based strategies that support the detection of recurring smells observed in existing aspect-oriented systems. We analyzed the accuracy of such smell detection strategies and also of those previously reported in the literature. Our study involved in total 17 releases of 3 evolving aspect-oriented systems from different domains. The outcome of our evaluation suggests that strategies for previously-documented AOP smells do not present a satisfactory accuracy. Our analysis also revealed that: (1) newly-discovered strategies achieved better results than well-known ones, and (2) the detection strategies seem to have high accuracy with respect to the identification of both trivial and non-trivial code smells.