Santiago Vidal

An approach to prioritize code smells for refactoring

Code smells are a popular mechanism to find structural design problems in software systems. Consequently, several tools have emerged to support the detection of code smells. However, the number of smells returned by current tools usually exceeds the amount of problems that the developer can deal with, particularly when the effort available for performing refactorings is limited. Moreover, not all the code smells are equally relevant to the goals of the system or its health. This article presents a semi-automated approach that helps developers focus on the most critical problems of the system. We have developed a tool that suggests a ranking of code smells, based on a combination of three criteria, namely: past component modifications, important modifiability scenarios for the system, and relevance of the kind of smell. These criteria are complementary and enable our approach to assess the smells from different perspectives. Our approach has been evaluated in two case-studies, and the results show that the suggested code smells are useful to developers.

JSpIRIT: a flexible tool for the analysis of code smells

Code smells are a popular mechanism to identify structural design problems in software systems. Since it is generally not feasible to fix all the smells arising in the code, some of them are often postponed by developers to be resolved in the future. One reason for this decision is that the improvement of the code structure, to achieve modifability goals, requires extra effort from developers. Therefore, they might not always spend this additional effort, particularly when they are focused on delivering customer-visible features. This postponement of code smells are seen as a source of technical debt. Furthermore, not all the code smells may be urgent to fix in the context of the systems modifability and business goals. While there are a number of tools to detect smells, they do not allow developers to discover the most urgent smells according to their goals. In this article, we present a fexible tool to prioritize technical debt in the form of code smells. The tool is flexible to allow developer s to add new smell detection strategies and to prioritize smells, and groups of smells, based on the confguration of their manifold criteria. To illustrate this flexibility, we present an application example of our tool. The results suggest that our tool can be easily extended to be aligned with the developers goals.

Toward automated refactoring of crosscutting concerns into aspects

Aspect-oriented programing (AOP) improves the separation of concerns by encapsulating crosscutting concerns into aspects. Thus, aspect-oriented programing aims to better support the evolution of systems. Along this line, we have defined a process that assists the developer to refactor an object-oriented system into an aspect-oriented one. In this paper we propose the use of association rules and Markov models to improve the assistance in accomplishing some of the tasks of this process. Specifically, we use these techniques to help the developer in the task of encapsulating a fragment of aspectizable code into an aspect. This includes the choice of a fragment of aspectizable code to be encapsulated, the selection of a suitable aspect refactoring, and the analysis and application of additional restructurings when necessary. Our case study of the refactoring of a J2EE system shows that the use of the process reduces the intervention of the developer during the refactoring.

Aspect mining meets rule-based refactoring

Aspect-oriented software development allows the encapsulation of crosscutting concerns, achieving a better system modularization and, therefore, improving its maintenance. One important challenge is how to evolve an object-oriented system into an aspect-oriented one in such a way the system structure gets gradually improved. This paper describes a process to assist developers in the refactoring of object-oriented systems to aspects. To do so, we propose a tool approach that combines aspect mining techniques with a rule-base engine to apply refactorings.

Identifying Architectural Problems through Prioritization of Code Smells

Architectural problems constantly affect evolving software projects. When not properly addressed, those problems can hinder the longevity of a software system. Studies have revealed that a range of architectural problems are reflected in source code through two or more code smells. However, a software project often contains thousands of code smells and many of them have no relation to architectural problems. Thus, developers may feel discouraged to identify architectural problems if they are not equiped with means to focus their attention in a reduced set of locations in their system to start with. However, state-of-the-art techniques fall short in assisting developers in the prioritization of code smells that are likely to indicate architectural problems in a program. As a consequence, developers struggle to effectively focus on (groups of) smells that are architecturally relevant, i.e., smells that contribute to a critical design problem. This work presents and evaluates a suite of criteria for prioritizing groups of code smells as indicators of architectural problems in evolving systems. These criteria are supported by a tool called JSpIRIT. We have assessed the prioritization criteria in the context of more than 23 versions of 4 systems, analyzing their effectiveness for spoting locations of architectural problems in the source code. The results provide evidence that one of the proposed criteria helped to correctly prioritize more than 80 (locations of) architectural problems, alleviating tedious manual inspections of the source code vis-a-vis with the architecture. This prioritization criteria would have helped developers to discard at least 500 code smells having no relation to architectural problems in the analyzed systems.

