JPH07334351A - Method and device for managing program correction history - Google Patents

Abstract

PURPOSE:To improve efficiency for managing respective editions with corrections on the stages of program development and to simplify the operation for extracting any arbitrary edition. CONSTITUTION:Concerning program correction history management for which the respective editions with the corrections of a program for the unit of a module are stored in a filing device 6 and any arbitrary edition to be the next correcting object is extracted from this device based on an identifier, the respective identifiers corresponding to respective editions are managed for the unit of modules in an identifier storage part 5 of a module managing part 4, all the identifiers for the unit of the module as the correcting object are displayed by an identifier list display/selector 3, and the identifier corresponding to the edition of the correcting object is selected out of those identifiers. Since the addresses of respective editions for the storage areas in the filing device 6 are automatically set as the identifiers, it is not necessary for a program developer to care of the identifiers and since the order of list display is defined as the order of preparing the editions of respective identifiers, the identifier can be selected with a reference showing how many times before that identifier is corrected.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to program revision history management, and in particular, relates to the revision of programs in module units, and stores the contents of each version up to then in a file device.
The present invention relates to a program revision history management method and apparatus capable of taking out a program of an arbitrary edition which is the next revision target from each edition. The “version” used in this specification includes the contents of the first version of the program that was initially created, so to speak, and the “module” also includes the function.

In general, at the development stage of a program, it is verified whether the modules therein are operating properly by running the program with a formula for logging and a print routine for debugging. After that, work such as deleting this expression is frequently performed.

If any inconvenient point is found as a result of the verification, the program is subjected to a predetermined modification and then re-verified. In particular, such trial-and-error development is usually performed to verify the operation of dynamic processing of a program.

Due to this trial and error, there are many modified versions of the program to be developed, and it is a reality that the programs to be verified and modified are not only the latest version, but also the older versions before that. Is.

Therefore, it is required to efficiently manage the program history information consisting of these versions so that any program to be verified or modified can be retrieved in a short time by a simple operation. Responds to such requests.

[0006]

2. Description of the Related Art FIG. 5 is an explanatory view showing an outline of conventional program history information management. 11 is a module name display / selection device, 12 is a program content display / editing device, 13 is a module management unit, and 14 is The external storage devices are respectively shown.

The module management unit 13 holds the latest version (executable program) of each module and its identifier. In addition, the external storage device 14 is a modified version in which only the formula for printing the log and the debug print routine are included in the program, and the target of verification / correction is actually put All previous editions, including unmodified versions, are stored individually in pre-compiled text format.

As the module unit identifier held in the module management unit 13, for example, the head address of the area in which the latest revised version of the module is stored is used.

In such program history information management, the contents of the program at that time, including the modified version and the unmodified version, which are simply included in the debug print routine, are verified every time the development program is verified / corrected. Is stored in the external storage device 14 as the latest version, and the corresponding part of the module management unit 13 is updated with the execution format and identifier of this latest version.

The operation target of the program developer is usually the module name display / selection device 11 and the program content display / editing device 12, and it is special for the program developer to retrieve an arbitrary old version from the external storage device 14. Need tools.

During this normal operation, the module name display /
When a module is selected by the selection device 11, the module management unit 13 extracts the latest version of the module from the external storage device 14 based on the corresponding identifier, and the content is displayed on the program content display / editing device 12. To be done.

The program content display / editing device 12
When a predetermined correction (edition) is performed by, the latest version is stored in an arbitrary area of the external storage device 14 and the corresponding portion of the module management unit 13 is updated.

[0013]

As described above, in the conventional program history information management, not only when a certain version of a program is selected and verified / corrected, but also when a certain version of the program is selected, no verification / verification is performed. Even when the processing is completed without modification, the same content is newly stored as the latest version in the external storage device, and the module management unit stores each version in module units stored in the external storage device. It manages only the latest version of.

Therefore, in the trial and error program development in which the verification and correction are complicated, the programs having the same contents are frequently stored in the external storage device, resulting in a huge amount of program history information. There is also a problem that an external storage device for storing this requires a large capacity.

Further, when it becomes necessary to modify the program for the old version and it is taken out from the file device, it is necessary to use a means different from the module name display / selection device which is the latest extraction tool. However, there is a problem that the operation procedure of program development becomes complicated.

Therefore, in the present invention, the program when the processing is completed without any verification or modification is not stored in a file device such as an external storage device, and the old version has the same identifier as the latest version. An object of the present invention is to improve efficiency of management of program history information and simplification of an operation of taking out an arbitrary modified version by making it possible to take out from a file device by selection.

Furthermore, it is an object of the present invention to reduce the processing time when running a program of an arbitrary version by holding the compiled form of execution together with the identifier of each version.

[0018]

FIG. 1 is a basic configuration diagram of the present invention. In the figure, 1 is a module name display / selection device, 2 is a program content display / editing device, 3 is an identifier list display / selection device, 4 is a module management unit, 5 is an identifier storage unit in module units, and 6 is a file device. Shown respectively.

