Tiago Massoni

Refactoring product lines

Adoption strategies for Software Product Lines (SPL) frequently involve bootstrapping existing products into a SPL and extending an existing SPL to encompass another product. One way to do that is to use program refactorings. However, the traditional notion of refactoring does not handle appropriately feature models (FM), nor transformations involving multiple instances of the same SPL. For instance, it is not desirable to apply a refactoring into a SPL and reduce its configurability. In this paper, we extend the traditional notion of refactoring to an SPL context. Besides refactoring programs, FMs must also be refactored. We present a set of sound refactorings for FMs. We evaluate this extended refactoring definition for SPL in a real case study in the mobile games domain.

Automated Behavioral Testing of Refactoring Engines

Refactoring is a transformation that preserves the external behavior of a program and improves its internal quality. Usually, compilation errors and behavioral changes are avoided by preconditions determined for each refactoring transformation. However, to formally define these preconditions and transfer them to program checks is a rather complex task. In practice, refactoring engine developers commonly implement refactorings in an ad hoc manner since no guidelines are available for evaluating the correctness of refactoring implementations. As a result, even mainstream refactoring engines contain critical bugs. We present a technique to test Java refactoring engines. It automates test input generation by using a Java program generator that exhaustively generates programs for a given scope of Java declarations. The refactoring under test is applied to each generated program. The technique uses SafeRefactor, a tool for detecting behavioral changes, as an oracle to evaluate the correctness of these transformations. Finally, the technique classifies the failing transformations by the kind of behavioral change or compilation error introduced by them. We have evaluated this technique by testing 29 refactorings in Eclipse JDT, NetBeans, and the JastAdd Refactoring Tools. We analyzed 153,444 transformations, and identified 57 bugs related to compilation errors, and 63 bugs related to behavioral changes.

An Abstract Equivalence Notion for Object Models

Equivalence notions for object models are usually too concrete in the sense that they assume that the compared models are formed by elements with the same names. This is not adequate in several situations: during model refactoring, when using auxiliary model elements, or when the compared models comprise distinct but corresponding elements. So, in this paper, we propose a more abstract and language-independent equivalence notion for object models. It supports, as desired, abstraction from names and elements when comparing models. We use the PVS system to specify and prove properties of our notion. It is illustrated here by comparing simple models in Alloy, a formal object-oriented modeling language, but has also been applied for deriving a comprehensive set of algebraic laws for Alloy.

A rigorous approach for proving model refactorings

Both model and program refactorings are usually proposed in an ad hoc way because it is difficult to prove that they are sound with respect to a formal semantics. In this paper, we propose guidelines on how to rigorously prove model refactorings for Alloy, a formal object-oriented modeling language. We use the Prototype Verification System (PVS) to specify and prove the soundness of the transformations. Proposing refactorings in this way can facilitate not only design, but also improve the quality of refactoring tools.

Formal model-driven program refactoring

Evolutionary tasks, specially refactoring, affect source code and object models, hindering correctness and conformance. Due to the gap between object models and programs, refactoring tasks get duplicated in commonly-used model-driven development approaches, such as Round-Trip Engineering. In this paper, we propose a formal approach to consistently refactor systems in a model-driven manner. Each object model refactoring applied by the user is associated with a sequence of behavior preserving program transformations, which can be semiautomatically performed to an initially conforming program. As a consequence, this foundation for model-driven refactoring guarantees behavior preservation of the target program, besides its conformance with the refactored object model. This approach is described in detail, along with its formal infrastructure, including a conformance relationship between object models and programs. A case study reveals evidence on issues that will surely recur in other model-driven development contexts.

Analyzing Refactorings on Software Repositories

Currently analysis of refactoring in software reposi- tories is either manual or only syntactic, which is time-consuming, error-prone, and non-scalable. Such analysis is useful to understand the dynamics of refactoring throughout development, especially in multi-developer environments, such as open source projects. In this work, we propose a fully automatic technique to analyze refactoring frequency, granularity and scope in software repositories. It is based on SAFEREFACTOR, a tool that analyzes transformations by generating tests to detect behavioral changes -- it has found a number of bugs in refactoring implementations within some IDEs, such as Eclipse and Netbeans. We use our technique to analyze five open source Java projects (JHotDraw, ArgoUML, SweetHome 3D, HSQLDB and jEdit). From more than 40,723 software versions, 39 years of software development, 80 developers and 1.5 TLOC, we have found that: 27% of changes are refactorings. Regarding the refactorings, 63,83% are Low level, and 71% have local scope. Our results indicate that refactorings are frequently applied before likely functionality changes, in order to better prepare design for accommodating additions.

A refactoring-based approach for test case selection and prioritization

Refactoring edits, commonly applied during software development, may introduce faults in a previously-stable code. Therefore, regression testing is usually applied to check whether the code maintains its previous behavior. In order to avoid rerunning the whole regression suite, test case prioritization techniques have been developed to order test cases for earlier achievement of a given goal, for instance, improving the rate of fault detection during regression testing execution. However, as current techniques are usually general purpose, they may not be effective for early detection of refactoring faults. In this paper, we propose a refactoring-based approach for selecting and prioritizing regression test cases, which specializes selection/prioritization tasks according to the type of edit made. The approach has been evaluated through a case study that compares it to well-known prioritization techniques by using a real open-source Java system. This case study indicates that the approach can be more suitable for early detection of refactoring faults when comparing to the other prioritization techniques.

A model-driven approach to formal refactoring

Applying refactorings to object-oriented systems usually affects source code and its associated models, involving complex maintenance efforts to keep those artifacts up to date. Most projects abandon design information in the form of models early in the life cycle, as their sustentation becomes extremely expensive. We propose a formal approach to consistently refactor systems in a model-driven manner. The refactoring applied to the model is linked to a sequence of behavior-preserving transformations that automatically refactor the underlying source code, based on structural properties from the model that must be implemented by the program. As a consequence, sound program refactoring can be accomplished without developer intervention, based only on the applied model transformations. Also, the refactored source code is consistent with the refactored model. Model information can be additionally used to improve refactoring automation, as more powerful transformations can be mechanized.

A Framework for Establishing Formal Conformance between Object Models and Object-Oriented Programs

Conformance between structural models and their implementations are usually simplified in practice, restraining reasoning to simple mappings between modeling and implementation constructs. This is not appropriate to accommodate the usual freedom of implementation for abstract concepts. A more flexible conformance notion must be addressed by conformance checking tools and model-driven development. In this paper, we propose a formal framework for defining conformance relationships between structural object models and object-oriented programs. In our framework, a syntactic mapping between model and program elements must be provided, yielding a coupling relation, used in framework instantiations for specific conformance relationships. Additionally, as in practice some intermediate program states are not relevant to conformance, we include the notion of heaps of interest, encompassing the filtered stable states for a less strict conformance checking. The framework is applied for establishing a conformance relationship in a technique of model-driven refactoring of programs.

Prioritizing test cases for early detection of refactoring faults

Refactoring edits are error‐prone, requiring cost‐effective testing. Regression test suites are often used as a safety net for decreasing the chances of behavioural changes. Because of the high costs related to handling massive test suites, prioritization techniques can be applied to reorder test case execution, fostering early fault detection. However, traditional prioritization techniques are not specifically designed for detecting refactoring‐related faults. This article proposes refactoring‐based approach (RBA), a refactoring‐aware strategy for prioritizing regression test cases. RBA reorders an existing test sequence, using a set of proposed refactoring fault models that define the refactorings impact on program methods.