Producing Just Enough Documentation: The Next SAD Version Problem

Software architecture knowledge is an important asset in today’s projects, as it serves to share the main design decisions among the project stakeholders. Architectural knowledge is commonly captured by the Software Architecture Document (SAD), an artifact that is useful but can also be costly to produce and maintain. In practice, the SAD often fails to fulfill its mission of addressing the stakeholders’ information needs, due to factors such as: detailed or high-level contents that do not consider all stakeholders, outdated documentation, or documentation generated late in the lifecycle, among others. To alleviate this problem, we propose a documentation strategy that seeks to balance the stakeholders’ interests in the SAD against the efforts of producing it. Our strategy is cast as an optimization problem called ”the next SAD version problem” (NSVP) and several search-based techniques for it are discussed. A preliminary evaluation of our approach has shown its potential for exploring cost-benefit tradeoffs in documentation production.

Building an expert system to assist system refactorization

The separation of concerns is an important issue in the building of maintenable systems. Aspect oriented programming (AOP) is a software paradigm that allows the encapsulation of those concerns that crosscut a system and can not be modularized using current paradigms such as object-oriented programming. In this way, AOP increases the software modularization and reduces the impact when changes are made in the system. In order to take advantage of the benefits of AOP, the legacy OO systems should be migrated. To migrate object-oriented systems to aspect-oriented ones, specific refactorings for aspects should be used. This is a complex and tedious task for the developer because he/she needs to know how the refactorings should be applied and under what context. Therefore, it is desirable to have tools that help him/her through the process. In this article, we present an expert software agent, named RefactoringRecommender, that assists the developer during a refactorization of a system. The agent uses a Markovian algorithm with the goal of predicting the needed restructurings.

On the criteria for prioritizing code anomalies to identify architectural problems

Architectural problems constantly affect evolving software projects. When not properly addressed, those problems can hinder the longevity of a software system. Some studies revealed that a wide range of architectural problems are reflected in source code through code anomalies. However, a software project often contains thousands of code anomalies and many of them have no relation to architectural problems. As a consequence, developers struggle to effectively determine which (groups of) anomalies are architecturally relevant. This work proposes criteria for prioritizing groups of code anomalies as indicators of architectural problems in evolving systems.

Understanding and addressing exhibitionism in Java empirical research about method accessibility

Information hiding is a positive consequence of properly defining component interfaces. Unfortunately, determining what should constitute a public interface remains difficult. We have analyzed over 3.6 million lines of Java open-source code and found that on the average, at least 20 % of defined methods are over-exposed, thus threatening public interfaces to unnecessary exposure. Such over-exposed methods may have their accessibility reduced to exactly reflect the method usage. We have identified three patterns in the source code to identify over-exposed methods. We also propose an Eclipse plugin to guide practitioners in identifying over-exposed methods and refactoring their applications. Our plugin has been successfully used to refactor a non-trivial application.

Analyzing the history of software systems to predict class changes

Determining the critical parts of a system is key to effectively conduct preventive software maintenance. To accomplish this task, information from the system history (i.e., past versions) can be helpful for identifying those software elements that are more likely to receive modifications in the near future. However, interpreting the large amount of data usually present in the history can be difficult. In this work, we propose an approach adapted from financial markets for analyzing the history of an object-oriented system and predicting the classes that might change. We have evaluated our approach by comparing it with existing approaches. The results, although preliminary, show that our approach makes more accurate predictions for class changes.