JPH06161759A - Method and device for supporting verification of system state transition rule - Google Patents

Abstract

PURPOSE:To provide the method and device for supporting the verification of the system state transition rule which can support high-reliability software development by making clear the relation between the system state transition of a system to be verified and a group of rules, which can be executed in parallel. CONSTITUTION:Initial states of >=2 element states are inputted in the method which supports the vertification of the system state transition rule of a system whose system state is defined by the direct product of the elements and rules as to the element states are inputted 121; and the rules are classified as to state values and events before and after transition. The classified rules are used to retrieve for rules which can be executed for the initial states of the respective element states, events are executed, event by event, to find the system state 108 after event occurrence, and the same processing is repeated even for a newly obtained system state, thereby generating and displaying all possible system state transition from the initial states.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method and apparatus for analyzing and verifying system state transitions, and more particularly, to use in designing a system in which a system state is defined by a combination of a plurality of element states. The present invention relates to a suitable system state transition analysis method and apparatus.

[0002]

2. Description of the Related Art Conventionally, a state transition graph and a state transition table are often used in tests such as program checks. For example, “Nogi, Nakasho: Programming Tools, Software Course 27, pp.156-157, Shokoido (198
9) ”describes a method of using the state transition diagram as a tool for automating the functional test of the designed and developed system. In addition, using state transition diagrams at the system specification design stage to create structured specifications that can be useful for design development is described in “E. Yoourdon, Kuroda et al .: Software Development by Structured Method, pp. 47-56, Nikkei McGraw-Hill Company
(S.62) ”.

By the way, the state transition diagram represents, in the form of a graph or a table, what kind of event occurs and how the system state transitions in each state that the system can take. Each transition shown in the state transition diagram corresponds to one rule. A rule represents how a state transitions when an event that is a certain state occurs. In other words, the state transition diagram and the rule corresponding to the state transition diagram have different expressions, and can be regarded as the same in terms of meaning.

Therefore, if a rule defining the change in the system state is given, it is easy to derive the system state graph from the rule. On the other hand, given a system state graph, it is easy to find the rule that realizes the transition on the system state graph.

[0005]

However, in a system in which there are a plurality of elements that make up the system and a plurality of rules relating to individual element states can be executed in parallel, the rules and the system state transitions have a one-to-one correspondence. Does not correspond to. This is because the system state transition is represented by a set of element states, whereas the rule is often represented by each element.

For example, if there are three elements that make up the system, the system state transition is "(α1, β1, γ
1) → (α2, β2, γ2) ”. However, the rule corresponding to this one transition is the rule relating to the transition of the state of the first element from α 1 to α 2,
There are three rules concerning the transition of the state of the element of β1 to β2 and the transition of the state of the third element of γ1 to γ2. Therefore,
One rule affects state transitions at multiple locations,
Conversely, one state transition may be realized by multiple rules.

Therefore, in a system in which there are a plurality of elements constituting the system and a plurality of rules relating to individual element states can be executed in parallel, the conventional technique cannot be used as it is, and the state transition diagram It was not easy to know the correspondence between each transition and the rule. Also, it was difficult to derive the state transition diagram from the rules.

Further, if one of the state transitions on the state transition diagram is changed, the rule associated therewith is changed, but the state transition of interest is corrected correctly, but the influence of other state transitions. I sometimes overlooked the receiving part and a new defect occurred.

In view of the problems in the above-mentioned conventional example, an object of the present invention is to clarify the relationship between the system state transition of the target system and a group of rules that can be executed in parallel,
It is an object of the present invention to provide a system state transition rule verification support method and apparatus capable of supporting more reliable parallel processing software development.

[0010]

To achieve the above object, the present invention is a method for supporting verification of a system state of a system, wherein the system state is defined by a direct product of two or more element states. Enter the system state transition rule consisting of the combination of the event that triggers the change of the state value, which is the possible value of the element state, the state value of the element state before the event occurs, and the state value of the element state after the event occurs And a step of generating and displaying a system state transition based on the rule.

A method for supporting verification of a system state of a system in which the system state is defined by a direct product of two or more element states, the step of inputting an initial state of each element state, A step of inputting a system state transition rule consisting of a combination of an event that triggers a change of a possible state value, a state value of an element state before the event occurs, and a state value of the element state after the event occurs, , A step of classifying the input rule with respect to each of state values and events before and after the transition included in the rule, and using the classified rule, it is possible to execute the initial state of each element state. Searches for rules, executes the rules for each event, calculates the state value of each element state after execution of each rule, and combines them to obtain the system state after the event occurs. , Even for newly obtained system state, by repeating the same process, characterized by comprising the step of generating and displaying all system state transitions possible transitions from the initial state.

Further, after the system state transition is displayed, the system state transition is used to instruct addition or deletion of the transition or the system state, and the rule to be corrected is searched and displayed accordingly. Good. Further, when the rules to be modified are displayed, those rules may be modified as appropriate, and all system state transitions may be generated and displayed again based on the modified rules.

