[logo]

-= http://win-www.uia.ac.be/u/lore/refactoringProject =-

Refactoring Project

This is the home page of "The Refactoring Project", a research project with the aim to provide a solid foundation for software refactoring.

Quick Links

Refactoring Project / Home

PEOPLE

PROMOTORS

RESEARCHERS

KEY WORDS

object-oriented software evolution, formal models, program transformation

AIM

The aim of the project is to provide a solid foundation for software refactoring by the development of a suitable formal model. We aim at a lightweight model, facilitating the investigation of basic properties of refactoring, as well as the design of tools supporting the refactoring process. In particular, the potential of graph rewriting as a basis for such a model will be explored. There are several reasons to assume that graph rewriting is a good basic technique for building the model. In the first place, the notion of a (typed) graph enables one to express numerous kinds of diagrammatic representations in a natural way. Secondly, the existing body of results concerning the representation and analysis of graph rewriting processes provides a good starting point for the description and manipulation of complex refactoring processes. This should lead to, e.g., methods for the detection of conflicting refactorings, and methods for the optimization of refactoring processes. Thirdly, the question whether a given set of refactorings is allowable in the sense that it preserves program behaviour is obviously related to the characterization of graph properties that are preserved by the corresponding rewriting rules. Other important aspects are the complexity of refactorings, which can be studied in terms of the number of graph rewriting steps needed, perhaps in combination with the sizes of the graphs involved, and the issue of consistency between various levels of abstraction, which is related to work about hierarchical graphs.

MOTIVATION

An intrinsic characteristic of software addressing a real-world application is the need to evolve. Several surveys of software organisations have shown that the major part of the total software-development cost is devoted to software maintenance and that the bulk of this cost is attributed to implementing new requirements [Coleman&al. 1994, Guimaraes 1983, Lientz&Swanson 1980]. Moreover, it appears that the better our software methods and tools, the more this capacity is used to cope with such changing requirements [Glass 1989]. Consequently, many researchers and practitioners are now investigating the phenomena of software maintenance and software evolution.

For object-oriented software, an important part of the evolution is accomplished by means of refactoring [Opdyke 1992]. The accepted definition for refactoring is "The process of changing a software system in such a way that it does not alter the external behaviour of the code, yet improves its internal structure" [Fowler 1999]. The key idea is to redistribute instance variables and methods across the class hierarchy in order to prepare the software for future extensions. If applied well, refactoring improves the structure of software, makes software easier to understand, helps to find bugs, and helps to program faster.

Today, refactoring is considered a mature technology and is a cornerstone of software development processes like eXtreme Programming [Beck 1999]. Although it is possible to refactor manually, tool support is considered crucial. Tools such as the Refactoring Browser [Roberts&al. 1997] support a semi-automatic approach, while the use of a fully automated tool is demonstrated by others [Casais 1992, Moore 1996], and refactoring is also investigated in the context of a UML case-tool [Sunye&al. 2001]. Nevertheless, most of the results available in this area today are rather "ad hoc": each experiment applies a limited set of refactoring operations on a few cases written in a particular language. It is more or less obvious that these experiments can be replicated in other contexts (other refactorings, other cases, other languages). We believe that a more formal approach is needed to address a number of unresolved issues and to get a clear picture of the possibilities and limitations of refactoring.

OBJECTIVES AND METHODOLOGY

Refactoring -transforming code while preserving behaviour- is currently considered a viable technique for dealing with evolving object-oriented software. Nevertheless some fundamental questions remain unanswered: The project will address these questions with the explicit objectives of establishing a formal basis for refactoring and improving current tool support, thus contributing to making refactoring a standard software engineering practice. To reach these goals, the project will develop a formal model validated in a proof-of-concept refactoring tool. Besides providing a sufficient basis for answering the above questions, the formal model should satisfy two additional criteria:
  1. it should be language-independent, in order to make the results applicable to different implementation languages,
  2. it should be lightweight, i.e. sufficiently simple to serve as a conceptual framework guiding tool builders as well as software engineers.
