JP2007011605A - Model inspection support device for software operation specification, model inspection system provided with the same, and model inspection support program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a model inspection support device capable of generating a model inspection program from operation specifications without requiring learning of a model description language, more preferably, also capable of automatically generating software corresponding to the verified operation specifications. <P>SOLUTION: The model inspection support device is provided with a specification input part 3 for inputting the operation specifications of the software as a logic description expressed with a state transition relation of a variable; a model description language dictionary 6 storing a prototype of the model inspection program; and a translation part 4 that extracts a logic structure of the operation specifications from the logic description inputted to the specification input part 3 and prepares the model inspection program by using the extracted logic structure and the prototype of the model description language dictionary 6. The device outputs the model inspection program prepared by the translation part 4 to a model inspection device 10. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to an apparatus for mathematically verifying that a software operation specification is correctly described without including defects such as self-contradiction, instability, and unexpected operation, and in particular, the operation specification is a finite state transition system. The present invention relates to a verification apparatus that converts and applies a model checking method.

  Conventionally, in software development, the presence or absence of a defect is confirmed by an experienced person reviewing operation specifications. For this reason, software design / development may be performed without completely detecting the defect, and it is necessary to find and fix the defect by inspection after completion. Therefore, there is a problem that the reliability of the software cannot be sufficiently secured and the development efficiency is lowered because the software needs to be reworked.

  Therefore, a model checking method for mathematically verifying the operation specifications of software is known. The model checking method mathematically verifies whether a model checking program in which a software operation specification is described as a state transition system satisfies a temporal logic expression input as a check item (for example, Patent Document 1). It is also possible to detect defects such as self-contradiction, instability, and unexpected operation that are latent in the operation specifications of software (see Non-Patent Document 1).

