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.