Chapter 6
Conclusion
6.1 Summary of contributions
This thesis describes and
offers the implementation of several automatic program-code transformations
which support programmers during refactoring of their software. The
contributions made by this research are:
1) Criteria for the practical
application of the transformation and the uses of the particular refactoring.
2) Design and implementation of
the refactoring catalog with a set of basic code transformations and support
for composed transformations.
3) Implementation of a tool
which can handle the whole refactoring process, including code-parsers,
file-table, symbol-table and code-generators.
6.2 Refactoring: Pros and
Cons
Every software developer
refactors his code during the implementation or maintenance of the program. He
creates, removes, and copies program entries in order to improve the design of
the software. The goal of this research was to create a tool that supports the
refactoring-process with automatic program transformations routines. This chapter
shows the benefits and problems of the automatic program transformations.
6.2.1 Benefits
- Automatic transformations increase the speed of software development and save development
costs. They checks the preconditions and generate the code changes.
- Refactoring is a safe way to change the source code
(Transformation preserves the
behavior of the program)
- Transformation makes the program more flexible and easily extendible
( see example in section 2.2)
- Refactoring helps to re-use existing software.
( see example in section 2.2)
- Design pattern transformations help to restructure the source code
and make the program more understandable. This may help find some of the
logical errors.
- Refactorings provide a high level of code-abstraction that could be
useful in the design and re-design of
the software. It reduces the need for an overly complex design.
- A tool for refactorings
generates the source code from existing code. It is called:
„Source to source „- transformations. This differs from „Specification to source“ transformations offered by UML-tools.
- Design patterns define the target for refactorings.
This makes transformations
more understandable.
6.2.2 Problems
-
Refactoring is risky:
Because it requires source-code changes that can introduce subtle bugs.
In order to refactor properly, the user has to know:
- what the program
does and how it is structured
- what he wants to
change and how it can be completed
- what a particular
transformation does and what are the preconditions.
-
Refactorings are dependent on a specific programming language and compiler.
An implemented
transformation for Smalltalk can't be applied to C++. Also by refactoring in
the same language, such as C++, transformation could get in trouble by dealing
with the preprocessor directives such as
„#pragma“ or „#ifndef“, because implementation of these directives is
dependent on the compiler or compiler-flags.
-
The developer has to be careful
while transforming „Program-families“.
Example: When a class is
used by more than one program and this class has been transformed for only one
program, there is no guarantee that other programs will preserve their
behavior.
-
Source files have to be accessible.
The transformation can not
make any changes to a „read-only“ source file! Although the
transformation does not
change a source file, it should be
available (at least as „read-only“) for the precondition-check of the
transformation.
Example: Transformation
„ remove method“, method does not have any references.
Transformation has to verify
that class does not implement an interface with this method. For this
check, the source of the interface
should be available.
- Enabling conditions of the
transformation.
In order to preserve the
behavior of the program, the preconditions of the transformation have to be
accomplished. It would be convenient if a refactoring-tool could check all of
the conditions. This is possible with an extremely good tool and the conditions
should be very conservative. On the other hand, if preconditions are too
conservative, the transformation might be useless.
- „Safety“ of the transformation
Tool based
transformation tries, but does not
guarantee to be complete safety, because refactoring tool is also software,
which is inherently unsafe.
6.2 Future of refactorings
In the near future,
refactoring technology will be able to augment existing object-oriented
software development environments and UML-tools. While design patterns involve
the reuse of design, refactorings involve re-use of the software that reduces
the cost of software development.
6.2.1 Future uses
Here are some ideas for the practical areas where refactorings could be
used:
Needs |
Context |
Examples |
Restructuring, extensions |
Split the inheritance hierarchy |
Frameworks |
Design pattern transformations |
Realization of operations like rename/move/copy an entity |
UML-Tools |
Re-use, extensions |
Re-use of old program-modules for the creation of new version of SW |
Games (reuse of old labyrinths) |
Extensions, flexibility |
Extension/upgrade of the communication protocol. |
Internet-SW |
Re-use, flexibility |
Port the software on new platform |
Product-upgrade |
|
|
|
6.2.1 Future extensions of
DPT
DPT has been designed as a
prototype of a refactoring tool. The main goal was to illustrate the benefits
of the refactorings and to prove that it is possible to create a small and
user-friendly refactoring tool without a huge repository(=database) overhead
and mountains of UML-specifications.
Of course it can be
maintained that this DPT-tool could be integrated into any object-oriented
microwave, but that is not the purpose of DPT. It would be preferable to extend
DPT with a better language parser and create a couple of generator-beans for
new transformations. DPT could be attached to a software development
environment as an „add on“-tool. It would be quite interesting to implement the
transformations between the languages, because many of the C/C++ programs are just waiting to be re- implemented in
Java. The UML-tools could also use transformations for reengineering
features(transformations like „rename/move-class“).
However, the most important
thing is that such a tool as DPT can help developers in refactoring and
developing their programs faster and more elegantly:
-Design:The future
extensions could be done in the future and supported by refactorings
- Re-implementation: Re-use
the program instead of reusing the
design of a program.
- Maintenance: Why spend
days re-typing and copying during restructuring of
the
program, if refactoring does this work automatically.
6.3
Summary
In this thesis we have gone
through the realization of refactoring-techniques and have shown the benefits
of the automatic code transformations. We have defined the transformation and
criteria, which are important for the practical application of the
transformation. We have also discussed the practical uses of the
transformation. We have defined a catalog of
basic code-transformations and talked about the properties and preconditions
for these transformations. We have shown how to create more complex
transformations( such as design pattern refactorings) as a composition of the
existing transformations.
The realization of a tool to support refactorings was an important part of this work. We have gone
through the design issues of a refactoring tool and described the design ideas
and solutions for particular realization problems. The DPT -tool shows that it
is possible to implement a small refactoring-tool with a few resources and in a
limited time.
We hope this research and the freely made availability of DPT(Design Pattern Transformer) as a prototype for the refactoring-tool will contribute some ideas and experience towards the development of commercial support for refactoring in common software developing environments for static compiled languages.