Page 267 -

250 Chapter 9 Software evolution

Automated Program Program and Data
Restructuring Restructuring

Automated Source Automated Restructuring Restructuring Plus
Code Conversion with Manual Changes Architectural Changes
Figure 9.12
Reengineering
approaches Increased Cost
data. This involves finding and correcting mistakes, removing duplicate records,
etc. Tools are available to support data reengineering.

Program reengineering may not necessarily require all of the steps in Figure 9.11.
You don’t need source code translation if you still use the application’s programming
language. If you can do all reengineering automatically, then recovering documenta-
tion through reverse engineering may be unnecessary. Data reengineering is only
required if the data structures in the program change during system reengineering.
To make the reengineered system interoperate with the new software, you may
have to develop adaptor services, as discussed in Chapter 19. These hide the original
interfaces of the software system and present new, better-structured interfaces that
can be used by other components. This process of legacy system wrapping is an
important technique for developing large-scale reusable services.
The costs of reengineering obviously depend on the extent of the work that is
carried out. There is a spectrum of possible approaches to reengineering, as shown
in Figure 9.12. Costs increase from left to right so that source code translation is
the cheapest option. Reengineering as part of architectural migration is the most
expensive.
The problem with software reengineering is that there are practical limits to how
much you can improve a system by reengineering. It isn’t possible, for example, to con-
vert a system written using a functional approach to an object-oriented system. Major
architectural changes or radical reorganizing of the system data management cannot be
carried out automatically, so they are very expensive. Although reengineering can
improve maintainability, the reengineered system will probably not be as maintainable
as a new system developed using modern software engineering methods.

9.3.3 Preventative maintenance by refactoring

Refactoring is the process of making improvements to a program to slow down degra-
dation through change (Opdyke and Johnson, 1990). It means modifying a program to
improve its structure, to reduce its complexity, or to make it easier to understand.
Refactoring is sometimes considered to be limited to object-oriented development but
the principles can be applied to any development approach. When you refactor a pro-
gram, you should not add functionality but should concentrate on program improve-
ment. You can therefore think of refactoring as ‘preventative maintenance’ that reduces
the problems of future change.