The system state transition before the rule modification and the system state transition after the rule modification may be displayed at the same time. Further, it is preferable to input the rules in a format such as a state transition table for each element state.

The system state transition rule verification support device according to the present invention is a device for supporting the system state verification of a system in which the system state is defined by the direct product of two or more element states. Means for inputting a system state transition rule consisting of a combination of an event that triggers a change in the state value that is a possible value of the element, a state value of the element state before the event occurs, and a state value of the element state after the event occurs And a means for generating and displaying a system state transition based on the rule.

Further, there is provided a device for supporting verification of a system state of a system in which a system state is defined by a direct product of two or more element states, and means for inputting an initial state of each element state, A means for inputting a system state transition rule consisting of an event that triggers a change in a possible state value, a state value of the element state before the event occurs, and a state value of the element state after the event occurs , A means for classifying the input rule with respect to each of state values before and after the transition and events included in the rule, and the above-mentioned method executable for the initial state of each of the element states by using the classified rule. Search the rules, execute the rules for each event, find and combine the state value of each element state after each rule execution, find the system state after the event occurrence, and newly Also to be the system state,
By repeating similar processing, a means for generating and displaying all system state transitions that can transit from the initial state is provided.

[0016]

With respect to the control system in which the system state is defined by the direct product of two or more element states, the rule of each element state can be input, and the system state transition can be generated and displayed based on the rule. The system state transition can be easily obtained from the rule.

Further, if there is a request for addition or deletion of a transition or a system state regarding the generated system state transition, selecting the transition or the system state on the state transition diagram causes a plurality of rules for realizing the transition to be set. It is possible to instruct to search, modify, add, and delete all the rules from the stored contents by classifying the rules individually by event or by state value and storing them.

Further, all the system state transitions obtained from the modified rule are obtained again, and the system state transitions before the change are compared with the stored contents so as to make the change clear, and the output is displayed. Since the range affected by is clarified, it is possible to prevent the designer from losing his or her mind.

[0019]

Embodiments of the present invention will now be described in detail with reference to the drawings.

FIG. 1 is a process flowchart showing the procedure of a system state transition rule verification support method according to an embodiment of the present invention. FIG. 2 is a device configuration diagram for realizing the present embodiment.

First, with reference to FIG. 2, an apparatus configuration diagram of this embodiment will be described. The device configuration is such that a computer 201 having a graphic function is provided with input devices 202, 205,
The storage device 203 and the output device 204 are connected. Although the keyboard 202 and the mouse 205 are shown as the input devices in the drawing, other input devices may be used, a combination thereof may be used, or any one of them may be used.

The storage device 203 is not limited to a magnetic storage device, but may be an optical disk or a semiconductor memory. In short,
It suffices if it has sufficient capacity to execute programs and store data files. The apparatus configuration for implementing the present invention may be what is generally called a computer or a computer system. As a matter of course, even the special-purpose device manufactured in order to carry out the present invention only needs to satisfy the functions of the peripheral devices as described above.

Next, an outline of the operation of this embodiment will be described with reference to the processing flowchart of FIG. In the figure, a solid arrow indicates a processing flow, and a dotted arrow indicates a data flow.

First, in step 100, an element state name, a state value, and an event of a system (referred to as a verification target system) for which a rule for realizing a state transition is to be verified are input. The system to be verified is a system that has a plurality of constituent elements and in which a plurality of rules relating to the element status of each constituent element can be executed in parallel. In other words, the system status is a direct product of two or more element statuses. It is a system as defined. The state value is a value of an element state that each component can have.

The element state name input in step 100,
The state value and the event are stored in the storage device 203 as the state / event definition table 102. This table 102 will be described later with reference to FIG.

Next, in step 120, the initial value of the system state is input. The initial value is the initial state of each component of the verification target system. The input initial value of the system state is stored in the storage device 203 as the initial state table 103. This table 103 will be described later with reference to FIG. 7.

In step 121, a rule defining the state transition in the verification target system is input. Specifically, a state transition table is displayed based on the state / event definition table 102, and rules are input on the state transition table. The input rules are stored in the storage device 203 as the rule storage file 104. The rule storage file 104 will be described later with reference to FIG.

Next, in step 105, rule classification processing is performed. With the rule classification processing, it is possible to search for each rule input in step 104 using any of the state value before the event occurs, the event, and the state value after the event occurs as a key. It is a process of assigning such an identifier and classifying by the identifier. The classification result is stored in the storage device 203 as the rule classification storage file 107.

In step 108, system state transition generation processing is performed. This is a process that starts from the initial state input in step 120 and generates all system state transitions based on the rules input and classified in steps 121 and 105. The generated system state transition is stored in the storage device 203 as the system state transition storage file 110. Further, the generated system state transition is output and displayed on the output device 114.

