JP2019040399A - Converter and conversion method - Google Patents

Abstract

To reduce cost to cope with failures in a system transition such as in a conversion development.SOLUTION: A converter 1 is characterized by comprising: a version management tool 10 for, with respect to a collection of sources s31 to s3n, s4, and s5 in the middle of conversion generated by converting a part of a conversion origin COBOL source s1 to a part of a converted Java source s2, managing meta information relating to the conversion to the sources s31 to s3n, s4, and s5 in the middle of conversion, respectively; and a test tool 30 for, when a failure is found in a test to check the converted Java source s2, identifying a conversion which created the factor for the failure by referring to the meta information.SELECTED DRAWING: Figure 1

Description

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

  In the system migration from the current system to the new system, for example, there is a work of conversion development of a program. In conversion development, the program language of the current program source (conversion source source) used in the current system (eg COBOL (COmmon Business Oriented Language)) is replaced with another program language (eg JAVA (registered trademark)) Create a new program source (source after conversion) used in the system.

  In conventional conversion development, for example, multiple types of conversion tools that perform language conversion in language grammar instruction units and syntax units are prepared, and language conversion is performed by sequentially executing each conversion tool on the source of conversion. Was creating a source after conversion. At this time, the conversion tool may not be executed on a part of the conversion source source due to cost vs. cost. In this case, language conversion is performed on the part by manual correction, and a post-conversion source in which language conversion is completely performed is obtained.

  In conversion development, a confirmation test (actual machine confirmation) is performed to confirm whether or not the obtained converted source has a defect. Specifically, the same input value is input to the conversion source source and the converted source, and if the same output value is obtained between them, it is determined that there is no defect, and if a different output value is obtained, it is determined that there is a defect. In conversion development, when there is a defect in the converted source, the conversion tool or manual correction that has created the cause of the defect is identified, and the identified conversion tool or manual correction is corrected to remove the defect cause.

  In general, it is possible to identify a line that causes a defect in the converted source. However, in the conventional language conversion that combines the sequential execution of conversion tools and manual correction, it is difficult to identify the conversion tool or manual correction that has created the cause of the defect, and it is difficult to identify by the expert. Needs corresponding costs. As a result, defect handling costs in conventional conversion development are high.

  Patent Document 1 states that “the conversion means for converting mainframe data to open data, the assignment means for assigning a color for each byte of input data, and the color assigned for each byte by the assignment means” Display means for displaying input data, and when the mainframe data is input as input data, the assigning means assigns a color to each byte of the mainframe data, and the display means Displays the mainframe data assigned a color for each byte by the assigning means, and when the open data is input as input data, the assigning means Assigning a color, the display means before the color assigned for each byte by the assigning means It discloses an information processing apparatus. "For displaying data in the open system.

JP, 2006-191977, A (claim 1)

  According to Patent Document 1, it is possible to roughly check whether or not conversion from a conversion source source corresponding to mainframe data to a post-conversion source corresponding to open data has been appropriately performed, It seems possible to display the line causing the defect for the post source. However, Patent Document 1 neither describes nor suggests specifying the conversion of data in which the cause of failure is specified. Therefore, in patent document 1, the defect handling cost in conversion development cannot be reduced.

  In view of such circumstances, an object of the present invention is to reduce the cost of handling defects in system migration such as conversion development.

In order to solve the above problems, the present invention provides:
A conversion device for converting a conversion source source into a converted source,
A meta information management unit for managing meta information related to conversion to each of the conversion-in-progress sources for a set of conversion-sources generated by converting a part of the conversion source source into a part of the converted source;
When there is a defect in the confirmation test of the converted source, a test unit that identifies the conversion that created the cause of the defect by referring to the meta information,
It is characterized by that.
Other inventions will be described later.

  ADVANTAGE OF THE INVENTION According to this invention, the defect handling cost in system transfer, such as conversion development, can be reduced.

It is a functional block diagram of the converter of this embodiment. It is a flowchart which shows a different language conversion process. It is explanatory drawing diverting a manual correction result. It is explanatory drawing of the one-way priority three-way merge. It is explanatory drawing which shows the procedure of the different language conversion performed before the catch-up work. It is explanatory drawing which shows the procedure of a catch-up operation | work.

  Next, embodiments of the present invention will be described with reference to the drawings. The conversion device of this 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 configured by a CPU (Central Processing Unit), information processing by a computer including the control unit is realized by program execution processing by the CPU. The storage unit included in the computer stores various programs for realizing the functions of the computer in accordance with instructions from the CPU. This realizes cooperation between software and hardware. The program can be provided by being recorded on a recording medium or via a network.

≪Configuration≫
As shown in FIG. 1, the conversion apparatus 1 of this embodiment includes converters c1 to cn, converter-specific conversion result repositories r11 to r1n, a version management tool 10, a meta information DB (DataBase) 11, and a merge tool m1. A machine conversion result repository r2, a manual correction management tool 20, a manual correction execution workspace 21, a manual correction result repository r3, a merge tool m2, a conversion result repository r4, and a test tool 30. .