Conventionally, when a model checker is applied to a software operation specification, a diagram is manually created from the operation specification to extract a logical structure, and a model check program is generated using a model description language (see, for example, Non-Patent Document 2). ).
Japanese Patent Laid-Open No. 10-301963 Hayami, Shinozaki, Takahashi, Watanabe, Specification verification of automatic meter reading system using model checker, AIST-PS-2003-005, AIST-PS-2003-005 Terada, Tsuchiya, Kikuno, Statechart verification using symbolic model checking, IEICE technical report, SS98-41 (1999-01)

  However, the conventional model checking described above is performed for research purposes because it requires acquisition of a model description language that is different from the software development language, but has not been adopted for actual software development.

  Furthermore, even if an operation specification that satisfies the inspection items is obtained as a result of model checking, when creating software from the operation specification, the developer extracts the logical structure from the operation specification and performs programming using the software development language. It was necessary to do.

  In view of the above problems, the present invention can generate a model checking program from an operation specification without requiring learning of a model description language, and more preferably automatically generates software according to a verified operation specification. An object of the present invention is to provide a model checking support device that can also be used.

  In order to achieve the above object, a model checking support apparatus for software operation specifications according to the present invention includes a specification input unit for inputting software operation specifications as a logical description represented by variable state transition relationships, and a model checking program. A model description language dictionary storage unit storing a model of the model, a logical structure of the operation specification is extracted from a logical description input to the specification input unit, and the extracted logical structure and the model description language dictionary storage unit A translation unit that creates a model checking program using a template is provided.

  The model checking system according to the present invention includes the model checking support device according to the present invention and a model checker that performs model checking of the model checking program generated by the model checking support device. .

  A model checking support program according to the present invention is a model checking support program that causes a computer to execute a model checking support process for software operation specifications, and that the software operation specifications are expressed as a logical description represented by variable state transition relationships. The specification input process to be input, the logical structure of the operation specification is extracted from the logical description input in the specification input process, and the extracted logical structure and the model checking program template acquired from the model description language dictionary storage unit And a computer is caused to execute a translation process for creating a model checking program.

  According to the present invention, it is possible to automatically generate a model checking program from an operation specification without requiring learning of a model description language. As a result, model checking can be applied to software development practices.

  A model operation support apparatus for software operation specifications according to the present invention includes a specification input unit for inputting software operation specifications as a logical description represented by a state transition relationship of variables, and a model description language storing a model of a model inspection program Extracting the logical structure of the operation specification from the dictionary storage unit and the logical description input to the specification input unit, and using the extracted logical structure and the model of the model description language dictionary storage unit, model checking And a translation unit for creating a program.

  In the above configuration, the translation unit extracts the logical structure of the operation specification from the logical description expressed by the variable state transition relationship, and applies the model description language dictionary storage unit template to the extracted logical structure. A model checking program can be created. As a result, there is no need to manually extract a logical structure from an operation specification as in the prior art, and development efficiency can be greatly improved.

  In the model checking support device, the specification input unit inputs a state transition relationship of the variables as a graphic representation, and the translation unit extracts a logical structure of an operation specification from the graphic representation input to the specification input unit. It is preferable to do. As the graphic representation, for example, a flowchart, a PAD, or a state transition diagram can be used.

  In the model checking support apparatus, a logical structure storage unit that stores a logical structure of an operation specification extracted by the translation unit, a development language dictionary storage unit that stores a template of a development language program, and the logical structure storage unit It is preferable to further include a program creation unit that creates a program in a development language using the logical structure stored in the development language dictionary and the template in the development language dictionary storage unit. As a result, the program development efficiency can be further improved.

  A model checking system according to the present invention includes a model checking support device according to any one of the above-described configurations, and a model checker that performs model checking of a model checking program generated by the model checking support device. It is.

  Furthermore, the model checking program according to the present invention is a model checking support program that causes a computer to execute model checking support processing of software operation specifications, and inputs the operation specifications of the software as a logical description expressed by variable state transition relationships. A specification input process, a logical structure of the operation specification is extracted from the logical description input in the specification input process, and the extracted logical structure and a model of the model checking program acquired from the model description language dictionary storage unit Is a program that causes a computer to execute translation processing for creating a model checking program.

  In the specification input process, the model checking program inputs the state transition relationship of the variables as a graphic expression, and in the translation process, extracts a logical structure of the operation specification from the graphic expression input in the specification input process. It is preferable.

  The model checking program refers to a logical structure storage unit that stores a logical structure of an operation specification extracted by the translation process, and a development language dictionary storage unit that stores a model of a development language program, It is preferable to cause a computer to execute a program creation process for creating a program in a development language using the logical structure acquired from the logical structure storage unit and the template acquired from the development language dictionary storage unit.