In view of the wide acceptance of graph-like representations in the world of software engineering, it seems natural to use graph rewriting as the basis of the desired formal model: the software to be refactored is represented by a graph, and refactorings correspond to graph rewriting rules. Thus the general approach is in line with recent work on the application of graph rewriting to software engineering [Taenzer&al. 1998] [Baresi&al. 2001].

RESEARCH QUESTIONS

The following issues will be addressed:

Which program properties should be preserved? Refactoring implies that "behaviour" is preserved, but a precise definition of behaviour is rarely provided. It is for instance accepted that refactoring may change the execution time of certain operations, although this is an essential aspect of real-time behaviour. At the moment it is unclear which properties are best preserved and which ones can be safely ignored. In a first approach one may concentrate on properties such as type correctness and reachability of objects, but the issue may also be treated at a more fundamental level: one may attempt to determine a language of interesting properties, and then relate this to the set of refactorings that guarantees the preservation of all expressible properties. Note that is similar to the well-known work of Courcelle [Courcelle 1990] on monadic second order logic.

How do refactorings interact? Since refactorings are typically applied independently on parts of a large piece of software, the refactoring process should be viewed to consist of parallel applications of small transformations.It has been observed that the parallel application of refactorings entails unforeseen interactions, sometimes even conflicts. In that respect, refactorings are very similar to database transactions. Just as is the case with nested transactions, we want to develop a formal basis that allows tools to detect and resolve such conflicts. On the theoretical level, we intend to build on existing work concerning parallellism and confluency in graph transformation systems [Baldan&al. 1999] and critical pair analysis.

How can refactorings be defined independently of the implementation language? Typical refactoring specifications are intended to be applied manually and consequently the specification of the different steps is open to human interpretation. As an example, the "move method" refactoring states that the developer should be cautious with private methods, but it is up to the human to interpret this advice in the context of the implementation language being used. Tools require a more precise specification in order to handle particular language details. Therefore, the formal model should be sufficiently abstract so as to allow one to plug in the desired concrete language mechanisms at such variation points.

How to compose refactorings? Current refactoring approaches combine primitive refactorings into more complex ones in an ad hoc manner. Consequently, tools tend to support primitive refactorings only. Yet, to address the needs of large-scale reengineering projects, tool support for complex refactorings is an absolutely necessity. A formal model will allow us to reason about composability in a more flexible and scalable way. For example, it is often needed to synthesize complex refactorings: given a program B that has been obtained by refactoring another program A, one wants to find a sequence of primitive refactorings that transforms A into B. On the abstract level, this requires a characterization of the set of refactorings that can be generated by composing primitive refactorings. A suitable representation of complex refactorings, possibly based on the existing process notions for graph rewriting, is essential. It would also be interesting to incorporate such representation into a configuration management system [Conradi&Westfechtel 1998].

How can we maintain consistency between the design and the implementation? Refactorings are typically applied at the implementation level, but these changes also affect representations at the design level. Given the behaviour-preserving nature of refactorings, it should be possible to identify what parts of a design (say, a statechart or sequence diagram) remain unaffected and what parts must be refactored accordingly. It should be possible to organize sets of refactorings at the implementation level into larger entities that are meaningful at the design level.

We have set up a Swiki as a follow-up of a meeting on this topic.

How do refactorings affect quality factors? Refactorings should reduce code redundancy, which must have a positive effect on the maintainability. On the other hand, refactorings often increase the complexity of the class structure, which may have a negative effect. To study the effect of refactoring, a classification of the different refactorings in terms of the quality factors they aim to improve is therefore essential. Once such a classification is made, the actual effect can be quantified by means of quality metrics.

REFERENCES