The conversion source COBOL source s1 in FIG. 1 is a source code in which a COBOL code described in COBOL (“COBOL 1”, “COBOL 2”,..., “COBOL N”, “COBOL X”) is recorded. It is executed to operate the system.
Further, the converted Java source s2 in FIG. 1 is a source code in which JAVA codes described in JAVA (“Java1”, “Java2”,..., “JavaN”, “JavaX”) are recorded. Is executed to operate the new system.
Various conversion sources s31 to s3n, s4, and s5 in FIG. 1 will be described later.

[Converters c1 to cn]
The converters c1 to cn mechanically convert a part of the COBOL code of the conversion source COBOL source s1 into a JAVA code. A character string as a COBOL code to be converted by each of the converters c1 to cn is determined in advance, and can be prepared, for example, in units of instruction words (eg, “MOVE” of the COBOL code is changed to “set” of the JAVA code). Converter to convert). Further, the converters c1 to cn can be prepared in units of syntax, and can be designed with various granularities in the language grammar.

  Each of converters c1 to cn is designed so as not to convert the same row of conversion source COBOL source s1 redundantly. As shown in FIG. 1, the converter c1 converts “COBOL1” of the conversion source COBOL source s1 into “Java1”, but the converter c2 and the like do not perform the same conversion. Similarly, each of converters c2 to cn converts each of “COBOL2” to “COBOLN” of conversion source COBOL source s1 into “Java2” to “JavaN”. “COBOLX” of the conversion source COBOL source s1 is a manually corrected COBOL code, details of which will be described later.

[Conversion result repository by converter r11 to r1n]
Each of the conversion result repositories r11 to r1n classified by converter executes the converters c1 to cn with respect to the conversion source COBOL source s1 to convert part of the COBOL code into JAVA code. Store each one.

[Version management tool 10]
The version management tool 10 acquires and manages information related to conversion as meta information when each of the converters c1 to cn converts from the conversion source COBOL source s1 to each of the conversion intermediate sources s31 to s3n. For example, for each conversion, the meta information includes the correspondence between the conversion source COBOL code and the converted JAVA code, the ID (Identifier) of the converter that executed the conversion, the content of the conversion (eg, “MOVE” → “set”), the conversion Including, but not limited to, design ID, date and time of execution of conversion, and comment as supplementary explanation. The version management tool 10 of this embodiment can be implemented as a distributed version management tool such as Git.

[Meta information DB11]
The meta information DB 11 stores the meta information acquired by the version management tool 10. Note that the conversion apparatus 1 according to the present embodiment may include a GUI (Graphic User Interface) such as TortoiseGit so that the meta information and the conversion sources s31 to s3n can be visually traced.

[Merge tool m1]
The merge tool m1 performs a merge process on the conversion intermediate sources s31 to s3n stored in the converter-specific conversion result repositories r11 to r1n. For the merge process, for example, a three-way merge (a well-known and detailed description is omitted) used in a distributed version management tool can be used.

  For example, the merge tool m1 performs a three-way merge with the conversion source COBOL source s1 as a parent and any two of the conversion intermediate sources s31 to s3n derived from the parent as a child, and reflects the conversion points of the two children in the parent Result (conversion source with more advanced conversion). If the conversion locations of the two children are the same row, the three-way merge will fail (collision), but the converters c1 to cn of this embodiment are designed so that the conversion locations are unique, so the two children Will not be on the same line.

For example, the merge tool m1 first performs a three-way merge using the conversion source COBOL source s1 as a parent, the conversion source sources s31 and s32 as a first child, and a second child, and obtains a first result. Next, the merge tool m1 performs a three-way merge with the conversion source COBOL source s1 as the parent, the first result as the first child, and the conversion intermediate source s33 as the second child, and the second result as the second result. obtain. By executing the three-way merging in multiple stages as described above, the conversion source s4 (“Java1”, “Java2”,..., “JavaN”) in which all the mechanical conversions by the converters c1 to cn are executed. , “COBOLX”).
Further, the merge tool m1 can also merge the conversion sources s31 to s3n at a time as a merge process to obtain the conversion source s4.

[Machine conversion result repository r2]
The machine conversion result repository r2 stores the conversion source s4 in which all the results of the mechanical conversion are merged by the merge tool m1.

[Hand correction management tool 20]
The manual correction management tool 20 manages manual correction for performing conversion from a part of the conversion source COBOL source s1 to a part of the converted Java source s2. Specifically, the manual correction management tool 20 converts the COBOL code “COBOLX” of the conversion source COBOL source s1 into the JAVA code “JavaX” of the converted Java source s2 by manual correction.
In addition, the manual correction management tool 20 outputs information related to manual correction conversion to the version management tool 10 as meta information.

