Automated Support for Legacy Code Understanding
any large companies are facing a problem: their legacy systems are inhibiting their business growth and capacity to chans. This problem can be approached in a number of ways. One way is to simply get rid of a legacy system, replacing it with a new one developed to meet new requirements. This option is rarely exercised for many reasons. For example , more often than not, alegacy systep contains critical business rules ,that are valuable assets to the company. The business rules embedded in the code may not be accurately and explicitly documented anywhere else and are therefore very difficult to capture and redevelop. Another alternative is to encapsulate a legacy system so it can be used as a whole under a new execution environment or within a new system. A very simple example of such system " wrapping " is the use of terminal emulators to translate data streams between a mainframe machine and terminal screens so that dumb terminals can be replaced with LAN-based intelligent workstations. This approach has a number of attractive features: 1) &f&y. Since there is no software change,original function&ties arc preserved. 2) Low cost. Since the system still runs on its original platform, no new hardware/equipment is necessary 3) Short miption cyck There is no need for deep analysis and understanding of system structures and code. But this approach has certain limitations: 1) Nopfmmmcegain. The system runs on its original, and possibly slow and outdated platform. It cannot take full advantage of the new computing environments. If we were to migrate a mainframe-based system to a client server-based system, it would be more desirable to break down the old system into client modules and service modules and distribute them properly. 2) Low j.?aibility. A legacy system can only be reused as a whole. It is impossible to reuse its individual parts. Yet another approach to dealing with legacy systems seems to be a compromise between the two preceding approaches. It is based on the concept of reumble component recovery (RCR). Functional components oflegacy systems are recognized, recovered, adapted, and finally reused in new system development. Since the recovered components are generally much smaller in scale than the original system, their reusability is higher and they can be more easily distributed to meet different platform requirements. The drawback of this approach is that it requires deep analysis and understanding of old code, which is a …