[Baldan&al. 1999] P. Baldan, A. Corradini, H. Ehrig, M. Loewe, U. Montanari and F. Rossi, "Concurrent Semantics of Algebraic Graph Transformations". In Handbook of Graph Grammars and Graph Transformation, pp. 107-188, World scientific, 1999
[Baresi&al. 2001] L. Baresi, M. Pezze and G. Taenzer, eds, Proc. ICALP 2001 Workshop on Graph Transformation and Visual Modeling Techniques, Electronic Notes in TCS, vol. 50, Elseviers, 2001
[Beck 1999] K. Beck. "Extreme programming explained: Embrace change", Addison-Wesley, 1999
[Casais 1992] E. Casais. "An incremental class reorganization approach", Proc. ECOOP '92, O. Lehrmann Madsen (Ed.), LNCS 615, Springer-Verlag, 1992
[Bergstein 1997] Paul L. Bergstein. "Maintenance of object-oriented systems during structural schema evolution", TAPOS Journal, 3(3), pp. 185-212, 1997
[Coleman&al. 1994] D. Coleman, D. Ash, B. Lowther, P. Oman. "Using metrics to evaluate software system maintainability", IEEE Computer, pp. 44-49, IEEE Computer Society Press, August 1994
[Conradi&Westfechtel 1998] R. Conradi, B. Westfechtel, "Version Models for Configuration Management", ACM Comp. Surveys, vol 30, Nr 2, pp. 232-282, 1998
[Courcelle 1990] B. Courcelle, "Graph Rewriting: an Algebraic and Logic Approach", in "Handbook of Theoretical Computer Science", vol. B, J. Van Leeuwen ed., pp. 193-242, Elsevier, 1990
[Demeyer&al. 2002] Serge Demeyer, Stéphane Ducasse and Oscar Nierstrasz. "Object-Oriented Reengineering Patterns". Morgan-Kaufmann Publishers, 2002
[Fowler 1999] M. Fowler. "Refactoring: Improving the design of existing programs", Addison-Wesley, 1999 [Glass 1998] R. L. Glass. "Maintenance: Less is not more", IEEE Software, July/August 1998
[Guimaraes 1983] T. Guimaraes. "Managing application program maintenance expenditure", Comm. ACM, 26(10), pp. 739-746, ACM Press, 1983
[Lientz&Swanson 1980] B. P. Lientz, E. B. Swanson. "Software maintenance management: a study of the maintenance of computer application software in 487 data processing organizations", Addison-Wesley, 1980
[Moore 1996] I. Moore. "Automatic inheritance hierarchy restructuring and method refactoring", Proc. OOPSLA '96, ACM Press, 1996
[Opdyke 1992] W.F. Opdyke. "Refactoring: A Program Restructuring Aid in Designing Object-Oriented Application Frameworks", Ph.D. Thesis, University of Illinois at Urbana-Champaign, Technical Report UIUC-DCS-R-92-1759, 1992
[Roberts&al. 1997] D. Roberts, J. Brant, R.E. Johnson. "A refactoring tool for Smalltalk", TAPOS Journal 3(4), pp. 253-263, 1997
[Sunyé&al. 2001] G. Sunyé, D. Pollet, Y. LeTraon, J.-M. Jézéquel. "Refactoring UML models", Proc. UML 2001, LNCS 2185, Springer Verlag, 2001
[Taenzer&al. 1998] G. Taenzer, M. Goedicke and T. Meyer, "Dynamic Change Management by Distributed Graph Transformation: Towards Configurable Distributed Systems", Theory and Application of Graph Transformations, LNCS 1764, pp. 179-193, Springer Verlag, 1998
[Tichelaar&al. 2000] Sander Tichelaar, Stéphane Ducasse, Serge Demeyer, and Oscar Nierstrasz. "A meta-model for language-independent refactoring", Proc. ISPSE 2000. IEEE Press, 2000.

Revision History
Edited by Bart - 29/11/02 - 05:12 pm
Edited by pvgorp - 2/12/02 - 12:34 am
Edited by pvgorp - 10/12/02 - 04:49 pm
Edited by pvgorp - 10/12/02 - 06:13 pm
Edited by pvgorp - 3/3/03 - 11:28 am: Added link to co-evo swiki



index - all nodes - edit - log in - wiki_guidelines