When refactoring acts like modularity

Oftentimes the changes required to improve the design of code are crosscutting in nature and thus easier to perform with the assistance of automated refactoring tools. However, the developers of such refactoring tools cannot anticipate every practical transformation, particularly those that are specific to the program's domain. We demonstrate Arcum, a declarative language for describing and performing both general and domain-specific transformations.

Despite the automated refactoring support provided by today's IDEs many program transformations that are easy to conceptualizesuch as improving the implementation of a design pattern-are not supported and are hence hard to perform. We propose an extension to the refactoring paradigm that provides for the modular maintenance of crosscutting design idioms, supporting both substitutability of design idiom implementations and the checking of essential constraints. We evaluate this new approach through the design and use of Arcum, an IDE-based mechanism for declaring, checking, and evolving crosscutting design idioms.

Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering - ESEC-FSE '07, 2007

Despite the automated refactoring support provided by today's IDEs many program transformations that are easy to conceptualizesuch as improving the implementation of a design pattern-are not supported and are hence hard to perform. We propose an extension to the refactoring paradigm that provides for the modular maintenance of crosscutting design idioms, supporting both substitutability of design idiom implementations and the checking of essential constraints. We evaluate this new approach through the design and use of Arcum, an IDE-based mechanism for declaring, checking, and evolving crosscutting design idioms.

2005

Refactoring is an essential and useful practice in developing and maintaining object-oriented software since it improves the design of existing code without changing its external behavior. Therefore, several refactoring tools tend to be integrated into contemporary IDEs. However, these tools represent source code as an abstract syntax tree (AST) and thus their implementations are hard to extend and modify. This paper presents Jrbx, a refactoring tool that uses a fine-grained XML representation of source code and supports stylized manipulations of the representation. Moreover, Jrbx aggressively exploits control flow graphs (CFGs) and program dependence graphs (PDGs) for both precondition checking and change creation. The use of the XML, CFG, and PDG representations makes the implementation of Jrbx more understandable and reusable, and thus facilitates tool developers creating new refactorings and modifying existing ones.

Proceedings IEEE International Conference on Software Maintenance. ICSM 2001

Program refactoring-transforming a program to improve readability, structure, performance, abstraction, maintainability, or other features-is not applied in practice as much as might be desired. One deterrent is the cost of detecting candidates for refactoring and of choosing the appropriate refactoring transformation. This paper demonstrates the feasibility of automatically finding places in the program that are candidates for specific refactorings. The approach uses program invariants: when a particular pattern of invariant relationships appears at a program point, a specific refactoring is applicable. Since most programs lack explicit invariants, an invariant detection tool called Daikon is used to infer the required invariants. We developed an invariant pattern matcher for several common refactorings and applied it to an existing Java code base. Numerous refactorings were detected, and one of the developers of the code base assessed their efficacy.

IEEE Software, 2000

Developers rely on compilation, test suite and tools to preserve observable behavior during refactoring. However, most of the refactoring tools do not implement all preconditions that guarantee the refactoring correctness, since formally identifying them is cost-prohibitive. Therefore, these tools may perform non-behavior preserving transformations. We present a tool for improving safety during refactoring. It automatically generates a test suite that is suited for detecting behavioral changes. We used our tool to evaluate seven real case study refactorings (from 3 to 100 KLOC). We reason about a JHotDraw (23 KLOC) and its refactored version, and automatically detected a behavioral change. This problem was not identified by developers. Finally, we also evaluated our tool against 17 defective refactorings that are not detected by refactoring tools.

2008 12th European Conference on Software Maintenance and Reengineering, 2008

Refactoring, in spite of widely acknowledged as one of the best practices of object-oriented design and programming, still lacks quantitative grounds and efficient tools for tasks such as detecting smells, choosing the most appropriate refactoring or validating the goodness of changes. This is a proposal for a method, supported by a tool, for cross-paradigm refactoring (e.g. from OOP to AOP), based on paradigm and formalism-independent modularity assessment.

2011 26th IEEE/ACM International Conference on Automated Software Engineering (ASE 2011), 2011

One of the most difficult parts of building automated refactorings is ensuring that they preserve behavior. This paper proposes a new technique to check for behavior preservation; we call this technique differential precondition checking. It is simple yet expressive enough to implement the most common refactorings, and the core algorithm runs in linear time. However, the main advantage is that a differential precondition checker can be placed in a library and reused in refactoring tools for many different languages; the core algorithm can be implemented in a way that is completely language independent. We have implemented a differential precondition checker and used it in refactoring tools for Fortran (Photran), PHP, and BC.

Refactoring is widely recognized as a method to improve the internal qualities of source code. However, manual refactoring is time-consuming and error prone. Consequently, many tools to support automated refactoring have been suggested, but most support only unit and simple refactoring, making it difficult to perform composite refactoring (e.g., introducing a design pattern) where a refactoring set is applied at one position or the same refactoring operation is applied at multiple positions. In this paper, we propose a novel script language and its processor to describe how and where to refactor by a model expressing source code *1 . Evaluations indicate that our language and processor allow refactoring steps to be described as scripts, which can be easily replayed and reused for multiple projects.

2015

Many software evolution and maintenance problems can be addressed through techniques of program transformation. To facilitate development of language tools assisting software evolution and maintenance, we created a Domain-Specific Language (DSL), named SPOT (Specifying PrOgram Transformation), which can be used to raise the abstraction level of code modification. The design goal is to automate source-tosource program transformations through techniques of code generation, so that developers only need to specify desired transformations using constructs provided by the DSL while being oblivious to the details about how the transformations are performed. The paper provides a general motivation for using program transformation techniques and explains the design details of SPOT. In addition, we present a case study to illustrate how SPOT can be used to build a code coverage tool for applications implemented in different programming languages.