Hereinafter, specific embodiments of a model checking system according to the present invention will be described with reference to the drawings. In the following embodiment, an example in which a software operation specification is graphically input by a flowchart and a model checking program is created will be described. However, a method for inputting a software operation specification is not limited to this example. For example, PAD (Problem Analysis) is used. Diagram) and state transition diagrams can also be used.
(First embodiment)
First, the schematic configuration of the model checking system according to the first embodiment of the present invention will be described with reference to FIG. FIG. 1 is a block diagram of the model checking system according to the present embodiment.

  As shown in FIG. 1, the model checking system according to the present embodiment checks a model checking support device 2 that generates a model checking program from an operation specification 1 of software, and a model checking program generated by the model checking support device 2. A model checker 10 for checking according to item 9 and outputting a check result 11 is provided.

  The model checking support device 2 reads a logical structure from the operation specification 1 and a specification input unit 3 for inputting information necessary for model checking from the operation specification 1 which is a program specification of the software. And a translation unit 4 for creating The model checking support device 2 further includes a logical structure storage unit 5 and a model description language dictionary 6, which are connected to the translation unit 4. The logical structure storage unit 5 stores the logical structure extracted from the operation specification 1. The model description language dictionary 6 stores typical templates for combinations of state transitions and state transition conditions.

  The model checking support device 2 and the model checking device 10 can be realized using a computer such as a personal computer. In this case, the functions of the specification input unit 3 and the translation unit 4 are realized by causing the computer to execute a predetermined program. The logical structure storage unit 5 and the model description language dictionary 6 are realized by a computer hard disk or other storage medium. The model checking support device 2 and the model checking device 10 can be implemented by a single computer, but can also be implemented by a plurality of computers.

  Next, the operation of the model checking system of this embodiment will be described with reference to FIG.

  When performing model checking in the model checking system of the present embodiment, first, an operator extracts the names of items necessary for model checking and the states that each item can take from the operation specification 1, and the extraction result is a specification input unit. 3 (step S10). The specification input unit 3 includes an input device such as a keyboard and an output device such as a display (both not shown), and the operator uses these input / output devices to input item names and states to the model checking system. input.

  Next, the operator inputs a variable name to be assigned to the item name input in step S10 from the specification input unit 3 (step S11). This variable name is a variable name used in the model checking program. At this time, if the operator assigns variable names according to a predetermined rule, the maintainability of the model checking program is improved. Further, the worker inputs a variable value to be assigned to the state input for each item in step S10 from the specification input unit 3 (step S12). This variable value is also used in the model checking program.

  The items and states input in the above steps S10 to S12 and the variable names and variable values assigned to them can be displayed as a list on a display or the like, or, for example, spreadsheet software or the like If the data is output as the above data, there is an advantage that it becomes easy for the operator to create a chart in the next step S13.

  Next, the worker creates a flowchart representing the contents of the operation specification 1 by referring to the list created in steps S10 to S12, and inputs it from the specification input unit 3 (step S13). The operator creates and inputs a flowchart as a chart on the display screen. At this time, the specification input unit 3 uses a graphic symbol drawing / arrangement function, a connection function between graphic symbols, a mathematical expression input function to the graphic symbol, and the like, which are prepared in advance. Supports the operator to input the connection between the terminals and the operation contents in the block. By inputting and displaying the contents of the operation specification 1 as a flowchart, the operator can easily confirm the input result.

  The translation unit 4 assigns the values of the program counter so as not to overlap each connection line in the flowchart (step S14). The program counter is treated as a variable in the same way as the input item.

  Next, the translation unit 4 traces the flowchart for each variable from the beginning, and extracts an initial value, a next value, and a conditional expression for changing to the next value, that is, a state transition relationship ( Step S15). At this time, by including the variable of the program counter in the conditional expression for changing the value of the variable, the time series of the flowchart is expressed in the state transition system.

  The obtained state transition relationships of all variables are stored and saved in the logical structure storage unit 5 as the logical structure of the operation specification 1 (step S16).

  Next, the translation unit 4 applies the state transition relationship for each variable to the template stored in the model description language dictionary 6 and converts it into a program code of the model description language (step S17). Furthermore, the translation unit 4 creates a model checking program by rearranging the program codes in the model description language obtained in step S17 in a predetermined order (step S18).

  The model checking program obtained by the model checking support device 2 in the above procedure is input to the model checker 10. The model checker 10 mathematically checks whether or not the above-described model check program satisfies the separately input check item 9 (step S19). The inspection result by the model checker 10 is output as the inspection result 11.

  The operator looks at the inspection result 11 and determines whether the operation specification 1 satisfies the inspection item 9 (step S20). If not satisfied, the operation specification or the logical structure is corrected, and again, The model check is repeated (step S21). If the operation specification 1 satisfies the inspection item 9, the verification work is finished (step S22).

  Here, a specific example of the processing of steps S10 to S22 in FIG. 2 will be described in more detail with reference to FIGS.

  For example, the contents of the operation specification 1 of the program are “if the numeric value is 1, the output is“ odd ”. If the numeric value is 2, the output is“ even ”. Is set to 1, and the subsequent value is nondeterministically rewritten after output and returns to the beginning, and the process of outputting “odd number” or “even number” is repeatedly executed according to the rewritten number. ” To do.

  In this case, variable names and variable values as shown in the list of FIG. 3 are assigned to the items and states necessary for model checking through the above steps S10 to S12. That is, “number” and “output” are extracted as item names, the states that “number” can take are “1” and “2”, and the states that “output” can take are “odd” and “even”. It is.

  The list illustrated in FIG. 3 includes an initial value column and a column indicating non-deterministic state in addition to the item name and its state. For the item “number”, it is described that the initial value is “1” and the nondeterminism of this item is “Yes” in accordance with the description contents of the operation specification 1 of the program. “Non-determinism” is, for example, when the item is selected at random, when the state of the item is input from the outside, or when the state of the item is given as the processing result of another item, etc. “Yes” if the status of the item is not definitive. In the above specific example, it is clearly stated that the “number” can be rewritten nondeterministically by the operation specification 1, and therefore “nondeterministic” is described as “present”.

  In the list illustrated in FIG. 3, “num” is assigned to the item “number” and “out” is assigned to the item “output” as variable names. In addition, “1” and “2”, which are the state of the item “number”, are assigned variable values “1” and “2”, respectively. “ODD” and “EVEN” are respectively assigned as variable values to “odd” and “even” which are the states of the item “output”. Furthermore, since the initial value of “number” is “1”, “ODD” is described in the initial value column of the item “output”. In addition, since the value of the item “output” is uniquely determined by the value of “number”, “none” is described in the non-deterministic column.

  FIG. 4 is a flowchart created based on the list illustrated in FIG. 3 and input from the specification input unit 3 by the operator. In this flowchart, after the start (step S1), it is determined whether or not the value of num is “1” (step S2). If the result of step S2 is YES, "ODD" is substituted for variable out (step S3), and if the result of step S2 is NO, "EVEN" is substituted for variable out (step S4). After assignment to the variable out, “1” or “2” is assigned to the variable num (step S5), and the above processing is repeatedly executed.

  5 to 7, when the flowchart of FIG. 4 is input from the specification input unit 3, the state transition relationship for each variable of the flowchart is extracted by the processing of steps S <b> 14 to S <b> 16 of FIG. 2 by the translation unit 4. Show the state.

  As shown in FIG. 5, the translation unit 4 first determines the processing of each block or the type of connection line for all the blocks and connection lines included in the flowchart, and assigns an ID number (1, 2,.・ ・) Is given. ID numbers are assigned to blocks in order, and after all ID blocks have been assigned ID numbers, ID numbers are assigned to connection lines.

  Specifically, step S1 is a block for performing the start process, and is the first block, and is therefore “start process / 1”. Step S2 is “general condition processing / 2”. Step S3 is “general processing / 3”, and step S4 is “general processing / 4”. Step S5 is “non-decision process / 5”.

  Furthermore, the connection line between step S1 and step S2 is “connection line / 6”. The connection line between step S2 and step S3 is “Yes connection line / 7”, and the connection line between step S2 and step S4 is “No connection line / 8”. The connection line between step S3 and step S5 is “connection line / 9”, the connection line between step S4 and step S5 is “connection line / 10”, and the connection line between step S5 and step S1 is “connection line / 11”. It is said.

  The translation unit 4 assigns a program counter (hereinafter referred to as PC) to each connection line in the flowchart (step S14 in FIG. 2). In the example of FIG. 5, PC = 1 is assigned to the connection line / 6, PC = 2 is assigned to the Yes connection line / 7, PC = 3 is assigned to the No connection line / 8, and PC = 4 is assigned to the connection line / 9. Since the connection destination is another connection line, the connection line / 10 and the connection line / 11 are not assigned a PC.

  Next, the translation unit 4 creates a definition list of elements of the flowchart according to the list of FIG. 3 and the assignment result of FIG. An example is shown in FIG. The definition list in FIG. 6 includes a variable declaration unit 61 and a definition unit 62 for each element of the flowchart. The contents of the variable declaration unit 61 are obtained from the list of FIG. The contents of the definition unit 62 are obtained from the assignment result of FIG.

  That is, in the variable declaration part 61, “#Variables” which is a comment indicating that it is a variable declaration part is described in the first line, and the variable “num” shown in FIG. Variable type (integer), variable name (num), initial value (1), lower limit value (1), and upper limit value (2) are defined. The next line defines the variable type (symbol set type), variable name (out), initial value (ODD), and all symbols (ODD, EVEN) for the variable “out” shown in FIG. Has been.

  In the definition part 62, “# Flow-Chart” which is a comment indicating that it is a definition part of an element of a flowchart is described in the first line. In the second and subsequent lines, the definition of each element is described in the order of ID number from start processing / 1. For example, since the general condition process / 2 is a branch process, a variable name (num), a comparison value (1), and a comparison operator (=) that are branch conditions are described. Since the general process / 3 is an assignment process, a variable name (out) and an assigned value (ODD) are described. The general process / 4 is the same as this. Since the non-decision process / 5 is a random substitution process, a variable name (num) and a substitution value candidate (1/2: this slash symbol represents a break between candidate values) are described. Since the connection line / 6 is a connection line connecting the preceding and following processes, the previous process (start process / 1), the subsequent process (general condition process / 2), and the PC value (1) of this connection line are Described. Similarly, for the Yes connection line / 7, No connection line / 8, and connection line / 9, the previous process, the subsequent process, and the PC value of the connection line are described. Since the connection line / 10 and the connection line / 11 do not have a PC value, only the previous process and the subsequent process are described.

  Next, the translation unit 4 extracts the variable name, initial value, value range, and state transition for each variable from the definition list in FIG. 6 (step S15 in FIG. 2). The extraction result is shown in FIG. The variable name, initial value, and value range are acquired from the variable declaration unit 61 of the definition list. The state transition is acquired from the definition unit 62 of the definition list, and is described in a state in which the state transition condition and the substitution value are separated by a comma. For example, since the variable num is assigned 1 or 2 as the variable value when the PC value is 4, the state transition is described as “PC = 4, 1/2” as shown in FIG. The The variable out is assigned the variable value ODD when the PC value is 2, and the variable value EVEN is assigned when the PC value is 3. Therefore, as shown in FIG. = 2, ODD "," PC = 3, EVEN ". The state transition relationship extracted as described above is stored in the logical structure storage unit 5 as a logical structure obtained from the operation specification 1.

  Next, the translation unit 4 generates an input language string (model check program) to the model checker 10 by referring to the model description language dictionary 6 based on the extraction result of FIG. 7 in steps S17 to S18 of FIG. To do. Here, FIG. 8 shows an example of a template stored in the model description language dictionary 6. The example of FIG. 8 is a model of SMV (Symbolic Model Verifier) language, but the language that can be used as the model description language in the present invention is not limited to this.

  In the template shown in FIG. 8, the symbols shown in italic characters are fixed portions. “VAR” is a variable declaration part and defines a value range. “ASSIGN” defines a state transition. “Init (xx)” defines an initial value of the variable xx. “Next (xx)” defines a state transition condition and an assignment value to a variable xx in a case statement (case to esac). In the case statement, the state transition condition is described on the left side of the colon “:”, and the assignment value to the variable xx is described on the right side. The first line of the case statement in FIG. 8 means that if the state transition condition on the left side of the colon is satisfied, the substitution value described in the first line is substituted into the variable xx. 1: xx (1 represents true), in all cases except for the state transition condition in the first row, the value of variable xx is substituted for variable xx, that is, the value of variable xx Means holding. The translation unit 4 assigns a variable to the part xx of the above template according to each system, and assigns a value range, an initial value, and an assigned value appropriately, so that the model checking program for the model checker 10 is assigned. Generate.

  FIG. 9 shows an example of a model checking program generated by the translation unit 4 using the template shown in FIG. 8 from the extraction result shown in FIG. The description “MODULE main” at the beginning of the model checking program indicates a main module. In FIG. 9, “&” is an operator for product conditions, and “!” Is an operator for negative conditions.

  The model check program generated in this way is transferred from the translation unit 4 to the model checker 10. The operator inputs a time phase logical expression (EF) as shown in FIG. The model checker 10 adds the input check item 9 with the symbol “SPEC” at the end of the model check program, and executes model check. The temporal logic formula has a format of EF (P), for example, and returns true / false that “P is established at a certain path (Exist) and at a future time (Future)”. That is, the time phase logical expression shown in FIG. 10 expresses that the program to be inspected reaches the final step, that is, the PC value reaches 4. In addition to this, the inspection item can be described in a manner such as EF (num = 2), for example. This temporal logic expression is an expression for checking whether or not the value of the variable num may be 2. It is also possible to use a temporal logic formula in the format of AF (P). This is an expression that returns the truth of “P is established at all points (All) and at a future time (Future)”.

  In step S19 of FIG. 2, the model checker 10 uses the model check program generated as described above, and returns the true / false of the check item given as a temporal logic formula as the check result 11. Then, the operator confirms the inspection result 11, and if the inspection result is good, the verification operation is terminated. If the inspection result is defective, the operation specification and the logical structure are reviewed in step S21, and the verification operation is performed again.