The user can instruct to change the system state transition displayed on the output device 114. If there is a change request, the change request is input in step 111, and if not, the process ends.

When a change request is input in step 111, a correction rule search process is performed in step 112. This is a process of detecting a rule to be modified according to a change in system state transition. The correction rule search processing is performed by the rule storage file 104 and the rule classification storage file 107.
And the system state transition storage file 110,
The contents of these files are appropriately modified according to the change request input in step 111.

Next, in step 113, redefinition of the rule is input. Redefinition input is performed on the display screen of the state transition table used when the rule is input. The rule storage file 104 is updated according to the redefinition input. After that, returning to step 105, the redefined rules are classified, and the process of generating and displaying the system state transition is continued again based on the redefined rules.

Next, each step of the processing procedure of FIG. 1 will be described in detail with a specific example. At the same time, the configuration of each table and file will be described in detail.

Here, an example of verifying a system in which the system state S is defined by three element states {control state, fault state, data state} by the apparatus of FIG. 2 according to the procedure of FIG. 1 will be described. . The respective element states are {α1, α2, α3, α4} in the control state, {β1, β2, β3} in the fault state, and {γ
1, γ2, γ3}. Furthermore, as the events that occur, {off instruction, on instruction,
Failure, data guarantee completion, restoration}.

<Input of Element State Name, State Value and Event (Step 100 in FIG. 1)> FIG. 3 shows an example of a screen image displayed on the display device 204 when the element state name and state value are input.

In FIG. 3, reference numeral 301 denotes a window for defining the element state. Reference numeral 304 is an area in which the user inputs the element state name. In this embodiment, as described above, the system having the three element states {control state, fault state, data state} is the verification target.
Enter these in 4. In FIG. 3, three element status names {control status, failure status, data status} have already been input and displayed. Reference numeral 307 denotes an add button or a delete button used when adding an element state name or deleting an input element state name. The Popup button of the window 301 is provided to define the state after the element state definition.

Reference numeral 303 indicates the currently selected element status. The display of the selected element status 303 is reversed,
The selected element state name is also displayed in the area 305. Select one of the element state names and select Window 3
If the 01 Popup button is specified, a window for defining the state value regarding the selected element state opens.

In FIG. 3, in window 301, "control state" is displayed.
Is selected, the Popup button is specified, and "Control state"
The state value definition window 302 related to is open. The state value definition window 302 has an area in which the user inputs a state value. In this embodiment, the control state takes state values {α1, α2, α3, α4}, and the user inputs these state values. In the window 302, the state values α1 to α4 have already been input and displayed. Reference numeral 306 is an area for displaying the selected state value, and 308 is an add button or a delete button for the state value.

As described above, the element states and state values are defined on the screen of FIG. Note that these names may be arbitrary and may be arbitrarily given by the user. Further, the number is not limited to the above example, and may be arbitrary. The above-mentioned various inputs are performed using the input device 202.

FIG. 4 shows an event definition screen for defining an event that occurs in each component of the verification target system. A window 401 defines an event.
402 is an area for inputting an event name, 403 is an inversion area showing the selected event, 405 is a display area for the selected event name, and 406 is an event name addition / display area.
These are the add button and the delete button used when deleting.
The user defines the event name by inputting it in the area 402. In the figure, an event {off instruction, on instruction, failure, data guarantee completion, recovery} is input and displayed.

As described above, the user can define and input the element state name, the state value and the event on the image screens shown in FIGS.

FIG. 5 shows the input element state name, state value,
The storage format of the state / event definition table 102 on the storage device 203 for storing the event and the event is shown. The element state name is stored with the element state number. The state value is stored with a state value number. Events are stored with event numbers.

The element state number and the state value number are associated with each other so that which element state takes which state value can be known. In this example, the "control state" of the element state number "0" is the state value whose tens digit of the state value number is "1", and the "fault state" of the element state number "1" is the state value number 10 The "0" digit corresponds to the state value, and the "data state" of the element state number "2" corresponds to the state value whose 10th digit of the state value number is "3". In addition,
Status value number "0" that indicates an error status as a special status value
“Error” of “0” is stored.

<Input of Initial Value of System State (Step 120 in FIG. 1)> FIG. 6 shows an initial state definition screen for inputting the initial state of the verification target system. The initial state definition screen displays all the element states of the verification target system and the state values of each element state. The user selects the displayed state value and inputs the initial state. In this example, the initial state of the verification target system is S0 = {α1, β1, γ1}. That is, the control state is α1, and the fault state is β
1. The state in which the data state is γ1 is the initial state of the system. In FIG. 6, α1, β1, and γ1 are selected as the initial state.

FIG. 7 shows a storage format of the initial state table 103 on the storage device 203 for storing the input initial state information. It is stored in the form of a pointer that points to the selected initial state. That is, since α1 is input as the initial state of the “control state”, the initial state table 103 is set with the pointer pointing to the memory storing the state value α1. The same applies to the initial states of other element states.

