JP2015076025A - Program upgrade assistance method and program upgrade assistance system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide means for facilitating reflecting customization contents and identifying an influence range of the customization contents at a time of upgrading a program.SOLUTION: A target program and a standard program are compared by means of source code files, an upgraded program and the standard program are compared by means of the source code files, and a type determination is carried out based on respective comparison results. A correction method is determined for each source code file for applying upgrading to the target program based on a type determination result, and information necessary to identify a correction influence range is calculated.

Description

  The present invention relates to a program update technique.

  For example, when package software is applied at the time of construction of a business system, modification (customization) is performed according to a request from a customer / user.

  When version upgrades such as adding functions are performed on the package software that is the source of this customized package software, it has been changed by simply comparing the customized source code file with the upgraded source code file. The point is being identified.

  In identifying such changes, since it is not possible to mechanically select a customized part and a version-up part, manual check work is required, and problems such as check omissions occur.

JP2012-159931A JP 2006-276953 A

  In the technology of Patent Document 1, the customization contents (customization results) for each customer / user of the package software are centrally managed in a database, and whether there is an influence on the customization for each customer / user from the change information of the package software is determined. And the affected objects are automatically extracted.

  However, since version upgrades other than those for which customization has been performed are not performed, it is necessary to manually identify the content of upgrades to objects that have not been customized. Further, the contents to be managed are only documents indicating which objects have been changed, and the management by the source code file entity is not performed, which may cause a deviation from the entity.

  The technology of Patent Document 2 provides a technology that reflects version upgrades for customized screen definition files. In order to check whether the contents of the upgrade should be reflected in the customized package software when screen items are added or changed as a result of upgrading the original package software of the customization, the screen items of the version upgrade are checked. The addition or change is reflected on the customized package software and displayed on the screen. Japanese Patent Application Laid-Open No. 2004-228561 is a technique related to reflection of version upgrade on a screen definition file, and cannot cope with application of anything other than a screen definition file. Further, as with Patent Document 1, version upgrade of a screen definition file that has not been customized is not targeted.

  The problem to be solved by the present invention is that, when a version upgrade occurs in a program that is a source of a customized program, the source code is based on the source code file entity while taking into consideration the range of influence due to the version upgrade. There is no means for mechanically determining whether a file has been upgraded or customized.

  In the present invention, the analysis target source code is a version obtained by comparing the analysis target file with the source code file (old version standard source code) of the old version program and adding functions to the old version program and the old version program. Based on the comparison result with the source code file of the new version program that has been upgraded (new version standard source code), the type is determined. Determine version upgrade method.

  With the system of the present invention, it is easy to reflect the contents of the upgrade in the customized program and specify the affected range when the program is upgraded.