Here, the main differences from the case of the conventional program history information management of FIG. 5 are: -The file device 6 stores only the version in which the module unit program is modified in any way. , For example, store only the program that includes the debug print routine in the original program, but do not store the program again if the original program has not been modified. The device 3 is newly provided ・ Each version (development program) stored in the file device 6
The identifier corresponding to each of the above is stored in the identifier storage unit 5 of the module management unit 4 for each module.

When the program used for the next correction work in such program history information management, for example, the program a.2 of the module A is taken out from the file device 6, the identifier list display / selection device 3 is operated as shown in FIG. By operating
Each identifier of the module A held in the module management unit 4 is read out and displayed on the device, and the identifier of the program a.2 is selected from this list display, and the module management unit 4 selects the selected identifier. The program a.2 corresponding to is read from the file device 6 and sent to the program content display / editing device 2.

Then, the program correction work is performed in a state where the program a.2 is displayed on the program content display / editing device 2, and the correction contents here are stored in the file device 6 as the latest version and the execution form thereof is executed. And the identifier is held in the module management unit 4.

When the program a.2 displayed on the program content display / editing device 2 is used as it is, it may be converted into an execution format. The converted program content is stored in the module of the module management unit 4. The identifier a.2 is held in the area A, and the identifier a.2 is moved to the highest rank in the identifier storage unit 5 of the module A, and the rank of the identifier a.1 is lowered. In this case, the program in text format
The a.2 is never stored in the file device 6 as the latest version.

It should be noted that the presence / absence of correction may be determined by the program content display / editing device 2, the module management unit 4, etc., and whether or not the execution format is held in the module management unit 4 is arbitrary.

Further, the module management unit stores the latest version after correction in the file device 6 or takes out the corresponding version from the file device 6 based on the identifier selected by the identifier list display / selection device 3. The processing unit different from the processing unit 4 may be in charge.

In general, the corresponding module is selected by the module name display / selection device 1 before the identifier list display / selection device 3 is displayed. You may make it have a module selection function.

As the identifier, the address of the storage area of the corresponding modified version, the ID information set by the program developer, for example, various information such as the keyword indicating the modification content and the modification date and time are used.

When the former identifier is used, each address is registered in the identifier storage unit 5 in the order of history. That is, the latest version of the address is registered in the highest rank, and the rank of the identifiers up to that point is sequentially lowered.

In this case, the program developer does not need to be aware of this identifier when the latest version is created, and every time the latest version is stored in the file device 6, the start address and the like are automatically set in the history order. Are registered in the identifier storage unit 5.

Then, when the program of the version previously created for a module is taken out from the file device 6, the identifier list display / selection device 3 displays a list of the identifiers of the module, and the version of the version is selected from that order (history order). The identifier is, so to speak, predicted and selected.

When the latter identifier is used, the program contents of the corresponding version can be individually recognized from the contents of the respective identifiers, so that the processing such as registering these based on the history order as in the former identifier is performed. It is unnecessary.

Further, the module management unit 4 may store the execution form together with the identifier of each version, and when the program of a certain version is run, it may be used directly without accessing the file device 6. .

[0032]

According to the present invention, the contents are stored in the file device 6 as the latest version only when the module-based development program is modified, and the stored version is stored in a one-to-one correspondence with each of the stored versions. By holding the corresponding identifier in the module management unit 4, the utilization efficiency of the file device 6 is improved, and any version can be taken out from the file device 6 by a simple operation.

That is, when the program developer wants to take out an arbitrary version from the versions stored in the file device 6 for a new examination, he / she operates the identifier list display / selection device 3 to select the object to be taken out. All you have to do is display the list of module identifiers and select the one in the list that corresponds to the version.

The contents displayed on the program contents display / editing device 2 after being taken out from the file device 6 include a debug print routine, but this routine is not necessary, so it is the old program before it is inserted. If desired, the program developer can retrieve the old program from the file device 6 by operating the identifier list display / selection device 3.

At this time, it is not necessary to perform a manual operation such as deleting the debug print routine from the display program. Further, the original program that has not been modified and remains unloaded from the file device 6 is not stored again in the file device 6.

In the case where the module management unit 4 holds the identifiers of the respective versions as well as the execution forms thereof, the program contents are verified by selecting and running a predetermined one of these.

[0037]

Embodiments of the present invention will be described with reference to FIGS. FIG. 3 is an explanatory diagram showing an embodiment of the module management unit, in which the execution format of each version stored in the file device 6 is also stored in the identifier storage unit 5 together with its identifier.

According to this, when the program of an arbitrary version is run and the validity of its contents is verified, the execution form of the verification target program is identified by the identifier selection operation without accessing the file device 6. It suffices to read the data directly from the storage unit 5, and the processing time can be shortened compared to the case of FIG.

FIG. 4 is an explanatory diagram showing a procedure for examining the program history information (old version and latest version) of an arbitrary module stored in the file device 6, and has the following contents. There is.

Although this processing procedure is premised on the use of the module management unit shown in FIG. 1, if the module management unit shown in FIG. 3 is used instead of the module management unit shown in FIG.
Is unnecessary.

