JPS6159549A - Method for forming software specification - Google Patents

Abstract

PURPOSE:To improve the quality of software demand specification by discovering errors of demand specification at the beginning of software development based on the performance of the demand specification describing system functions and carrying out modifications easily. CONSTITUTION:A test function 13 compares with a previously predicted result given in a test procession 14 after the output of an output talken, discriminates right or wrong of performance and outputs the discriminated result as a performance result 15. If it is impossible to continue the performance, the position of a talken at that time is preserved as a performance condition 16 and outputted as an error in the performance result 15. A test function 13 monitors an action of a performance function 11, the performed work row is registered in the performance condition 16 and the performed work name is left only when right output is obtained, and the process is left when wrong output is obtained. When the results of the test procession are entirely normal, the proportion of performed works is outputted, a user investigates the performance result 15 and selects errors for debug.

Description

[Detailed Description of the Invention] [Field of Application of the Invention] The present invention relates to a method for defining the functions of a system that is online, real-time, and distributed. This invention relates to a software specification formulation method that enables methods for detecting and correcting errors in software and validating software requirements.

[Background of the invention]

Requirements definition technology has been proposed as a means to improve the quality of system functions ("Software Engineering - Requirements Specification Technology J bit Extra Edition, 197g, Kyoritsu Publishing). Its characteristics are However, there are limits to the quality improvement due to the following points.

(1) Although it is easier to understand each part by representing it graphically, it is difficult to understand the relationship between each part and the movement of the entire system from input to output.

(2) Computer checks are being used but no one offers them, or the same thing is being used but the way it is used is different. Because it is a static analysis, for example, even if the system forgets to reduce the balance when it withdraws money from the account, the balance should be reduced by that amount, but the error cannot be detected. Such errors can be discovered immediately by actually running the system.

On the other hand, testing/debugging techniques for verifying programs already exist ("Software Testing Techniques JG
, J. Myars, 1980, Kindai Kagakusha, "Program Testing Device" (copy attached)) has the following problems.

(1) It is not possible to test the program until after it has been created.Therefore, if an error is found in the system's functionality during program testing, it will cost a lot of money to correct it.

(2) Although computers are fast, the functionality of the programming language is small and a large number of statements are executed, making it difficult to obtain information appropriate for investigating the cause of program errors.

The invention related to the present invention is an earlier application filed by the same applicant.

It has patent application No. 59-92870.

[Purpose of the invention]

An object of the present invention is to discover errors in the requirements specifications at an early stage of software development and correct them based on the execution of the requirements specifications that describe the functions of the system, in order to solve the drawbacks mentioned in the prior art described above. It can be done easily. The purpose of the present invention is to provide a method for forming software specifications.

[Summary of the invention]

In order to achieve the above object, the present invention provides a system flow diagram that describes the entire system using processes that represent system components and token strings that represent data exchange between processes, and a system flow diagram that describes the entire system using processes that represent system components and token strings that represent data exchange between the processes. Requirement specifications are written using a data flow diagram that describes the relationship between links that indicate flow locations and operations that indicate token conversion, and based on execution methods that convert tokens according to operational rules that determine how tokens flow. This is a method of testing/debugging.

The differences between the program testing/debugging method and the present invention are as follows.

(1) Since instructions change the contents of memory, a program cannot check the contents of memory at a certain point in time unless it traces the instructions that are executed sequentially or outputs the contents of memory.In the requirements specification, tokens are used for work. Since execution is triggered and the token disappears, just by tracking the movement of the token, you can check the order in which the work is executed and the contents of the token.

(2) Work can be further detailed as a function within one component using a data flow diagram. now.

Since the level of token abstraction is not specified, requirements specifications can be tested according to the level of functional detail.

[Embodiments of the invention]

The present invention will be explained in detail below with reference to Examples.

FIG. 1 is a block diagram of a software specification formation or verification method according to the present invention.

Reference numeral 11 denotes a requirement specification execution function that moves tokens on the requirement specification 12 described in a system flow diagram and a data flow diagram. The test function 13 gives the token indicated in the test procedure 14 to the execution function 11, outputs and judges the execution result 15, and determines the order of generation and disappearance of the tokens in the execution status 16.
Record as. The debug function 14 displays the flow of tokens by the execution function 11 as an operation in 18, and
Information 19 is output according to the instructions input from 8.

FIG. 2 shows the flow of data in the requirement specification execution function 11. Reference numeral 22 represents the requirement specifications using intermediate language data, a configuration table 23 lists the processes and functions that make up the system, and a logic table 24 describes the data flow of the processes and functions in relation to tasks and links. The name table 25 holds names of processes and functions. Work data 26
is used to store the state at the time of execution, and the instance table 27
holds the state of work and links, and the token table 281 holds the tokens.

FIG. 3 is a diagram showing the memory relationships at the start of execution, and FIG. 4 is a diagram showing the memory relationships during execution of the six function instances 4.
4 is generated every time it is executed and is released when the execution is finished. The token table 45 is created and deleted according to the generation and disappearance of tokens.

FIG. 5 is a flowchart showing the execution procedure.

FIG. 6 is a diagram showing an example of the configuration of a test procedure, in which several cases are collectively described for each system to be executed. Describe the actions to be taken when an abnormality is detected, such as when a token is lost or there are no executable tasks.

FIG. 7 is a flowchart showing the procedure of the debug function.

The test/debug method will be explained below with reference to FIG.

The test function 13 requests the execution function 11 to execute on the required specifications specified in the test procedure 14. Execution function 1
1 inquires of the test function 13 each time it is necessary to input a token and determine a condition for the token, and the test function 13 inputs a token or assigns a condition according to the test 1-procedure 14. The execution function 13 also notifies the test function 13 when the token reaches an output, when the token cannot be moved, or when an event not specified by the operation rules occurs. When the output token is issued, the test function 13 compares it with the expected result given in advance in the test procedure 14 to determine whether the execution is correct or not, and outputs the output token and the determination result as the execution result 15. Also, if execution cannot be continued, the token placement status at that time is saved as execution status 16, and the execution result 15 contains errors? Output. Test function 13 operates simultaneously with the above operations.

The operation of the execution function 11 is monitored, the executed work sequence is recorded in the execution status 16, and if a correct output is obtained, only the executed work name is left. If there is a mistake, leave it as is.

When one of the test procedures 14 is completed, the test function 13 extracts and executes the next test procedure.

When all test procedure execution results are normal, output the percentage of work performed. The user examines the execution results 15, selects errors, and debugs them.

The debug function 17 issues two types of execution commands, forward execution and backward execution, to the execution function 11.3 First, the debug function 17 issues the requirement specifications 12 to be executed to the execution function 11 according to instructions from the execution function 18, and the target test procedure. 14 will be announced.

Forward execution is performed as follows. The execution function 11 extracts inputs and conditions from the test procedure 14, proceeds with the execution of the work according to the operation rules, and informs the debug function 17 each time one work is executed.The debug function 17 uses the operation display device 18 to monitor the data flow. Display the work performed and the link where the token exists on the diagram. At the same time, according to instructions from 18, execution is interrupted, display is switched between a system flow diagram and a data flow diagram, and information 19 at the time of execution is output.

Perform backward execution as follows. First, executive function 11
is test procedure 1 from the execution status saved in 16.
Reproduce the token placement situation corresponding to 4. After that, when a token exists in the link (output link) where the work writes the token (output link), the token is extracted and the work is executed (
perform a backward execution), convert the token inversely, and write the token to the link where the work reads the token (input link). At this time, the backward execution of the work is performed in the reverse order of the execution status 16 saved at the time of test execution.

The embodiment described above has the following effects.

(1) By writing expected results in the test procedure in advance, the execution results can be automatically determined. When testing a program, it takes time to verify the execution results.
Moreover, even if an incorrect result is output, it is easy to miss it when a person is investigating it. Automation can improve efficiency and prevent oversights.

(2) The forward execution of the debug function displays the operation from input to output, allowing you to understand the dependencies between each component of the system and easily identify differences from the system image that the system user has. Can be discovered.

(3) In the case of software errors, the time when the wrong process is performed and the time when the error becomes apparent are different, so it generally takes time to find out where the real error is. However, according to the present invention, by using backward execution, execution is started from the point where an error has become apparent, and the work is executed in the opposite direction, so that the cause of the error can be easily identified.

〔Effect of the invention〕

By using the method of the present invention, the quality of the software requirements specification that describes the functionality of the system is improved. Errors in system functionality that were previously discovered after the program was created can be discovered and corrected at the requirements definition stage, so it takes less time to investigate and correct the causes of errors discovered at the program testing stage. There are no additional costs. Normally, this cost is much higher than the extra cost required for testing/debugging the required specifications, but according to the present invention, the development cost of the entire system can be significantly reduced.

Furthermore, since the system operation can be displayed at the stage of designing the system functions, it is possible to deepen the understanding of the system users. Therefore, it is possible to elicit specific opinions from users before creating the system, and the quality of the requirements specifications can be further improved6.

[Brief explanation of drawings]

FIG. 1 is a functional configuration diagram of the present invention, FIG. 2 is a diagram showing the data flow of the execution function of the present invention, and FIG. FIG. 4 shows memory relationships. FIG. 3 is a relational diagram showing the storage relationship at the start of execution according to the present invention, FIG. 4 is a relational diagram showing the relationship of storage during execution, FIG. FIG. 7 is an explanatory diagram showing an example of the configuration of the test procedure of the embodiment, and FIG. 7 is a flowchart showing the flow of the debug function. 11... Required specification execution function, 12... Required specification. 13...Test function, 14...Test procedure, IS
...Execution results, 16.Execution status, 17.Debug function, Fig. 1 Fig. 2 Working table f 3 Fig. 4 Fig. 5 Fig. Z vfj to step 2 j tez I-child set

Claims (1)

[Claims] 1. The functions of a system that has a plurality of components, each of which performs its functions asynchronously, are defined as: (1) Data exchange between the components (system flow) and internal A method of defining data flow using a requirements specification that describes the data flow in terms of locations (links) and conversion means (work), and an execution method that moves data according to rules (operation rules) on the requirements specification. 1. A software specification forming method comprising the steps of: successively capturing input data of the requirements specification; and detecting errors from operations of the requirements specification on the captured data and output data. 2. The software specification forming method according to item 1, further comprising the step of determining and verifying the sufficiency of the test from the execution record. 3. The software specification formation method according to item 1, wherein the data is a token. 4. The third feature is that the movement of the token on the requirements specification is displayed and execution information is output according to the user's instructions.
Software specification formation method described in Section 1.