JPH09258964A - System for managing version of software - Google Patents

Abstract

PROBLEM TO BE SOLVED: To realize version management making used for forms by interfacing a form database and a version database and making them refer one another. SOLUTION: For newly inputting forms, a form input/display part 102 registers the forms in a form data base(DB) 105 by a form DB access part 103, and a version DB access part 104 accesses to version DB, recognizes a version where a former version is defined from various versions of a designated module and takes it out from a work file. The version of the module which is taken out is registered to the slip as the former version by the form DB access pat 103. A person in charge of development corrects an objective module and indicates the storage of the corrected module from a form input screen. The form input/display part 102 stores the objective module in version DB 106 from a work file 107 and registers the new version of the stored module in the form DB 105.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software version management system, and more particularly to a method for facilitating management of a software version corresponding to a document in which software changes are described.

[0002]

2. Description of the Related Art Conventionally, in software version management, target software is stored in a DB in version units by dedicated version management software. In addition, the contents of the change are different from the above (DB) for the purpose of development management (examination of the contents of the change, grasping the occurrence status of defects, etc.).
Was managed as.

[0003]

In the above prior art,
Since the correspondence between the software version and the form (change content) is managed as a separate DB, the modules related to a specific change are identified and the modules (versions) related to a plurality of change contents are extracted to create a single database. When constructing a program, the version management work was complicated because the contents of the change and the version were manually handled.

[0004]

In order to achieve the above object, according to the present invention, an interface is provided between a form DB and a version DB, and the system is provided with a function of referring to each other in synchronization with each other to change software, Registration of·
Each time it is updated, both DBs are updated at the same time, the consistency between the DBs is guaranteed, and version management mainly based on the form is enabled.

[0005]

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, an embodiment of the present invention will be specifically described with reference to the drawings. Incidentally, the operation of fetching one version from the version DB as a work file is "GET", version DB
The operation to store in is called "PUT", and the operation of giving a different name to each version is distinguished from the version by "label".
Call and explain.

A "module" is defined as a file that realizes a partial function of software, a "program" is defined as a file created by linking (linking) modules, and a "system" is defined as a set of programs.

FIG. 1 shows a block diagram of the present invention. Reference numeral 101 denotes a version management system that systemizes the present invention,
Form input / display unit (102), form DB access unit (1
03) and a version DB access unit (107). In addition, 105 is a form D in which the form is converted into a DB for each case.
B and 106 are version DBs in which modules and programs are stored in each version unit, and 107 is a GET from the version DB when changing modules or constructing programs.
Indicates a work file for / PUT.

The form input / display unit (102) has a function of inputting and displaying each form, a function of searching a plurality of forms according to various conditions and displaying them in a list format, and selecting and grouping the displayed forms. Function, form DB access part (1
03) and the version DB access unit (107).

The form DB access unit (103) has a function of reading and writing form data from the form DB in accordance with instructions from the form input / display unit (102).

The version DB access unit (107) follows the instruction from the form input / display unit (102) to display the version D.
It has a function of GET / PUT a target version of a module or program from B as a work file.

The contents of processing when operating the module will be described below with reference to FIGS. 2, 3, and 4.

It is assumed that the version DB stores in advance the old versions of programs and modules by the present system, and the label "old version of system" is defined in all files.

First, in order to input a new form, the version management system is activated and the form input screen is displayed. The system name and version in which the problem has occurred, the program name, the module name, the changed contents, and the work directory for GET are specified, and GET execution is instructed. (201).

The form input / display unit activates the form DB access unit, registers the form in the form DB (202), and then activates the version DB access unit to GET the specified version of the specified module from the version DB ( 20
3).

At this time, the version DB access unit accesses the version DB and recognizes the defined version of the old version (label) of the system from the various versions (301) of the specified module (30
2) G as a work file in the work directory
ET (303). Further, the version of the GET module is registered as an old version of the module in the form by the form DB access unit (304).

The person in charge of development corrects the target module (compiles and links with a development tool as necessary to test), specifies the corrected module again from the form input screen, and gives an instruction to execute PUT (205).

The form input / display unit activates the version DB access unit and PUTs the target module from the work directory to the version DB (206, 401). Further, the form DB access unit is activated to register the new version of the PUT module in the form DB (207, 40).
2).

Next, processing contents at the time of program construction and system definition will be described with reference to FIGS. 5, 6 and 7.

The version management system is started, and the forms for which the countermeasures for the modules have been completed are searched for and displayed as a list. From the displayed forms, select and group the forms that build the new version of the program, and get the countermeasure version of the module included in the selected form.
The execution is instructed (501).

The form input / display unit activates the form DB access unit, acquires the countermeasure version of the module to be GET from the selected form (502, 601), and stores the countermeasure version of the target module in the work directory from the version DB. GET (503, 602).

A person in charge of development compiles and links the target module with a development tool to build a program.
Again, specify the program from the form list display screen, PU
T execution is instructed (504, 603).

The form input / display unit activates the version DB access unit and PUTs the target program from the work directory to the version DB (505 and 604). In addition, the form DB access unit is activated to register the new version of the PUT program in the form (506, 60).
5).

Finally, again, the new version of the system is designated from the form list display screen, and the system definition is instructed (507).

The form input / display unit activates the version DB access unit to display the new version of the specified system.
A label is defined for the target version of the program or module included in the selected form (508, 701). In addition, the form DB access unit is activated and the selected form is
Register the new version of the system (509, 70
1).

At this time, for all programs and modules in the version DB that are not described in the selected form, the old version is labeled with the new version after the countermeasure.

[0026]

As described above, according to the present invention,
It is possible to manage the form that describes the software changes and the software version by matching, identify the module-modified version based on the form, and build a program by selecting multiple forms, version management To facilitate.

[Brief description of drawings]

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

FIG. 2 is a schematic flow when operating a module.

FIG. 3 is a schematic diagram of module operation (GET).

FIG. 4 is a schematic diagram of module operation (PUT).

FIG. 5 is a schematic flow of building a program and a system.

FIG. 6 is a schematic diagram when a program is constructed.

FIG. 7 is a schematic diagram when the system is constructed.

[Explanation of symbols]

101 ... Version management system, 102 ... Form input /
Display unit 103 ... Form DB access unit 104 ... Version DB access unit 105 ... Form DB
106 ... Version DB, 107 ... Work file.

Claims (1)

[Claims] (1) A form (electronic DB (database)) describing the contents of a program change and a source to which a version (generation) for each change is added for each program and a module constituting the program are stored. A "software version management method" that enables synchronous creation by allowing both DBs to interface with each other and refer to each other. (2) Due to the feature of item (1), it is easy to wash out the module related to the specific change, and the similar change work can be executed without omission. (3) By utilizing the feature of item (1), a series of change items are grouped and designated to extract a relation change module and enable the construction of a program.