WO2019039394A1

WO2019039394A1 - Conversion device and conversion method

Info

Publication number: WO2019039394A1
Application number: PCT/JP2018/030483
Authority: WO
Inventors: 佳範城代; 芳恵堀岡
Original assignee: 株式会社日立社会情報サービス
Priority date: 2017-08-25
Filing date: 2018-08-17
Publication date: 2019-02-28
Also published as: CN111052077B; JP6944838B6; CN111052077A; JP2019040399A; JP6944838B2

Abstract

A conversion device (1) is characterized by being provided with: a version management tool (10) that, for a set of conversion-in-progress sources (s31)-(s3n) which are generated by converting a part of a conversion-origin COBOL source (s1) to a part of a post-conversion Java source (s2), (s4), (s5), manages meta information related to the conversion to the conversion-in-progress sources (s31)-(s3n), (s4), (s5); and a test tool (30) that, when a failure is found in a checking test of the post-conversion Java source (s2), specifies the conversion in which the failure cause of the failure was created, by referring to the meta information.

Description

Converter and conversion method

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

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

In the conventional conversion development, for example, a plurality of types of conversion tools for performing language conversion in units of instructions in the language grammar or syntax units are prepared, and language conversion is performed by sequentially executing each conversion tool on the conversion source source. Source was created after conversion. At this time, there are cases where the conversion tool can not be executed on part of the conversion source due to reasons such as cost-to-cost. In this case, the language conversion is performed on the part by manual correction to obtain a converted source in which the language conversion is completely performed.

In addition, in the conversion development, a confirmation test (actual device 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 and the converted source, and if the same output value is obtained between the two, there is no defect, and if different output values are obtained, it is determined as defective. In conversion development, if there is a defect in the converted source, the conversion tool or manual correction that created the cause of the failure is identified, and the identified conversion tool or manual correction is corrected to remove the defective cause.

Generally, for the converted source, it is possible to identify the line causing the defect. However, in conventional language conversion based on a combination of sequential execution of conversion tools and manual correction, it is difficult to identify conversion tools or manual corrections that cause defects, so that it is difficult for experts to consider, and large defects Needs a response cost. As a result, the defect handling cost in the conventional conversion development is large.

In Patent Document 1, "the conversion means for converting mainframe data to open data, the allocation means for allocating a color for each byte of input data, and the color allocated for each byte by the allocation means" And display means for displaying input data, and when the mainframe system data is input as input data, the allocation means assigns a color to each byte of the mainframe system data, and the display means The display means displays the mainframe system data to which a color is assigned for each byte by the assignment means, and when the open system data is inputted as input data, the assignment means is for each of the open system data. Assigning a color, the display means being assigned a color for each byte by the assigning means It discloses an information processing apparatus. "For displaying data of the serial open system.

Unexamined-Japanese-Patent No. 2016-191977 (Claim 1)

According to Patent Document 1, it is possible to roughly check whether the conversion from the conversion source corresponding to the data of the mainframe system to the converted source corresponding to the data of the open system is appropriately performed or not, It would be possible to display the offending lines for the after source. However, Patent Document 1 does not describe or suggest specifying the conversion of data in which the cause of failure is incorporated. Therefore, Patent Document 1 can not reduce the defect handling cost in conversion development.

In view of such circumstances, the present invention has an object to reduce the cost for dealing with defects in system migration such as conversion development.

In order to solve the above-mentioned subject, the present invention is
A conversion device for converting a conversion source into a converted source,
A meta-information management unit that manages meta-information related to conversion to each of the conversion intermediate sources, for a set of conversion intermediate sources generated by converting a part of the conversion source to a part of the converted source;
And a test unit for identifying a conversion in which the cause of the defect is created by referring to the meta information when there is a defect in the post-conversion source confirmation test.
It is characterized by
Other inventions will be described later.

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

It is a functional block diagram of the converter of this embodiment. It is a flowchart which shows a foreign language conversion process. It is explanatory drawing of hand correction result diversion. It is an explanatory view of one-sided priority three-way merge. It is explanatory drawing which shows the procedure of the foreign language conversion performed before the catch-up operation. It is explanatory drawing which shows the procedure of a catch-up operation.

Subsequently, 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 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. Further, the storage unit included in the computer stores various programs for realizing the functions of the computer according to an instruction of the CPU. This enables collaboration 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 device 1 of this embodiment includes converters c1 to cn, conversion result repositories r11 to r1 n for each converter, a version control tool 10, a meta information DB (DataBase) 11, and a merge tool m1. And a machine conversion result repository r 2, a manual correction management tool 20, a manual correction execution work space 21, a manual correction result repository r 3, a merge tool m 2, a conversion result repository r 4, and a test tool 30. .

The conversion source COBOL source s1 in Fig. 1 is source code that records COBOL code ("COBOL 1", "COBOL 2", ..., "COBON", "COBOLX") described in COBOL, and the customer is current Executed to operate the system.
Also, the converted Java source s2 in FIG. 1 is source code in which JAVA code (“Java 1”, “Java 2”,..., “Java N”, “Java X”) described in JAVA is recorded, and is a customer Is implemented to operate the new system.
The various conversion sources s31 to s3 n, s4, and 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 conversion source COBOL source s1 into JAVA code. The character strings as COBOL code to be converted by each of the converters c1 to cn are predetermined, and can be prepared, for example, in units of instruction words (eg, "MOVE" of COBOL code to "set" of JAVA code) Converter to convert). Also, the converters c1 to cn can be prepared in syntactic units, and can be designed at various granularities in language grammar.

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

[Converter-by-converter conversion result repository r11 to r1n]
Each of the conversion result repositories r11 to r1n by converter executes each of the converters c1 to cn with respect to the conversion source COBOL source s1 so that part of the COBOL code is converted into JAVA code. Store each one.

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

[Meta information DB11]
The meta information DB 11 stores the meta information acquired by the version control tool 10. Note that the conversion device 1 of the present embodiment may be provided with a GUI (Graphic User Interface) such as Tortoise Git to enable visual tracking of meta information and sources s31 to s3n during conversion.

[Merge tool m1]
The merge tool m1 merges the conversion-in-progress sources s31 to s3 n stored in the converter-by-converter conversion result repositories r11 to r1 n. The merge process can use, for example, three-way merge (well-known and detailed description will be omitted) used in a distributed version control tool.

For example, the merge tool m1 performs three-way merging with the conversion source COBOL source s1 as a parent and any two conversion sources s31 to s3n derived from the parent as children, and the conversion points of the two children are reflected to the parent To obtain the result (conversion in progress conversion source). Although three-way merge fails (collision) if the conversion points of the two children are in the same row, the converters c1 to cn in this embodiment are designed to have only one conversion point. The conversion point of is never the same line.

For example, the merge tool m1 first performs three-way merging with the conversion source COBOL source s1 as a parent and the conversion in-progress sources s31 and s32 as first children and second children, and obtains a first result. Next, the merge tool m1 performs three-way merge with the conversion source COBOL source s1 as a parent, the first result as a first child, and the conversion in-progress source s33 as a second child, and the second result as a second obtain. As described above, by executing the three-way merge in multiple stages, the conversion-in-progress sources s4 (“Java 1”, “Java 2”,..., “Java N”) on which all mechanical conversions by the converters c1 to cn have been executed. , "COBOLX") can be obtained.
Further, the merge tool m1 can merge the sources s31 to s3n in the middle of conversion at once as a merge process to obtain the source s4 in the middle of conversion.

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

[Manual correction management tool 20]
The manual correction management tool 20 manages manual correction for converting 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 manually converts the COBOL code "COBOLX" of the conversion source COBOL source s1 into the JAVA code "JavaX" of the Java source s2 after conversion.
Further, the manual correction management tool 20 outputs, to the version management tool 10, information on conversion of the manual correction as meta information.

