JPH03250326A - Automatic extracting system for design specification of hierarchical data base - Google Patents

Abstract

PURPOSE:To automatically extract the design specifications used for a specific project with common use of a data base by using a hierarchical data base for extraction of the design specifications. CONSTITUTION:A hierarchical data base 10 stores the design specifications corresponding to all projects which use an verification system. Then the design specifications containing the desired number of editions to be extracted are extracted out of a data base 101 for higher rank hierarchies. Meanwhile the design specifications corresponding a due project are extracted out of a data base 102 for lower rank hierarchies. If the design specifications of a lower rank hierarchy to be included in the base 102 are contained in the base 101. These specifications are extracted for acquisition of the conversion origin design specifications 14. Thus it is possible to use the data base 10 in common and also to automatically extract the design specifications to be used by a specific project.

Description

[Detailed Description of the Invention] [Summary] Regarding a method for automatically extracting design specifications from a hierarchical database, the present invention provides a method that can standardize a database that stores design specifications and automatically extract design specifications used in a specific project from the database. We have created a hierarchical database that is managed as an upper layer database and a lower layer database in which program design specifications are assigned a version number, and the design specifications are assigned a specific specified version number from the upper layer database. and a design specification that determines whether a design specification of the same type as the extracted design specification is included in the lower layer database, and outputs the extracted design specification if it is not included. Comprising a comparison unit, and a design specification output unit that extracts all design specifications from a lower layer database and outputs the design specifications output from the design specification comparison unit as design specifications to be converted into a knowledge base. Configure it like this.

[Industrial Field of Application] The present invention relates to a method for automatically extracting design specifications from a hierarchical database, and relates to a method for automatically extracting necessary design specifications when the design specifications of an exchange program are configured and managed using a hierarchical database. .

When designing a switching program, a method is used in which the content is automatically verified using a knowledge base, but in this case it is not verified whether the designed program violates the design specifications used. Ru. To do this, it is necessary to create a knowledge base of design specifications corresponding to the designed program and supply it to the verification system.

However, many customers have different design specifications, and in the past, these design specifications were managed individually, making it difficult to improve storage capacity and management. desired.

[Prior Art] FIG. 5 shows an example of a design specification and a knowledge base. FIG. 9 is an explanatory diagram of a conventional example.

A5 in FIG. 9 is a block diagram of the exchange program verification system, and B is a diagram showing how the program design is changed.

Exchange programs are generally created by combining program parts called task macros. Many types of task macros are available.

Each calling format and parameters are defined in advance as design specifications before the program is created.

A specific example will be explained with reference to Figure 5 A. In this example, “%
The design specifications of a task macro called ABCDEJ are shown,
This calling format is defined as "%ABCDEA, BJ, where rA and BJ represent parameters used in the program. In this design specification, each parameter is defined, and for parameter rA",
Either "5ENDJ or rRECJ can be specified, and for B, either r rORcJ or rNRC" can be specified. In addition.

rSEND, , rREcj, etc. represent the operation or status of the device.

When developing a program by combining program parts with such design specifications, tests were conducted to ensure that the program was error-free.

The testing process required a lot of man-hours. In order to streamline this process, it has become possible to use a verification system that supports program verification using AI technology.

To explain the configuration of the verification system with reference to FIG. 9A, a design specification with the content "X" for a large number of task macros is provided as a database 61, and a program 62 with the content χl is created using the design specification. In this case, the verification system 6 checks whether there are any errors in this program X1.
Check by 3. This verification system 63 automatically detects errors by checking whether the program is created according to the design specifications (such as whether it uses a task macro other than the specified ones or specified parameters). It is something to do.

In this verification system, the verification is performed using the knowledge base 65. This knowledge base 65 is converted into a knowledge base by the knowledge base conversion unit 64 based on the design specifications xi of the program 62 to be verified.

An example of the knowledge of the knowledge base is shown in Fig. 5, and this example represents the design specifications in Fig.
This is an example.

Exchange programs like this are often changed based on requests from each customer and subsequent improvements.

Design specifications are determined accordingly, a program is created (including modifications) based on the design specifications, and the program is verified for errors.

The development of exchange programs is carried out in separate projects for each customer according to their requests, and subsequent improvements are also made individually.
As shown in Figure 5, the design specifications for each customer were managed completely independently. That is, the program for customer A and the program for customer B have separate design specifications necessary for verifying them. In this case, the design specifications for each customer are updated as a database, but at the same time, multiple versions of the design specifications are saved in correspondence with improvements, and the details of each improvement are displayed by version number.

