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 …
[1]
Wojtek Kozaczynski,et al.
A Knowledge-based Approach To Software System Understanding
,
1991,
Proceedings., 6th Annual Knowledge-Based Software Engineering Conference.
[2]
Charles Rich.
A Formal Representation For Plans In The Programmer's Apprentice
,
1982,
On Conceptual Modelling.
[3]
Alfred V. Aho,et al.
Compilers: Principles, Techniques, and Tools
,
1986,
Addison-Wesley series in computer science / World student series edition.
[4]
Kate Ehrlich,et al.
Empirical Studies of Programming Knowledge
,
1984,
IEEE Transactions on Software Engineering.
[5]
Bill Curtis,et al.
Experimental evaluation of software documentation formats
,
1989,
J. Syst. Softw..
[6]
Wojtek Kozaczynski,et al.
Program concept recognition
,
1992,
Proceedings of the Seventh Knowledge-Based Software Engineering Conference.
[7]
William Lewis Johnson,et al.
Intention-based diagnosis of errors in novice programs (program understanding, debugging, intelligent computer-aided instruction)
,
1986
.
[8]
Linda Mary Wills,et al.
Automated program recognition by graph parsing
,
1992
.
[9]
John Edwin Hartman,et al.
Automatic Control Understanding for Natural Programs
,
1991
.
[10]
Joe D. Warren,et al.
The program dependence graph and its use in optimization
,
1987,
TOPL.
[11]
Linda M. Wills,et al.
Automated Program Recognition: A Feasibility Demonstration
,
1987,
Artif. Intell..
[12]
Mark Weiser,et al.
Program Slicing
,
1981,
IEEE Transactions on Software Engineering.
[13]
Elliot Soloway,et al.
PROUST: Knowledge-Based Program Understanding
,
1984,
IEEE Transactions on Software Engineering.
[14]
M. T. Harandi,et al.
A knowledge-based approach to automatic program analysis
,
1989
.