<Rule Input (Step 121 in FIG. 1)>
The rule defines a change in the state value due to an event for each element state. The rule is, for example, {Sbe
Fore, e, Safter}. Sbefo
re indicates the state value before the transition, e indicates the event, and Safter indicates the state value after the transition. That is, it means that when the event e occurs at the state value Sbefore, the state transitions to the state value Safter. As a method of inputting a rule, a state transition table may be used or if-then type description may be used. In this example, the state transition table is displayed so that the user can input rules.

FIG. 8 shows a state transition table displayed when a rule is input. For example, when a rule regarding the "control state" of the element states is input, the state transition table of FIG. 8A is displayed. The horizontal axis is the state value Sbefor before transition
e, the vertical axis represents the event e. In the in-table area where the state value Sbefore and the event e intersect, the state value Safte of the change result is displayed.
Enter r. Since no rule has been input at the beginning, only the states on the horizontal axis and the events on the vertical axis of the state transition table of FIG. 8A are displayed, and the area in the table is blank.

The user inputs a rule using such a state transition table. For example, as shown in FIG. 8A, the state α1
The state value α2 is described at the intersection of the event “off instruction” and the event “off instruction”, and the rule that the state α2 is entered when the event “off instruction” occurs in the pre-transition state α1 is input. Since the state transition table has been conventionally used for understanding the state transition, the input is easy and the operability is high. For events that should not occur, enter error in the Change Result field. Also, if the status value does not change depending on the event, it is blank.

The input rules are expressed by using rule identifiers, rule numbers are assigned in the order of input of rules, and the rules are stored in the rule storage file 104 in the format shown in FIG. In the figure, the rule number is a rule identifier unique to each rule. Following each rule number, a rule consisting of a state value number before transition, an event number, and a state value number after transition is stored.

When inputting a rule, it is advisable to judge whether or not the same rule exists among the rules that have already been input, and notify the user that a duplicate rule has been input.

<Rule classification process (step 105 in FIG. 1)
> The rule classification process uses an identifier that can be searched for each input rule by using the state value before the event occurs, the event, or the state value after the event as a key. This is a process of adding and classifying and storing as a rule classification storage file 107 in the storage device 203. The rule identifier may be a name or a code such as a number or an abbreviation. Here, as shown in FIG. 9, the rule number is used as the rule identifier.

FIG. 10 is a flowchart showing the detailed procedure of the rule classification process. The operation of the rule classification process in step 105 of FIG. 1 will be described in detail with reference to FIG.

First, in step 1001, the rule storage file 104 is referred to and it is determined whether there is any unprocessed rule. If there is any unprocessed rule, the process proceeds to step 1002, and if not, the process ends. In step 1002, one rule is fetched from the rule storage file 104. Then, in step 1003, the rules having the same state value before the transition of the rule are linked by a pointer. Step 1
At 004, the rules having the same event are linked by a pointer. Further, in step 1005, the pointers connect the rules having the same state value after the transition of the rule. This completes the processing for one rule. afterwards,
Returning to step 1001, the next rule is processed.

In this way, the process of classifying rules by associating is performed for all rules. The processing result is stored as the rule classification storage file 107.

FIG. 11 shows the rule classification storage file 107.
Shows the storage format of. One rule (eg, block 1100 in the figure) in the rule classification storage file 107
Is the rule number, state value number before transition, event number,
And the state value number after transition. Furthermore, a backward pointer 1 pointing to a rule having the same state value number before transition
101, a pointer 1102 that points to a rule with the same state value number before transition, a backward pointer 1103 that points to a rule with the same event number, a pointer 1104 that points to a rule with the same event number, and a state value after the transition Reverse pointer 110 pointing to a rule with the same number
5 and a pointer 1106 pointing to a rule having the same state value number after transition.

The pointers 1101 and 1102 are generated in step 1003. Pointers 1103 and 1104
Are generated in step 1004. Pointer 1105
And 1106 are generated in step 1005. In addition,
If there is no rule number to point to, NULL is set. Further, in the rule group connected by the pointer, the entry (1201, 1202, 12 in FIG.
03) is generated.

The pointers 1101 to 1104 are used in the system state transition generation process (step 108). Also,
The pointers 1105 and 1106 are used in the correction rule search process (step 112). The usage of these pointers will be described later.

FIG. 12 shows a rule classification storage file 107 obtained as a result of the rule classification processing using the specific rule data input as shown in FIGS. 8 and 9.
Shows a part of. Entry 120 of state value number before transition
1, an event entry 1202, and an after-transition state value number entry 1203 are provided. By tracing the pointers from these entries, it is possible to search for a rule with the same state value number before the transition, a rule with the same event number, and a rule with the same state value number after the transition. .