As described above, according to the present embodiment, if the operator assigns variables to the items and states of the operation specification 1 and inputs a flowchart representing the contents of the operation specification 1 from the specification input unit 3, the translation unit 4 The state transition relationship for each variable is extracted from the flowchart, and a model checking program corresponding to the operation specification 1 is automatically generated. As a result, there is no need to manually extract a logical structure from an operation specification as in the prior art, and development efficiency can be greatly improved.
(Second Embodiment)
Next, a schematic configuration of a model checking system according to the second embodiment of the present invention will be described with reference to FIG. FIG. 11 is a block configuration diagram of the model checking system of this embodiment.

  As shown in FIG. 11, the model checking system according to the present embodiment is the first in that the model checking support device 2 includes a development language dictionary 8 and a program creation unit 7 that creates a development language program. This is different from the model checking system according to the embodiment.

  The program creation unit 7 creates a development language program 12 from the logical structure stored in the logical structure storage unit 5 when the inspection result 11 by the model checker 10 is good. That is, when the operation specification 1 satisfies the inspection item 9, the logical structure extracted from the operation specification 1 and stored in the logical structure storage unit 5 naturally satisfies the inspection item 9. Therefore, if the program creation unit 7 generates a program based on the logical structure, a development language program 12 that satisfies the inspection item 9 is obtained.

  Next, creation of the development language program 12 performed by the program creation unit 7 will be described with reference to the flowchart of FIG. Note that the generation of the model checking program by the translation unit 4 and the checking procedure by the model checker 10 using the model checking program are the same as those described in the first embodiment with reference to FIG. The explanations made are omitted.

  When the inspection result 11 by the model checker 10 is good (when the result of step S20 in FIG. 2 is good), the process proceeds to step S22 and the verification operation is completed. In the present embodiment, thereafter, the program creation unit 7 calls the state transition function of each variable from the logical structure storage unit 5 as shown in FIG. 12 (step S31). Next, the program creation unit 7 converts the state transition relation for each variable into a development language template stored in the development language dictionary 8 to convert it into a development language program source code (step S32). Further, the program creation unit 7 rearranges the development language program source codes in a predetermined order to complete the development language program (step S33).

  Here, a specific example of the processing in steps S31 to S33 in FIG. 12 will be described in more detail with reference to FIGS.

  FIG. 13 shows a JavaScript (registered trademark) language template as an example of a development language template stored in the development language dictionary 8. However, the development language used in the present invention is not limited to this. In FIG. 13, the part represented by italic characters is a fixed part. The program creation unit 7 appropriately assigns a variable to xx, a class name / method name, a variable type, an initial value, a state transition condition, an assignment value, and the like according to each system. In the template of FIG. 13, the variable type and initial value of the variable are described at the beginning. In the third and subsequent lines, state transition conditions and substitution values at the time of state transition are described.

  For example, by applying the template shown in FIG. 13 to the logical structure shown in FIG. 7, a program source code as shown in FIG. 14 is obtained. Here, the program creation unit 7 may arbitrarily assign the class name and the method name on condition that they are unique. In the example of FIG. 14, the PC values that are not used in JavaScript (registered trademark) language are omitted, and the processing order indicated by the PC values is changed to JavaScript (registered trademark) language by processing in the order of the PC values of FIG. The execution order has been replaced. Furthermore, the program creation unit 7 implements non-determination processing with a Random class.

  As described above, according to the second embodiment, the model checking support device 2 not only automatically creates a model checking program for the operation specification 1, but also when the verification result 11 is good, the operation specification 1 The development language program 12 is automatically generated based on the logical structure and the development language dictionary 8. As a result, the program development efficiency can be further improved.

It is a block diagram showing a schematic structure of a model check system concerning a 1st embodiment of the present invention. It is a flowchart which shows operation | movement of the model check system concerning 1st Embodiment. It is explanatory drawing which shows an example of the variable allocated to the item and state of an operation | movement specification in the model check system concerning 1st Embodiment. It is an example of the flowchart showing operation | movement specification. It is explanatory drawing which shows a mode that the ID number and the program counter were allocated to each element of the flowchart shown in FIG. It is explanatory drawing showing an example of the definition list | wrist of each element obtained from the flowchart showing operation | movement specification. It is explanatory drawing which shows an example of the list showing the transition state relationship for every variable. It is explanatory drawing which shows an example of the model of a model description language. It is explanatory drawing which shows an example of the produced | generated model check program. It is a description example of a temporal logic formula of an inspection item. It is a block diagram which shows schematic structure of the model check system concerning the 2nd Embodiment of this invention. It is a flowchart which shows operation | movement of the model check system concerning 2nd Embodiment. It is explanatory drawing which shows an example of the template of the development language of a program. It is explanatory drawing which shows an example of the source code of the produced | generated development language program.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Operation | movement specification 2 Model test | inspection assistance apparatus 3 Specification input part 4 Translation part 5 Logical structure memory | storage part 6 Model description language dictionary 7 Program creation part 8 Development language dictionary 9 Test item 10 Test result 11 Test result