The case where the conversion from the COBOL code to the JAVA code is performed by manual correction is a case where the same machine conversion is not applied to the same COBOL code due to a difference in language specifications. Specifically, this is a case corresponding to the following manual correction required examples 1 to 3.
Manual correction required example 1: Existence of multiple data item names Manual correction required example 2: Presence of clear dead code (unreachable code) Manual correction required example 3: Existence of multiple identical branch conditions

Regarding the manual correction example 1, for example,
[COBOL code]
01 D1 PICTURE X (2) VALUES 'AZ'.
01 D1 PICTURE 9 (2) VALUES 10.
Is machine converted,
[JAVA code]
String d1 = “AZ”
int d1 10;
Is created. The above COBOL code has no problem in the syntax of COBOL, but the above JAVA code causes a compilation error due to variable name duplication in JAVA.

With regard to Manual Correction Need Example 2, for example,
[COBOL code]
EXIT.
MOVE A TO B.
Is machine converted,
[JAVA code]
return;
b.set (a);
Is created. The above COBOL code has no problem in the syntax of COBOL, but the above JAVA code causes a compilation error due to a clear dead code in JAVA.

With regard to Manual Correction Need Example 3, for example,
[COBOL code]
EVALUATE A
WHEN 0
~~
CONTINUE
WHEN 0
~~
END EVALUATE.
Is machine converted,
[JAVA code]
switch (a) {
case 0:
~~~;
break;
case 0:
~~~;
:
}
Is created. The above COBOL code has no problem in the syntax of COBOL, but the above JAVA code causes a compilation error due to duplication of branch conditions in JAVA.

  When the manual correction required examples 1 to 3 are applicable, different manual correction results are created so that the same operation is performed in the JAVA code even if the COBOL code is the same.

[Workspace 21 for manual correction]
The manual correction execution workspace 21 is a work area for executing manual correction by the manual correction management tool 20.

[Manual correction result repository r3]
The manual correction result repository r3 stores the conversion source s5 in which a part of the COBOL code is converted into the JAVA code by executing the manual correction by the manual correction management tool 20 on the conversion source COBOL source s1.

[Merge tool m2]
The merge tool m2 merges the conversion intermediate source s4 stored in the machine conversion result repository r2 and the conversion intermediate source s5 stored in the manual correction result repository r3. Specifically, the merge tool m2 performs a three-way merge with the conversion source COBOL source s1 as a parent, the conversion intermediate source s4 as a first child, and the conversion intermediate source s5 as a second child, and the converted Java source s2 Get.
Further, the merge tool m1 and the merge tool m2 can merge the conversion source s31 to s3n and the conversion source s5 at a time as a merge process to obtain a converted Java source s2.

[Conversion result repository r4]
The conversion result repository r4 stores the converted Java source s2 that is subjected to mechanical conversion and manual correction conversion by the merge tool m2 and in which only the JAVA code is recorded.

[Test tool 30]
The test tool 30 performs a confirmation test (actual machine confirmation) of the converted Java source s2. In the confirmation test, for example, the same input value is input to the conversion source COBOL source s1 and the converted Java source s2, and if the same output value is obtained between them, it is determined that there is no defect, and if a different output value is obtained, it is determined that there is a defect. . When there is a defect, the test tool 30 refers to the meta information DB 11 based on the defect location information, and identifies the conversion that has created the defect.

  For example, as shown in FIG. 1, it is assumed that, as a result of the test tool 30 executing the confirmation test, it is determined that there is a defect, and the JAVA code “Java2” of the converted Java source s2 is found to be the cause of the defect. Specifically, it is known in advance for the conversion developer, the correct code for normalizing the operation of the “Java2” line, and the JAVA described in the converted Java source s2 output by the merge tool m2. Assume that a difference from the code “Java2” is found. In this case, the test tool 30 refers to the meta information DB 11 and acquires meta information related to the conversion from the COBOL code “COBOL 2” to the JAVA code “Java 2”. The test tool 30 has a problem in the converter c2 that has performed the conversion to the JAVA code “Java2” by analyzing the acquired meta information, and has a problem in the conversion design related to the conversion to the JAVA code “Java2”. The details of the cause of failure such as can be identified.

<< Process >>
Next, a different language conversion process from COBOL to JAVA will be described with reference to FIG. 2 as a process executed by the conversion apparatus 1 of the present embodiment. In the description, FIG. 1 is also referred to as appropriate.

  First, the conversion apparatus 1 performs format shaping on the conversion source COBOL source s1 (step S1). Specifically, the conversion apparatus 1 performs shaping that facilitates conversion by the converters c1 to cn, such as one line of division and unification of upper and lower case letters, with respect to the COBOL code of the conversion source COBOL source s1.

  Next, the conversion apparatus 1 converts the definition source DB into the conversion source COBOL source s1 (step S2). Specifically, the conversion apparatus 1 analyzes the COBOL code of the conversion source COBOL source s1, and stores the definition information of the data items in a DB (a storage unit not shown in FIG. 1).

  Next, the conversion apparatus 1 performs grammatical shaping on the conversion source COBOL source s1 (step S3). Specifically, the conversion apparatus 1 reshapes the syntax of the conversion source COBOL source s1 into a syntax that is premised on input to the converters c1 to cn, for example, by unifying the sugar-coating syntax into regular notation.

  Next, the conversion apparatus 1 performs common conversion into the JAVA language on the conversion source COBOL source s1 (step S4). Specifically, the conversion apparatus 1 applies a conversion design that is commonly required between the converters c1 to cn, such as a JAVA import statement and a description of a main method, regardless of the conversion design characteristics. According to step S4, the conversion designs of the converters c1 to cn can be prevented from including the common conversion design among the converters c1 to cn, and the conversion designs of the converters c1 to cn can be simplified. can do.

  Next, the conversion apparatus 1 performs order-dependent conversion to the JAVA language on the conversion source COBOL source s1 (step S5). Specifically, the conversion device 1 determines that the execution result of one conversion design depends on the execution results of other conversion designs for a plurality of types of conversion designs related to conversion from the conversion source COBOL source s1 to the converted Java source s2. When doing so, a conversion design related to the dependency is applied to perform conversion having execution order dependency. According to step S5, by executing the conversion having the execution order dependency in advance, it is possible to prevent the conversion by the converters c1 to cn from having the execution order dependency. The conversion design of each cn can be simplified.

  Next, the conversion apparatus 1 performs parallel conversion into the JAVA language on the conversion source COBOL source s1 (step S6). Specifically, the conversion device 1 applies the conversion design of each of the converters c1 to cn, and for the conversion that cannot be dealt with or cannot be dealt with by the conversion by the converters c1 to cn, the manual correction by the manual correction management tool 20 Apply the conversion design.

  As shown in FIG. 2, step S6 corresponds to, for example, individual instruction word conversions (1) to (N) (steps S6-1 to S6-N) corresponding to each of converters c1 to cn and manual correction. Can be divided into hand correction conversion (step S6-X). The individual instruction word conversions (1) to (N) are processes for performing mechanical conversion to JAVA for each type of COBOL instruction words (for example, “MOVE” → “set”). Since the conversion between the converters c1 to cn is designed not to affect other conversions, the individual instruction word conversions (1) to (N) can be performed mechanically and in parallel. . In addition, instead of performing conversion in units of instruction words as in individual instruction word conversions (1) to (N), for example, mechanical conversion may be performed individually in units of syntax. Manual correction conversion (S6-X) is conversion by the manual correction management tool 20.

  In step S6, the version management tool 10 acquires meta information related to individual instruction word conversions (1) to (N) corresponding to each of the converters c1 to cn and meta information related to hand correction conversion corresponding to manual correction. And stored in the meta information DB 11.

  Next, the conversion apparatus 1 merges the conversion results of the parallel conversion in step S6 (step S7). Specifically, the conversion device 1 is converted by the merge tools m1 and m2 by the conversion intermediate sources s31 to s3n (or the conversion intermediate source s4) converted by the converters c1 to cn and the manual correction management tool 20. A merge process is performed on the conversion source s5 to generate a converted Java source s2.

  Next, the conversion apparatus 1 performs a confirmation test of the converted Java source s2 using the test tool 30 (step S8). If there is a defect in the confirmation test, the test tool 30 refers to the corresponding meta information stored in the meta information DB 11 based on the defect location information, and identifies the conversion that has created the cause of the defect.

  In the conversion development, after correcting the converter that performs conversion incorporating the cause of the defect, the different language conversion process of FIG. 2 is performed again. At this time, the conversion between the respective converters does not affect the conversion of the other converters. Therefore, in the parallel conversion in step S6, it is only necessary to perform the individual instruction word conversion corresponding to the corrected converter, and the other individual conversions. There is no need to perform instruction word conversion. Therefore, in the merge in step S7, the conversion result after individual instruction word conversion corresponding to the converter that has not been corrected can be diverted, contributing to the reduction in the number of re-conversion steps after dealing with defects, and required for the processing of FIG. The burden can be reduced and the time can be shortened.

According to the processing in FIG. 2, when the conversion source COBOL source s1 is converted into the converted Java source s2, the version management tool 10 can manage the meta information, thereby tracing the conversion history. As a result, the cause of the failure when the Java source s2 after conversion is defective can be sufficiently achieved by referring to the meta information, and does not require the examination of an expert as in the past, and is easy.
Therefore, it is possible to reduce defect handling costs in conversion development.

≪Use of hand correction results in catch-up work≫
In conversion development, where the conversion source provided by the customer is converted to the converted source, the customer modifies the conversion source regardless of the progress of conversion development due to maintenance development reasons such as defect handling and legal revision. The specification may be changed. In that case, after the completion of the first conversion development, it is necessary to carry out conversion development again and incorporate the specification changes into the converted source. Completion of the first conversion development means completion without defect in the verification test of the converted source, and it is sometimes called “freezing”. Also, there is a case in which the specification change handling work after freezing in the second conversion development is called “catch-up work”.

Although the catch-up work is indispensable, it increases the amount of conversion development work and delays the system migration, so there is a demand to reduce the work man-hours and end it early. However, conventionally, for example, when the conversion source source corresponds to the above-mentioned manual correction necessity examples 1 to 3 and the corresponding line is manually corrected in the first conversion development, the same line is handled in the catch-up operation. It had to be corrected and was inefficient.
In addition, in the past, even if a confirmation test was performed before freezing for the converted part of the source after conversion, it is necessary to perform almost the same confirmation test again in the catch-up work, and the test man-hour for the catch-up work Could not be reduced.

  That is, generally, in the maintenance development on the customer side, the code modification of the specification change is often performed on a functional unit basis, and therefore the influence of the code modification on the new system is usually local. On the other hand, in conversion development, since conversion is a conversion viewpoint unit (syntax unit) (whether mechanical or manual correction), the conversion affects the entire new system. For this reason, the confirmation items of the confirmation test for the conversion by manual correction tend to be distributed throughout the new system. As a result, even if the amount of manual correction is small, the number of confirmation items in the confirmation test for the conversion by manual correction is not small, and a test man-hour approximately equal to the test man-hour before freezing is required. Such a situation exists regardless of whether or not the conversion location by manual correction is affected by the correction on the customer side.

  The conversion apparatus 1 according to the present embodiment uses the three-way merge performed by the merge tools m1 and m2 to mechanically process the manual correction result before freezing that is irrelevant to the correction of the specification change on the customer side in the catch-up operation. To divert. In this embodiment, the three-way merging for the result of manual correction is performed by the merge tool m2. In the following description, the three-way merge is performed by the merge tool m2, but the merge tool m1 can perform the same.

As shown in FIG. 3, a conversion source source sp, a modified version conversion source source sc1, and a manual correction source sc2 are prepared.
The conversion source source sp is a source code in which a COBOL code described in COBOL (first line “COBOL 1”, second line “COBOL 2”, and third line “COBOL 3”) is recorded. The conversion source source sp is a conversion development target originally provided from the customer by the conversion development side. The conversion source source sp corresponds to the conversion source COBOL source s1 in FIG.

  The modified version conversion source source sc1 is a source code in which a COBOL code described in COBOL (first line “COBOL 1”, second line “COBOL 2”, third line “COBOL”) is recorded. The corrected version conversion source source sc1 is equivalent to the conversion source source sp reflecting the correction of the specification change on the customer side (“COBOL3” (specific line) → “COBOLA”). The modified version conversion source source sc1 is provided by the customer during the catch-up operation, that is, after freezing.

  The manual correction source sc2 is a source code obtained by converting a part of the COBOL code of the conversion source source sp into a JAVA code (“COBOL2” → “Java2”) by the manual correction management tool 20. The hand correction source sc2 is created in the first conversion development, that is, before freezing.

  The version management tool 10 manages meta information related to the conversion source source sp, the corrected version conversion source source sc1, and the manual correction source sc2, and the conversion source source sp, the corrected version conversion source source sc1, and the manual correction source sc2. The contents can be managed.

  The merge tool m2 performs a three-way merge with the conversion source source sp as the merge parent, the corrected version conversion source source sc1 as the merge child (first child), and the manual correction source sc2 as the merge child (second child). I do. As a result, the hand correction diversion source sd shown in FIG. 3 is obtained. The version management tool 10 acquires and manages meta information related to the manually modified diversion source sd.

  When the modified version conversion source source sc1 and the manually modified diversion source sd are compared, the code of the second line “COBOL2” is converted to “Java2” without being affected by the customer's modification to the third line “COBOL3”. Therefore, it can be said that the manual correction result by the manual correction source sc2 can be used for the corrected version conversion source source sc1. Conventionally, in the catch-up operation, the corrected version conversion source source sc1 is manually converted from “COBOL2” to “Java2”. However, in the present invention, the conversion effort can be saved. As a result, the target of manual correction in the catch-up operation is limited to the COBOL code in which the specification change on the customer side is corrected among the COBOL codes that have been manually corrected before freezing.

  Further, the confirmation test before freezing on the converted source including the manual correction result by the manual correction source sc2 has already been completed, and the manual correction result is used. For this reason, in the catch-up work, when performing a confirmation test of the converted source (customer correction reflected) that has been merged using the manually corrected diversion source sd, the confirmation items of the confirmation test for the conversion by the diverted manual correction are omitted. be able to. As a result, the test man-hour for the catch-up work can be reduced.

  Regarding the conversion of the third line “COBOLA” of the hand-corrected diversion source sd obtained by the three-way merge into a JAVA code, if “COBOLA” is a COBOL code that can be machine-converted, the converters c1 to cn The result is converted by either of them, and the result is stored in the machine conversion result repository r2. On the other hand, if “COBOL” is a COBOL code that requires manual correction, the manual correction management tool 20 performs manual correction on the manual correction diversion source sd, and the result is stored in the manual correction result repository r3. The After that, the procedure already described (step S7 in FIG. 2, etc.) is followed.