For example, referring to the area of the state value number before transition “10” of the entry 1201, the first rule of the state value number before transition “10”, that is, the rule of block 1204 is known. be able to. Furthermore, the next block 1205 can be known by referring to the pointer that follows the rule having the same state value number before the transition in block 1204. Similarly, block 1205 can be followed by blocks 1206, 1207, 1208. The last block 1208 points to NULL, and it can be seen that the rule is last.

Similarly, following the entry 1202, the rule corresponding to the event e0 is set in blocks 1204 and 120.
It can be traced to 9,1212. Further, tracing from the entry 1203, the rule whose state value number after transition is “11” is
The blocks 1204, 1209, 1213 and 1214 can be followed.

<System State Transition Generation Process (Step 108 in FIG. 1)> In the system state transition generation process, all the system state transitions obtained from the given initial state are generated and edited, and the system state transition storage file is stored in the storage device 203. It is stored as 110.

FIG. 13 is a flow chart showing the detailed procedure of the system state transition generation processing. The operation of the system state transition generation processing in step 108 of FIG. 1 will be described in detail with reference to FIG.

First, in step 1300, a flag check list including rule numbers and flags corresponding to the rule numbers is generated. "1" is set as an initial value for all the flags in the flag check list. next,
In step 1301, the initial state S0 = {α1, β1, γ1} stored in the initial state table 103 is read.
The system state number of the initial state S0 is "0".

The state value α1 is the initial state of the control state, and the state value number is "10". The state value β1 is
This is the initial state of the fault state, and the state value number is "20".
Is. The state value γ1 is the initial state of the data state,
The state value number is “30”. In step 1302, this initial state is positioned as the system state before the transition. Further, the initial state S0 is stored in the system state transition storage file 110.

FIG. 14 shows the storage format of the system state transition storage file 110. One system state is stored to store how the system state transitions.
Expressed in one block. One block (eg, block 1400) contains a system state number, a control state state value, a fault state state value, and a data state state value. A pointer 1401 indicating the system state after the event e0 has occurred, a pointer 1402 indicating the system state after the event e1 has occurred, and a pointer indicating the system state after the event e2 has occurred under the system state. 1403, a pointer 1404 that points to the system state after the event e3 occurs, and the event e
Pointer 1405 pointing to the system state after occurrence of 4
Equipped with.

