Legacy system program transformation by Lyee methodology

https://doi.org/10.1016/j.knosys.2004.07.002Get rights and content

Abstract

Based on the comparative review of several approaches to legacy system conversion and revitalization, the Lyee methodology application for the issue is presented to clarify its idea, the associated procedure, and the implemented tools. It could be said that with the tools and manual developed by ICBSM&T, the mechanical transformation of the conventional program to a Lyee-structured one becomes possible as long as the programs are made in a procedure-oriented language. In addition to the program structure conversion, the Lyee methodology permits people to choose any application language in the transformed program. At the same time, quite a new approach related to the system conversion is introduced, in which the chunk of data extracted from an old program is edited to make a new conventional structure program that has a logical sequence instead of a Lyee type of declarative program. These features can be realized through the concept of LyeeBELT, which is a set of word-information about the attributes, formulae, and conditions for an independent data item.

The overall workflow of the legacy program transformation is shown in the following.

A critical part in its implementation is the feasibility study (pre-analysis) stage where necessary information is supposed to be secured, and an appropriate plan and policy about the system to be revitalized in the new system environment should be clarified so as to customize the tools accordingly. If the initial process is completed, the mechanical legacy system conversion will be realized by registering the parameters in the tool, and the reestablishment of business knowledge in the LyeeBELT will be enabled. With the regulated business logic on the LyeeBELT, the program maintenance afterwards becomes drastically simplified and stable without the ‘spaghetti’ problem, so that software evolution can be possible.

Introduction

It is not unusual that a software program, which was developed in the past and has been maintained for long time, is to be transferred to work on a new execution system environment and that the application language used up until a certain time is forced to be converted to a new one for some reason. However, an even more efficient methodology to mechanically transform the program is not yet successful in practice. Generally, an information system may resist modification and evolution rather than meet new and constantly changing business requirements [2].

In the present situation where the execution environment and the operation base of software diversify, the needs of the legacy system conversion are extremely high from a viewpoint of succession and maintenance of software assets [1]. However, the currently available ‘Scrap and Build’ approach does not satisfy the user in terms of the transition period, cost, and safety [5]. There were various trials to revitalize the legacy program as reviewed in next chapter, but to our knowledge none of them are satisfactory. For example, French [4] describes an example of a defense system consisting of almost 380,000 lines of source code that had been undergoing maintenance for 11 years. The software support tools are described as antiquated [3].

On the other hand, Lyee methodology applied on the issue is believed to be unique. Lyee-oriented legacy conversion is for breaking down the existing program into minimum constituents as the unit of a data item, then filtering and analyzing the information of each constituent, and deciding a word's subject type and its attribute. Given this extracted information, the new program is mechanically reconstructed to fit in the new environment and/or in the new application language.

Even in a Lyee-oriented approach, there are several parts where automatic conversion cannot or should not be realized for an independent chunk of programs like functions or subroutine, for example. However, at least mechanical treatment for such kinds of program units is possible. Using such Lyee-oriented legacy conversion, the actual business environment, revitalization period, and cost of existing software can be minimized. At the same time, the maintainability of the revitalized program can be improved. This paper contributes to such a prospect.

Section snippets

Conventional (structuring design) approach

Most software systems are structured design programs made in so-called procedure-oriented language [6], [7]. Various devices were made based on the factual knowledge of an engineer, and these conventional programs were assembled as a bunch of functions, which system engineers devised originally. The processing order made in this way is very rational but, on the other hand, it is natural that it comes in a non-defined order. Therefore, a processing function also becomes difficult to decompose,

The originality of Lyee legacy conversion

With the Lyee approach [1], A WORD is focused as a minimum configuration element in the conventional program. And then, according to the Definition 1 (Lyee Vector Definition rule), the reform processing is conducted on all extracted Words so as to reconstruct the new program, which has an equivalent value to the conventional program to be converted.

Definition 1 Lyee Vector Definition rule

This rule is the explanation of word subject types and attributes of a word, which construct various functions in a program. Word subject types

Overview of legacy conversion procedure

Lyee legacy conversion process is shown in Fig. 1.

(1st)–(3rd) steps in above Fig. 1, all necessary information for a legacy conversion can be extracted, and all the information is summarized up to an Exploration Table. Next (4th) step, information is edited to be assembled to produce Process Route Diagram. In (5th) step, LyeeBELT is generated as a core source of generated program. In (6th) step, the language conversion from old to new in LyeeBELT is executed. In (7th) step, editing new LyeeBELT

Lyee legacy system conversion tools

The relation of group of conversion tools (shown in Fig. 15) enabling the legacy system conversion processes is shown in the Fig. 14.

Referemce to Fig. 14, configuration (flow of execution) of the whole tool components is as follows:

  • [1]

    Reform program to do regulation of source program and to make Exploration Table.

  • [2]

    Old-LyeeBELT making program to generate Process Route Diagram and New-LyeeBELT

  • [3]

    Element generating program to do the Vector generation of Lyee structure

  • [4-1]

    Functional editing program which does

System configuration modification

There are OS (Operating System), DBMS (Data Bases management system), screen communication, middle software, and others in terms of system configuration, for which some renewal might be requested in connection to legacy system conversion. For these needs, the boundary inquiry between middle software versus business application program, between an OS versus a business application program, or between an OS versus middle software should be sufficiently conducted. This is to confirm the feasibility

Customized tool

Current tools should be customized, according to the corresponding language and the specifications of the corresponding old program. Customization is done through designating parameters based on the analysis. Therefore, it is expected that one will add functions and conversion logic, whenever necessary, for each conversion. Also, a mechanical analysis of the old program is possible for the most part, and therefore expected improvement is underway.

Expansion of the handling language

In the current version of our Legacy system, the

Conclusion

In comparison with the conventional legacy conversion approach that focuses mainly on the function of program, the Lyee approach pays attention to the data link in a program. In order to grasp the conventional program using a Lyee-style data link approach outlined in this paper we should first conduct a word-unit-based analysis and edit a set of analyzed data in the table format by which corresponding data is assigned to what we called Vector (Lyee's Word-unit-based program).

As for making the

Acknowledgement

The authors would like to thank Jun ISEDA and Akira NAKAZAWA, for their contribution and valuable comments on the work that reported in this paper.

References (16)

  • F. Negoro

    Study on axiomatic rules for building up relationships between requirement and source programs

    Int. J. Knowledge-Based Syst.

    (2003)
  • F. Negoro, Issam A. Hamid, Methodology to define software in a deterministic manner, International Conference on...
  • H. Bennett

    Legacy systems: coping with success

    IEEE Software

    (1995)
  • V.A. French, applying software engineering and process improvement to legacy defense system maintenance: an experience...
  • A. Monden, S. Sato, K. Matsumoto, Capturing industrial experiences of Software maintenance using product metrics,...
  • S.S. Yau et al.

    A survey of software design techniques

    IEEE Trans. Software Eng.

    (1986)
  • E. Yourdon et al.

    Structured Design: Fundamentals of a Discipline of Computer Program and System Design

    (1979)
  • R. Wirfs-Brock, B. Wilkerson, Object-oriented Design: a Responsibility-driven Approach, OOPSLA'89 Conference...
There are more references available in the full text version of this article.

Cited by (1)

View full text
Copyright © 2004 Elsevier B.V. All rights reserved.