[Problem to be Solved by the Invention] According to the conventional method described above, when a program for each customer is improved2, in order to verify the program with a verification system, a database storing each individual design specification is required. It is necessary to create a design specification that includes the newly added (or deleted) functions to the database, convert that design specification (conversion source design specification) into a knowledge base, and perform verification.

However, with conventional methods, design specifications are managed for each individual project (customer).

Even though they include common specifications, each of them needs to be stored in a storage device and searched for, resulting in a problem that the amount of memory used is large.

Also, when updating design specifications in a project, when searching for the design specification you want to update from the original design specification database, you may notice that the new version is stored due to a previous update, and at the same time the old version is stored. The problem is that the search takes time because the design specifications (older versions) that are not subject to update in that project are also included in the search.

SUMMARY OF THE INVENTION An object of the present invention is to share a database that stores design specifications and to provide a method that can automatically extract design specifications used in a specific project from the database.

[Means for solving the problem] Fig. 1(a) is a first principle configuration diagram of the present invention, Fig. 1 et al.)
is a second principle configuration diagram.

In FIG. 1(a), 10 is a hierarchical database consisting of an upper layer database 101 that stores common design specifications and a plurality of lower layer databases 102 that store design specifications specific to each project; A specific version extraction unit 12 extracts the design specifications of a specific version, and 12 compares the extraction output from the specific version extraction unit 11 with the contents of the lower layer database, and if they do not match, selects the output of the specific version extraction unit 1. A design specification comparison section 13 is a design specification output section that extracts and outputs the output of the design specification comparison section 12 and the extracted output from the lower layer database, and 14 is a knowledge base in which the design specifications output from the design specification output section are stored. Represents the source design specification to be converted.

The first configuration of the present invention is to provide a hierarchical database that stores design specifications for all projects that use the verification system, extract the design specifications assigned the desired version number from the upper-level database, and extract the design specifications from the lower-level database. The design specifications corresponding to the project are extracted from the database, and if there are design specifications included in the lower layer database in the upper layer database, those in the lower layer are selected to obtain the conversion source design specifications.

In the second principle configuration of the present invention shown in Fig. 1 et al.
0 is the upper layer database 7 that stores common design specifications
01 and a plurality of lower layer databases 702 storing design specifications specific to each project; 71 is a specification database for determining the type of design specification that exists in the upper layer database but does not exist in the lower layer database; A design specification type extraction unit 72 is a specific common design specification extraction unit that extracts a specific version of the design specification regarding the design specification type bone obtained from the specific design specification type extraction unit 71.

73 is a design specification output unit that extracts and outputs the output of the specific common design specification extraction unit 72 and the extraction output from the lower layer database; 74 is a design specification output unit where the design specifications output from the design specification output unit are stored and converted into a knowledge base; represents the source design specification.

The second principle configuration of the present invention is to provide a hierarchical database that stores design specifications for all projects that use the verification system, and to store design specification types that exist in the upper layer database but not in the lower layer database. seek,
The design specification to which the version number to be extracted within this range is assigned is extracted from the upper layer database, and all the lower layer databases are extracted to obtain the conversion source design specification.

[Effect] The operation of the first principle configuration will be explained.

In FIG. 1(a), first, the version number to be used in the target project is specified in the specific version extraction unit 11, and the design specification to which the specified version number has been assigned is extracted from the upper layer database of the hierarchical database 10. Extract. Next, the design specification comparison unit 12 compares the design specifications of the specific lower layer database 102 corresponding to the specified project with the design specifications extracted from the specific version extraction unit 11, and detects design specifications of the same type. In this case, the design specifications corresponding to the project are given priority, so the design specifications extracted from the upper layer database are excluded (they are not output from the design specification comparison section).

The design specification output unit 13 outputs the design specifications not excluded by the design specification comparison unit 12 and the design specifications in the lower layer database corresponding to the project as design specifications to be converted into a knowledge base.

Next, the operation of the second principle configuration will be explained.

In FIG. 1, the specific design specification type extraction unit 71 first obtains the design specification types that exist in the five upper layer databases but do not exist in the lower layer databases. Next, specify the version number to be used in the target project to the specific common design specification extraction unit 72, and select the version number from the upper layer database within the range of the design specification type obtained by the specific design specification type extraction unit 71. Extract the design specifications given.

The design specification output unit 73 includes the specific common design specification extraction unit 7
The design specifications extracted in step 2 and the design specifications in the lower layer database corresponding to the project are output as the design specifications to be converted from the knowledge base.

With this operation, design specifications used in a specific project can be automatically extracted from a single-layer database.

