KR20050062896A - Method for extracting reusable components from legacy systems - Google Patents

Abstract

The present invention relates to a method for extracting reusable components from a legacy system to reengineer legacy systems that contain the core logic of the task into a new system that can meet new functional and environmental requirements. A typical legacy system consists of hundreds to thousands of programs. These programs work together tied to various business process flows. In order to extract components from legacy systems and reconfigure the system based on these extracted components, these programs must be separated into a set of programs that provide a single business function (service). The component extraction process is to grasp the area of business functions realized in the software system and extract a set of programs that perform one independent business function as components. Accordingly, the present invention provides an effective method for identifying components based on a work flow, thereby increasing the possibility of the components being independently reused, and dividing and arranging the components according to the target platform on which the components are to be placed.

Description

How to extract reusable components from legacy systems {METHOD FOR EXTRACTING REUSABLE COMPONENTS FROM LEGACY SYSTEMS}

The present invention relates to a method for extracting reusable components from a legacy system to convert from a legacy system that contains the core logic of the task to a new system that meets new functional and environmental needs.

Since the recent Y2K issue, companies have begun to recognize legacy systems as their core assets. Corporate backbone systems such as finance and distribution run on IBM mainframes, most of which are written in third-generation programming languages such as COBOL and PL / 1. However, as the importance of expanding services and component-based development on various webs is gradually increasing, reengineering converts important knowledge and processes of tasks developed with past technologies into component-based web environments. There is a lot of research on this. Legacy systems lack openness and lack of standardization, so the system itself is very inflexible and cannot support interactive ways of making dynamic decisions through the user-expected intimate user interface. . Therefore, rather than developing a new system for the new environment from the beginning, it is possible to save the development cost by maximizing the program of the legacy system with much support from the company and analyze and reuse the legacy system so that the existing resources can be reused. You should be able to extract the component.

The conventional component extraction technique proposes a method of clustering system components related to a specific function and recognizing them as one component. In this method, there is a tool that provides a code evaluation tool for evaluating how much program code is associated with a particular function. In order to extract components that perform a function related to a characteristic, the reengineer gives a high weight to the characteristic evaluation factors related to the characteristic and searches the system components based on it. That is, by assigning different weights to elements such as control flow, mathematical calculation, input / output, etc., the characteristics of the component to be extracted can be reflected. As a result of the search, the system component with the highest code evaluation value is found. After searching, the found component is set as a reference element, and system elements that affect or are affected by the element are found by applying system dependency information, clustered, and mapped into one component. This approach has the advantage of making it easier for legacy systems to find small components (e.g., interest calculations) for a specific purpose, but they do not seem to do the unit business. Rather, it would be right to recognize it as part of the unit business. As a result, this method is only concerned with extracting components of specific functions from legacy systems, which means that component extraction is weak in terms of moving and deploying the entire legacy system to a new platform.

SUMMARY OF THE INVENTION The present invention has been made to solve the above-described technical problem, and aims to identify and extract components from a legacy system and then place the extracted components on a new platform (J2EE or .NET).

To this end, we present a method to identify the components of the system based on the use case from the screen flow of the legacy system in order to identify the components from the legacy system, merge the use cases for similar purposes, extract them as components, and extract the extracted components. This paper presents a method for restructuring components by analyzing shared components. Finally, we present a method of dividing and arranging the extracted components according to the component platform.

The present invention further enhances the possibility of the components being independently reused by identifying components based on the work flow of the legacy system, and provides a method of dividing and arranging components in accordance with a target platform environment in which the components are to be deployed.

Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention will be described in detail.

1 is an overall flowchart of a method of extracting a component from a legacy system according to the present invention. In the present invention, a representative COBOL system of a legacy system will be described.

Referring to the drawing, in the use case-related system element identification step 100, for the use case identified through reverse engineering of the legacy system, the components of the software system participating in the use case are identified. In this process, program analysis information extracted through reverse engineering is used. We begin with the screen flow that we used to identify the use case in reverse engineering. The use case's screen flow is ultimately perceived as the work flow achieved through that use case.

Based on the screen flow graph, the screen flow associated with the use case is tracked, identifying the programs, screen files, or databases (or files) that participate in the use case. At this time, use the system resource graph and variable relation table restored through counter attack. For each of the programs identified in the above process, we identify system components that have an association relationship such as call relationship / link relationship and reference relationship by using program call graph and variable relationship table. The elements that make up a COBOL application system include "paragraphs", "program statements", "global variables", "programs", "screen files", "transactions", "databases", and "libraries". The elements are limited to "program", "paragraph", "screen file", "database", "library", and the like. Once all the use case related elements are identified, the relationship modeling is prepared as shown in Table 1 below.

The rows of the association modeling table in Table 1 represent subprograms, map files, copy books, and databases. In the column, each use case (UseCase, UC) and a program included in the use case (Prog) are represented. The x in the table means that a program in a column is associated with a subprogram in a row, a map file, a copy book, or a database.