(1) A list of identifiers belonging to this module is displayed on the identifier list display / selection device 3, and the process proceeds to the next step. (2) The identifier list display / selection device 3 selects an identifier corresponding to the version under consideration, for example, based on how many times the version under consideration has been modified, and proceeds to the next step. (3) The program (text format) of the version to be examined is read from the file device 6 based on this identifier, and the process proceeds to the next step. (4) This program content is displayed on the program content display / editing device 2, and the process proceeds to the next step. (5) The program developer judges whether or not this display program is under consideration, and if “YES”, proceeds to the next step, and if “NO”, returns to step (2). (6) The program developer decides whether or not to modify this display program, and in the case of "YES", the step (9)
If the answer is "NO", proceed to the next step. (7) This display program is converted into the execution format and replaced with the execution format of the module management unit 4, and the process proceeds to the next step. (8) The history order (identifier arrangement order) is switched so that the identifier selected in step (2) is at the top of the identifier storage unit 5, and the process ends. (9) The program developer corrects this display program with the program content display / editing device 2, and proceeds to the next step. (10) The corrected program is stored in the file device 6 as history information (latest version), and the process proceeds to the next step. (11) The corrected program is converted into the execution format and replaced with the execution format of the module management unit 4, and the process proceeds to the next step. (12) The history order (identifier arrangement order) is switched so that the latest version of the identifier is at the top of the identifier storage unit 5, and the process ends.

To set a state in which the debug print routine or the like is excluded from the program, the old program used when the debug print routine or the like is inserted is set to the file device 6 based on its identifier. There is a method of manually removing this debug print routine, etc., and the present invention is premised on using the former. However, when the latter is used by the program developer, the above step (9 ) ~ (12) will be performed.

Further, the processing procedure for newly creating a program, that is, for creating the first edition is as follows. -Create a program (text format) on the program content display / editing device 2-Store this program in the file device 6 as history information (latest version) -Convert this stored program to the execution format and manage the module 4. Store this stored program identifier in the module management unit 4.

[0044]

As described above, according to the present invention, the modified version is stored in the file device only when the substantial modification of the development program or the formal modification of the debug print routine is made, and the old version is stored. Since the same tool as the latest version, that is, the module management unit that manages the identifier of each version, can be taken out from the file device, the usage efficiency of the file device can be improved and any program history information (old version and latest version) can be retrieved. It is possible to improve the convenience of taking out.

Further, since the top address of the storage area of each version is used as the identifier and the identifier is displayed in the order of creation of each corresponding version, the program developer can change the identifier It is possible to specify an arbitrary version on the basis of how many times it has been corrected while checking the arrangement order of the displayed identifiers without having to pay particular attention to the setting.

In addition to the identifier of each version, its execution format is also held in the module management unit, so that the processing time for running a program of a certain version and verifying its contents is dependent on the execution format. It will be shortened by the conversion amount.

[Brief description of drawings]

FIG. 1 is a basic configuration diagram of the present invention.

FIG. 2 is an explanatory diagram showing an outline when the program history information used for the next correction work of the present invention is taken out from the file device.

FIG. 3 is an explanatory diagram showing an embodiment of a module management unit of the present invention.

FIG. 4 is an explanatory diagram showing a procedure of examining program history information stored in a file device according to the present invention.

FIG. 5 is an explanatory diagram showing an outline of conventional program history information management.

[Explanation of symbols]

 In FIG. 1, 1 ... Module name display / selection device 2 ... Program content display / editing device 3 ... Identifier list display / selection device 4 ... Module management unit 5 ... Identifier storage unit 6. ..File devices

Claims (6)

[Claims] 1. The contents of each version up to that point regarding the modification of the program in module units are stored in a file device,
A program revision history management method capable of retrieving a program of an arbitrary edition that is the next revision target from each edition, wherein each of the identifiers corresponding to each edition is managed in the module unit. , All the identifiers belonging to the module unit to be modified are displayed, and one corresponding to the modification target version is selected from among the identifiers, and the program of the arbitrary version is selected from the file device based on the selected identifier. A program modification history management method characterized by extracting. 2. The program revision history management method according to claim 1, wherein the management of the identifier is performed in such a manner that each of the identifiers is displayed in the order of creation of the respective versions. 3. The program revision history management method according to claim 1, wherein when the identifier is managed, an execution format of the program of each version is also held. 4. A file device that stores the contents of each version up to that point regarding the modification of a program in module units, a module management unit that holds each of the identifiers corresponding to each version in module units, and a modification target. An identifier list display / selection device that displays all the identifiers belonging to the module unit and selects the one corresponding to the revision target version from among the identifiers, and the revision target is based on the selected identifier. A program revision history management device, characterized in that a version program is retrieved from the file device. 5. The program revision history management apparatus according to claim 4, wherein the module management unit displays each of the identifiers in the order of creation of the respective versions during the holding. 6. The program correction history management device according to claim 4, wherein the module management unit also stores the execution format of the program of each version.