JPH02181224A - Software development system - Google Patents

Abstract

PURPOSE:To secure the consistency of information, and also, to improve the efficiency of a maintenance work by providing a bidirectional filter having a function as an information extracting part and a reverse generating part, and storing the information so as not to be overlapped. CONSTITUTION:Specifications 10 of each module and source programs 11 of each module are stored as program information or specification information in an integrated data base 13 through a bidirectional filter 12 which operates as an information extracting part. Subsequently, the information stored in the data base 13 is reconstituted to specifications or source programs of each module through the filter 12 which operates as a reverse generating part, as well, and outputted in a shape of an editable text file. In such a way, it becomes unnecessary to mention redundantly program information, and information overlapped between the modules or in the module, the work efficiency is improved, and also, the consistency of data is secured automatically, and a maintenance work is executed efficiently.

Description

DETAILED DESCRIPTION OF THE INVENTION <Industrial Application Field> The present invention relates to a system for efficiently developing programs written in C language or the like.

<Prior Art> In developing a software system, the work is usually progressed by sequentially executing each phase shown in FIG. In other words, first determine the required specifications of the system.
Next, a specification is created in accordance with this required specification, and a rough design and detailed design are performed in accordance with this specification. Next, we perform coding according to these rough and detailed designs to create the actual software. Once the coding is completed, each subsystem is debugged, and once the debugging is completed, a comprehensive test is performed and the project is completed. This kind of procedure is called a waterfall model. Various documents are output in each phase of system creation, and the work of the next phase is executed based on these documents.

Furthermore, text files such as detailed design documents and source programs are stored in large file units, such as compilation units, that have semantically and formally complex content.

<Problems to be solved by the invention> However, there were the following problems in developing such a system. First, the information on the documents that are output becomes more detailed and increases in amount as it goes downstream. Furthermore, since each phase requires the description of the entire software system, although the format of the document changes, there are many overlapping contents. Therefore, if a change is required in the upstream phase, such as when an error is discovered in the upstream phase while executing the downstream phase,
Since all documents that have already been output had to be changed, work efficiency was low and human errors were likely to occur.

Second, because the same development procedure was used for large-scale systems and small-scale systems, there was a lot of waste in small-scale systems, and in large-scale systems, discrepancies in information could occur within the same phase. Ta.

Third, when syntactic analysis of text 1 is required, such as during compilation or static analysis, the entire file must be analyzed even for small changes, and even if there are common software components, their identification is difficult. It was difficult. Therefore, they were forced to perform duplicate work, reducing reliability.

Such issues also arise between two consecutive phases, such as the detailed design stage and the coding stage. In other words, global data, etc. are duplicated between the module specification and the source program, and declarations of function names, addition of comments, etc. are duplicated even within a single source program, resulting in poor work efficiency and the possibility of human error. It was highly sexual.

<Object of the invention> The object of the invention is to provide a software development system that can guarantee the integrity of information by storing information in a manner that prevents duplication. > In order to solve the above problems, the present invention inputs a program or module specification in a predetermined format using an editor, extracts program information or specification information from the input program or module specification using an information extraction section, and extracts the information. are stored in the database to avoid duplication. Further, a module specification and a source program are constructed and outputted from the information stored in this database by a reverse generation section.

<Example> Fig. 1 shows the basic concept of the software development system according to the present invention.
Suppose that it is composed of B, C1, . . . In FIG. 1, reference numeral 10 indicates the specifications of each module, and reference numeral 11 indicates the source program of each module. These specifications and source programs are transferred to the integrated database 13 as program information via a bidirectional filter 12 that functions as an information extractor. Or stored as specification information. For example, global variables are described in different formats, such as the data type, contents, etc. being described descriptively in the module specifications, and described in a format according to the language specifications or as comments in the source program. The omitted information is stored in the integrated database 13. The integrated database 13 includes at least one module, and stores programs that operate as one process or task and related information in a non-duplicate manner. The information stored in this integrated database 13 is reconfigured into specifications or source programs for each module by a bidirectional filter 12 that functions as a reverse generator, and output in the form of an editable text file.

Program information is a component of a program, and is a collection of names and attributes of module functions, global variables, etc., and relationship information with other components.

FIG. 2 shows the hierarchical relationship of the constituent elements of program information as a network. There is a system at the top level, and below that there are multiple files, and these files store modules.

Each module is attached with lower modules, global data, and functions are defined. In such a configuration, a function 31 defined in a certain module 30 may refer to a module 32 in another file. Therefore, along with attributes such as names as constituent elements,
It is necessary to include relationship information between components such as definitions and references. Note that components have multiple IMNJ configurations such as variables, functions, parameters defined within functions, and local variables.For example, global data, which is one of the components, is divided into classes of attributes and relational information. The attribute class includes data items such as data type, content, initial value, and size, and the relationship information class includes data items such as location of definition, reference function, change function, and extern specification. This global data forms an information unit that is always handled collectively within the database. Furthermore, components shared between files have a similar configuration. This kind of relationship is the same for specification information.