≪One-way priority three-way merge≫
In the catch-up operation, there are cases where the customer's correction part (specific line) for the conversion source and the part where the correction before the freezing for the conversion source (hand correction line) is duplicated. In this case, if the three-way merging using the hand correction result is performed, a conflict occurs and the merging cannot be performed.

Therefore, when the customer correction line and the manual correction line overlap, the merge tool m2 performs one-way priority three-way merging that prioritizes the customer correction line.
As shown in FIG. 4, a case where a conversion source source sp, a corrected version conversion source source sc1a, and a manual correction source sc2 are prepared will be described. The conversion source source sp and the manual correction source sc2 in FIG. 4 are the same as the conversion source source sp and the manual correction source sc2 shown in FIG.

The modified version conversion source source sc1a is a source code in which the COBOL code described in COBOL (first line “COBOL1”, second line “COBOL”, third line “COBOL3”) is recorded. The corrected version conversion source source sc1a is equivalent to the conversion source source sp reflecting the correction of the specification change on the customer side (“COBOL 2” → “COBOLA”). The modified version conversion source source sc1a is provided by the customer during the catch-up operation, that is, after freezing.
The version management tool 10 can manage meta information related to the modified version conversion source source sc1a, and can manage the contents of the modified version conversion source source sc1a.

  If the three-way merging of FIG. 3 is performed on the conversion source source sp, the corrected version conversion source source sc1a, and the manual correction source sc2, the customer correction for the second line “COBOL2” of the conversion source source sp (“ COBOLA "(specific line)) and manual correction (" Java2 "(manual correction line)) conflict (overlap) and cannot be merged.

  Therefore, as shown in FIG. 4, the merge tool m2 uses the conversion source source sp as the parent of the merge, the corrected version conversion source source sc1a as the child of the merge (first child), and the manual correction source sc2 as the child of the merge (first). One-way priority three-way merging is performed. As a result, the customer correction priority source sda that does not include the manual correction result (“Java 2”) but includes the customer correction (“COBOLA”) (first line “COBOL 1”, second line “COBOLA”, third line “COBOL 3”) )). The version management tool 10 acquires and manages meta information related to the customer modification priority source sda.

  According to the one-way priority three-way merge of the present embodiment, even if manual correction and customer correction conflict, the customer correction can be reliably reflected in the result of the three-way merge. The customer's original requirements can be reliably met.

  Regarding conversion of the second line “COBOLA” of the customer modification priority source sda obtained by the one-way priority three-way merge into a JAVA code, if “COBOLA” is a machine-convertible COBOL code, the converter c1 The result is converted by any of cn, and the result is stored in the machine conversion result repository r2. On the other hand, if “COBOL” is a COBOL code that requires manual correction, the manual correction management tool 20 performs manual correction on the customer correction priority source sda, and the result is stored in the manual correction result repository r3. The After that, the procedure already described (step S7 in FIG. 2, etc.) is followed.

