CN111052077B - Conversion device and conversion method - Google Patents

Abstract

The conversion device (1) is characterized by comprising: a version management tool (10) which manages meta information on conversion to each of conversion halfway sources (s 31) to (s 3 n), (s 4), and (s 5) for a set of conversion halfway sources (s 31) to (s 3 n), (s 4), and (s 5) generated by converting a part of a COBOL source (s 1) before conversion into a part of a Java source (s 2) after conversion; and a test tool (30) for specifying, when there is a failure in the confirmation test of the converted Java source (s 2), the conversion of the cause of the failure by referring to the meta information.

Description

Conversion device and conversion method

Technical Field

The present invention relates to a conversion device and a conversion method.

Background

In system migration from a current system to a new system, for example, there is a job of conversion development of a program. In the conversion development, a program language (for example, COBOL (Common Business Oriented Language, general business orientation language)) of a current program source (a source before conversion) used by a current system is replaced with another program language (for example, JAVA (registered trademark)), and a new program source (a source after conversion) used by a new system is created.

In conventional conversion development, for example, a plurality of conversion tools for performing language conversion in units of a command in a language grammar and in units of a syntax are prepared, and each conversion tool is sequentially executed for a source before conversion, thereby creating a converted source after the language conversion. In this case, the conversion tool may not be executed for a part of the conversion source for reasons of cost and cost. In this case, the part is subjected to the language conversion by manual correction, and a converted source in which the language conversion is completely performed is obtained.

In addition, in the conversion development, a confirmation test (true machine confirmation) for confirming whether or not there is a failure in the obtained converted source is performed. Specifically, the same input value is input to the source before conversion and the source after conversion, and if the same output value is obtained between the two, it is determined that there is no defect, and if different output values are obtained, it is determined that there is a defect. In the conversion development, when there is a failure in the source after conversion, a conversion tool or manual correction for causing the failure is specified, and the specified conversion tool or manual correction is corrected to remove the failure.

In general, a line that causes a failure can be specified for a transformed source. However, in the conventional language conversion in which the combination of the sequential execution of the conversion tool and the manual correction is performed, it is difficult to identify the conversion tool causing the failure or the more the manual correction requires the study of an knowledgeable person, and a large cost for coping with the failure is required. As a result, the conventional conversion development has a large cost for solving the problem.

Patent document 1 discloses the following: an information processing apparatus has: a conversion means for converting data of the main frame system into data of the open system; an allocation mechanism that allocates a color for each byte of input data; and a display means for displaying the input data in which the color is assigned for each byte by the assignment means, wherein the assignment means assigns a color for each byte of the data of the main frame system when the data of the main frame system is input as the input data, wherein the display means displays the data of the main frame system in which the color is assigned for each byte by the assignment means, wherein the assignment means assigns a color for each data of the open system when the data of the open system is input as the input data, and wherein the display means displays the data of the open system in which the color is assigned for each byte by the assignment means.

Prior art literature

Patent literature

Patent document 1: japanese patent laid-open publication 2016-191977 (claim 1)

Disclosure of Invention

Problems to be solved by the invention

According to patent document 1, it can be briefly confirmed whether or not a conversion from a pre-conversion source corresponding to data of the main frame system to a post-conversion source corresponding to data of the open system is properly performed, and a line which is a cause of a failure can be displayed for the post-conversion source. However, patent document 1 neither describes nor suggests a conversion of data for specifying a cause of a failure. Therefore, in patent document 1, the cost of coping with the failure in the conversion development cannot be reduced.

Problems to be solved by the invention

The present invention has been made in view of such circumstances, and an object of the present invention is to reduce cost for coping with a failure in system migration such as transition development.

Means for solving the problems

In order to solve the above-described problems, a conversion device according to the present invention converts a source before conversion into a source after conversion, and includes:

a meta information management unit that manages meta information on a transformation to each of the transformation halfway sources for a set of transformation halfway sources generated by transforming a part of the pre-transformation sources into a part of the post-transformation sources; and

And a test unit that refers to the meta information and determines a conversion of a failure cause of the failure when the failure exists in the confirmation test of the converted source.

The other invention will be described below.

Effects of the invention

According to the present invention, it is possible to reduce the cost for handling the failure in the system migration such as the conversion development.

Drawings

Fig. 1 is a functional configuration diagram of a conversion device according to the present embodiment.

Fig. 2 is a flowchart showing a different language conversion process.

Fig. 3 is an explanatory diagram of the manual correction result application.

Fig. 4 is an explanatory diagram of one-side priority three-way combination.

Fig. 5 is an explanatory diagram showing a procedure of the different language conversion performed before the additional work.

Fig. 6 is an explanatory diagram showing a sequence of the addition operation.

Detailed Description

Next, an embodiment of the present invention will be described with reference to the drawings. The conversion device of the present embodiment is a computer including hardware such as an input unit, an output unit, a control unit, and a storage unit. For example, when the control unit is constituted by a CPU (Central Processing Unit ), information processing of a computer including the control unit is realized by program execution processing of the CPU. The storage unit included in the computer stores various programs for realizing the functions of the computer by instructions of the CPU. Thus, the cooperation of the software and the hardware is realized. The program can be recorded on a recording medium and provided via a network.

Structure