The case where conversion from COBOL code to JAVA code is performed manually is a case where the rule that the same machine code is to be converted does not apply because of differences in language specifications. Specifically, the cases corresponding to the following hand correction necessary examples 1 to 3 are as follows.
Hand correction required example 1: Presence of multiple same data item names Hand correction required example 2: Presence of clear dead code (unreachable code) Hand correction required example 3: Presence of multiple same branch conditions

For example, with regard to the manual correction required example 1,
[COBOL code]
01 D1 PICTURE X (2) VALUES 'AZ'.
01 D1 PICTURE 9 (2) VALUES 10.
In the case of machine conversion,
[JAVA code]
String d1 = “AZ”
intd1 10;
Is created. The above COBOL code does not have a problem with COBOL syntax, but the above JAVA code results in a compilation error due to variable name duplication in JAVA.

For the hand correction required example 2, for example,
[COBOL code]
EXIT.
MOVE A TO B.
In the case of machine conversion,
[JAVA code]
return;
b. set (a);
Is created. The above COBOL code does not have a problem with COBOL syntax, but the above JAVA code causes a compile error due to a clear dead code in JAVA.

For the hand correction required example 3, for example,
[COBOL code]
EVALUATE A
WHEN 0
...
CONTINUE
WHEN 0
...
END EVALUATE.
In the case of machine conversion,
[JAVA code]
switch (a) {
case 0:
~ ~;
break;
case 0:
~ ~;
:
}
Is created. The above COBOL code does not have a problem with COBOL syntax, but the above JAVA code causes a compile error due to overlapping branch conditions in JAVA.

In the case of hand correction required examples 1 to 3, different hand correction results are created so as to perform the same operation in JAVA code even with the same COBOL code.

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

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

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

[Conversion result repository r4]
The conversion result repository r4 is mechanically converted and manually converted by the merge tool m2, and stores only Java code and stores the converted Java source s2.

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

For example, as shown in FIG. 1, as a result of the test tool 30 executing the confirmation test, it is determined that there is a defect and it turns out that the JAVA code "Java 2" of the converted Java source s2 is the cause of the defect. Specifically, the conversion code corrects the operation of the line of “Java 2”, which the conversion developer knows in advance, and the JAVA described in the converted Java source s 2 output from the merge tool m 2 Suppose that the difference with the code "Java 2" is found. In this case, the test tool 30 refers to the meta information DB 11 to acquire meta information on conversion from the COBOL code “COBOL 2” to the JAVA code “Java 2”. The test tool 30 analyzes the acquired meta information to find a problem with the converter c2 itself that has executed conversion to the JAVA code "Java 2". There is a problem with the conversion design related to the conversion to the JAVA code "Java 2". , Etc can be identified details of the cause of failure.

«Processing»
Next, as processing executed by the conversion device 1 of the present embodiment, foreign language conversion processing from COBOL to JAVA will be described with reference to FIG. In the description, FIG. 1 is also referred to as appropriate.

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

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

Next, the conversion device 1 grammatically shapes the conversion source COBOL source s1 (step S3). Specifically, the conversion device 1 shapes the syntax of the conversion source COBOL source s1 into a syntax that assumes input to the converters c1 to cn, such as unifying the sugar coating syntax into the normal notation.

Next, the conversion device 1 performs common conversion to the JAVA language on the conversion source COBOL source s1 (step S4). Specifically, the conversion device 1 applies a conversion design that is necessary in common among the converters c1 to cn regardless of the characteristics of the conversion design, such as the JAVA import statement and the description of the main method. According to step S4, the conversion design of each of the converters c1 to cn can not include a common conversion design among the converters c1 to cn, and the conversion design of each of the converters c1 to cn can be simplified. can do.