≪Reduction of test work man-hours in catch-up work≫
The catch-up work is essentially sufficient if a conversion conversion is performed again for the (generally small-scale) corrections made by the customer to the conversion source source. Most of the confirmation items of the test that need to be performed in the catch-up work overlap with the confirmation items of the test already performed in the initial conversion development before the catch-up work. Therefore, the idea of reducing the test work man-hours in the catch-up work by diverting the test confirmation result in the initial conversion development has been established, and the method will be specifically described below.

  As shown in FIG. 5, in different language conversion before the catch-up work, that is, in the first conversion development, the conversion apparatus 1 of the present embodiment converts the conversion source source sp (for example, COBOL) into the converted source sq (for example, JAVA). ) Conversion design setting (step S11), converter generation (step S12), mechanical conversion + hand correction (step S13), and three-way merging (step S14) are executed.

  The conversion design setting (step S11) is a step of analyzing the conversion source source sp on the conversion development side and setting one or a plurality of types of conversion designs necessary for creating the converted source sq for the conversion source source sp. is there. Conversion design is a framework that defines how to rewrite a code string to be converted. The type of conversion design required may be determined as appropriate on the conversion development side, for example, but the determination method is not limited to this.

  In the example of FIG. 5, it is assumed that five types of conversion designs A1 to E1 are set for each conversion target for the conversion source source sp. Conversion designs A1 to C1 are conversion designs related to mechanical conversion by a converter (corresponding to converters c1 to cn in FIG. 1). The conversion designs D1 and E1 are conversion designs related to conversion by 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 associated with the conversion design related to the mechanical conversion among the set conversion designs. In FIG. 5, converter A2 for conversion design A1, converter B2 for conversion design B1, and converter C2 for conversion design C1 are generated for each of conversion designs A1 to C1 related to mechanical conversion. Converter A2 for conversion design A1, converter B2 for conversion design B1, and converter C2 for conversion design C1 have the same functions as converters c1 to cn of FIG.

  Machine conversion + hand correction (step S13) is a step of executing machine conversion and manual correction according to the conversion design. In FIG. 5, each of converters A <b> 2 to C <b> 2 performs mechanical conversion according to conversion designs A <b> 1 to C <b> 1 for each conversion target in conversion source source sp, and outputs conversion results A <b> 3 to C <b> 3. Further, the manual correction management tool 20 (FIG. 1) executes manual correction according to the conversion designs D1 and E1 for each of the conversion targets in the conversion source source sp, and outputs conversion results D3 and E3. The conversion results A3 to E3 correspond to the conversion intermediate sources s31 to s3n, s4, and s5 shown in FIG.

  As shown in FIG. 1, the conversion apparatus 1 of the present embodiment manages the conversion results by the converters c1 to cn in the repository for each converter (converter-specific conversion result repositories r11 to r1n in FIG. 1). The conversion results by correction were collectively managed in one repository (manual correction result repository r3 in FIG. 1). However, the management unit by the repository can be set arbitrarily. 5 and 6, the conversion apparatus 1 according to the present embodiment manages the conversion result in the repository for each conversion design. That is, the conversion results A3 to E3 shown in FIG. 5 are managed in a repository (not shown in FIG. 5) prepared for each of the conversion designs A1 to E1. As a repository, a repository for a collection of a plurality of conversion designs may be prepared instead of a repository prepared for each conversion design.

  The conversion development side performs desktop confirmation on the conversion results A3 to E3. The desk check is a well-known method and will not be described. In this embodiment, it is assumed that the result of the desktop confirmation for the conversion results A3 to E3 is good.

  The three-way merging (step S14) is a step for performing the three-way merging on the conversion result obtained by the machine conversion + hand correction (step S13). The three-way merge (step S14) is executed by the merge tools m1 and m2 shown in FIG. In FIG. 5, a post-conversion source sq is obtained by performing a three-way merge on the transformation results A3 to E3.

  The conversion development side checks the actual machine against the converted source sq. The actual machine confirmation corresponds to the confirmation test of the test tool 30 shown in FIG. This completes the initial conversion development.

  After the completion of the initial conversion development, the customer modified the source of the conversion, so the catch-up work is executed. As shown in FIG. 6, in the catch-up operation, the conversion apparatus 1 of the present embodiment converts the conversion source source spa (corresponding to the corrected version conversion source source) including the customer correction amount spa1 into the correction amount corresponding to the correction amount spa1. Convert to converted source sqa including sqa1. At the time of this conversion, conversion design setting (step S21), converter generation (step S22), mechanical conversion + hand correction (step S23), and three-way merging (step S24) shown in FIG. 6 are executed.

  The conversion design setting (step S21) is the same step as the conversion design setting (step S11) in FIG. As shown in FIG. 6, in the conversion design setting (step S21), conversion designs B1 and D1 (FIG. 5) are converted into conversion designs B11 and D11, respectively, in accordance with the fact that the correction source spa1 is included in the conversion source source spa. Instead, it is assumed that five types of conversion designs A1, B11, C1, D11, and E1 are set for each conversion target for the conversion source source spa. The conversion design B11 is a conversion design related to machine conversion. The conversion design D11 is a conversion design related to conversion by manual correction.

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

  The machine conversion + hand correction (step S23) is the same step as the machine conversion + hand correction (step S13) in FIG. In FIG. 6, in addition to the conversion results A3 and C3 (FIG. 5) already generated by the machine conversion, the converter B21 for the conversion design B11 converts the conversion target in the conversion source source sp according to the conversion design B11. And the conversion result B31 is newly output. In FIG. 6, in addition to the conversion result E3 (FIG. 5) already generated by manual correction, the manual correction management tool 20 (FIG. 1) applies the conversion design D11 to the conversion target in the conversion source source sp. The hand correction according to the above is executed, and the conversion result D31 is newly output. The conversion results B31 and D31 correspond to the conversion intermediate sources s31 to s3n, s4, and s5 shown in FIG.

  The conversion development side performs desktop confirmation on the new conversion results B31 and D31. Since the conversion results A3, C3, and E3 that have already been generated have been confirmed on the desk (FIG. 5), they are omitted in the catch-up operation. Therefore, managing the conversion result for each conversion design can reduce the number of test steps for desktop confirmation in the catch-up work. Further, in the present embodiment, it is assumed that the result of desktop confirmation for the conversion results B31 and D31 is good.

  The three-way merge (step S24) is the same step as the three-way merge (step S14) in FIG. In FIG. 6, by performing a three-way merge on the conversion results A3, B31, C3, D31, and E3, a post-conversion source sqa that includes the correction part sqa1 corresponding to the correction part spa1 is obtained.

  The conversion development side checks the actual machine for the converted source sqa. In this actual machine confirmation, among all the confirmation items, the confirmation items that are not affected by the correction portion sqa1 (confirmation items related to the conversion designs A1, C1, and E1 other than the conversion designs B11 and D11 changed according to the correction portion spa1) Is already confirmed before the catch-up work (FIG. 5), and can be omitted in the catch-up work. Therefore, as shown in the examples of FIGS. 5 and 6, by managing the conversion results for each conversion design, it is only necessary to check the confirmation items affected by the correction sqa1 among all the confirmation items of the actual machine confirmation. . As a result, it is possible to reduce the number of test steps for checking the actual machine in the catch-up work.