It is a block diagram of the program version upgrade assistance system concerning the Example of this invention. It is a flowchart of the name conversion process part concerning the Example of this invention. It is a flowchart of the source comparison process part concerning the Example of this invention. It is an example of the comparison result of the old version standard source code which made the analysis object source code concerning the Example of this invention the comparison origin. It is an example of a comparison result with the analysis object source code which made the comparison source the old version standard source code concerning the example of the present invention. It is a flowchart of the classification determination process part concerning the Example of this invention. It is a list of the classification determination result from the comparison result concerning the Example of this invention, and a source code correction method. It is an example of the type determination result file concerning the Example of this invention. It is an image of the influence range by the classification concerning the Example of this invention.

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

  FIG. 1 is a block diagram showing a program version upgrade support system.

  The program upgrade support system 100 is realized by, for example, a general computer (computer, server, etc.), and is stored in a CPU (Central Processing Unit) 110, a program executed by the CPU, an HDD that stores various data, a semiconductor memory, and the like. The apparatus 111 includes an input device (not shown) such as a keyboard / mouse, and an output device (not shown) such as a display.

  Based on the standard source code, the analysis target source code 130 is customized for each user such as customer request, and the same version number as the old version standard source code 131 is obtained by upgrading the version of the source code based on the original source code or after customization. It is the source code which has. Further, the new version standard source code 132 is obtained by performing a function addition or a defect countermeasure on the old version standard source code 131. The old version standard source code 131 and the new version standard source code 132 are comparison target source codes of the analysis target source code 130. The analysis target source code 130, the old version standard source code 131, and the new version standard source code 132 are each composed of one or more source code files. In this embodiment, a case where a plurality of source code files are used will be described as an example.

  In the present embodiment, in order to add a new function implemented in the new version standard source code 132 and reflect a defect countermeasure to the analysis target source code 130, a correction method for each source code file is determined, and The information that enables the identification of the affected range is output. Simply comparing the source code file of the analysis target source code 130 and the source code file of the new version standard source code 132, not only the changes in the new version standard source code 132 but also the customized parts are different. Therefore, it is not possible to extract only differences due to version upgrades. Therefore, for each source code file, the difference (customization difference) between the analysis target source code 130 and the old version standard source code 131, and the difference (version upgrade difference) between the old version standard source code 132 and the new version standard source code 133. By performing extraction, and further determining the type based on the presence or absence of customization differences and version upgrade differences for each source code file, it is possible to provide information for specifying a correction method and an affected range of the source code file. It is also possible to automate the update of the source code file of the analysis target source code using these output information. If the comparison unit is an application unit, it is determined that the entire application is manually upgraded for some files that cannot be automatically upgraded because of a rough determination, and the influence between files cannot be investigated. Even if the line-by-line comparison result of the source code file is output, the replacement of the source code file is performed on a file basis. Therefore, in the present invention, the comparison result is output on a file basis.

  In FIG. 1, the program version upgrade support system 100 includes a name conversion processing unit 120, a source comparison processing unit 121, and a type determination processing unit 122.

  The name conversion processing unit 120 converts the source code file name of the analysis target source code 130. When customizing based on the old version standard source code 131, the file name may be changed according to a predetermined naming rule so that it can be understood that the customization has been performed. In that case, the name conversion processing unit 120 returns the file name to that before customization. If the file name is not changed during customization, the file name is not converted. The customization program 131 used in the source comparison processing unit 121 and later is a name-converted source code file.

  The source comparison processing unit 121 compares the analysis target source code 130 with the old version standard source code 131 and the old version standard source code 131 with the new version standard source code 132, and sends each comparison result 133 to the storage device 111. Store. The type determination processing unit 122 performs type determination based on the comparison result 133 stored in the storage device 111 and stores the type determination result 134 in the storage device 111. Here, the types will be described. The type is determined for each source code file. The types are classified into four types, from type 1 to type 4, and the method for correcting the source code file is different for each type. As will be described in detail later with reference to FIG. 7, type 1 is a source code file that has not been changed by customization or upgrade, and no modification is required. Type 2 is a source code file that is changed only in version upgrade, and the source code file of the new version standard source code is applied. Type 3 is a source code file that is changed only by customization, and the source code file of the analysis target source code is applied. Type 4 is a source code file that has been changed by both version upgrade and customization, and it is necessary to merge the analysis source code and the new version standard source code.

  Next, processing of the program version upgrade support system 100 will be described with reference to FIGS.

  FIG. 2 shows a processing flow of the name conversion processing unit 120 of FIG. In this processing, since it is premised that the file names are the same when performing source comparison, if the file name has been changed during customization, the file name before customization is restored. In step 200 in FIG. 2, the customization name change rule 210 defined in advance by the user of this system is read. One source code file of the analysis target source code 211 is read. . In step 201, the file name of the read source code file is compared with the definition contents of the customization-time name change rule 210, and it is determined whether or not the file has the file name changed at the time of customization. As a result of the determination, if the file name at the time of customization has been changed, the process returns to the file name before customization in step 203, and the source code file having the file name before customization is stored in the storage device of FIG. 111. For example, a case where a source code file created in the Java (registered trademark) language is customized will be described. It is assumed that “original class name” + “_ cstm” + “. Java” is defined as a coding rule at the time of customization. If the source code file name of the previous version was “SampleClass1.java”, it will be renamed to “SampleClass1_cstm.java” and saved when customization is performed. The contents of “original class name” + “_ cstm” + “. Java” are defined in advance in the name change rule 210 at the time of customization. The file name is changed. The analysis target source code file reading, customization determination, and file name conversion are performed for each file of the analysis target source code one by one.

  FIG. 3 shows a processing flow of the source comparison processing unit 121 of FIG. In step 310, the analysis target source code 300 and the old version standard source code 301 are compared, and a comparison result 320 and a comparison result 321 are output. In the comparison, the source codes are matched character by character, and a step count is performed to determine whether there is no difference and they are exactly the same or there is a difference. In some cases, the file to be compared does not exist. Here, the comparison result 320 is a result of comparison with a source code file having the same file name in the old version standard source code 301 using the file name of the source code existing in the analysis target source code 300 as a comparison source. The comparison result 321 is a result of comparison with the source code file having the same file name in the analysis target source code 300 using the file name of the source code existing in the old version standard source code 301 as a comparison source contrary to the above. is there. Thus, by comparing twice, the source code file which exists only in one side can be added to the comparison results 320 and 321 without omission.

  In step 311, the old version standard source code 301 and the new version standard source code 302 are compared, and a comparison result 322 and a comparison result 323 are output. Here, the same comparison as in step 310 is performed. The comparison result 322 is a result of comparison with a source code file having the same file name in the old version standard source code 301 using the source code file name existing in the new version standard source code 302 as a comparison source. Contrary to the above, the comparison result 323 is the result of comparison with the source code file having the same file name in the new version standard source code 302 using the file name of the source code existing in the old version standard source code 301 as the comparison source. It is.

  FIG. 4 is an example of the comparison result 320 of FIG. The judgment result is shown for each source code file name. The comparison result “new” is a source code file that does not exist in the old version standard code but exists only in the analysis target source code. “No change” in the comparison result is a source code file that is not changed in the analysis source code compared to the standard source code of the previous version. The “changed” of the comparison result is a source code file that has been changed in the analysis source code compared to the old version standard source code.

  FIG. 5 is an example of the comparison result 321 of FIG. The comparison results “no change” and “change” are the same as the comparison result 320 for the same file. The “deletion” of the comparison result is a source code file that exists in the old version standard source code but does not exist in the analysis target source code. For example, “A01_010_I010.java” of item number 3 in FIG. 5 does not exist in FIG. 4 and is thus determined to be “deleted”.

  By merging the comparison results 320 and 321, it is possible to determine “no change”, “change”, “new”, and “delete” for each file. Further, the comparison results 322 and 323 can be handled in the same manner, and each file can be determined as four types.

  FIG. 6 shows a processing flow of the type determination processing unit 122 of FIG. The comparison result 610 represents the comparison results 320, 321, 322, and 323 in FIG. In step 600, the comparison result 610 is read. The file name of the source code file is acquired from the comparison result 610, and step 601 and step 602 are performed. In step 601, the type of each source code file is determined based on the comparison result, and in step 602, the type determination result is output to the type determination result file 611. The type determination method will be described with reference to FIG. Steps 601 and 602 are repeated for all source code files described in the comparison result.

  FIG. 7 shows a type determination pattern based on the comparison result created by the source comparison processing unit and a method for correcting the source code file for each pattern. The VerUP difference 701 is a result of acquiring “new”, “no change”, “changed”, and “deletion” from the comparison result of the comparison result 322 and the comparison result 323 in FIG. This is the result of determining the comparison result from the result 321. “-” In No. 3 is a source code file that exists in the new version standard source code added at the time of version upgrade, but does not exist in the old version standard source code and the analysis source code. . In contrast, No. 7 is a source code file that is added in the analysis source code, but does not exist in the old version standard source code and the new version standard source code. “No.” in both of No. 11 indicates that the source code files added to the new version standard source code and the analysis source code happen to have the same file name, and the contents are the same. Not always. The type 710 is a type determination result determined from the combination of the comparison results 700. For example, No. 1 in FIG. 7 can be determined to be a file that has not been updated because the VerUP difference 701 and the customization difference 702 are both “no change”, and the type is determined to be “type 1”. The No. 4 is a source code file that is updated only when upgrading because the VerUP difference 701 is “changed” and the customization difference 702 is “no change”, and the new version standard source code is applied. Is determined as “type 2”. No. 3 is a source code file added only in the new version because the VerUP difference 701 is “new” and the customization difference 702 is “−”, and the new version standard source code is applied. Is determined as “type 2”. No. 8 is a source code file updated only at the time of customization because the VerUP difference 701 is “no change” and the customization difference 702 is “changed”. It is determined as “type 3”. In addition, Nos. 9 and 10 may be called in the analysis source code because the VerUP difference 701 is “deleted” and the customization difference 702 is “no change” or “changed”. Since the target source code is applied, the type is determined as “type 3”. In No. 12, since both the VerUP difference 701 and the customization difference 702 are “changed”, it can be determined that both are updated files, and the type is determined as “type 4”.

  FIG. 8 shows an example of the type determination processing file 611. 800 is a type code, 801 is a source code file name, and 802 is a source code file correction method. The type code 800 corresponds to the type code 720 in FIG. For example, in the first line, the type code is “1-a”, so it corresponds to the pattern No. 1 in FIG. 7, the type is “type 1”, and the source code is not updated at the time of version upgrade or customization. Since it is a file, it can be determined that correction is unnecessary. In the second line, the type code is “3-b”, so it corresponds to the pattern of No. 8 in FIG. 7, the type is “type 3”, and it is the source code updated at the time of customization. It can be determined that the source code is applied.

  Further, the influence range can be specified based on the type determination result file 611. This section describes how to identify the source code file to be modified and tested. Call related information indicating the call relation of a program (source code file) is prepared, and the type determination result of the type determination result file 611 is applied thereto. The call related information is preferably the analysis target source code after the version upgrade, but the old version standard source code, the new version standard source code, or the analysis target source code before the version upgrade may be used. If there is a type 4 (913) source code file in the call, it can be determined that the test is necessary because the source code file is a mixture of the contents of the upgrade and the contents of customization. All source code files (910, 911, 912) having a calling relationship with the type 4 (913) source code file are set as test targets. Also, if there is a type 3 (902) source code file that has a call relationship with type 2 (903), it is determined that a test is necessary because the upgrade program and the customization program are related. The type 3 (902) that has a calling relationship with the type 2 (903), the source code file corresponding to the parent program, and the source code file corresponding to the child program are set as test targets. Since Type 1 is not changed, it can be determined that the test is unnecessary. If Type 2 and Type 3 are not mixed in the calling relationship, it can be determined that the test is unnecessary because the process has already been tested when the upgrade program is created and when the customized program is created. By determining the above using the call-related information and the type determination result file 611 in this system, it is possible to calculate the influence range information 135 for specifying the influence range and the target that requires the test as shown in FIG. it can.