Next, the conversion device 1 performs order-dependent conversion to the JAVA language on the conversion source COBOL source s1 (step S5). Specifically, conversion device 1 depends on the execution results of one conversion design for the execution of one conversion design for conversion designs of conversion source COBOL source s1 to conversion to Java source s2 after conversion. If so, apply the conversion design related to that dependency, and perform conversion with execution order dependency. According to step S5, by executing the conversion having the execution order dependency in advance, the conversion by each of the converters c1 to cn can be made to have no execution order dependency, and the converter c1 to c The conversion design of each cn can be simplified.

Next, the conversion device 1 performs parallel conversion to 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 the conversion that can not be handled or can not be handled by the conversion by the converters c1 to cn is manually corrected by the manual correction management tool 20 Apply the transformation design of.

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

In step S6, the version control tool 10 acquires meta-information on individual command conversions (1) to (N) corresponding to each of the converters c1 to cn and meta-information on manual correction conversion corresponding to manual correction. , Stored in the meta information DB11.

Next, the conversion device 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 in-progress sources s31 to s3 n (or conversion in-progress source s4) converted by the converters c1 to cn and the manual correction management tool 20 During conversion, merge processing is performed on the source s5, and a converted Java source s2 is generated.

Next, the conversion device 1 performs a confirmation test of the converted Java source s2 by the test tool 30 (step S8). When there is a defect in the confirmation test, the test tool 30 specifies conversion based on the defect location information with reference to the corresponding meta information stored in the meta information DB 11 to create the defect cause of the defect.

In conversion development, after correcting the converter that performs conversion that incorporates the cause of defects, the different language conversion process of FIG. 2 is performed again. At this time, since the conversion between each converter does not affect the conversion of the other converter, in the parallel conversion in step S6, the individual instruction word conversion corresponding to the corrected converter only needs to be performed. There is no need to perform instruction word conversion. Therefore, in the merge of step S7, the conversion result of the individual instruction word conversion corresponding to the converter which is not corrected can be diverted, which contributes to the reduction of the number of reconversion steps after handling the defect, which is required for the processing of FIG. The burden can be reduced or the time can be shortened.

According to the process of FIG. 2, when the conversion source COBOL source s1 is converted to the Java source s2 after conversion, the version management tool 10 can trace the conversion history by managing the meta information. As a result, the identification of the cause of the defect when there is a defect in the converted Java source s2 can be sufficiently achieved by referring to the meta information, and it becomes easy without the need for the examination of a conventional expert.
Therefore, it is possible to reduce the defect handling cost in conversion development.

«Use of hand correction result in catch-up work»
In conversion development, in which the conversion source provided by the customer is converted to the conversion source, the customer corrects the conversion source regardless of the progress of conversion development, for maintenance development reasons such as defect handling and legal revision correspondence. Specifications may be changed. In that case, after completing the first conversion development, it is necessary to carry out conversion development again and incorporate specification changes into the converted source. Completion of the initial conversion development means completion without defects in the post-conversion source verification test and may be referred to as "freezing". In addition, there is a case where specification change handling operation after freezing in conversion development again is referred to as "catch-up operation".

Although catch-up work is essential, it increases the amount of conversion development work and causes delay in system migration, so there is a demand to reduce the number of work steps and terminate it early. However, conventionally, for example, in the case of hand-correcting necessary examples 1 to 3 described above for the conversion source source, when hand-correcting the corresponding line in the first conversion development, the same line It had to be corrected and it was inefficient.
In addition, conventionally, even if the confirmation test is performed on the converted part of the converted source by manual correction before the freezing, almost the same confirmation test needs to be performed again in the catch-up operation, and the test man-hours for the catch-up operation Could not be reduced.

That is, in general, in the case of maintenance development on the customer side, the code modification of the specification change often needs to be done in functional units, so the impact of the code modification on the new system is usually local. On the other hand, in conversion development, the conversion is a conversion viewpoint unit (syntax unit) (whether mechanical or manual correction), so the conversion has an overall impact on the new system. For this reason, there is a tendency that the confirmation items of the confirmation test against the conversion by manual correction are dispersed throughout the new system. As a result, even if the amount of manual correction is small, the number of confirmation items of the confirmation test for conversion by manual correction is not small, and a test man-hour substantially equal to the test man-hour before freezing is required. Such a situation exists regardless of whether or not the conversion by manual correction is affected by the correction on the customer side.

