Towards a language independent refactoring framework

4th International Workshop …, 2003

There is a historical gap between UML tools and refactoring tools. The former tools are designed to produce analysis and design models whereas the latter are designed to manipulate program code. MDA tool vendors aim to bridge this gap by regenerating program code from evolving UML OOAD models and vice versa. In this position paper, we describe the problems and a novel solution for implementing traditional OO source refactorings into the infrastructure from UML tools. After discussing the practical feasibility of advanced UML refactoring applications, we present our running tool prototype and round up with an overview of our future work on model driven refactoring.

Software & Systems Modeling, 2017

Software refactoring is the process of changing a software system in a manner that does not alter its external behavior and yet improving its internal structure. Modeldriven architecture and the popularity of the UML enabled the application of refactoring at model level, which was earlier applied to software code. In this paper, we propose a multi-view integrated approach to model-driven refactoring using UML models. We selected a single model from each UML view at metamodel level to construct an integrated metamodel. We selected class diagram to represent the structural view, sequence diagram to represent the behavioral view and use case diagram to represent the functional view. We validated the proposed approach by comparing integrated refactoring approach with refactoring applied to models individually in terms of quality improvement through UML model metrics. Our results indicate that more bad smell instances can be detected using the integrated approach rather than the individual refactoring approach.

New Trends in Software Methodologies, Tools and Techniques, 2006

As big software projects grow, there is an increasing need of cleaning up or restructuring the existing code. This problem can be addressed by using refactorings, which are small semantics-preserving code transformations. Many refactorings have been automated in existing development environments to help the developer in this process. Most implementations are currently based on the abstract syntax tree. Unfortunately, this model, which was first designed for the compilation process, does not provide all the abstractions that are required for complex refactorings such as extracting a method. In this paper, the FOOD model is introduced and described. Based entirely on graphs, this model is targeted to the implementation of complex code transformations by providing the necessary abstractions. The "extract method" refactoring is applied on the FOOD model as a concrete example. Then a comparison with existing models such as abstract syntax trees is made.

2017

Metamodels can be considered one of the key artifacts of any model-based project. Similarly to other software artifacts, metamodels are expected to evolve during their lifecycle and consequently it is crucial to develop approaches and tools supporting the definition and re-use of metamodel refactorings in a disciplined way. This paper proposes Edelta, a domain specific language for specifying reusable libraries of metamodel refactorings. The language allows both atomic and complex changes and it is supported by an Eclipse-based IDE. The developed supporting environment allows the developer to apply refactorings both in a batch manner and in a step-by-step fashion, which provides developers with an immediate view of the evolving Ecore model before actually changing it.

ASE 2002 Workshop on Declarative Meta-Programming, 2002

In this paper, we advocate the use of declarative metaprogramming todetect violations of important (object-oriented) design guidelines and bestpractices. This is particularly useful for detecting when a design shouldbe refactored, and which refactorings in particular should be applied. Aswe will show, a declarative environment incorporating metaprogrammingcapabilities is very well suited for detecting such violations and providinginformation for possible refactorings.

2013

Abstract. One of the current trends in refactoring is when and where we should refactor. Until now, most of the proposals establish that the refactoring process starts from the programmer intuition and experience. From the bad smell concept, and using metrics, it is possible to discover refactoring opportunities, not only from a subjective point of view but also from an objective point of view. The following work presents an exploratory case study on the use of metrics in the detection of bad smells.This leads to related refactorings in order to improve underlying design. The process is achieved in a language independent manner. In this sense, it is briefly described a framework support for collecting metrics that allows to reuse the effort on a wide family of object-oriented languages. Framework solution is based on the use of metamodels describing family of languages. In addition to this, it is also described how to use the approach and its support, with other metamodels. Key Word...

9th ECOOP Workshop …, 2005

2019

Developing a tool that provides support for different refactorings, through a set of refactoring detectors which identify opportunities for source code improvements, is not easy. Our experience in developing such a tool for refactoring object-oriented software revealed the Three-Step Refactoring Detector pattern. The main idea behind the pattern is to develop an extensible hierarchy of refactoring detectors, with respect to a general three-step refactoring detection process. The proposed pattern facilitates the expansion of the hierarchy with new refactoring detectors and enables the reuse of existing refactoring detectors, provided by third party developers. Concerning maintainability, the pattern promotes the development of simple, clean and technology independent refactoring detectors. We have used the pattern for the development of 11 different refactoring detectors in the context of our tool. The pattern has not been observed in other contexts. However, the usage of the pattern...

The modular design of software systems is an important factor that contributes to the success of software engineering projects. It is enabled by a set of design principles, among which information hiding and separation of concerns are the most influential ones. Their application limits coordination needs and fosters the simple replacement of components, thus facilitating sustainable software engineering processes. Many software systems are initially created in a modular way. However, over time modularity often degrades as components are reused outside the context where they were created. My work proposes an automated strategy to remodularize software based on move refactoring, i.e. the simplest possible refactoring which moves classes between packages without changing other aspects of the code. Main goal is to automatically identify move refactoring that result in a large improvement of modularity.

One of the current trends in refactoring is when and where we should refactor. Until now, most of the proposals establish that the refactoring process starts from the programmer intuition and experience. From the bad smell concept, and using metrics, it is possible to discover refactoring opportunities, not only from a subjective point of view but also from an objective point of view. The following work presents an exploratory case study on the use of met- rics in the detection of bad smells.This leads to related refactorings in order to improve underlying design. The process is achieved in a language independent manner. In this sense, it is briefly described a framework support for collecting metrics that allows to reuse the effort on a wide family of object-oriented languages. Framework solution is based on the use of metamodels describing family of languages. In addition to this, it is also described how to use the approach and its support, with other metamodels.

2008

The paper surveys how software tools such as refactoring systems can be validated, and introduces a new mechanism, namely the extraction of a refactoring engine for a functional programming language from an Isabelle/HOL theory in which it is verified. This research is a first step in a programme to construct certified programming tools from verified theories. We also provide some empirical evidence of how refactoring can be of significant benefit in reshaping automatically-generated program code for use in larger systems.

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.

Software modelers refactor their design models to improve design quality while preserving essential functional properties. Tools that allow modelers to check whether their refactorings preserve specified essential behaviors are needed to support rigorous model evolution. In this paper we describe a rigorous approach to analyzing design model refactorings that involve changes to operation specifications expressed in the Object Constraint Language (OCL). The analysis checks whether the refactored model preserves the essential behavior of changed operations in a source design model. A refactoring example involving the Abstract Factory design pattern is used in the paper to illustrate the approach.

Tool support for refactoring is widespread nowadays. The most widely known IDEs include refactoring support, and many refactoring-specific tools are also available. Developers are aware of refactoring activities and they do refactor their applications even manually or in an assisted way. For the users of refactoring tools, the current state of the art is well documented in refactoring catalogs, where objectives, motivation, mechanisms, etc. are defined. There are also available collections of criteria to detect refactoring opportunities; compilations of guidelines to help decide when and how to apply refactorings. However, refactoring tool implementors can not only base their work on the documentation available in refactoring catalogs because they do not offer clear guidelines on how to build the tools to automate these refactorings. Implementing refactoring tools without any guidance, involves reasoning about which will be the better plan to implement refactoring operations in the tool, their complexity or their graphical interface design, etc. This paper introduces a refactoring characterization, and proposes how it can help refactoring tool implementors on making decisions.

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.