100 Program version upgrade support system 110 CPU
111 Storage Device 120 Name Conversion Processing Unit 121 Source Comparison Processing Unit 122 Type Determination Processing Unit 130 Analysis Target Source Code 131 Old Version Standard Source Code 132 New Version Standard Source Code 133 Comparison Result 134 Type Determination Result 135 Influence Range Information

Claims (8)

A first comparison step in which the source comparison processing unit compares the target source code with the first standard source code;
A second comparison step in which a source comparison processing unit compares the first standard source code with a second standard source code that is a version difference of the same source code of the first standard source code;
The type determination processing unit upgrades the target source code to a version related to the second standard source code based on the comparison result of the first comparison step and the comparison result of the second comparison step. A determination process for determining the policy of
A version-up support method comprising: In claim 1,
The target source code, the first standard source code, and the second standard source code each have a plurality of files,
In the first and second steps and the determination step, a comparison result and a determination result are created for each of the files. In claim 2,
In the first comparison step and the second comparison step, a file to be compared is determined based on file names of the plurality of files. In claim 3,
The version upgrade support method characterized in that the comparison results of the first and second comparison steps include a difference, no difference, new and deletion. In any one of Claims 1 thru | or 4,
When there is no difference in the result of the first comparison and there is a difference in the result of the second comparison, the determination result is applicable to the second standard source code as the target source code. A version upgrade support method characterized by outputting. In any one of Claims 1 thru | or 4,
A version upgrade support method characterized in that if there is a difference in the result of the first comparison and there is no difference in the result of the second comparison, it is output that version upgrade is unnecessary as the determination result. In any of claims 2 to 4,
An upgrade support method, wherein an affected range calculation unit calculates an affected range of upgrade based on the call relation information of the plurality of files and the determination result. A first comparison step for comparing the target source code with the first standard source code, and a second standard in which the first standard source code is a version difference of the same source code of the first standard source code A source comparison processing unit for performing a second comparison step comparing with source code;
Judgment for determining a policy for upgrading the target source code to a version of the second standard source code based on the comparison result of the first comparison step and the comparison result of the second comparison step A type determination processing unit that performs the process;
An upgrade support system characterized by comprising:

Images