The conversion device 1 of the present embodiment uses the three-way merge performed by the merge tools m1 and m2 to mechanically perform the hand correction result before freezing, which is irrelevant to the correction of the specification change on the customer side in the catch-up operation. Diverted to In the present embodiment, the three-way merge for the hand correction result is performed by the merge tool m2, and the following description is also described as the three-way merge by the merge tool m2, but can be performed similarly by the merge tool m1.

As shown in FIG. 3, a conversion source source sp, a correction version conversion source source sc1, and a manual correction source sc2 are prepared.
The conversion source source sp is source code in which COBOL code (1st line "COBOL1", 2nd line "COBOL2", 3rd line "COBOL3") described in COBOL is recorded. The conversion source source sp is a conversion development object originally provided by the customer from the conversion developer side. The conversion source source sp corresponds to the conversion source COBOL source s1 in FIG.

The modified version conversion source sc1 is a source code in which COBOL code (1st line "COBOL 1", 2nd line "COBOL 2", 3rd line "COBOA") written in COBOL is recorded. The modified version conversion source sc1 is equal to the conversion source source sp that reflects the correction of the specification change on the customer side (“COBOL 3” (specific line) → “COBOLA”). The modified version conversion source sc1 is provided by the customer during catch-up operation, that is, after freezing.

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

The version control tool 10 manages meta information on the conversion source source sp, the correction version conversion source source sc1, the manual correction source sc2, the conversion source source sp, the correction version conversion source source sc1, and the manual correction source sc2. Content can be managed.

The merge tool m2 is a three-way merge with the conversion source sp as the merge parent, the modified conversion source sc1 as the merge child (first child), and the hand 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 control tool 10 acquires and manages meta-information on the manual correction diversion source sd.

Comparing the modified conversion source sc1 with the manual correction diversion source sd, the code of the second line "COBOL2" is converted to "Java2" without being affected by the customer correction to the third line "COBOL3". It can be said that the hand correction result by the hand correction source sc2 can be diverted to the correction version conversion source sc1. Conventionally, in the catch-up operation, conversion of “COBOL 2” → “Java 2” is manually performed on the correction version conversion source sc 1, but according to the present invention, it is possible to save time for the conversion. As a result, the target of manual correction in the catch-up operation is limited to the COBOL code in which the customer-side specification change has been corrected among the COBOL code which has been manually corrected before freezing.

Moreover, the confirmation test before freezing with respect to the converted source including the manual correction result by the manual correction source sc 2 has already been completed, and the manual correction result is used. Therefore, in the catch-up operation, when performing the confirmation test of the converted source (customer correction reflected) after the merge processing using the hand correction diversion source sd, the confirmation item of the confirmation test for the conversion by the hand correction which is diverted is omitted be able to. As a result, it is possible to reduce the number of test steps for catch-up work.

In addition, about conversion to the JAVA code of the 3rd line "COBOA" of hand correction diversion source sd obtained by 3-way merge, when "COBOA" is machine code which can be machine-converted, converter c1 to cn Any one of them is converted, and the result is stored in the machine conversion result repository r2. On the other hand, if "COBOLA" is COBOL code that requires manual correction, manual correction is performed by the manual correction management tool 20 for the manual correction diversion source sd, and the result is stored in the manual correction result repository r3. Ru. After that, the procedure described above (such as step S7 in FIG. 2) is followed.

«One-sided three-way merge»
In the catch-up operation, there may be a case where the customer-side correction portion (specific line) for the conversion source source and the portion (hand correction line) where manual correction before freezing is performed for the conversion source source overlap. In this case, when performing three-way merge using the hand correction result, a conflict occurs and the merge can not be performed.

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