In the initial state S0 stored first, the system state number is "0", the control state is the state value α1 (state value number "10"), and the fault state is the state value β1 (state value number "20". ”), The data state is the state value γ1 (state value number“ 3
0 "), these values are set.

Referring again to FIG. 13, step 1303
Then, it is determined whether or not there is an unprocessed event regarding the system state. If there is an unprocessed event, the process proceeds to step 1304, and if not, the process proceeds to step 1306. In this example, since there are four events e0 to e4, these events are sequentially processed.

In step 1304, the state value after the event is fired (occurred) is obtained for each element state based on the rules stored in the rule storage file 104. Also, the flag of the flag check list of the rule used is set to "0" which means "used". And step 130
In step 5, a system state is generated by combining the obtained state values and stored in the system state transition storage file 110.
After that, the process returns to step 1303 to continue the process for the next event.

The processing of steps 1304 and 1305 will be described with a specific example. For example, step 130
In 4, the event e0 from the initial state S0: "off instruction"
When is fired, how the state value of each element state that constitutes the system state before transition changes is calculated. First, the state value number before transition: "10" is shown in FIG.
From the entry 1201 of 1., and by tracing the pointers (pointers 1101 and 1102 in FIG. 11) coming out therefrom, the rule in which the event e0 is fired is searched. In this example, the rule with the rule number: 0 is searched.

Next, when the rule with the state value number: 20 before the transition is searched for by following the pointer (pointers 1103, 1104 in FIG. 11) to which the event e0 is connected, the rule with the rule number: 20 is searched. . Furthermore, a pointer to which the event e0 is connected (pointer 11 in FIG.
03, 1104) and the state value number before transition: 30
When the rule of No. 35 is searched, the rule of the rule number: 35 is searched. The rule thus detected is 0: {α1, e0,
α2}, 20: {β1, e0, β1}, 35: {γ1, e
0, γ1}.

By combining these, the system state S
When event e0 occurs at 0, system state S1 = {α
2, β1, γ1} (system state number: 1) is detected. The detected result is step 130.
In step 5, it is stored in the system state transition storage file 110.
That is, the system state transition storage file 11 of FIG.
A block representing the system state S1 = {α2, β1, γ1} (system state number: 1) is created in 0, and the pointer 1401 of the block of the system state S0 is set to point to the block of the system state S1. At this time, the flags of rule numbers 0, 20, and 35 in the flag check list are set to "0", which means "used". Once this flag becomes "0", it will not become "1" again.

Then, an event e is issued for the initial state S0.
1: Even when the "on instruction" occurs, it is processed in the same manner as in the case of the event e0 in step 1304. The rules searched are 1: {α1, e1, α1}, 21: {β
1, e1, β1}, 36: {γ1, e1, γ1}, and the system state does not change. In this case, step 1305
In the processing of 1, NULL is connected to the pointer 1402 that connects the result of the change due to the event e1. Step 130
4, 1305 is performed for the remaining events e2 to e4.

When the processing is completed up to the event e4, it is determined in step 1306 whether or not there is a system state that has not been selected as a system state before transition among the newly generated system states. If there are still unselected ones,
Regarding the system state, steps 1303 to 130 are also performed.
Since it is necessary to perform the processing of step 5, in step 1307, one of them is appropriately selected to make it the system state before the transition, and the process returns to step 1303. As described above, all system states are processed to obtain all system state transitions, and the system state transition storage file 110
To store.

At step 1306, if all system states have been selected and processed, step 1308 follows. In step 1308, the flag check list is traced to find an unused rule, that is, a flag check list in which "1" is set, and the rule number is output and displayed.

Further, the system state transition generated in the format shown in FIG. 14 is output by the output device 204 (114 in FIG. 1).
The output is displayed. The representation format may be any format such as a state transition graph, a state transition diagram, or a tree display. In this embodiment, the display is made in the format as shown in FIG. In FIG. 15, the horizontal axis indicates the data state γ1.
~ Γ3, and failure states β1 to β3 are set on the vertical axis. The control states α1 to α4 are described in the table, and the occurring events are represented by arrows. The event name is shown near the arrow.

The display may be switched and the vertical axis and the horizontal axis of the table different from FIG. 15 may be used. For example, it is possible to switch to a format in which the vertical is a control state α1 to α4 and the horizontal is a failure state β1 to β3, and the data states γ1 to γ3 are described inside.

<Input change request (step 111 in FIG. 1)>
The user desires the state transition of the system by referring to the system state transition as shown in FIG. 15 displayed by the above-described system state transition generation processing and the unused rule number detected in step 1308 (FIG. 13). You can check if it is. It is also possible to instruct to change the system state transition. This indicates the addition or deletion of transitions or system states. Such a change request can be made by designating the system state or transition on the system state transition displayed as described above. Alternatively, the system state number may be directly input to instruct the change. In the following, a case of deleting a transition will be described as an example. First, the user designates the transition to be deleted on the display screen of FIG. Here, FIG.
Suppose that the deletion of the dotted line part of is requested. That is, for example, it is assumed that a request for deleting the transition of event e3: "data guarantee completed" that has been output from the system state S0 = {α1, β1, γ1} is input. Such a change is instructed by clicking an object (for example, an arrow for transition) on the display screen of FIG.

<Correction rule retrieval processing (step 11 in FIG. 1)
The 2)> correction rule search process is a process of detecting a rule to be corrected after a change is input.

FIG. 17 is a flow chart showing the detailed procedure of the correction rule search process. The operation of the processing of steps 111 and 112 in FIG. 1 will be described in detail with reference to FIG.

First, in step 1701, a change request is input. The change request can be added, deleted, or changed as described above.
Alternatively, the system state is either added or deleted.
Adding a transition means adding a transition between existing system states. Also, defining a new event or state value that has not existed before is included in the change request.

Next, in step 1702, it is determined whether the transition is added or deleted. If the transition is added or deleted, the process proceeds to step 1703, and if not, the process proceeds to step 1705. In step 1703, the system state before the transition of the added or deleted designated transition is collated and searched from the system state transitions stored in the system state transition storage file 110. Then, the pointers 1401 to 1405 (FIG. 14) are traced to detect the transition designated for addition or deletion. The storage format of the system state transition storage file 110 shown in FIG. 14 stores the state value of each element before the transition, the event, and the system state after each event is fired. Further, pointers 1101 to 110 of the rule classification storage file 107 of FIG.
The rule number can also be known by tracing 6. Therefore, it is possible to easily detect the rule related to the transition whose change is instructed. Then, the process ends.

If it is determined in step 1702 that the transition is not added or deleted, the process proceeds to step 1705. Step 1705
Then, it is determined whether or not the system state is added.
In the case of adding a system state, it is necessary to specify the system state before the transition to the system state to be added, and therefore the system state is input in step 1706. Next, step 17
At 07, the input system state is searched from the system state transitions stored in the system state transition storage file 110. Then, in step 1708, all the rules whose transition source is the retrieved system state are detected using the pointers 1401 to 1405. The rule number can be detected in the same manner as in step 1704 described above. Then, the process ends.

If it is determined in step 1705 that the system state is not added, the process proceeds to step 1709. Step 170
At 9, it is determined whether the system state is deleted. If it is the deletion of the system state, step 171
Go to 0.