[Example] Figures 2 to 4 show Example 1 corresponding to the first principle configuration of the present invention; Figure 2 is a configuration diagram of Example 1;
The figure shows a hierarchical database that stores design specifications. FIG. 4 is a processing flow of the specific version number extraction section. 6 to 8 show a second embodiment corresponding to the second principle configuration of the present invention, FIG. 6 is a configuration diagram of the second embodiment, and FIG. 7 is a specific design specification type extraction section. FIG. 8 is a processing flow of the specific common design specification extraction section.

First, the configuration and operation of the first embodiment will be explained.

In Fig. 2, 20 to 24 are l of the principle configuration of Fig. 1.
Corresponding to each part of O=14, 20 is a hierarchical database that stores design specifications, 21 is a specific version extraction section, 22 is a design specification comparison section, 23 is a design specification output section, and 24 is a conversion source design specification. .

To explain the inside of the specific version extraction unit 21, there are 1 version link selection unit 210 that selects a specific version from the hierarchical database 20, 1 common design specification extraction unit 211 that extracts the common design specifications of the selected version, and Common design specification extraction unit 211
and a temporary storage section 212 that stores the design specifications extracted.

The configuration of the hierarchical database 20 shown in FIG. 2 will be explained in FIG. 3.

In FIG. 3, 31 is a common database directory for searching the type of common design specification (task macro), 32 is a version link for searching the version of common design specification from the common database directory, and 33 is a common design specification, 34 is a configuration link that creates a hierarchical relationship between the common database and the project database, and 35 is a project-compatible database directory for searching for the type of design specification compatible with the project (the figure shows the database directory corresponding to the α project to the database directory corresponding to the β project). database directory is shown), 36
represents the project-enabled design specification.

As shown in FIG. 3, the common database directory 31
Each task macro has a version link corresponding to one version, but there are cases where design specifications corresponding to the version are provided for the same type of task macro, or when there are multiple versions. There are various cases, such as cases where one design specification is provided for each.

In order to use the verification system in β project 35 (lower right side of Figure 3) when the hierarchical database is the third one, the operation of automatically extracting the design specifications necessary for this project will be explained.

- The specific version number extraction unit 21 extracts the design specifications of the 10th version as the version number required for the β project from the common database according to the operation flow shown in FIG.

That is, in Figure 4, one task macro is extracted from the common database directory (31 in Figure 3) (40 in Figure 4), and the version link with the version specified on the project side is first selected. (41 in Figure 4). Next, extract the common design specification of the selected link destination and store it in the temporary storage section (212 in FIG. 2) (42 in FIG. 4), and determine whether there is an unprocessed task macro (43) in FIG. If so, the next task macro is extracted from the common database directory and the same process is executed.

By the operation of this specific version number extraction unit, the 5th order design specification group Ul
is stored in the temporary storage section 2]2.

C1= (A2.Bl, CI, D2...) In addition, A2
is "%A, A2J, Bl is "%B.

This is an abbreviation of BIJ, and the same applies to the others.

(2) The design specification comparison unit 22 determines, for each Ul stored in the -time storage unit 212, whether a design specification of the same type as these exists in the β project correspondence database. In this example, design specifications B1 and Dl
Since the same type of design specifications exist in the beta project compatible database, exclude these from Ul,
If the result is C2, it becomes quadratic.

C2= (A2.CI...) ■Next, the design specification output unit 23 extracts the design specification group U3 from the β project database.

U3-(BB, DD) Subsequently, U, which is the sum of the above U2 and U3, is output.

U-fA2. BB, C1, DD, . . .) This output U is output as the conversion source design specification 24 as a design specification necessary for the β project.

Next, the configuration and operation of the second embodiment will be explained using FIGS. 6 to 8.

In FIG. 6, 80 to 84 are the second
80 is a hierarchical database for storing design specifications, 81 is a specific design specification type extraction unit, 82 is a specific common design specification extraction unit, 83 is a design specification output unit, 84 represents the source design specification.

To explain the inside of the specific design specification type extraction unit 81, there is a design specification type comparison unit 810 that calculates a design specification type that exists in the common database but does not exist in the project-compatible database, and a design specification output unit that temporarily saves this design specification type extraction unit. It is composed of a design specification type storage section 811.

To explain the inside of the specific common design specification extraction unit 82, there is a version link selection unit 820 that selects a specific version number from the hierarchical data hese 80 within the range of design specification types stored in the design specification type storage unit, and a version link selection unit 820 that selects a specific version number from the hierarchical data hese 80. The common design specification extraction section 821 extracts the common design specifications of the selected version number, and the common design specification storage section 822 stores the design specifications extracted by the common design specification extraction section 821.

The structure of the hierarchical database 80 shown in FIG. 6 is as follows.

Same as Figure 3.

In order to use the verification system in the β project 35 (lower right side of FIG. 3) when the hierarchical database is as shown in FIG. 3, the operation of automatically extracting the design specifications necessary for this project will be explained.

(2) The specific design specification type extraction unit 81 obtains the design specification types that exist in the common database but not in the β project corresponding database using the operation flow shown in FIG.

That is, in FIG. 7, one task macro is extracted (90 in FIG. 7) from the common database directory (31 in FIG. 3), and it is determined whether it exists in the directory of the β project compatible database (
91 in Figure 7). Only if it does not exist, store the task macro name in the design specification type storage section (92 in Figure 7).
, determine whether there is an unprocessed task macro or not.
).

If so, the next task macro is extracted from the common database directory and the same process is executed.

As a result of the operation of the specific design specification type extraction unit, the design specification type base (1) to be extracted from the common database regarding the β project is stored in the design specification type storage unit 811.

■1=(%A2%C9...) ■The specific common design specification extraction unit 82 extracts a specific version number from the hierarchical database 80 within the range of the design specification type stored in the design specification type storage unit. The design specifications are extracted according to the operation flow shown in FIG.

That is, in FIG. 8, one task macro type name is extracted from the design specification type storage section (100 in FIG. 8).
, First, a version link having the version number (10th version) specified on the β project side is selected from the common data base (101 in FIG. 8). Next, extract the common design specifications of the selected link destination and store them in the common design specifications storage section 822.
2).

It is determined whether there is an unprocessed task macro (103) in FIG. 8), and if so, the next task macro type name is retrieved from the design specification type storage section and the same process is executed.

As a result of the operation of this specific common design specification extraction section, the next design specification group (2) is stored in the common design specification storage section 822.

V2-+A2. CI, ...) ■Next, the design specification output unit 83 extracts the design specification group ■3 from the β project database.

V3- (BB, DD+ Subsequently, ``■'', which is a combination of ``2'' and ``3'' above, is output.

V= +A2. BB, C1, DD, . . . ) This output is output as the conversion source design specification 84 as the design specification necessary for the β project.

[Effects of the Invention] According to the present invention, by extracting design specifications using a hierarchical data cache, memory usage is reduced compared to the conventional method of managing design specifications completely independently between projects. This solves the problem of the conventional method that it takes a long time to search when updating design specifications.

[Brief explanation of drawings]

FIG. 1(a) is the first principle configuration diagram of the present invention, FIG. 1(b)
) is the second principle configuration diagram of the present invention, FIG. 2 is the configuration diagram of the first embodiment, FIG. 3 is a hierarchical database that stores design specifications, FIG. 4 is the processing flow of the specific version extraction unit, and FIG. Figure 5 is a diagram showing an example of design specifications and knowledge base, Figure 6 is a configuration diagram of the second embodiment, Figure 7 is a processing flow of the specific design specification type extraction unit,
FIG. 8 is a processing flow of the specific common design specification extraction section, and FIG. 9 is an explanatory diagram of a conventional example. 10.7 (1-layer data hese 101, 701: upper layer data hese 102.702: lower layer database 11: specific version number extraction section 12: design specification comparison section 13 in Fig. 1(a) and Fig. 1(b) : Design specification output unit 14; Conversion source design specification 71; Specific design specification type extraction unit 72: Specific common design specification extraction unit 73: Design specification output unit 74: Conversion source design specification

Claims (2)

[Claims] (1) A hierarchical database (10) is provided in which the program design specifications are managed as an upper layer database and a lower layer database to which version numbers are assigned, and a design in which a specific specified version number is assigned from the upper layer database. A specific version extraction unit (11) that extracts specifications, and determines whether a design specification of the same type as the extracted design specification is included in the lower layer database, and if it is not included, extracts the extracted design specification. Design specification comparison section to output (1
2), and a design specification output unit (13) that extracts all design specifications from the lower layer database and outputs the design specifications output from the design specification comparison unit as a source design specification (14) for conversion into a knowledge base. An automatic design specification extraction method for a hierarchical database, characterized by comprising: (2) A hierarchical database (70) is provided in which program design specifications are managed as an upper layer database and a lower layer database with version numbers assigned, and design specification types that do not exist in the lower layer database are obtained from the upper layer database. A specific design specification type extraction unit (71) and a specific common design specification extraction unit (71) that outputs a design specification to which a specific designated version number is assigned from the determined design specification type.
2), and a design specification output unit (74) that extracts all design specifications from the lower layer database and outputs the design specification output from the specific common design specification extraction unit as a source design specification (74) for conversion into a knowledge base. 73) A method for automatically extracting design specifications for a hierarchical database.