The modified version conversion source sc1a is a source code in which COBOL code (1st line "COBOL 1", 2nd line "COBOA", 3rd line "COBOL 3") described in COBOL is recorded. The modified version conversion source sc1a is equal to the conversion source source sp that reflects the correction of the specification change on the customer side (“COBOL 2” → “COBOLA”). The modified version conversion source sc1a is provided from the customer during the catch-up operation, that is, after freezing.
The version management tool 10 can manage meta information on the modified version conversion source source sc1a and can manage the content of the modified version conversion source source sc1a.

If the three-way merge in FIG. 3 is temporarily performed on the conversion source source sp, the correction 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 ("Java 2" (manual correction line)) conflict (duplicate) and merge is impossible.

Therefore, as shown in FIG. 4, the merge tool m2 merges the conversion source source sp into a merge parent, the modified version conversion source source sc1a into a merge child (first child), and the hand correction source sc2 merges into a child (first Performs one-way three-way merge with 2). As a result, the customer modification priority source sda (1st line "COBOL1", 2nd line "COBOLA", 3rd line "COBOL3" not including the manual correction result ("Java 2") but including the customer correction ("COBOLA") Get "). The version control tool 10 acquires and manages meta information on the customer modification priority source sda.

According to the one-side three-way merge of this embodiment, even if the manual correction and the customer correction conflict, the customer correction can be reliably reflected on the product of the three-way merge. The customer's inherent requirements can be met with certainty.

In addition, about conversion to the JAVA code of the 2nd line "COBOA" of the customer modification priority source sda obtained by one-side three-way merge, if "COBOA" is a machine-convertible COBOL code, converter c1 ~ It is converted by any of cn, and the result is stored in the machine conversion result repository r2. On the other hand, if "COBOLA" is COBOL code requiring manual correction, manual correction is performed by the manual correction management tool 20 for the customer correction priority source sda, and the result is stored in the manual correction result repository r3. Ru. After that, the procedure described above (such as step S7 in FIG. 2) is followed.

«Reducing man-hours for test in catch-up work»
The catch-up process is essentially sufficient if another conversion development is made to the (generally small scale) correction made by the customer to the conversion source. Most of the test validations that need to be done in the catch-up task overlap with those already done in the first conversion development before catch-up. Therefore, the idea of reducing the number of test operations in catch-up work by using the check results of the first conversion development test is realized, and the method will be specifically described below.

As shown in FIG. 5, in the foreign language conversion before catch-up operation, that is, in the first conversion development, the conversion device 1 of this embodiment converts the conversion source source sp (for example, COBOL) after conversion source sq (for example, JAVA) When converting into (), conversion design setting (step S11), converter generation (step S12), machine conversion + hand correction (step S13), and three-way merge (step S14) are executed.

The conversion design setting (step S11) is a step in which the conversion development side analyzes the conversion source source sp, and sets one or more types of conversion design necessary for creating the converted source sq to the conversion source source sp. is there. Conversion design is a framework that defines how to rewrite the code string to be converted. The type of conversion design that is required may be determined as appropriate, for example, by the conversion developer, but the method of determination is not limited thereto.

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

Machine transformation + hand correction (step S13) is a step of performing machine transformation and hand correction in accordance with the transformation design. In FIG. 5, each of the converters A2 to C2 executes machine conversion according to the conversion designs A1 to C1 on each of conversion targets in the conversion source source sp, and outputs conversion results A3 to C3. Further, the manual correction management tool 20 (FIG. 1) performs manual correction in accordance with the conversion designs D1 and E1 on each of conversion targets in the conversion source source sp, and outputs conversion results D3 and E3. The conversion results A3 to E3 correspond to the sources s31 to s3 n, s4, and s5 during conversion shown in FIG.

Note that, as shown in FIG. 1, the conversion device 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 due to the corrections were collectively managed in one repository (FIG. 1 manual correction result repository r3). However, the management unit by repository can be set arbitrarily. Therefore, for the description with reference to FIGS. 5 and 6, the conversion device 1 of this 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. Note that as a repository, instead of a repository prepared for each conversion design, a repository for a collection of multiple conversion designs may be prepared.

The conversion developer side checks the conversion results A3 to E3 on the desk. Desktop confirmation is a known method and the description is omitted. In the present embodiment, it is assumed that the result of desktop confirmation for the conversion results A3 to E3 is good.

The three-way merge (step S14) is a step of performing the three-way merge on the conversion result obtained by 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, the converted source sq is obtained by executing three-way merge on the conversion results A3 to E3.

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

After the initial conversion development is complete, the customer corrects the conversion source, and performs catch-up work. As shown in FIG. 6, in the catch-up operation, the conversion device 1 of the present embodiment converts the conversion source source spa (corresponding to the correction version conversion source source) including the correction portion spa1 of the customer Convert to the transformed source sqa including sqa1. At the time of this conversion, conversion design setting (step S21) shown in FIG. 6, converter generation (step S22), machine conversion + hand correction (step S23), and three-way merge (step S24) are executed.

The conversion design setting (step S21) is the same step as the conversion design setting (step S11) of 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 response to the correction source spa including the correction part spa1. Instead of the above, it is assumed that five types of conversion designs A1, B11, C1, D11, and E1 are set for each conversion target with respect to 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 conversion design A1 (FIG. 5) already generated and the converter C2 for conversion design C1 (FIG. 5), conversion design B11 is performed with respect to the newly set conversion design B11. Forward converter B21 is newly generated. The converter B21 for conversion design B11 has the same function as the converters c1 to cn in FIG.

The machine conversion + hand correction (step S23) is the same step as the machine conversion + hand correction (step S13) of FIG. In FIG. 6, in addition to the conversion results A3 and C3 (FIG. 5) already generated by machine conversion, the converter B21 for conversion design B11 performs machine conversion according to conversion design B11 for the conversion target in conversion source source sp. To output a conversion result B31 anew. Further, in FIG. 6, in addition to the conversion result E3 (FIG. 5) already generated by hand correction, the hand correction management tool 20 (FIG. 1) converts the conversion design D11 for the conversion target in the conversion source source sp. Perform manual correction according to and newly output a conversion result D31. The conversion results B31 and D31 correspond to the sources s31 to s3 n, s4 and s5 during conversion shown in FIG.

The conversion developer side checks the new conversion results B31 and D31 on the desk. As for the conversion results A3, C3, and E3 that have already been generated, since desktop confirmation has been completed (FIG. 5), they are omitted in the catch-up operation. Therefore, by managing the conversion result for each conversion design, it is possible to reduce the number of test steps for desktop confirmation in the catch-up operation. Further, in the present embodiment, it is assumed that the result of the desktop confirmation with respect to 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) of FIG. In FIG. 6, by executing three-way merge on conversion results A3, B31, C3, D31, and E3, a converted source sqa including the correction part sqa1 corresponding to the correction part spa1 is obtained.