In step 1710, the system state transition to be deleted is searched from the system state transitions stored in the system state transition storage file 110. Then, in step 1711, all transitions whose transition destination is the retrieved system state to be deleted are detected. This is because pointers 1105 and 110 that connect rules having the same state value after transition in the rule classification file 107 in the format of FIG.
It can be detected by tracing 6.

Next, in step 1712, all the realized rules are detected for each of the retrieved transitions. The rule number can be obtained similarly to step 1704. Then, the process ends.

If it is determined in step 1709 that the system state is not deleted, the user is notified of the error, and the process ends.

For example, as shown in FIG. 16, the system state S
It is assumed that deletion is instructed for the transition when the event e3 “Data guarantee complete” occurs at 0 ({α1, β1, γ1}). At this time, the system state transition stored in the system state transition storage file 110 is searched to find that the event e3 has occurred in the state of the system state number “0”. Furthermore, by the procedure described above,
It can be seen that the rule numbers 3, 23 and 38 are realized.

<Redefinition input of rule (step 11 in FIG. 1)
3)> Once the rule (and rule number) that realizes the transition for making a change such as deletion is found as described above, FIG.
A screen for redefining rules as shown in 8 is displayed. This screen is the same as the screen of FIG. 8 used when the rule is input and is in the form of a state transition table. Since the rule related to the transition instructed to change is already known, the state value and the event before and after the transition are displayed in reverse for that part.

In FIG. 18, the shaded portions show the rules related to the transition instructed to change. This allows the user to know which rule should be changed in order to realize the transition instructed to change. Note that the output display method may use the state transition table as in the case of FIG. 8 or the if-then type description.

The user refers to the display in FIG. 18 and redefines and inputs the rule determined to require correction. The rule storage file 104 is updated according to the redefinition input. The redefinition of rules at this time includes deletion of events, new creation, deletion of state values, and new creation.

For example, referring to the display of FIG. 18, it is assumed that the user judges that "the event e3:" data guarantee complete "should not occur when the state value is β1"".
Based on the determination, the user inputs the rule {β1, e3, error} as shown in FIG. That is, FIG.
At the intersection of the state β1 in (b) and the data guarantee completion, "error"
Enter. This means that the rule with the rule number 23 among the rules with the affected rule numbers 3, 23 and 38 detected in step 112 is redefined as {β1, e3, error}. The redefined rules are
As shown in FIG. 20, it is modified and stored in the rule storage file 104.

<Rule Reclassification and System State Transition Regeneration Processing> Using the rule storage file 104 updated in step 113 as described above, the rule classification processing in step 105 and the system state transition generation in step 108 are again performed. Perform processing. The content of the processing has already been described.

That is, all the system state transitions are created, edited, and output from the given initial state using the updated rule. At this time, it is desirable in terms of operability if the output display of the system state transition before the rule change can be viewed at the same time. Therefore, the system state transition storage file 110 also saves the system state transition stored immediately before the rule change. As a result, when the system state transition is reproduced and displayed, the display color of the system state transition newly added or deleted under the influence of the change request is changed, highlighted, or blinked. It is possible to display in a mode different from the others.

Further, in order to clearly show the difference between the two system state transitions before and after the rule change, the added portion and the deleted portion may be color-coded and temporarily displayed. Before deciding the content of the temporary display, it is possible to return to the display of the system state transition before the redefinition of the rule. Even if the content of the temporary display is used as the decision item, it is possible to repeatedly request the change. In the specific example, the state transition diagram as shown in FIG. 21 is finally created. As described above, similar processing is repeated until there is no change request.

As described above, according to this embodiment, even in a complicated system in which it is difficult for the user who is the designer to grasp the whole picture of the system state transition, all system states can be edited by only giving individual rules. You can Further, when there is a change request for the generated system state transition, all the affected system state transitions can be output and displayed without omission. In this way, when designing software, there is an effect of preventing the designer from losing his thoughts. Further, high operability can be obtained in inputting and displaying.

Further, since the state transition table which has been conventionally used can be used for inputting, it is possible to obtain the effect that the technique which the designer has up to now can be utilized. Moreover, since it is possible to output using a state transition diagram, it is easy to grasp a complicated system state transition. Furthermore, the designer only needs to specify the change regarding the system state transition, and the computer automatically detects the rule to be redefined. Further, since the influence on the system state transition after the change is displayed without omission, it is possible to obtain the effect of preventing the designer from losing his or her mind.

[0097]

As described above, according to the present invention,
The remarkable effect of providing a method for clarifying the relationship between the rule and the system state transition and supporting the development of control software that operates correctly is provided.

[Brief description of drawings]

FIG. 1 is a process flowchart showing a procedure of a system state transition rule verification support method according to an embodiment of the present invention.

FIG. 2 is a device configuration example for realizing the method of the present embodiment.

FIG. 3 is an example of a screen image for inputting an element state name and a state value.

FIG. 4 is an example of a screen image for inputting an event.