Claims (7)

A specification input unit for inputting software operation specifications as a logical description represented by state transition relations of variables;
A model description language dictionary storage unit storing model checking program templates;
Translation that extracts a logical structure of the operation specification from the logical description input to the specification input unit, and creates a model checking program using the extracted logical structure and the template of the model description language dictionary storage unit A model checking support device for software operation specifications, characterized by comprising: The specification input unit inputs the state transition relationship of the variable as a graphic expression,
The model checking support device according to claim 1, wherein the translation unit extracts a logical structure of an operation specification from a graphic expression input to the specification input unit. A logical structure storage unit for storing a logical structure of the operation specification extracted by the translation unit;
A development language dictionary storage unit storing development language program templates;
The model according to claim 1, further comprising: a program creation unit that creates a program in a development language using the logical structure stored in the logical structure storage unit and the template in the development language dictionary storage unit. Inspection support device. The model checking support device according to any one of claims 1 to 3,
A model checking system comprising: a model checker that performs model checking of a model checking program generated by the model checking support device. A model checking support program for causing a computer to execute model checking support processing of software operation specifications,
Specification input processing for inputting software operation specifications as a logical description represented by variable state transition relationships;
Extracting the logical structure of the operation specification from the logical description input in the specification input process, and using the extracted logical structure and the model of the model checking program acquired from the model description language dictionary storage unit, model checking A model checking support program that causes a computer to execute a translation process for creating a program. In the specification input process, the state transition relationship of the variable is input as a graphic expression,
6. The model checking support program according to claim 5, wherein in the translation process, a logical structure of an operation specification is extracted from a graphic expression input in the specification input process. A logical structure storage unit storing a logical structure of the operation specification extracted by the translation process;
With reference to the development language dictionary storage section that stores the development language program template,
7. The computer is caused to execute a program creation process for creating a program in a development language using the logical structure acquired from the logical structure storage unit and the template acquired from the development language dictionary storage unit. Model checking support program described in 1.

Images