The conversion developer side checks the actual source for the converted source sqa. In this actual machine confirmation, among all the confirmation items, the confirmation items that the correction part sqa1 does not affect (the conversion items related to the conversion designs A1, C1 and E1 other than the conversion design B11 and D11 changed according to the correction part spa1) Since it has already been confirmed before the catch-up operation (FIG. 5), it may be omitted in the catch-up operation. Therefore, as shown in the example of FIGS. 5 and 6, by managing the conversion result for each conversion design, it is only necessary to confirm the confirmation item affected by the correction part sqa1 among all the confirmation items of the actual device confirmation. . As a result, it is possible to reduce the number of test steps for checking the actual machine in the catch-up operation.

«Modification»
As mentioned above, although embodiment of this invention was described, this invention is not limited to the said embodiment, It can change suitably in the range which does not deviate from the summary of this invention. For example, the programming language of conversion source in conversion development is not limited to COBOL, and may be another programming language. Also, the program language of the converted source in conversion development is not limited to JAVA, and may be another programming language.

Furthermore, language conversion in conversion development is not limited to conversion to a different kind of programming language such as conversion from COBOL to JAVA, which was taken up in this embodiment, and the same kind of programming language such as conversion from host-based COBOL to open-based COBOL. May be converted to

Further, the present invention is applicable not only to conversion development for conversion of program language, but also to various migration development involved in 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 conversion tools prepared for the conversion source as in the prior art. Also, conventionally, as a tool for mechanically converting a programming language, there is a tool for parsing (parsing tree interpretation) and replacing code. This tool is configured as one (or a few) tools that can handle almost all language conversions, and is generally large and complex. The present invention can also be applied to such tools, and contributes to identification of the cause of defects, reduction in the number of test steps in catch-up work, and the like.

