The OpenEdge Hive

Such legacy applications are also often poorly documented. Even if there were design documents created at the time the software was originally written, it is typical for these to be so badly out of date as to be of limited use as documentation for the current system. The original intent and purpose which drove the current design is reflected only in the details of the existing software, where it can be difficult to discern. Thus, it is very difficult to imagine a transformation process which would reverse the normal OOAD process by creating abstract model forms from concrete ones. Even when one is working in a normal OOAD context where the software has been created by moving from abstract to concrete forms, if one modifies the code rather than the model and wants to bring the model back into line with the revised code, only the simplest and most straightforward transformations can be reversed and the more abstract levels can only be corrected manually.

If there were some “magic” tool which would create the abstract components corresponding to an existing legacy application, this would be enormously attractive. Then, one could perform some reorganization of those elements to better suit modern architectural practice and use well understood OOAD processes to create a fresh application with a new architecture and a new user interface. This fresh application could be just as modern in its technology and principles as one wanted. However, no such “magic” tool exists.

The difficulty of this problem can be appreciated by considering a simple example from a typical legacy application. Consider a simple file maintenance program. This program or group of programs might easily be hundreds of lines of code. Exactly what those hundreds of lines would look like are likely to vary significantly from one application to another based on both the state of technology at the time it was written and the “style” of the shop where it was created. All or most file maintenance programs from the same application are likely to be similar in structure, unless there was a shift in style during the life of the application, but the programs from one application are likely to be quite different in details than those from another application. This typical pattern of how such programs are written in a given shop constitutes a kind of intrinsic framework.

If one was working in the context of such an intrinsic framework and were given the schema for the table to be maintained and any special business logic which applied, one would have little difficulty in copying the framework pattern and applying it to these new elements. But, when we are trying to create an abstract model, we want to extract just the schema and business rules because the rest of the framework will be discarded in favor of the framework to be used for the new architecture. Seen from this perspective, the intrinsic framework of the legacy application is “noise” which is getting in the way of us extracting the “signal” of the key information.

To date, there is no software that can do this kind of “noise removal” so moving from concrete to abstract is a largely manual process. Indeed, in order to understand what one reads in the code, it is likely that one has to also interview the users in order to determine why the code behaves in a certain way, so the effort required may not be substantially less than simply designing the system from scratch. In fact, the biggest benefit in this context of having the legacy code as a starting point may be that one has a very concrete documentation of what has been considered correct behavior, which is not always easily determined from user interviews. If there were software that could automate or semi-automate large parts of this process, it would be perhaps the most desirable approach to transformation since we would end up with a completely fresh application using all of the most modern technology and architectural principles. But, without such software, a complete transformation along this path can be extremely expensive and time consuming.