≪Modification≫
As mentioned above, although embodiment of this invention was described, this invention is not limited to the said embodiment, In the range which does not deviate from the summary of this invention, it can change suitably. For example, the conversion source program language in conversion development is not limited to COBOL, but may be another program language. Further, the program language of the converted source in the conversion development is not limited to JAVA, but may be another program language.

  In addition, the language conversion in the conversion development is not limited to a different type of programming language such as conversion from COBOL to JAVA adopted in the present embodiment, but the same type of programming language such as conversion from the host system COBOL to the open system COBOL. Conversion to

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

  The present invention can also be applied to a method of sequentially executing a plurality of types of conversion tools prepared for a conversion source source as in the prior art. Conventionally, as a tool for mechanically converting a programming language, there is a tool for replacing code by parsing (syntactic tree interpretation). This tool is configured as one (or a small number) of tools that can accommodate almost any language translation and is generally large and complex. The present invention can also be applied to such a tool, which contributes to the identification of the cause of failure and the reduction of test man-hours in catch-up work.

A technique obtained by appropriately combining various techniques described in the present embodiment can also be realized.
The software described in this embodiment can be realized as hardware, and the hardware can also be realized as software.
In addition, hardware, software, flowcharts, and the like can be changed as appropriate without departing from the spirit of the present invention.

1 conversion device c1 to cn converter 10 version management tool (meta information management unit)
11 Meta information DB
20 Manual Correction Management Tool (Manual Correction Management Department)
21 Workspace for manual correction 30 Test tool (test section)
m1, m2 Merge tool (merge part)
r11-r1n Converter-specific conversion result repository r2 Machine conversion result repository r3 Manual modification result repository r4 Conversion result repository s1 Conversion source COBOL source (conversion source source)
s2 Java source after conversion (source after conversion)
s31 to s3n, s4, s5 Conversion source sc1, sc1a Modified version conversion source source sp, spa Conversion source source sq, sqa Source after conversion A1 to E1, B11, D11 Conversion design A2 Conversion design A1 converter B2 Conversion design B1 Converter B21 Conversion design B11 converter C2 Conversion design C1 converter A3 to E3, B31, D31 Conversion result

Claims (8)

A conversion device for converting a conversion source source into a converted source,
A meta information management unit for managing meta information related to conversion to each of the conversion-in-progress sources for a set of conversion-sources generated by converting a part of the conversion source source into a part of the converted source;
When there is a defect in the confirmation test of the converted source, a test unit that identifies the conversion that created the cause of the defect by referring to the meta information,
A conversion device characterized by that. Prepared for each character string in the conversion source, a plurality of types of converters that perform mechanical and parallel conversion from a part of the conversion source to a part of the converted source, and
A manual correction management unit for managing manual correction for performing conversion from a part of the conversion source source to a part of the converted source;
A merge unit that performs a merge process on the set of sources in the middle of the conversion, and
The conversion device according to claim 1. If there is a modified version of the conversion source source in which the specific line of the conversion source source has been corrected,
The merge unit
Three-way merging with the conversion source source as a parent, the corrected version conversion source source as a first child, and the one that has been converted by the manual correction among the conversion intermediate sources as a second child,
The conversion device according to claim 2. The merge unit
In the three-way merge, the specific line that has been corrected in the corrected version conversion source source and the manual correction line that has been manually corrected in the conversion intermediate source that has been converted by the manual correction overlap. , Giving priority to the specific line,
The conversion device according to claim 3. When the conversion intermediate source is generated for each conversion design set for the conversion source source, a new conversion is performed for the conversion design changed according to the correction of the corrected version conversion source source. Generate source on the way,
5. The conversion device according to claim 3 or 4, wherein: The conversion from the conversion source source to the converted source is a program language conversion.
The conversion device according to any one of claims 1 to 5, wherein The programming language conversion is
Conversion to a different type of programming language or to the same type of programming language,
The conversion device according to claim 6. A conversion method in a conversion device for converting a conversion source source to a converted source,
Registering meta information related to conversion to each of the conversion-in-progress sources for a set of conversion-sources generated by converting a part of the conversion source source into a part of the converted source;
Performing a verification test of the post-conversion source, and if there is a defect, refer to the meta information to identify the conversion that has created the cause of failure of the defect, and
A conversion method characterized by that.

Images