Legacy System

Topics: Object-oriented programming, Legacy system, Application software Pages: 20 (6123 words) Published: December 14, 2012
Annals of Software Engineering 9 (2000) 293–313


Encapsulation of legacy software: A technique for reusing legacy software components Harry M. Sneed
Prellerweg 5, D-82054 Arget, Bavaria, Germany E-mail: Harry.Sneed@T-Online.de

The following paper reviews the possibilities of encapsulating existing legacy software for reuse in new distributed architectures. It suggests wrapping as an alternative strategy to reengineering and redevelopment. It then defines the levels of granularity at which software can be encapsulated before going on to describe how to construct a wrapper and how to adapt host programs for wrapping. Some wrapping products are discussed and the state of the art summarized. The advantage of wrapping over conventional reengineering is the low cost and even lower risks involved. This is the driving force in the search for improved wrapping technology.


Motivation for encapsulation

Legacy software components can be jobs, transactions, programs, modules or procedures within existing application systems which are more than five years old. Usually these systems are running on a mainframe and are based on an outdated technology such as hierarchical or networked database systems and transaction-oriented teleprocessing monitors with fixed panels. Although the technology with which they have been implemented is out of fashion, the application systems themselves are performing critical business functions in an acceptable and reliable manner. It took a lot of time and effort to develop these systems and specially to test them. Therefore, it is irrational to discard them completely, just because they do not meet current technical requirements. Typical candidates for encapsulation as business objects are batch jobs, online transactions and user subroutines as depicted below. On the other hand, there is a definite need to reengineer existing systems in order to satisfy the needs of modern business practices. It is not possible to restructure business processes without restructuring the computer process behind them [Taylor 1995]. If business processes are distributed to ensure more flexibility and to delegate responsibility then the supporting computer systems must also be broken up and distributed. Very often this leads to a new hardware architecture with client and server computers as well as a central host computer. On the software side it leads to a new user interface with a different work flow control and to a distributed relational or object-oriented database system, i.e., the underlying hardware is replaced as well as the software frontend and backend [Brodie and Stonebraker 1995]. © J.C. Baltzer AG, Science Publishers


H.M. Sneed / Encapsulation of legacy software

Figure 1. Legacy software components.

The question which comes up here is whether it is necessary to replace all of the existing software. Some will say yes, if you are going to replace the user interface and the database system, you might as well replace it all. Others will say no, you should keep as much of the existing software as possible and to reuse it in the new environment. The correct answer depends on the quantity, complexity and quality of the existing software as well as on the time and resources of the user. If the user has tight time or budget constraints, he may have no other choice but to reuse the existing programs. On the other hand, if the business logic of the old software is only a small layer of code between the presentation and access logic, then it might as well be replaced together with the presentation and access layers. So there is no cut and dried answer to this question. It is context dependent [Mattison 1994]. In practice, it depends on the ratio of business logic relative to the presentation and access logic. In order to justify the effort involved in reusing the existing programs, their business logic functions must be a significant part, i.e., there must be enough business logic available to...

References: Aberdeen Group (1995), “Hewlett-Packard’s C++ SoftBench 5.0,” Aberdeen Group Report, Boston, MA. Antares Inc. (1996), “ObjectStar – A Product for Wrapping Legacy Databases,” Antares Alliance Group, Dallas. Brodie, M. and M. Stonebraker (1995), Migrating Legacy Systems, Morgan Kaufman, San Francisco, CA. DeLucia, A., G.A. DiLucca, and A.R. Fasolini (1997), “Migrating Legacy Systems Towards ObjectOriented Platforms,” In Proceedings of IEEE-ICSM-97, Bari, Italy, October, p. 122. Dietrich, W.C. (1989), “Saving a Legacy with Objects,” In Proceedings of OOPSLA-90, Addison-Wesley, Reading, MA. Gamma, E. et al. (1995), Design Patterns, Addison-Wesley, Reading, MA. Gossain, S. (1997), “Accessing Legacy Systems,” In Object Expert, London, March. Graham, I. (1995), Migrating to Object Technology, Addison-Wesley, Workingham, GB. IBM (1997), “A Survey of Object-Oriented Technology on MVS/ESA,” IBM International Technical Support Center Report GG24-2505-00, Poughkeepsie Center, New York. Jacobson, I. and F. Lindstrom (1991), “Reengineering of Old Systems to an Object-oriented Architecture,” In Proceedings of OOPSLA-91, ACM Press, New York. Jacobson, I. (1992), Object-Oriented Software Engineering, Addison-Wesley, Reading, MA. Leeb, G. and S. Molterer (1999), “Developing Reengineering and Reusing Enterprise Software Using a Business Object Approach,” to be presented at TOOLS-99, CBESD Transition Workshop, Santa Clara, July. Mattison, R. (1994), The Object-Oriented Enterprise, McGraw-Hill, New York. Molterer, K. (1999), “Erfahrung mit der Reengineering bestehender Systeme in BMW,” In Proceedings of GI-Workshop on Software Wartung & Reengineering, F. Lehnert and F. Ebert, Eds., GI Arbeitskreis 5, Bad Honnef. Mowbray, T. and R. Zahavi (1994), The Essential CORBA, Wiley, New York. OMG (1998), “Business Object Component Architecture (BOCA),” Proposal – Revision 1.1, OMG Document bom/98-01-07, London. Orfali, R., D. Harkey, and J. Edwards (1996), The Essential Distributed Objects Survival Guide, Wiley, New York.
H.M. Sneed / Encapsulation of legacy software
Parodi, J. (1996), “Building Wrappers for Legacy Software Applications,” Digital Equipment Corp., Boston. Rugaber, S. and J. White (1998), “Restoring a Legacy – Lessons Learned,” IEEE Software 15, 4, 28. Sneed, H. (1996), “Encapsulating Legacy Software for Reuse in Client/Server Systems,” In Proceedings of WCRE-96, IEEE Press, Monterey, November. Sneed, H. (1997a), “Software Interface Reengineering,” In Proceedings of WCRE-97, IEEE Press, Amsterdam, October. Sneed, H. (1997b), “SoftWrap – ein Tool f¨ r die Kapselung vorhandener Assembler, PLI und COBOL u Programme,” HMD Heft Nr. 194, Stuttgart, Germany. Sneed, H. (1998), Objektorientierte Softwaremigration, Addison-Wesley, Bonn. Souder, T. and S. Mancordis (1999), “Legacy – A Tool for Securely Integrating Legacy Systems into a Distributed Environment,” In Proceedings of IEEE-WCRE-99, Atlanta, October, to appear. Taylor, D. (1995), Business Engineering with Object Technology, Wiley, New York. Verhoef, C., A. Sellink, and H. Sneed (1999), “Restructuring of COBOL/CICS Legacy Systems,” In Proceedings of 3rd European Conference on Software Maintenance and Reengineering, Amsterdam, March, p. 72. Wallner, K. and E. Wallace (1996), “Simulated Evaluation of the Object Management Group’s (OMG) Object Management Architecture (OMA),” ACM SIGPLAN Notices 31, 10, 168. Winsberg, P. (1995), “Legacy Code – Don’t Bag it, Wrap it” Datamation, May. Yourdon, E. (1997), “Distributed Computing,” American Programmer 10, 12.
Continue Reading

Please join StudyMode to read the full document

You May Also Find These Documents Helpful

  • Approaches to Legacy System Evolution Essay
  • Essay about Riordan Manufacturing Wan and Legacy
  • Cisco Systems, Inc.: Implementing ERP Essay
  • Pak Elekron Limited Case Essay
  • Pak Eektron Limited CASE Essay
  • Erp vs Legacy System Essay
  • Spa Works: New Integrated System Essay

Become a StudyMode Member

Sign Up - It's Free