A Refactoring Environment for Incremental Migration of Legacy Code
The rate of rapid change in the computing industry in the last few decades has meant that systems with long lifetimes often rely on software written in languages that are no longer being actively or widely used. Typical of such systems are large military and aerospace applications such as the Air Force's B2 bomber, which relies on software written in Jovial. Similarly, many Navy applications are programmed using CMS2, and NASA has systems written in HAL/S. Older systems, such as for the Navy's E2C aircraft, are even written in custom assembly languages for processors that are no longer manufactured. None of these languages are used in the mainstream. Programs written in these languages are expensive to maintain for several reasons. First, there is a very small and constantly diminishing pool of engineers trained in the use of these languages. Also, there is a lack of tool support for these languages. What tools exist are not always fully supported, and are rarely of the breadth and quality of tools for more popular languages, so the engineers cannot be as productive as they might be. For these reasons, many organizations are transitioning these systems to use modern and popular languages.
Transitioning a program to a new language is itself a difficult problem. Rewriting a program from scratch in a new language is an extremely expensive proposition. Information on the design of the original system may be out of date, incomplete or missing. Recovering the design in these cases in order to rewrite the code can be time consuming and error prone. Furthermore, the cost to retest the program is very high. Perhaps the greatest drawback of all is the high risk of failure.
Another approach, at the other end of the spectrum from rewriting the code, is fully automatic translation from the original language to the new language. This is a low-cost approach when it is successful, but it only solves half the problem-the translated code is generally of very poor quality, so it remains difficult to maintain. More often, it may not be possible to do an automatic translation of the entire program, so some parts may have to be re-written by hand.
A more attractive approach is a semi-automatic incremental transition from code written in the legacy language to equivalent code written in the new language. With good tool support, this approach can be low cost. Because the process will be incremental, the process of testing the code will be simpler, the project will have a lower risk of failure, and there will be a faster return on time invested.
The key that will make this feasible is a technique called Refactoring. To refactor is to restructure software by applying a series of transformations that make the code easier to understand and maintain, but which do not change its essential behavior.
We propose to develop a system for the incremental transitioning of programs from one language to another that uses Refactoring as a fundamental operation. The system will consist of three parts. A legacy source refactoring editor will allow a user to transform selected portions of the code written in the legacy language into a form suitable for translation to the new. An incremental translator will translate these selections into the new language. Finally a target language refactoring editor will allow the user to transform the translated code so that it is understandable and maintainable.
The resulting tool will be of use not only for translating code from one language to another, but also for helping maintain code that is not translated.
We propose to develop technology that will be applicable to many languages. However, for this Phase I SBIR we propose to focus on the translation of Ada to Java. Despite its clear technical superiority to many other languages, Ada (at least in the U.S.) has the reputation of being a niche language. Tools for Ada have traditionally been much more expensive than similar tools for more popular languages. Trained developers are in short supply, and since the advent of Java, few schools teach Ada, so the supply is getting tighter. Since the withdrawal of the congressional Ada mandate that all defense contractors use Ada for military systems, many contractors who had been chafing at the requirement are now starting to transition their systems to other languages. Although this is a sad state of affairs for the Ada market, it represents a significant commercial opportunity for legacy code translation tools.