Figure 3 explains the procedure for extracting necessary information from the module specification or source program, storing it in the integrated database, and inversely generating the module specification or source program from the data stored in Manako's integrated database. . Detailed 1Sill for detailed module design
Design designer 14 is module specification frame editor 1
5 to create module specifications. This module specification frame editor 15 is a tool for creating and editing module specifications, and fixed-form parts are set in advance. The detailed design designer 14 can create a module specification by writing necessary data into the root 1. The module specifications created in this way are easy to read and highly reliable. 16 is the created module specification;
The information is divided into format information set in advance and specification information input by the detailed design designer 14. 17
is a specification information extraction tool, which extracts specification information from the created module specifications 16 and creates an integrated database 1.
Store in 3. As mentioned above, Formatsu 1-fil
Since it is determined in advance, it becomes possible to extract specification information. Reference numeral 18 denotes a module specification reverse generation tool, which generates and outputs the module specification 16 from the specifications and information stored in the integrated database 13. In this case as well, since the format 1 to information is predetermined, the module specification 16 can be generated only from the specification information. The same is true for programs, when the programmer 19 creates a source program 21 using the source program frame editor 20 in which format information is set in advance, the program information extraction tool 2
2 extracts program information from the created source program 21 and stores it in the integrated database 13. Further, the source program reverse generation tool 23 adds format information to the program information stored in the integrated database 13, reconstructs the source program 21, and outputs the reconstructed source program 21. Therefore, all information is stored in the integrated database 13 and there is no need to have text i-files. In this embodiment, a module specification frame editor 15, a specification information extraction tool 17, a module specification reverse generation tool 1
8 or a source program frame editor 20, a program information extraction tool 22, and a source program reverse generation tool 23 constitute a bidirectional filter 12.

Next, a specific example of creating a module specification and a source program will be explained based on FIGS. 4, 5, and 6 in accordance with the flow of waterfall type development. Note that FIG. 5 is an example of argument information of the main function of the C language. In FIG. 4, a detailed design designer creates a module specification document 16 using a module specification frame editor 15.

The specification information of this module specification 16 is extracted by a specification information extraction tool 17 and stored in the integrated database 13. 24 in FIG. 5 is a part of the module specification created in this way, and 25 is the integrated database 1.
After writing all the module specifications indicating the data stored in the integrated database 13, the source program inverse generation tool 23 outputs the source program of the detailed designed part from the data stored in the integrated database 13.

In this case, information that becomes clear at the coding stage, such as code information, is left blank. Reference numeral 26 in FIG. 5 shows the source program reversely generated in this manner. Next, the source program frame editor 20 supplements and updates the code information and the like of the reversely generated source program. The updated program information of the source program is extracted and stored in the integrated database 13. Furthermore, the module specification 16 is inversely generated from the stored data by the module specification inverse generation tool 18. In this way, the specification information of the created module specification and the program information of the source program are stored in the same format in the integrated database, and the module specification and source program are reversely generated using the data stored in this integrated database. and update this.

Therefore, if either the module specification or the source program is changed, the contents of the integrated database 13 will be changed.
If the other is reversely generated based on the data stored in this integrated database 13, changes in one will be automatically reflected in the other. The same applies to FIG. 6, where 33 is a detailed design document, 34 is the content of the integrated database 13, and 35 is a source program. Codes in the detailed design document 33, integrated database 34, and source program 35 represent corresponding parts. In other words, only the necessary information of detailed design document 33 and source program 35 is integrated into database 1.
3, and then reconstructed from this stored content.

Although this embodiment shows an example based on the waterfall model, it is also applicable to a case where a development method not based on the waterfall model is adopted, such as creating a module specification after coding/debugging.

Furthermore, even when using global data shared between modules, consistency of information between modules and modules can be ensured. That is, in FIG. 7, it is assumed that the specification 27 of module A includes functions P and Q, and function P refers to global data defined in the source program 28 of module C. In this case as well, the specifications 27 of module A and the specification information and program information of the source program 28 of module C are stored in the integrated database [3], and the source program 29 of module A is generated from the information in this integrated database 13. Therefore, the consistency of global data can be ensured.

In addition, in this example, we have explained the process of creating a source program based on the module specifications created in the detailed design and updating this source program. The integrity of the information in the document and the source program can be guaranteed.

Furthermore, in the embodiment shown in FIG. 3, a module specification frame editor 15, a specification information extraction tool 17, a module specification reverse generation tool 18, a source program frame editor 20, a program information extraction tool 22, a source program reverse generation tool Although the bidirectional filter 12 is configured with 23, it may be configured to access the direct combined database 13.

<Effects of the Invention> As specifically explained above based on the embodiments, the present invention stores information manually created by an editor in an integrated database in a form without duplication, and reconstructs it using a reverse generation tool. I made it. Therefore, it is no longer necessary to repeatedly write program information and information that overlaps between modules or within a module, which has the effect of improving work efficiency.

Furthermore, when one part is changed, the change is reflected in the song part, so there is also the effect that data consistency can be automatically maintained r4.

Furthermore, even when coding is performed from the initial stage for prototypes or small-scale development, module specifications can be automatically generated later, which has the effect of streamlining maintenance work.

[Brief explanation of the drawing]

FIG. 1 is a configuration diagram showing an embodiment of the software development system according to the present invention, FIG. 2 is a network diagram showing the hierarchical relationship of the components of program information, FIG. 3 is a diagram showing the specific configuration, 4 to 7 are diagrams for explaining the operation, and FIG. 8 is a flowchart showing the procedure for developing the software system. 10... Module specification, 11... Source program, 12... Bidirectional filter, 13... Integrated database, 15... Module specification frame editor, 17... Specification information extraction tool, 18. ... Module specification reverse generation tool, 20... Source program frame editor, 22... Program information extraction tool,
23... Source program reverse generation tool.

Claims (1)

[Claims] an editor for inputting program or module specifications; an information extraction section for extracting program information or specification information from the program or module specifications input by the editor; a database for storing the extracted information; and a reverse generation unit that configures and outputs a module specification and a source program from the stored information, and the information extraction unit stores the program information or specification information in a form that does not overlap in the database. A software development system featuring: