Migrating legacy systems towards object-oriented platforms

Abstract

We present an approach to migrate legacy systems to object-oriented platforms. The process consists of six sequential phases and encompasses reverse engineering and re-engineering activities. The aim of the reverse engineering phases is to decompose programs into components implementing the user intelface management and components implementing application domain objects. The identification of objects is centred around persistent data store and exploits object-oriented design metrics. Wrapping techniques are the core of the reengineering activities. They make new sxstems able to exploit existing resources, thus allowing an incremental and selective translation of the identifed objects.CA, 1990, IEEE CS Press, pp. 266-271.P.E. Livadas and T. Johnson, "A new approach to finding objects in programs",

Reengineering windows software applications into reusable CORBA objects

“…However, he did not encapsulate the extracted software components into object-orientated modes. De Lucia, et al [8,9] proposed a six-step process to migrate the existing source code into object-orientated format. During object identification, the legacy program codes could be decomposed into individual program parts according to an abstract object model.…”

Recovering structured data types from a legacy data model with overlays

“…Migration to object oriented programming and extraction of an object oriented data model from procedural code are the topics of several works (e.g., [8][9][10][11][12]). Class fields originate from persistent data, user interface, files, records and function parameters, while class operations come from the segmentation of the program according to branch labels, in the migration of legacy procedural code to an object-oriented design described by Sneed and Nyary [10].…”

Automated Translation of Java Source Code to Eiffel

“…Wrapping foreign code. A wrapper enables the reuse a foreign implementation through the API provided by a bridge library [5,4,19,13]. This approach does not change the foreign code, hence there is no risk of corrupting it or of introducing inconsistencies; on the other hand, it is usually restrictive in terms of the type of data that can be retrieved through the bridging API (for example, primitive types only).…”