Reconstructing the workflow for realizing one use case based on the system elements identified in relation to the use case is shown in FIG. 2. This figure depicts a general workflow for performing a function in most COBOL systems. In the figure, a rectangle represents a "use case workflow", and a circle inside the rectangle is a "program" or a "paragraph" constituting a program. Also shown in the figure are "screen files", "databases" and the like.

Next, based on the use case-related system elements and information identified in the previous step in the use case analysis step (110), each use case may be classified into a boundary class, a control class, and an entity class. Analyze from the point of view. The reason for this analysis is to identify use cases that perform similar business functions and responses through this analysis, and integrate them to recognize larger components. This step utilizes application use case diagrams, use case correspondence tables, and functional relationships that have been recovered through reverse engineering. For each use case, we analyze the use case components from the boundary class perspective. A boundary class is a class used to model the interaction between a system and its surroundings. In general, each actor / usecase pair has at least one boundary class. There are several types of boundary classes in a system, representing interactions with users, external systems, or devices. One boundary class provides an abstraction for the various screens associated with the use case. The analysis from the boundary class perspective analyzes the use case in terms of the order of user operations and tasks and the order of the screens to be shown to the user. As shown in FIG. 3, when the use case components are analyzed from the boundary class perspective for the general workflow for realizing the use case, the program or paragraph of the "screen file" and "screen generation function" and the "data collection function through the screen" are shown. "Program or paragraph is an element from the boundary class perspective. In other words, screen elements, elements that control the screen, input processing elements from the screen, and the like become use case components from the boundary class perspective. They can correspond to Java Server Pages or Servlets in a J2EE environment. JSP corresponds to screen element, and servlet is in charge of screen control function, input processing function from screen, etc.

Analyze the use case from the control class perspective. The control class represents the main control flow for the use case. It realizes the business logic of an application system and usually corresponds to a module that performs various operations or calculations to process and provide application services. In the case of Fig. 3, when analyzing the use case components from the control class point of view, the program / paragraph of the “move to record-field” function and the program / paragraph of the “calculate” function are elements from the control class point of view. to be. In the form shown, this program / paragraph seems to perform a very simple function, but is actually a program / paragraph that is responsible for the important business logic that performs the various operations to process and provide application services in a COBOL system. For example, in the case of "create account", which opens a bank account for a customer, the following specific business logic is implemented. Here, the business logic is underlined. To open an account, first create an account record for the customer. At this time, the account number is automatically assigned by the system according to the nature of the account. Next, the detailed information about the account record is filled in with the user information obtained through the screen. This information includes your username, your social security number, your password, and your account balance. System elements identified from the control class perspective may correspond to operations provided by the component's interface later. It can also correspond to Session Enterprise Java Beans (JEBs) in a J2EE environment.

Analyze the use case from the object class perspective. An object class encapsulates information represented in the system with all its attributes and associated behavior. In other words, it encapsulates the information handled or accessed by the use case. In the case of FIG. 3, if the use case components are analyzed from the object class perspective, the program / paragraph and DB / file of the “write to DB / file” function are elements from the object class perspective. In other words, the elements from the object class perspective include object information stored in a DB or a file, and related logic for storing such an object. For example, when opening a bank account for a customer, the "account" entity and "logic to store account information" are use case components from an object class perspective. This can correspond to an Entity EJB in a J2EE environment.

When the analysis of each use case is finished, prepare a use case analysis table as shown in Table 2. The use case analysis table records the summary of analysis from the boundary class, control class, and entity class perspectives for the use case.

The workflow of FIG. 2 may be analyzed as shown in FIG. 3 when analyzed in terms of a boundary class, a control class, and an object class.

As the business rules are realized in various forms in various parts of the legacy system, in order to effectively understand them, the components of the legacy system are decomposed based on the use case, and each use case is composed, as suggested in this research. We need to divide the system elements into three class perspectives, and then identify the business rules that are implemented in each class perspective.

Next, in the component candidate identification step (120), use cases that perform similar business functions and responsibilities are identified and grouped to identify component candidates. Group use cases that create, update, or delete an object class among use cases that cover the same object class. Here, even the use cases dealing with the same object class, except the case of only referencing (Read). Add use cases to the group that perform similar responsibilities or objectives from the control class perspective. Recognize a use case group as a component candidate.

Next, in the identifying a shared element step 130, the shared elements shared between them are identified based on the component candidates identified in the component identification work. The purpose of identifying the shared elements is to organize the highly reusable elements into separate components. Basically, highly reusable components are shared among many functions even within one software system. Identify shared elements shared among component candidates. The method of identifying shared elements uses the association modeling shown in Table 3. For example, consider the following association modeling table:

Assume that component candidate Comp1 consists of use cases UC1 and UC2 and component candidate Comp2 consists of UC3, UC4 and UC5. As shown in Table 3, use cases UC1 and UC2 share subprograms P11, P12, P13, and P14. However, UC3, UC4, and UC5 share only subprograms P12 and P13. Thus, shared elements shared between two component candidates Comp1 and Comp2 are P12 and P13. Once the shared elements are identified, the next step is to see if each shared element can be integrated with each other to form a larger unit. In order for shared elements to be integrated, the data or functions they handle must be similar. For example, in the above example, if shared elements P12 and P13 perform similar functions, they are combined to form a larger unit of shared elements.