It is also possible to realize a technology that appropriately combines the various technologies described in the present embodiment.
The software described in the present embodiment can be realized as hardware, or hardware can be realized as software.
In addition, hardware, software, flowcharts, and the like can be appropriately modified without departing from the spirit of the present invention.

1 Converter c1 to cn Converter 10 Version Management Tool (Meta Information Management Department)
11 Meta Information DB
20 Manual revision management tool (hand revision management department)
21 Manual correction work workspace 30 Test tool (test section)
m1, m2 merge tool (merge section)
r11 to r1n Conversion result repository for each converter r2 machine conversion result repository r3 manual correction result repository r4 conversion result repository s1 conversion source COBOL source (conversion source source)
s2 Converted Java source (converted source)
s31 to s3n, s4, s5 conversion in process source sc1, sc1a modified version conversion source sp, spa conversion source source sq, sqa converted source A1 to E1, B11, D11 conversion design A2 conversion design A1 converter B2 conversion design B1 Converter B21 Converter design for B11 Converter C2 Converter design for C1 Converters A3 to E3, B31, D31 Conversion results

Claims

A conversion device for converting a conversion source into a converted source,
A meta-information management unit that manages meta-information related to conversion to each of the conversion intermediate sources, for a set of conversion intermediate sources generated by converting a part of the conversion source to a part of the converted source;
And a test unit for identifying a conversion in which the cause of the defect is created by referring to the meta information when there is a defect in the post-conversion source confirmation test.
A conversion device characterized by
A plurality of types of converters, provided for each character string in the conversion source, and performing mechanical and parallel conversion from part of the conversion source to part of the converted source;
A manual correction management unit that manages manual correction for converting a part of the conversion source to a part of the converted source;
And a merge unit performing merge processing on the set of conversion-in-progress sources.
The converter according to claim 1, characterized in that:
If there is a modified version of the conversion source, the specific line of the conversion source has been corrected:
The merge unit is
A three-way merge is performed with the conversion source as a parent, the modified version conversion source as a first child, and the conversion in-progress source subjected to conversion by the manual correction as a second child.
The converter according to claim 2, characterized in that:
The merge unit is
In the three-way merge, when the specific line corrected in the correction version conversion source and the manually corrected line subjected to the manual correction overlap in the conversion midway source subjected to the conversion by the manual correction , Prioritize the particular line,
The converter according to claim 3, characterized in that:
When the conversion in-progress source is generated for each conversion design set for the conversion source, a new conversion is generated for the conversion design changed according to the correction of the correction version conversion source in the conversion design. Generate a source on the way,
The conversion device according to claim 3 or 4 characterized by things.
The conversion from the conversion source to the converted source is a program language conversion,
The converter according to any one of claims 1 to 5, characterized in that:
The program language conversion is
Conversion to a different kind of programming language, or conversion to the same kind of programming language,
The converter according to claim 6, characterized in that:
A conversion method in a conversion apparatus for converting a conversion source into a converted source,
Registering meta information related to conversion to each of the conversion intermediate sources for a set of conversion intermediate sources generated by converting a part of the conversion source to a part of the converted source;
Conducting a confirmation test of the converted source and, if there is a defect, referring to the meta-information to specify a conversion in which the cause of the defect is created.
A conversion method characterized by