Chapter 2

Motivation

 

One of a programmer’s favorite operations is „copy and paste“ which takes time to find all  relevant locations and to repeat this operation (for example: 100 times) and can cause very strange errors  just because at this time the developer does not realize the consequences of those changes.

 

A tool could help to refactor(see chapter 5.5) if programmers would try to use it!

- How to get a developer to refactor without  „copy-and-paste“?

- What are the programmer’s expectations?

- Where is that super-tool for code transformation? 

- Which problems need to be solved in order to develop a refactoring tool?

All these questions are also part of this research.

 

2.1    Support for code transformation

 

The idea of refactoring is beginning to enjoy widespread acceptance since costs for the evolution and maintenance of software make up to 70 percent of the software budget. In the 90's  a large number of software was realized in object-oriented languages such as C++/Smalltalk and  later Java.  Object-oriented software is organized into classes and frameworks which provide modularity and enhance reusability. The first people who started popularizing refactorings were Kent Beck, Ralph Johnson and Bill Opdyke.

In the last couple of years several people have written good books[Bek97] about program transformations and how important refactorings for software design, upgrade and maintenance could be.

Most of those books end with the same statement: „One of the largest barriers to refactoring code has been the woeful lack of tool support for it“[Fowler99]

 

So far only a „Refactoring Browser“ for Smalltalk has been written to support the transformation of program code. Statically-compiled languages such as C++/Java are waiting for a good refactoring tool. We hope this research and the free availability of  DPT 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 statically compiled languages.  

 

The  object-oriented design methods offer important opportunities for the reduction of maintenance and evolution costs. Language features such as inheritance, interfaces also contribute to reuse and extend existing classes. New UML-tools such as Rational Rose or STP  increase the speed for design of  object-oriented software.

 

But sometimes programmers(and also consultants) get too carried away:

They start making the classes too small(e.g. one method - one class!), for every class they define an abstract super-class, an interface and a factory-class. They start thinking about the future program extensions which will never happen and just loose too much expensive time. Instead of increasing the speed of program development, this kind of  misuse of  object-oriented design slows down  the productivity and inflates the budget of the project.

 

Refactorings provide a new view of object-oriented program development:

- All future program changes can be done later (if the change is really required!) and can be supported by refactorings.

 

2.2 First Example

 

At this point it is customary to count all the benefits(see section 6.2) of refactorings. Instead, we would like to continue with an example which will show the practical use of refactorings. This example is a part of  the DPT-tool and can be performed by users.

 

For the description of a transformation in examples, the following scheme will be used:

- Name and short information about transformation

- Start- and end- state (UML-diagram)

- Actual parameters of transformation

Note: For a complete definition and preconditions of each transformation see chapter 4

 

2.2.1 Program description

 

The welcome-program is a simple car-lifecycle simulation program written in Java. It creates a BMW3 car with BMW3 tires and a BMW3 engine, and lets this car drive until the car is a wreck. During the drive, the tires are rotated and changed and the engine is replaced. This program works only for a BMW3 car.

 

- Program-files(see appendix C):

AppMain.java    - Contains main function, creates and runs a new application frame.

AppFrame.java  - Class contains GUI-Components. Creates and drives a BMW-3 car.

Car.java              - Class Car(BMW3) contains tires and engine and calls to their methods

HelpBox.java     - Dialog that displays help-information.

BMW3_Tire.java - Contains concrete class tire for a BMW3 car

BMW3_Engine.java - Contains concrete class engine for a BMW3 car

 

- New requirements for car-simulator:

a) Next the BMW3 will be built with a new type of engine/tire (Program extension)

b) A manager decides to use this program to simulate other cars.(Reuse of the program)