Next, in the component extraction step 140, each component candidate identified in the component identification work is extracted as a component. At this time, if the shared element identified in step 130 can be configured as a separate component, such a shared component is configured first, and then the component is configured for the part except the shared element. The shared element is evaluated to see if the shared element identified in step 130 can be configured as a separate component. The results of the evaluation are divided into three parts. It is composed of separate components (componentization), division of shared elements, and duplication of shared elements. If it is necessary to configure a separate component as a result of the evaluation, the shared element identified in step 130 is extracted as a shared component. Specific examples of evaluating shared elements are shown in Tables 4 and 5 below.

In the above table, it is a reference table for scoring the reusability (Rx) for each detail item for the result value of the detail item (x) of the evaluation criteria to evaluate the reusability. Where x is fi, fo, ch, cp. For example, if the value for Fan-in (fi) is 4, 4 points are given to the reusability (R _fi ) of the module in terms of Fan-in item, and if the module is divided into three slices in terms of cohesion, You get two points of reusability score (R _ch ). In this way, scores are given in terms of each sub-item, and the shared elements are evaluated based on the sum of these scores, and the shared elements are evaluated as separate components, integrated, or duplicated. Decide if you want to be included in The evaluation results and the conditions of the shared elements are described in Table 6 below.

After extracting the shared component, each component candidate identified in the component identification task is composed of a component. At this time, components of the shared component are excluded from the components of each component candidate. If the result of the evaluation is to divide the shared elements, first divide the shared elements. In the case of division, it may be simply divided into subprogram units. In a more complicated case, one subprogram may be divided into smaller subprograms (slices) by applying a program slicing technique. After dividing the shared elements, each component candidate identified in the component identification work is composed of components. At this time, the divided shared elements are incorporated into an appropriate component. When the shared elements need to be duplicated as a result of the evaluation, the shared elements necessary in the process of composing the component candidates identified in the component identification work as components are duplicated.

Identifying the association / interaction between the components of FIG. 1 In step 150, the association or interaction of the components is determined.

The reusable component extraction method from the legacy system according to the embodiment of the present invention may be manufactured as a computer program and stored in a recording medium such as a hard disk, a floppy disk, a magneto-optical disk, a CD-ROM, a ROM, a RAM, and the like.

Most programs that contain significant business logic running on IBM mainframe systems, such as financial institutions, are now written in the CCOBOL programming language. The maintenance and operation of such systems takes up more than 70-80% of the information system budget. Recently, the environment of e-business companies is changing to user-oriented systems, and the necessity of converting legacy systems to component-based environments such as J2EE and .NET is emerging to satisfy these requirements. However, abandoning the existing legacy system and developing a new one from the beginning is a huge loss of the existing invested resources, and a new investment cost must be invested, so a method for utilizing the existing legacy resources as efficiently as possible should be suggested. Accordingly, the present invention proposes a method for maximizing the existing legacy support by identifying components based on the work flow of the legacy system, extracting and presenting components that are likely to be reused.

What has been described above is only one embodiment for implementing a method for extracting reusable components from a legacy system according to the present invention, and the present invention is not limited to the above-described embodiment, but is claimed in the following claims. Without departing from the gist of the invention, those skilled in the art to which the invention belongs, the technical spirit of the present invention to the extent that various modifications can be made.

1 is an overall flow chart for component extraction proposed in the present invention.

FIG. 2 illustrates a typical workflow for performing one function, mostly in a legacy system (COBOL program).

FIG. 3 is a diagram illustrating information analyzed in terms of a boundary class, a control class, and an object class with respect to the workflow of FIG. 2; FIG.

Claims (3)

(a) identifying use case-related system elements that identify software components that participate in the use case for those use cases identified through reverse engineering of the legacy system; (b) Use case analysis in which each use case is analyzed in terms of a boundary class, a control class, and an entity class based on the use case related system elements and information identified in the above step. step; (c) identifying use cases that perform similar business functions and responsibilities and identifying component candidates that group them; And (d) identifying the shared elements among them and finally extracting the components from the component candidates identified in the component identification work, and finally extracting the components. How to extract reusable components from legacy systems. The method of claim 1, Step (a) tracks the screen flow associated with the use case based on the screen flow graph, identifies programs, screen files, or databases participating in the use case execution, and analyzes the program of the reverse engineering step. The system resource graph and the variable relation table which are outputs of the program are used. For each of the programs identified in the above step, the program call graph and the variable relation table are used to call, link, and reference relations. Identifying system components that have a relationship of How to extract reusable components from legacy systems. The method of claim 1, Step (b) analyzes each use case in terms of boundary class, control class, and entity class based on the use case related system elements and information identified in the previous procedure. Characterized by How to extract reusable components from legacy systems.