FIG. 5 is an example of a storage format of a status / event definition table.

FIG. 6 is an example of a screen image for inputting an initial state of a system state.

FIG. 7 is an example of a storage format of an initial state table.

FIG. 8 is an example of a screen image for inputting a rule.

FIG. 9 is an example of a rule storage file.

FIG. 10 is a flowchart showing a rule classification process.

FIG. 11 is a diagram showing an example of a rule classification storage file.

FIG. 12 is a diagram illustrating a specific example of a rule classification storage file.

FIG. 13 is a flowchart showing system state transition generation.

FIG. 14 is a diagram showing an example of a system state transition storage file.

FIG. 15 is an example of outputting and displaying the edited system state transition.

FIG. 16 is a diagram showing a specification required by a designer in a system state transition by a solid line.

FIG. 17 is a flowchart showing a process of searching a rule that realizes a system state transition.

FIG. 18 is an example in which a rule correction request instruction is output and displayed.

FIG. 19 is an example of inputting redefinition of a rule.

FIG. 20 is an example showing re-storing of redefined rules.

FIG. 21 is an output example of a system state transition regenerated after reviewing specifications.

[Explanation of symbols]

201 ... Calculator, 202, 205 ... Input device,
203 ... storage device, 204 ... output device.

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Inventor Kenzo Kurihara 1099 Ozenji, Aso-ku, Kawasaki-shi, Kanagawa Incorporated company Hitachi, Ltd. Systems Development Laboratory

Claims (11)

[Claims] 1. A method for supporting verification of a system state of a system in which a system state is defined by a direct product of two or more element states, which triggers a change in a state value which is a possible value of the element state. Inputting a system state transition rule consisting of an event, a state value of the element state before the event occurs, and a state value of the element state after the event occurs; and generating a system state transition based on the rule. A method for supporting verification of a system state transition rule, which comprises a step of displaying. 2. A method for supporting verification of a system state of a system, wherein a system state is defined by a direct product of two or more element states, the method comprising inputting an initial state of each element state, A step of inputting a system state transition rule consisting of a combination of an event that triggers a change of a possible state value, a state value of an element state before the event occurs, and a state value of the element state after the event occurs, , A step of classifying the inputted rule with respect to each of state values and events before and after the transition included in the rule, and using the classified rule, it is possible to execute the initial state of each element state. Search the rules, execute the rules for each event, obtain the state value of each element state after the execution of each rule, combine them, obtain the system state after the event occurs, A system state transition characterized by comprising the step of generating and displaying all system state transitions that can transit from the initial state by repeating the same processing for the newly obtained system state. Rule verification support method. 3. A step of inputting a request for addition or deletion of a transition or a system state in response to the displayed system state transition, and searching a rule to be modified according to the addition or deletion request. And a step of displaying.
A method for supporting verification of the system state transition rule described in. 4. The method according to claim 3, further comprising a step of modifying the displayed rule, and a step of generating and displaying all system state transitions again based on the modified rule. Verification support method for system state transition rules. 5. The system state transition before the rule modification and the system state transition after the rule modification are displayed at the same time.
A method for supporting verification of the system state transition rule described in. 6. The system state transition rule verification support method according to claim 1, wherein the input of the rule is performed for each element state. 7. The system state transition rule verification support method according to claim 6, wherein the input of the rule is performed by displaying a state transition table for each element state and using the state transition table. 8. The input of the rule compares the combination of the state value and the event of the rule which is the current input with the combination of the state value and the event of the existing rule that has been input before, and has the same state value. 8. The verification support method for the system state transition rule according to claim 1, wherein when the combination is an event and an event, the overlapping display is output and displayed. 9. The system state transition is generated by searching for and displaying an unused rule among the rules after generating all system state transitions and displaying the result.
A method for supporting verification of the system state transition rule described in. 10. An apparatus for supporting verification of a system state of a system in which a system state is defined by a direct product of two or more element states, which triggers a change of a state value which is a possible value of the element state. A means for inputting a system state transition rule consisting of an event, a state value of the element state before the event occurrence, and a state value of the element state after the event occurrence, and generating a system state transition based on the rule. A system state transition rule verification support device comprising: means for displaying. 11. An apparatus for supporting verification of a system state of a system in which a system state is defined by a direct product of two or more element states, said means for inputting an initial state of each element state, A means for inputting a system state transition rule consisting of an event that triggers a change in a possible state value, a state value of the element state before the event occurs, and a state value of the element state after the event occurs , Means for classifying the inputted rule with respect to each of state values and events before and after the transition included in the rule, and the above-mentioned method that is executable for the initial state of each element state by using the classified rule. Search the rules, execute the rules for each event, find and combine the state value of each element state after each rule execution, find the system state after the event occurrence, and newly obtain The system state transition rule is characterized by including means for generating and displaying all system state transitions that can transit from the initial state by repeating the same processing for the system state Support device.