As shown in fig. 1, the conversion device 1 of the present embodiment includes: the converters c1 to cn, conversion result libraries (restoration) r11 to r1n for each converter, a version management tool 10, meta information (meta information) DB (DataBase) 11, a merge tool (merge tool) m1, a mechanical conversion result library r2, a manual correction (manual correction) management tool 20, a manual correction implementation work space 21, a manual correction result library r3, a merge tool m2, a conversion result library r4, and a test tool 30.

The pre-conversion COBOL source s1 in fig. 1 is a source code in which COBOL codes ("COBOL 1", "COBOL2", … "," COBOL ") described by COBOL are recorded, and is executed for a customer to use the current system.

The converted Java source s2 in fig. 1 is a source code in which Java codes ("Java 1", "Java2", …, "Java" and "Java x") described by Java are recorded, and is executed for a customer to use a new system.

The various transformation halfway sources s31 to s3n, s4, s5 in fig. 1 will be described later.

[ converters c1 to cn ]

The converters c1 to cn mechanically convert a part of COBOL code of the COBOL source s1 before conversion into JAVA code. The character string of the COBOL code converted for each of the converters c1 to cn is determined in advance, and can be prepared in units of command words (for example, a converter that converts "MOVE" of the COBOL code into "set" of JAVA code). The converters c1 to cn can be prepared in units of syntax, and can be designed with various granularities in terms of language syntax.

Furthermore, each of the converters c1 to cn is designed not to repeatedly transform the same row of the COBOL source s1 before transformation. As shown in fig. 1, the converter c1 converts "COBOL1" of the COBOL source s1 before conversion into "Java1", whereas the converter c2 and the like do not perform the same conversion. Similarly, each of the converters c2 to cn converts each of "COBOL2" to "COBOLN" of the COBOL source s1 before conversion into "Java2" to "Java". The "COBOLX" of the COBOL source s1 before conversion is COBOL code to be manually corrected, and details thereof will be described later.

[ transformation result library r 11-r 1n for per-transformer ]

Each of conversion intermediate sources s31 to s3n for converting a part of COBOL code into JAVA code by executing each of converters c1 to cn for COBOL source s1 before conversion is stored in conversion result libraries r11 to r1n of the converters.

Version management tool 10

The version management tool 10 acquires and manages, as meta information, information on conversion when the converters c1 to cn are respectively converted from the COBOL source s1 before conversion to the intermediate sources s31 to s3n during conversion. The meta information includes, for example, for each conversion, a correspondence between COBOL code before conversion and JAVA code after conversion, an ID (Identifier) of a converter that executed the conversion, a content of the conversion (for example, "MOVE" → "set"), an ID of a conversion design, a date and time of execution of the conversion, and comments as supplementary instructions, but is not limited to these. The version management tool 10 of the present embodiment can be installed as a distributed version management tool such as Git.

[ meta information DB11]

The meta information DB11 stores meta information acquired by the version management tool 10. The conversion device 1 of the present embodiment may be provided with a GUI (Graphic User Interface, graphical user interface) such as TortoiseGit, and can visually trace meta information and convert the intermediate sources s31 to s3n.

[ merging tool m1]

The merging tool m1 performs merging processing for the transformation intermediate sources s31 to s3n stored in the transformation result libraries r11 to r1n for each converter. The merging process can use, for example, three-way merging (which is well known and will not be described in detail) used in the distributed version management tool.

For example, the merging tool m1 performs three-way merging with the COBOL source s1 before conversion being a parent (parent), with any 2 of the conversion intermediate sources s31 to s3n derived from the parent being children, and reflects the conversion positions of the 2 children in the result of the parent (conversion intermediate source in which the conversion further progresses). If the conversion positions of 2 sub-groups are the same row, the three-way combination fails (collision), but the converters c1 to cn of the present embodiment are designed so that the conversion positions are unique, and therefore, there is no case where the conversion positions of 2 sub-groups are the same row.

For example, the merging tool m1 first performs three-way merging with the COBOL source s1 before conversion as a parent and the sources s31 and s32 in the middle of conversion as the 1 st child and the 2 nd child, and obtains the 1 st result. Next, the merging tool m1 performs three-way merging with the COBOL source s1 before conversion as a parent, the 1 st result as the 1 st child, and the transform halfway source s33 as the 2 nd child, thereby obtaining the 2 nd result. By performing three-way merging in multiple stages as described above, it is possible to obtain a transformation intermediate source s4 ("Java 1", "Java2", …, "Java" and COBOLX ") in which all the mechanical transformations by the converters c1 to cn are performed.

In addition, as the merging process, the merging tool m1 may merge the conversion intermediate sources s31 to s3n together to obtain the conversion intermediate source s4.

[ mechanical transformation result library r2]

The mechanical transformation result library r2 stores transformation intermediate sources s4 in which all the mechanical transformation results are combined by the combining tool m 1.

[ Manual correction management tool 20]

The manual correction management tool 20 manages manual correction for performing a conversion from a part of the COBOL source s1 before conversion to a part of the Java source s2 after conversion. Specifically, the manual correction management tool 20 converts the COBOL code "COBOLX" of the COBOL source s1 before conversion into the Java code "Java x" of the Java source s2 after conversion by manual correction.

In addition, the manual correction management tool 20 outputs information on the transformation of the manual correction as meta information to the version management tool 10.

Further, the conversion from COBOL code to JAVA code by manual correction is performed in a case where the same COBOL code is not applicable to the rule of performing the same mechanical conversion due to the difference in language specifications. Specifically, the following manual correction requirements 1 to 3 are satisfied.

Manual correction necessity 1: there are multiple identical data item names

Manual correction necessity 2: there is an explicit dead code (unreachable code)

Manual correction necessity 3: there are multiple identical branching conditions

Regarding the manual correction necessary example 1, for example, in the case of the pair

[ COBOL code ]

01 D1 PICTURE X(2) VALUES ‘AZ’.

01 D1 PICTURE 9(2) VALUES 10.

In the case of mechanical transformation, a product is produced

[ JAVA code ]

String d1＝“AZ”

int d1 10；

The COBOL code described above has no problem in the syntax of COBOL, but the JAVA code described above becomes a compiling error caused by repetition of variable names in JAVA.

Regarding the manual correction necessary example 2, for example, in the case of the pair

[ COBOL code ]

EXIT.

MOVE A TO B.

In the case of mechanical transformation, a product is produced

[ JAVA code ]

return；

b.set(a)；

The COBOL code described above has no problem in the syntax of COBOL, but the JAVA code described above becomes a coding error in JAVA due to explicit dead code.

Regarding the manual correction necessity example 3, for example, in the case of the pair

[ COBOL code ]

In the case of mechanical transformation, a product is produced

[ JAVA code ]

The COBOL code described above has no problem in the syntax of COBOL, but the JAVA code described above becomes a compiling error in JAVA due to repetition of branching conditions.

In the case of the manual correction according to the necessary examples 1 to 3, different manual correction results are produced so that the same operation is performed in the JAVA code even for the same COBOL code.

[ Manual correction of working space 21 for practical use ]

The manual correction execution work space 21 is a work area for performing manual correction of the manual correction management tool 20.

[ Manual correction result library r3]

The manual correction result library r3 stores a transformation intermediate source s5 for performing manual correction by the manual correction management tool 20 on the COBOL source s1 before transformation to transform a part of COBOL code into JAVA code.

[ merging tool m2]

The merging tool m2 merges the transformation halfway source s4 stored in the mechanical transformation result library r2 with the transformation halfway source s5 stored in the manual correction result library r 3. Specifically, the merge tool m2 performs three-way merge with the COBOL source s1 before conversion as a parent, the intermediate source s4 as the 1 st child, and the intermediate source s5 as the 2 nd child, thereby obtaining the Java source s2 after conversion.

As the merging process, the merging tool m1 and the merging tool m2 may merge the transformation intermediate sources s31 to s3n and the transformation intermediate source s5 together to obtain the transformed Java source s2.

[ transformation result library r4]

The conversion result library r4 stores the converted JAVA source s2 in which only JAVA codes are recorded, and which is subjected to mechanical conversion and manual correction by the merging tool m 2.

[ test tool 30]

The test tool 30 performs a validation test (true validation) of the transformed Java source s 2. In the confirmation test, for example, the same input value is input to the COBOL source s1 before conversion and the Java source s2 after conversion, and if the same output value is obtained between the two, it is determined that there is no failure, and if different output values are obtained, it is determined that there is a failure. When there is a defect, the test tool 30 refers to the meta information DB11 based on the defect position information, and determines a conversion of the defect.

For example, as shown in fig. 1, the test tool 30 determines that there is a failure as a result of the validation test, and recognizes that the Java code "Java2" of the converted Java source s2 is a cause of the failure. Specifically, it is found that the correct code for the line "Java2" which is a priori knowledge to the conversion developer is different from the Java code "Java2" described in the converted Java source s2 outputted by the merging tool m 2. In this case, the test tool 30 refers to the meta information DB11, and acquires meta information on conversion from COBOL code "COBOL2" to JAVA code "JAVA 2". By analyzing the acquired meta information, the test tool 30 can specify details of causes of defects such as problems in the converter c2 itself that performs the conversion to JAVA code "JAVA2", and problems in the conversion design related to the conversion to JAVA code "JAVA 2".

< treatment >

Next, as a process performed by the conversion device 1 of the present embodiment, a different language conversion process from COBOL to JAVA will be described with reference to fig. 2. In the description, reference is also made appropriately to fig. 1.

First, the conversion device 1 performs format shaping for the COBOL source S1 before conversion (step S1). Specifically, the conversion device 1 performs 1-degree parallelization of intermittent writing, unification of large characters and small characters, and the like on COBOL codes of the COBOL source s1 before conversion, and facilitates conversion in the converters c1 to cn.

Next, the conversion device 1 performs definition DB conversion for the COBOL source S1 before conversion (step S2). Specifically, the conversion device 1 analyzes the COBOL code of the COBOL source s1 before conversion, and stores definition information of the data item in a DB (a storage unit not shown in fig. 1).

Next, the conversion device 1 syntactically shapes the COBOL source S1 before conversion (step S3). Specifically, the conversion device 1 performs syntax such as unifying the sugar coating syntax into a regular notation, and shaping the syntax of the COBOL source s1 before conversion into syntax on the premise of inputting to the converters c1 to cn.

Next, the conversion device 1 performs a common conversion into the JAVA language for the COBOL source S1 before conversion (step S4). Specifically, the conversion device 1 uses the report of JAVA, main method, and the like, and requires a conversion design common to the converters c1 to cn regardless of the characteristics of the conversion design. According to step S4, the conversion designs common to the converters c1 to cn can be excluded from the conversion designs of the converters c1 to cn, and the conversion designs of the converters c1 to cn can be simplified.

Next, the conversion device 1 performs sequential dependency conversion into JAVA language for the COBOL source S1 before conversion (step S5). Specifically, the transformation device 1 applies a transformation design having a relation to the dependency of the execution sequence to a plurality of transformation designs related to the transformation from the pre-transformation COBOL source s1 to the post-transformation Java source s2, when the execution result of one transformation design depends on the execution result of another transformation design. According to step S5, the conversion having the execution order dependency is performed in advance, and thus the conversion design of each of the converters c1 to cn can be simplified without having the execution order dependency between the conversion of each of the converters c1 to cn.

Next, the conversion device 1 performs parallel conversion into JAVA language for the COBOL source S1 before conversion (step S6). Specifically, the conversion device 1 applies the conversion design of each of the converters c1 to cn, and applies the manually corrected conversion design of the manual correction management tool 20 to the conversion that is not handled or cannot be handled in the conversion of the converters c1 to cn.

As shown in fig. 2, step S6 can be divided into, for example, independent command language transformations (1) to (N) corresponding to the converters c1 to cn, respectively (steps S6-1 to S6-N), and manual correction transformations corresponding to the manual correction (step S6-X). The independent command words conversion (1) to (N) are processes (for example, "MOVE" → "set") of performing mechanical conversion to JAVA according to the type of command words of COBOL. The conversion between the converters c1 to cn is designed not to affect other conversions, so that the independent command word conversions (1) to (N) can be performed in parallel. Further, instead of performing the conversion in terms of command words like the independent command word conversion (1) to (N), the conversion may be performed independently in terms of syntax, for example. The manual correction change (S6-X) is a change based on the manual correction management tool 20.

In step S6, the version management tool 10 acquires meta information on the independent command language transformations (1) to (N) corresponding to the respective converters c1 to cn and meta information on the manual correction transformations corresponding to the manual correction, and stores the meta information in the meta information DB11.

Next, the conversion device 1 combines the conversion results of the parallel conversion in step S6 (step S7). Specifically, the conversion device 1 performs the merging process by the merging tools m1 and m2 on the conversion intermediate sources s31 to s3n (or the conversion intermediate source s 4) converted by the converters c1 to cn and the conversion intermediate source s5 converted by the manual correction management tool 20, and generates the converted Java source s2.

Next, the conversion device 1 performs a validation test of the converted Java source S2 by the test tool 30 (step S8). When confirming that there is a failure in the test, the test tool 30 refers to the corresponding meta information stored in the meta information DB11 based on the failure position information, and determines a change of the failure cause that causes the failure.

In the conversion development, after the converter for performing the conversion causing the failure is corrected, the different language conversion processing of fig. 2 is performed again. In this case, since the conversion between the converters does not affect the conversion of the other converters, the parallel conversion in step S6 is only required to perform the independent command language conversion corresponding to the corrected converter, and the other independent command language conversion is not required. Therefore, in the combination of step S7, the conversion result of the completion of the independent command language conversion corresponding to the unmodified converter can be applied, which contributes to a reduction in the man-hour for the reconversion after the response to the failure, and can reduce the burden and the time required for the processing of fig. 2.

According to the processing of fig. 2, when converting the COBOL source s1 before conversion into the Java source s2 after conversion, the version management tool 10 manages the meta information, thereby making it possible to trace back the history of conversion. As a result, the identification of the cause of the failure when the Java source s2 is defective after conversion can be sufficiently achieved by referring to the meta information, and thus it is easy to perform the conventional study without the need for a person having knowledge.

Therefore, the cost for coping with the failure in the conversion development can be reduced.

Manual correction result application in addition work

In the conversion development of converting a source before conversion provided by a customer into a source after conversion, there are cases where the customer corrects the source before conversion and changes the specification regardless of the progress of the conversion development, for reasons of maintenance development such as countermeasures against defects and countermeasures against method correction. In this case, it is necessary to perform the conversion development again after the completion of the initial conversion development, and to introduce the specification change into the post-conversion source. The completion of the initial conversion development means that the confirmation test of the source after conversion is not completed poorly, and is sometimes referred to as "freezing". In addition, the frozen specification change handling operation in the conversion development again may be referred to as "additional operation".

Although the additional work is necessary, since the delay of the system migration is caused by increasing the amount of work for conversion development, there is a strong demand for reducing the number of man-hours of the work and for ending the work in advance. However, conventionally, for example, in accordance with the above-described manual correction requirements 1 to 3, when the manual correction of the corresponding line is performed in the initial conversion development, the same line must be manually corrected even in the additional work, and the efficiency is low.

In addition, conventionally, even if a confirmation test is performed before freezing for a manually corrected conversion position in a conversion source, it is necessary to perform substantially the same confirmation test again in an additional operation, and thus the number of test steps for the additional operation cannot be reduced.

That is, in general, in maintenance development on the customer side, code correction of specification change is often ended in units of functions, and therefore the influence of code correction on a new system is approximately local. On the other hand, in the conversion development, the conversion (either mechanical or manual correction) is performed in terms of conversion (syntax), and thus the influence of the conversion on the new system is related to the whole. Thus, there is a tendency for the validation items of the validation test for the manually revised transformation to be scattered throughout the new system. As a result, even if the manual correction is small, the number of confirmation items of the confirmation test for the conversion of the manual correction is not small, and thus test man-hours of substantially the same extent as those before freezing are required. Such a case exists regardless of whether the manually corrected conversion position is a position that causes an influence of the correction on the customer side.

The conversion device 1 of the present embodiment uses the three-way combination performed by the combination tools m1 and m2 to mechanically apply the manual correction result before freezing, which is not related to the correction of the specification change on the customer side, in the additional work. In the present embodiment, the three-way merging with the manual correction result as the object is performed by the merging tool m2, and the three-way merging performed by the merging tool m2 is described in the following description, but the same can be performed by the merging tool m 1.

As shown in fig. 3, a pre-conversion source sp, a correction-version pre-conversion source sc1, and a manual correction source sc2 are prepared.

The pre-conversion source sp is a source code in which COBOL codes described by COBOL (row 1 "COBOL1", row 2 "COBOL2", and row 3 "COBOL 3") are recorded. The pre-conversion source sp is a conversion development object from which a customer originally provides a conversion development side. The pre-conversion source sp corresponds to the pre-conversion COBOL source s1 of fig. 1.

The pre-correction version conversion source sc1 is a source code in which COBOL codes described by COBOL (row 1 "COBOL1", row 2 "COBOL2", and row 3 "COBOLA") are recorded. The correction version pre-conversion source sc1 is equal to the pre-conversion source sp, and reflects the correction amount ("COBOL 3" (specific line) → "COBOLA") of the customer-side specification change. The source sc1 before the modification conversion is provided by the customer at the time of the additional work, in other words, after freezing.

The manual correction source sc2 is a source code that converts a part of COBOL code of the source sp before conversion into JAVA code ("COBOL 2" → "JAVA 2") by the manual correction management tool 20. The manual correction source sc2 is created during the initial conversion development, in other words, before freezing.

The version management tool 10 can manage meta information on the pre-conversion source sp, the pre-correction-version-conversion source sc1, and the manual correction source sc2, and can manage the contents of the pre-conversion source sp, the pre-correction-version-conversion source sc1, and the manual correction source sc 2.

The merging tool m2 performs three-way merging in which the source before conversion sp is set as a parent of merging, the source before conversion sc1 is set as a child of merging (1 st child), and the manual source sc2 is set as a child of merging (2 nd child). As a result, the manual correction application source sd shown in fig. 3 is obtained. The version management tool 10 retrieves and manages meta information about the manual revision application source sd.

When comparing the source sc1 before correction version conversion with the manual correction application source sd, the code of the line 2 "COBOL2" is converted into "Java2" without being affected by the correction by the customer for the line 3 "COBOL3", and the manual correction result of the manual correction source sc2 can be applied to the source sc1 before correction version conversion. In the prior art, the conversion of "COBOL2" → "Java2" is performed by manual correction with respect to the correction version conversion source sc1 in the additional work, but in the present invention, the trouble of the conversion can be omitted. As a result, the object of the manual correction in the additional work is reduced to a corrected COBOL code for changing the specification on the customer side, among COBOL codes for performing the manual correction before freezing.

In addition, the manual correction result is applied to the confirmation test before freezing of the source after conversion including the manual correction result based on the manual correction source sc 2. Therefore, in the additional work, when the confirmation test of the transformed source (customer correction reflection end) for the merging process using the manual correction application source sd is performed, the confirmation item of the confirmation test of the transformation with respect to the applied manual correction can be omitted. As a result, the number of test steps for the additional work can be reduced.

Further, for the conversion of the 3 rd line "cobolla" of the manual correction application source sd obtained by the three-way combination into the JAVA code, when "cobolla" is a mechanically convertible COBOL code, the conversion is performed by any one of the converters c1 to cn, and the result is stored in the mechanical conversion result library r2. On the other hand, when "COBOLA" is a COBOL code requiring manual correction, the manual correction is performed by the manual correction management tool 20 with the manual correction application source sd as an object, and the result is stored in the manual correction result library r3. After that, the sequence (step S7 and the like of fig. 2) already described is followed.

Three-way combination of party priority

In the additional work, there is a case where the correction position (specific line) on the customer side with respect to the source before conversion and the position (manual correction line) where the manual correction is performed before freezing with respect to the source before conversion are repeated. In this case, if the three-way combination of the manual correction result application is performed, a collision occurs, and the combination cannot be performed.

Therefore, when the correction line on the customer side and the manual correction line overlap, the merging tool m2 performs the one-priority three-way merging that prioritizes the correction line on the customer side.

As shown in fig. 4, a case will be described in which a pre-conversion source sp, a correction-version pre-conversion source sc1a, and a manual correction source sc2 are prepared. The pre-conversion source sp and the manual correction source sc2 in fig. 4 are the same as the pre-conversion source sp and the manual correction source sc2 shown in fig. 3.

The pre-correction version conversion source sc1a is a source code in which COBOL codes described by COBOL (line 1 "COBOL1", line 2 "COBOL", line 3 "COBOL 3") are recorded. The correction version pre-conversion source sc1a is equal to the pre-conversion source sp in terms of correction amount ("COBOL 2" → "COBOLA") reflecting the specification change on the customer side. The original sc1a before the modification is provided by the customer at the time of the additional work, in other words, after freezing.

The version management tool 10 manages meta information on the source sc1a before conversion of the modified version, and can thereby manage the content of the source sc1a before conversion of the modified version.

If the three-way combination of fig. 3 is assumed for the pre-conversion source sp, the pre-correction version conversion source sc1a, and the manual correction source sc2, the customer correction ("cobla" (specific line)) for the 2 nd line "COBOL2" of the pre-conversion source sp collides with (repeats) the manual correction ("Java 2" (manual correction line)), and thus the combination cannot be performed.

Therefore, as shown in fig. 4, the merging tool m2 performs one-way preferential three-way merging in which the source before conversion sp is the parent of the merging, the source before conversion sc1a is the child (1 st child) of the merging, and the manual source sc2 is the child (2 nd child) of the merging. As a result, the customer correction priority source sda (line 1 "COBOL1", line 2 "COBOL1", line 3 "COBOL 3") including the customer correction ("COBOL") without the manual correction result ("Java 2") is obtained. The version management tool 10 acquires and manages meta information about the customer correction priority source sda.

According to the first aspect of the present embodiment, even if the manual correction collides with the customer correction, the customer correction can be reliably reflected on the result of the three-way combination, and the original demand of the customer can be reliably satisfied.

Further, in the case where "cobolla" is a COBOL code that can be mechanically converted, conversion is performed by any of the converters c1 to cn, and the result is stored in the mechanical conversion result library r2, with respect to conversion of the 2 nd line "cobolla" of the customer correction priority source sda obtained by one-way priority three-way combination into JAVA code. On the other hand, when "COBOLA" is a COBOL code requiring manual correction, the manual correction is performed by the manual correction management tool 20 with the customer correction priority sda as an object, and the result is stored in the manual correction result library r3. After that, the sequence (step S7 and the like of fig. 2) already described is followed.

Test work time reduction in additional work >

The additional work is sufficient in essence to perform the conversion development again for the correction amount (of a substantially small scale) performed by the customer with respect to the source before conversion. Most of the validation items of the test performed in the additional work are required to be repeated with the validation items of the test already performed in the initial conversion development before the additional work. Therefore, the idea of reducing the number of test work steps in the additional work is established by applying the result of the test validation in the initial conversion development, and the method will be specifically described below.

As shown in fig. 5, in the conversion of a different language before the additional work, that is, in the initial conversion development, the conversion device 1 of the present embodiment executes the conversion design setting (step S11), the converter generation (step S12), the mechanical conversion+manual correction (step S13), and the three-way combination (step S14) when converting the pre-conversion source sp (for example, COBOL) into the post-conversion source sq (for example, JAVA).

The conversion design setting (step S11) is a step of analyzing the pre-conversion source sp at the conversion development side, and setting 1 or more conversion designs necessary for the production of the post-conversion source sq for the pre-conversion source sp. The transformation design is a framework for defining how the code string to be transformed is rewritten. For example, the type of the required conversion design may be appropriately determined on the conversion development side, but the method of determining is not limited thereto.

In the example of fig. 5, 5 types of conversion designs A1 to E1 are set for each conversion target for the pre-conversion source sp. The conversion designs A1 to C1 are conversion designs related to mechanical conversion of the converters (corresponding to the converters C1 to cn of fig. 1). The conversion designs D1 and E1 are conversion designs related to conversion of manual correction (corresponding to manual correction performed by the manual correction management tool 20 in fig. 1).

The converter generation (step S12) is a step of generating a converter related to a conversion design related to the mechanical conversion among the set conversion designs. In fig. 5, for each of the conversion designs A1 to C1 related to the mechanical conversion, a converter A2 facing the conversion design A1, a converter B2 facing the conversion design B1, and a converter C2 facing the conversion design C1 are generated. The converter A2 for the conversion design A1, the converter B2 for the conversion design B1, and the converter C2 for the conversion design C1 have the same functions as the converters C1 to cn of fig. 1.

The mechanical transformation+manual correction (step S13) is a step of performing mechanical transformation and manual correction conforming to the transformation design. In fig. 5, the converters A2 to C2 perform mechanical transformation conforming to the transformation designs A1 to C1 for each of the transformation objects in the pre-transformation source sp, respectively, and output transformation results A3 to C3. Further, the manual correction management tool 20 (fig. 1) performs manual correction conforming to the transformation designs D1, E1 for each of the transformation objects in the pre-transformation source sp, and outputs the transformation results D3, E3. The conversion results A3 to E3 correspond to the conversion intermediate sources s31 to s3n, s4, s5 shown in fig. 1.

As shown in fig. 1, the conversion device 1 according to the present embodiment manages the conversion results of the converters c1 to cn in a single library (conversion result libraries r11 to r1n for each converter in fig. 1), and centrally manages the conversion results of the manual correction in one library (manual correction result library r3 in fig. 1). However, the management unit of the library can be arbitrarily set. Therefore, for the description with reference to fig. 5 and 6, the conversion device 1 of the present embodiment manages the conversion result in the library for each conversion design. That is, the conversion results A3 to E3 shown in fig. 5 are managed in a library (not shown in fig. 5) prepared for each of the conversion designs A1 to E1. In addition, as the library, a library in which a plurality of transformation designs are concentrated may be prepared instead of the library prepared for each transformation design.

The conversion development side performs on-board confirmation of the conversion results A3 to E3. The on-board confirmation is a well-known method, and the description thereof is omitted. In the present embodiment, the results of the on-board confirmation of the conversion results A3 to E3 are good.

The three-way combination (step S14) is a step of three-way combination for the conversion result obtained by the mechanical conversion+manual correction (step S13). Three-way merging (step S14) is performed by the merging tools m1, m2 shown in fig. 1. In fig. 5, three-way merging is performed for the conversion results A3 to E3, whereby a converted source sq can be obtained.

The conversion development side performs true machine confirmation for the converted source sq. The true machine validation corresponds to the validation test of the test tool 30 shown in fig. 1. The initial conversion development ends as described above.

After the initial conversion development is completed, the customer corrects the source before conversion, and thus performs an additional job. As shown in fig. 6, in the addition operation, the conversion device 1 of the present embodiment converts a pre-conversion source spa (corresponding to a pre-conversion source of a correction version) including a correction amount spa1 of a customer into a post-conversion source sqa including a correction amount sqa1 corresponding to the correction amount spa 1. In this conversion, the conversion design setting (step S21), the converter generation (step S22), the mechanical conversion+manual correction (step S23), and the three-way combination (step S24) shown in fig. 6 are executed.

The conversion design setting (step S21) is the same as the conversion design setting (step S11) of fig. 5. As shown in fig. 6, in the conversion design setting (step S21), corresponding to the case where the correction amount spa1 is included in the pre-conversion source spa, the conversion designs B1 and D1 (fig. 5) are replaced with the conversion designs B11 and D11, respectively, and 5 kinds of conversion designs A1, B11, C1, D11 and E1 are set for each conversion target for the pre-conversion source spa. The conversion design B11 is a conversion design related to mechanical conversion. The transformation design D11 is a transformation design related to the manually corrected transformation.

The converter generation (step S22) is the same step as the converter generation (step S12) of fig. 5. As shown in fig. 6, in addition to the converter A2 (fig. 5) for the conversion design A1 and the converter C2 (fig. 5) for the conversion design C1 that have been generated, the converter B21 for the conversion design B11 is newly generated for the newly set conversion design B11. The converter B21 facing the conversion design B11 has the same function as the converters c1 to cn of fig. 1.

The mechanical transformation+manual correction (step S23) is the same as the mechanical transformation+manual correction (step S13) of fig. 5. In fig. 6, in addition to the conversion results A3, C3 (fig. 5) that have been generated by the mechanical conversion, the converter B21 facing the conversion design B11 performs the mechanical conversion conforming to the conversion design B11 for the conversion object in the pre-conversion source sp, while newly outputting the conversion result B31. In fig. 6, in addition to the conversion result E3 (fig. 5) that has been generated by the manual correction, the manual correction management tool 20 (fig. 1) performs the manual correction conforming to the conversion design D11 for the conversion object in the pre-conversion source sp, and newly outputs the conversion result D31. The conversion results B31 and D31 correspond to the conversion intermediate sources s31 to s3n, s4, and s5 shown in fig. 1.

The conversion development side performs on-board verification of the new conversion results B31, D31. The conversion results A3, C3, and E3 that have been generated are omitted in the additional work because the completion of the on-board confirmation (fig. 5) is completed. Therefore, the conversion result is managed for each conversion design, and thus the number of test man-hours for on-board confirmation during the additional work can be reduced. In the present embodiment, the results of the on-board confirmation of the conversion results B31 and D31 are good.

The three-way combination (step S24) is the same step as the three-way combination (step S14) of fig. 5. In fig. 6, three-way combination is performed on the conversion results A3, B31, C3, D31, and E3, whereby the post-conversion source sqa including the correction amount sqa1 corresponding to the correction amount spa1 can be obtained.

The conversion development side performs a true machine validation with respect to the transformed source sqa. In this real machine check, the check items (check items related to the conversion designs A1, C1, and E1 other than the conversion designs B11 and D11 that are changed in accordance with the correction amount spa 1) of all the check items that the correction amount sqa1 does not affect are checked to be finished before the addition work (fig. 5), and therefore, may be omitted in the addition work. Therefore, as shown in the examples of fig. 5 and 6, the conversion result is managed for each conversion design, and only the confirmation item, which affects the correction amount sqa1, of all the confirmation items confirmed by the machine may be confirmed. As a result, the number of man-hours for testing the verification of the real machine in the additional work can be reduced.

Modification example

The embodiments of the present invention have been described above, but the present invention is not limited to the above embodiments and can be appropriately modified within a scope not departing from the gist of the present invention. For example, the program language of the source before conversion in the conversion development is not limited to COBOL, and may be another program language. The program language of the converted source in conversion development is not limited to JAVA, and may be another program language.

The language conversion in the conversion development is not limited to the conversion from COBOL to JAVA, which is used in the present embodiment, and may be a conversion from a host system COBOL to an open system COBOL, which is a conversion to a different type of program language.

The present invention is not limited to the conversion development concerning the conversion of the program language, and can be applied to various migration developments accompanying the system migration, such as data migration development for migrating the data processed by the current application software to the new application software.

The present invention can also be applied to a method of sequentially executing a plurality of types of conversion tools for a conversion source as in the prior art. Conventionally, as a tool for mechanically converting a program language, there is a tool for replacing a code perspective (syntax tree interpretation). The tool is configured as one (or a few) tool capable of coping with the transformation of almost all languages, in general large-scale and complex. The present invention can be applied to such a tool, and is advantageous in determining the cause of the failure, reducing the number of test steps in the additional work, and the like.

The techniques described in this embodiment can be combined as appropriate.

The software described in the present embodiment may be implemented as hardware or as software.

The hardware, software, flowcharts, and the like can be appropriately modified within a range not departing from the gist of the present invention.

Symbol description

A 1-conversion device, which is used for converting the input signals into the output signals,

c 1-cn-converters,

10-version management tool (meta information management part),

11-the meta information DB,

20-manual correction management tool (manual correction management section),

21-manual correction implementation working space,

30-test tool (test section),

m1, m 2-merge tool (merge),

r 11-r 1 n-a library of conversion results by the converter,

r 2-a library of mechanical transformation results,

r 3-manually modifying the result library,

r 4-a library of transform results,

s 1-COBOL source before conversion (source before conversion),

s 2-transformed Java source (transformed source),

s 31-s 3n, s4, s 5-transform halfway sources,

sc1, sc1 a-correction version conversion precursor,

sp, spa-the pre-conversion source,

sq, sqa-transformed source,

A1-E1, B11, D11-conversion design,

a2-converter for the transformation design A1,

B2-converter for the transformation design B1,

b21-converter for the transformation design B11,

c2-converter for the transformation design C1,

a3 to E3, B31, D31-transformed results.

Claims (9)

1. A conversion device for converting a source before conversion into a source after conversion, characterized in that,

the conversion device is provided with:

a plurality of kinds of converters that mechanically and in parallel perform conversion from a part of the pre-conversion source to a part of the post-conversion source, the converters being prepared for each character string in the pre-conversion source;

a manual correction management unit that manages manual correction for performing a conversion from a part of the conversion-front source to a part of the conversion-rear source;

a meta information management unit that manages meta information on a transformation to each of the transformation halfway sources for a set of transformation halfway sources generated by transforming a part of the pre-transformation sources into a part of the post-transformation sources;

a merging unit that performs a merging process capable of applying a conversion result of an independent command language conversion end corresponding to an unmodified converter to the set of conversion intermediate sources; and

and a test unit that, when there is a failure in the confirmation test of the transformed source, refers to the meta information based on the failure location information, and determines a transformation for causing the failure.

2. The transformation device according to claim 1, wherein,

in the case where there is a corrected version of the pre-conversion source that has been corrected for the particular run of the pre-conversion source,

the merging section performs the following processing:

the transformation-before-source is set as a parent, the correction-version transformation-before-source is set as child 1, and the transformation-halfway source obtained by performing the manual correction transformation in the transformation-halfway sources is set as three-way combination of child 2.

3. The transformation device according to claim 2, wherein,

the merging section performs the following processing:

when the specific line corrected in the correction version conversion front source and the manual correction line corrected in the conversion intermediate source obtained by converting the manual correction are repeated, the specific line is prioritized in the three-way combination.

4. A conversion device according to claim 2 or 3, characterized in that,

when the conversion intermediate source is generated for each conversion design set for the conversion front source, a new conversion intermediate source is generated for a conversion design which is changed in accordance with the correction amount of the correction version conversion front source among the conversion designs.

5. A conversion device according to any one of claim 1 to 3,

the transformation from the pre-transformation source to the post-transformation source is a programming language transformation.

6. The transformation device according to claim 4, wherein,

the transformation from the pre-transformation source to the post-transformation source is a programming language transformation.

7. The transformation device according to claim 5, wherein,

the program language conversion is a conversion into a different kind of program language or a conversion into the same kind of program language.

8. The transformation device according to claim 6, wherein,

the program language conversion is a conversion into a different kind of program language or a conversion into the same kind of program language.

9. A conversion method of a conversion device for converting a source before conversion into a source after conversion, characterized by comprising the steps of,

the conversion method comprises the following steps:

preparing each character string in the pre-conversion source, and mechanically and parallelly converting from a part of the pre-conversion source to a part of the post-conversion source;

a step of managing manual correction for performing a transformation from a part of the pre-transformation source to a part of the post-transformation source;

A step of registering meta information on a transformation to each of the transformation halfway sources for a set of transformation halfway sources generated by transforming a part of the pre-transformation sources into a part of the post-transformation sources;

a step of merging the conversion results of the conversion completion of the independent command language conversion corresponding to the unmodified converter, with respect to the set of conversion intermediate sources; and

and a step of performing a confirmation test of the transformed source, and when there is a defect, determining a transformation of a defect cause of the defect with reference to the meta information.