Specification verification support device, method, and program

Abstract

To reduce the oversight of errors in verifying system specifications.SOLUTION: A specification verification support device that supports specification verification of an information system includes: a specification registration unit that accepts registration of state transition specifications that specify state transitions due to events in each of a plurality of models, in which the events include events that occur in other models due to state transitions of the models and event constraints that specify violation items that should be regarded as violations in relation to the events when the events occur; and a specification verification unit that verifies whether any event that corresponds to the violation items occurs in the state transition specifications.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present disclosure relates to a technique for verifying a system specification of an information system. [Background technology]

[0002] In the development of an information system, the developer listens to the requirements of the client who is procuring the information system and writes them down as system specifications. After the client and developer confirm the system specifications, the information system is designed and created according to the system specifications. Since errors in the system specifications can cause malfunctions in the information system, verifying the system specifications is important in system development.

[0003] State transition models are sometimes used to describe system specifications. A state transition model is a model that represents, for each object that makes up an information system, the states that the object can take, the events that occur to the object, and the state transitions caused by the events. A state transition model is described as a state transition diagram or a state transition table.

[0004] Patent Document 1 discloses a device for editing a state transition table. The state transition table editing device in Patent Document 1 allows a system verifier to specify simplification of state transition specifications from a viewpoint based on a sequence diagram, enabling the verifier to correctly simplify the state transition specifications. The state transition table editing device displays a sequence diagram, prompts the verifier to input a viewpoint for degeneration of the state transition table and a portion in the sequence diagram to be degenerated, determines the content of degeneration of the state transition table based on the input viewpoint for degeneration of the state transition table and the portion in the sequence diagram to be degenerated, and generates data of the state transition table after degeneration from data representing the original state transition table. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Laid-Open No. 2010-250422 Summary of the Invention [Problem to be solved by the invention]

[0006] According to the disclosure of Patent Document 1, system verification can be supported by simplifying the state transition table based on the viewpoint specified by the verifier. However, the objects whose state transition models are shown in the system specifications are managed as individual, independent entities. Therefore, as the number of objects and their states increases, errors inherent in the system specifications, such as missing states or transitions, or inconsistencies between states, may be overlooked.

[0007] One objective of this disclosure is to provide a technique that allows for a reduction in oversight of errors in the verification of system specifications. [Means for solving the problem]

[0008] A specification verification support device according to one aspect included in the present disclosure is a specification verification support device that supports specification verification of an information system, and includes: a specification registration unit that accepts registration of a state transition specification that specifies state transitions due to events in each of a plurality of models, where the events include events that occur in other models due to the state transition of the model; and an event constraint that specifies violations that should be considered when the event occurs; and a specification verification unit that verifies whether any event that corresponds to the violation has occurred in the state transition specification.

[0009] A specification verification support method according to one aspect included in the present disclosure is a specification verification support method that supports specification verification of an information system, in which an apparatus having a processor and a memory accepts registration of a state transition specification that specifies state transitions due to events in each of a plurality of models, where the events include events that occur in other models due to the state transition of the model, and event constraints that specify violations that should be considered when the event occurs, and verifies whether any event that corresponds to the violation has occurred in the state transition specification.

[0010] A specification verification support program according to one aspect included in the present disclosure is a specification verification support program that supports specification verification of an information system, and causes an apparatus having a processor and memory to accept registration of state transition specifications that specify state transitions due to events in each of a plurality of models, where the events include events that occur in other models due to the state transition of one model, and event constraints that specify violations that should be considered when the event occurs, and to verify whether any events that correspond to the violations have occurred in the state transition specifications. [Effects of the Invention]

[0011] According to one aspect of the present disclosure, it is possible to reduce oversight of violations in verifying a system specification. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a conceptual diagram illustrating an example of a hardware configuration of a specification verification support device according to at least one embodiment of the present disclosure. [Figure 2] FIG. 1 is a conceptual diagram illustrating an internal structure of formulated specification data according to at least one embodiment of the present disclosure. [Figure 3] 1 is a flowchart illustrating a system specification determination process, according to at least one embodiment of the present disclosure. [Figure 4]FIG. 1 is a conceptual diagram illustrating a format of formalized specification data according to at least one embodiment of the present disclosure. [Figure 5] 10 is a flowchart illustrating a system specification registration process according to at least one embodiment of the present disclosure. [Figure 6] 10 is a flowchart illustrating a system specification registration process according to at least one embodiment of the present disclosure. [Figure 7] 10 is a flowchart illustrating an example of an event registration (standard) process according to at least one embodiment of the present disclosure. [Figure 8] FIG. 10 is a diagram illustrating a processing example of an event registration (standard) process according to at least one of the embodiments of the present disclosure. [Figure 9] 10 is a flowchart illustrating an event registration (exception) process according to at least one embodiment of the present disclosure. [Figure 10] FIG. 10 is a diagram illustrating a processing example of an event registration (exception) process according to at least one of the embodiments of the present disclosure. [Figure 11] 10 is a flowchart illustrating an event registration (sub-event) process according to at least one embodiment of the present disclosure. [Figure 12] FIG. 10 is a diagram illustrating a processing example of an event registration (sub-event) process according to at least one of the embodiments of the present disclosure. [Figure 13] 10 is a flowchart illustrating an event registration (procedure result) process according to at least one embodiment of the present disclosure. [Figure 14] FIG. 10 is a diagram illustrating a processing example of an event registration (procedure result) process according to at least one of the embodiments of the present disclosure. [Figure 15] 10 is a flowchart illustrating a constraint registration process according to at least one embodiment of the present disclosure. [Figure 16] 1 is a flowchart illustrating a system validation process according to at least one embodiment of the present disclosure. [Figure 17]FIG. 10 is a conceptual diagram illustrating a format of specification verification result data according to at least one of the embodiments of the present disclosure. [Figure 18] 10 is a flowchart illustrating a system comparison verification process according to at least one embodiment of the present disclosure. [Figure 19] FIG. 10 is a conceptual diagram illustrating a format of specification comparison result data according to at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, embodiments of the present invention will be described with reference to the drawings. Note that the examples described below do not limit the invention according to the claims. Furthermore, not all of the elements and combinations thereof described in the examples are necessarily essential to the solution of the invention.

[0014] FIG. 1 is a conceptual diagram illustrating an example of a hardware configuration of a specification verification support device corresponding to at least one of the embodiments of the present disclosure.

[0015] The specification verification support device 1 includes a processor and a memory (not shown).

[0016] The processor is configured, for example, by a central processing unit (CPU), a micro processing unit (MPU), a graphics processing unit (GPU), a field-programmable gate array (FPGA), or the like.

[0017] A memory is a device that stores programs and data, and is, for example, a random access memory (RAM), a read only memory (ROM), or a non-volatile semiconductor memory (Non-Volatile RAM (NVRAM)).

[0018] The memory may be, for example, a device for reading and writing recording media such as a Hard Disc Drive (HDD), a Solid State Drive (SSD), a storage system, an Integrated Circuit (IC) card, a Secure Digital (SD) memory card, or an optical recording medium (Compact Disc (CD), Digital Versatile Disc (DVD), etc.).

[0019] The processor reads and executes various programs, such as a specification verification support program, stored in memory, thereby realizing a data management unit 10, a specification registration unit 20, a specification verification unit 30, and a specification comparison unit 40.

[0020] The data management unit 10 manages the system specification 110, the specification verification result data 120, and the specification comparison result data 130, which are data stored in the memory of the specification verification support device 1 or in a storage device of an external device seen from the specification verification support device 1.

[0021] The system specification 110 includes formalized specification data corresponding to one or more information systems. Formalized specification data refers to data related to the specifications of an information system that is formulated as a single data structure according to a predetermined standard. Data related to the specifications of an information system refers to, for example, data in natural language format or UML format, but is not limited to these formats. In the illustrated example, the system specification 110 includes formalized specification data 111 for system 1 and formalized specification data 112 for system 2. The system specification 110 may similarly include formalized specification data for other systems.

[0022] The specification registration unit 20 accepts registration of a state transition specification 111A that specifies state transitions due to events for each of a plurality of models, where the events include events that occur in other models due to state transitions of the model, and an event constraint 111B that specifies violations that should be considered when the event occurs.

[0023] That is, the state transition specification 111A and the event constraint 111B are data registered by the specification registration unit 20.

[0024] The specification verification unit 30 verifies whether or not any event occurs that violates the state transition specification 111A.

[0025] That is, the specification verification unit 30 acquires data on the state transition specification 111A and the event constraint 111B, verifies whether or not an event that violates the state transition specification 111A specified by the event constraint 111B has occurred, and outputs the result as specification verification result data 120.

[0026] The specification comparison unit 40 stores in advance a comparison state transition specification for comparison with the state transition specification 111A, and compares the state transition specification 111A with the comparison state transition specification to extract differences.

[0027] The specification comparison unit 40 compares state transition specifications among a plurality of specifications. In FIG. 1, a state transition specification 111A included in the system 1 formulated specification data 111 is compared with a state transition specification (corresponding to a comparison state transition specification) included in the system 2 formulated specification data 112. Here, the system 1 formulated specification data 111 and the system 2 formulated specification data 112 registered by the specification registration unit 20 are both formulated according to a predetermined standard. This makes it possible to mechanically perform the above-mentioned comparison. The specification comparison unit 40 outputs the comparison result, i.e., data related to the differences extracted by the comparison between the state transition specification and the comparison state transition specification, as specification comparison result data 130.

[0028] In addition to the above-mentioned components, the specification verification support device 1 may also include at least one of an input device, an output device, and a communication device. The processor, memory, input device, output device, and communication device included in the specification verification support device 1 are communicably connected to each other via communication means such as a bus.

[0029] An input device is a device that accepts input from a user, and examples of the input device include a keyboard, a mouse, a touch panel, a card reader, and a voice input device.

[0030] An output device is a device that provides users with various information such as processing progress and results. Examples of output devices include screen display devices (Liquid Crystal Displays (LCDs), Head Mounted Displays (HMDs), etc.), audio output devices, and printers.

[0031] A communication device is a wired or wireless communication interface that enables communication with other devices via communication means such as a Local Area Network (LAN) or the Internet, and is, for example, a Network Interface Card (NIC), a wireless communication module, a Universal Serial Interface (USB) module, or a serial communication module.

[0032] The specification verification support device 1 may be configured to input and output information to and from other devices via a communication device.

[0033] FIG. 2 is a conceptual diagram illustrating the internal structure of the formulation specification data according to at least one embodiment of the present disclosure.

[0034] The formalized specification data in Fig. 2 corresponds to, for example, the system 1 formalized specification data 111 in Fig. 1. The formalized specification data is a representation of the specifications of one information system based on at least multiple models and inter-model events.

[0035] A model corresponds to a single process, such as "order entry" in an e-commerce system. A model includes state transition specification data and event constraint data. Models are connected by inter-model events.

[0036] State transition specification data is data that specifies state transitions due to events for each of multiple models. An event refers to any event or action that occurs in an information system. For example, receiving a message indicating that a product has been shipped or sending a message indicating that a product has been shipped to another processing unit, device, or system is an event that corresponds to this definition. Events include events that occur in other models due to the state transitions of a model.

[0037] The event constraint data is data that defines violations that should be considered when an event occurs.

[0038] As conceptually shown in Figure 2, the specifications of an information system are formulated according to a predetermined standard that connects multiple models with inter-model events, making it easier to discover overlooked or missing considerations in the specifications. Furthermore, because the specification data formulated as described above is structured according to a unified standard, it becomes easy to compare specifications between multiple information systems. A more specific example of the format of such formulated specification data will be described later with reference to Figure 4.

[0039] 3 is a flowchart illustrating a system specification determination process corresponding to at least one of the embodiments of the present disclosure. Hereinafter, each process described as being performed by the specification verification support device 1, the specification registration unit 20, the specification verification unit 30, or the specification comparison unit 40 may be performed mechanically by each processing unit, or may be performed by requesting user input from a user such as a person in charge as necessary and using the information entered by the user.

[0040] A person in charge (human) writes the system specifications of the information system in a free format (S11). The free format may be, for example, UML format or natural language format.

[0041] The specification registration unit 20 registers the system specifications (S12). The system specifications are registered in a formalized format. The detailed processing of step S12 will be described later.

[0042] The specification verification unit 30 performs system specification verification (S13). The detailed processing of step S13 will be described later.

[0043] The specification comparison unit 40 performs a system specification comparison and verification (S14). The detailed processing of step S14 will be described later.

[0044] FIG. 4 is a conceptual diagram illustrating a format of the formalized specification data according to at least one embodiment of the present disclosure.

[0045] The formalized specification data includes event information, model information, state transition information, and event constraint information. The state transition information corresponds to the state transition specification 111A in Fig. 1, and the event constraint information corresponds to the event constraint 111B in Fig. 1, respectively.

[0046] The event information has the following items: event name, business procedure name, model name, standard / exception category, and main / subcategory.

[0047] The model information includes a model name as an item.

[0048] The state transition information has the following items: event name, business procedure name, model name, state name, event result, and destination state name.

[0049] The event constraint information includes the event name, the business procedure name, the constraint type, and the constraint content as report items.

[0050] Fig. 5 is a flowchart illustrating a system specification registration process according to at least one embodiment of the present disclosure. Fig. 6 is a flowchart illustrating a system specification registration process according to at least one embodiment of the present disclosure. The system specification registration process shown in Fig. 5 and Fig. 6 corresponds to step S12 in Fig. 3.

[0051] First, the specification registration unit 20 extracts events from the free-form specification description (S21).

[0052] The specification registration unit 20 determines whether or not a model that is the target of the event already exists (S22). If it already exists, the process proceeds to step S23, and if it does not exist, the process proceeds to step S24.

[0053] In step S23, the specification registration unit 20 determines an already existing model as the model that is the target of the event.

[0054] In step S24, the specification registration unit 20 newly registers the model that is the target of the event.

[0055] In step S25, the specification registration unit 20 determines a business procedure name, and in step S26, the specification registration unit 20 determines an event name.

[0056] The specification registration unit 20 determines whether the event is a process that is required under normal circumstances (S27). If the event is a process that is always performed under normal circumstances, the process proceeds to step S28, where the specification registration unit 20 determines the standard / exception classification of the event to be "standard." If the event is a process that is performed when an error occurs, or a process that is required under normal circumstances but is not necessarily performed, the process proceeds to step S29, where the specification registration unit 20 determines the standard / exception classification of the event to be "exception."

[0057] After step S28 or S29, the process proceeds to step S31 shown in FIG.

[0058] In step S31, the specification registration unit 20 determines whether the event in question is an event that changes the state of a part of an attribute of the target model. If the event in question is an event that changes the state of a model, the process proceeds to step S32, where the specification registration unit 20 determines the main / sub-category of the event to be a "main event." If the event in question is an event that changes the state of a part of an attribute of the model, the process proceeds to step S33, where the specification registration unit 20 determines the main / sub-category of the event to be a "sub-event."

[0059] Note that it is not necessary to categorize events as primary / secondary. If multiple events were to be interpreted as different types of events even when they merely change the state of some attributes of a model, the number of event types would increase dramatically, resulting in a large processing load. To avoid this, events that merely change the state of some attributes of a model are managed as secondary events derived from primary events. This helps to reduce the increase in processing load.

[0060] In step S34, the specification registration unit 20 determines whether or not there are any unprocessed events in the free-form specification description. If there are any unprocessed events, the process proceeds to step S21 in Fig. 5, where the specification registration unit 20 extracts and processes the next unprocessed event. If there are no unprocessed events, the process proceeds to step S35.

[0061] The specification registration unit 20 performs an event registration (standard) process (S35), an event registration (exception) process (S36), and an event registration (sub-event) process (S37).

[0062] The specification registration unit 20 performs an event registration (procedure result) process (S38) and a constraint condition registration process (S39).

[0063] The detailed processes of steps S35 to S39 will be described later.

[0064] 7 is a flowchart illustrating an example of an event registration (standard) process according to at least one embodiment of the present disclosure. The event registration (standard) process corresponds to step S35 in FIG.

[0065] The specification registration unit 20 registers an event (standard) in the target model (S41).

[0066] The specification registration unit 20 determines whether or not there is an unregistered event (S42). If there is an unregistered event, the process returns to step S41, where the specification registration unit 20 registers the next event. If there is no unregistered event, the process proceeds to step S43.

[0067] In step S43, the specification registration unit 20 determines the state transition of the model due to the event. That is, it determines how the state of the target model will transition due to the event. This determination process may be performed by the specification registration unit 20 outputting information to an output device such as a monitor so that the person in charge can input or select the state transition of the model due to the event, and accepting user input, for example. For example, the person in charge specifies the order between events using an input device. The specification registration unit 20 determines the state transition according to the specified order.

[0068] The specification registration unit 20 determines whether there is an event whose state transition is not registered (S44). If there is an event whose state transition is not registered, the process returns to step S43. If there is no event whose state transition is not registered, the process shown in FIG. 7 ends.

[0069] 8 is a diagram illustrating an example of an event registration (standard) process corresponding to at least one of the embodiments of the present disclosure, in which standard events numbered 1 to 5 are added to a model (order).

[0070] The model (order) has six states: initial state S0, order received state S1, inventory confirmed state S2, prepared for shipping state S3, shipped state S4, and completed state S5. The states change depending on the occurrence of some event.

[0071] Five events were registered in the model (order) according to the flow shown in Figure 7. For example, the following event was registered as number 1: Event: Order Placed Business Procedures: Order Entry Model: Order Standard / Exception classification: Standard

[0072] Similarly, Figure 8 shows the results of registering events numbered 2 to 5. The "Procedure Result" column in the registered data is blank at this point. The state transition (see step S43 in Figure 8) column is set to the setting value shown in Figure 8. For example, if the event "Order Placed" occurs in state S0, the state transitions from S0 to S1. "E" in the state transition column indicates an error. For example, it is strange for a shipping preparation event to occur in state S4 (shipped). In such a case, the information system needs to perform some kind of error processing, so "E" is set as the setting value in the state transition column. The setting value "-" in the state transition column indicates that the state transition in question cannot occur in the first place.

[0073] 9 is a flowchart illustrating an event registration (exception) process according to at least one embodiment of the present disclosure. The event registration (exception) process corresponds to step S36 in FIG.

[0074] The specification registration unit 20 registers an event (exception) in the target model (S51).

[0075] The specification registration unit 20 determines whether or not there is an unregistered event (S52). If there is an unregistered event, the process returns to step S51, where the specification registration unit 20 registers the next event. If there is no unregistered event, the process proceeds to step S53.

[0076] In step S53, the specification registration unit 20 determines the state transition of the model due to the event (exception). That is, it determines how the state of the target model will transition due to the exceptional event. This determination process may be performed by the specification registration unit 20 outputting information to an output device such as a monitor so that the person in charge can input or select the state transition of the model due to the event, and accepting user input, for example. For example, the person in charge specifies the order between events using an input device. The specification registration unit 20 determines the state transition according to the specified order.

[0077] The specification registration unit 20 determines whether or not there is an event whose state transition is not registered (S54). If there is an event whose state transition is not registered, the process returns to step S53. If there is no event whose state transition is not registered, the process proceeds to step S55.

[0078] In step S55, the specification registration unit 20 determines whether or not there is a state to be added to the model due to the event (exception). If there is a state to be added, the process proceeds to step S56. If there is no state to be added, the process shown in FIG. 9 ends.

[0079] In step S56, the specification registration unit 20 adds a state to the model and determines the transition of the state due to an event (standard).

[0080] 10 is a diagram illustrating an example of an event registration (exception) process according to at least one of the embodiments of the present disclosure, illustrating a case where an exception event number 6 is added to a model (order).

[0081] As mentioned above, the model (order) has six states: the initial state S0, the order received state S1, the stock confirmed state S2, the prepared for shipping state S3, the shipped state S4, and the completed state S5, and the states transition depending on the occurrence of some event.Five standard events have already been registered in the model (order) according to the flow shown in Figure 7.

[0082] A new exceptional event is registered in the model (order) according to the flow shown in Figure 9. For example, the following event is registered as number 6.

[0083] Event:Cancelled Business Procedures:- Model: Order Standard / Exception classification: Exception

[0084] The result of registering exception event number 6 is shown in Figure 10. The "Procedure Result" column in the registered data is blank at this point. The meanings of the setting values ​​"E" and "-" in the state transition column are the same as those described above with reference to Figure 8, so a detailed explanation will be omitted.

[0085] If an exception event requires an addition to the state transition of the model, the addition is made (see step S56 in FIG. 9). Although not shown, for example, a new state S6 is added. At this time, the specification registration unit 20 also determines the state transition for state S6. In other words, a setting value is also set in the column for state S6.

[0086] 11 is a flowchart illustrating an event registration (sub-event) process according to at least one embodiment of the present disclosure. The event registration (sub-event) process corresponds to step S37 in FIG.

[0087] The specification registration unit 20 registers the sub-events in the target model and the sub-model (S61). The sub-model will be described later with reference to FIG.

[0088] The specification registration unit 20 determines whether or not there is an unregistered sub-event (S62). If there is an unregistered sub-event, the process returns to step S61, where the specification registration unit 20 registers the next sub-event. If there is no unregistered sub-event, the process proceeds to step S63.

[0089] In step S63, the specification registration unit 20 determines the state transition of the target model due to the sub-event. That is, it determines how the state of the target model will transition due to the sub-event. This determination process may be performed by the specification verification support device 1 outputting information to an output device such as a monitor so that the person in charge can input or select the state transition of the model due to the sub-event, and accepting user input. For example, the person in charge specifies the order of events using an input device. The specification registration unit 20 determines the state transition according to the specified order.

[0090] The specification registration unit 20 determines whether or not there is a sub-event whose transition destination (state transition) is not registered in the target model (S64). If there is a sub-event whose transition destination (state transition) is not registered, the process returns to step S63. If there is no sub-event whose transition destination (state transition) is not registered, the process proceeds to step S65.

[0091] In step S65, the specification registration unit 20 determines the state transition of the secondary model due to the secondary event. That is, it determines how the state of the target secondary model will transition due to the secondary event. This determination process may be performed by the specification registration unit 20 outputting information to an output device such as a monitor so that the person in charge can input or select the state transition of the secondary model due to the secondary event, and accepting user input. For example, the person in charge specifies the order between events using an input device. The specification registration unit 20 determines the state transition according to the specified order.

[0092] The specification registration unit 20 determines whether or not there is a sub-event whose transition destination (state transition) is not registered in the sub-model (S66). If there is a sub-event whose transition destination (state transition) is not registered, the process returns to step S65. If there is no sub-event whose transition destination (state transition) is not registered, the process shown in FIG. 11 ends.

[0093] FIG. 12 is a diagram illustrating a processing example of an event registration (sub-event) process corresponding to at least one of the embodiments of the present disclosure.

[0094] As a result of performing the event registration (sub-event) process shown in Figure 11 from the registration state shown in Figure 10, the event "Deposit" and the event "Refund" were added to the target model. Number 7 is the event "Deposit". Number 8 is the event "Refund". In addition, events similar to numbers 1 to 8 added to the target model were added to the sub-model.

[0095] Here, we will explain sub-models. A sub-model is a model derived from a target model (main model). The specification registration unit 20 registers and manages state transitions for each model. Therefore, as the number of target models increases, the structure of the formalized specification data (see Figure 2) becomes more complex, and the processing load for various processes based on the formalized specification data also increases. Therefore, models that only differ in some attributes from the target model are not treated as main models, but as derived models (sub-models) subordinate to the main model. The state transition specification then defines transitions by treating secondary states derived from specific states of a model (main model) as states of the sub-models of the model. This prevents an explosive increase in the number of model types and reduces the processing load.

[0096] In the example shown in Figure 12, the main model (order) has six states: initial state S0, order received state S1, inventory confirmed state S2, ready to ship state S3, shipped state S4, and completed state S5, and the states transition depending on the occurrence of some event. On the other hand, the sub-model (payment state) derived from the main model (order) has five states: initial state SS0, waiting for payment state SS1, paid state SS2, waiting for refund state SS3, and refunded state SS4, and the states transition depending on the occurrence of some event.

[0097] Sub-events are registered in the model (order) and the sub-model (deposit processing) derived from the model (order) according to the flow shown in Figure 11. For example, the following sub-event "deposit" is registered:

[0098] Event: Deposit Business Procedures:- Model: Order Standard / Exception classification: Standard Main / Subdivision: Sub

[0099] The secondary event "refund" is also registered in the same way.

[0100] The result of registering these secondary events is shown in Figure 12. The meanings of the setting values ​​"E" and "-" in the State Transition column are the same as those described above with reference to Figure 8, so a detailed explanation will be omitted. The setting value "(SS)" in the State Transition column means that a state transition does not occur in the main model, but that the generated event is managed by the secondary model.

[0101] 13 is a flowchart illustrating an event registration (procedure result) process according to at least one of the embodiments of the present disclosure. The event registration (procedure result) process corresponds to step S38 in FIG.

[0102] The procedure result fields in the models (main model and sub-model) were blank at the end of step S37 in Fig. 6. By the event registration (procedure result) process, a setting value is set in the procedure result field.

[0103] The specification registration unit 20 records (sets) the procedure results of the target model (S71).

[0104] The specification registration unit 20 determines whether or not there is a line in the target model where the procedure result is not yet described (S72). If there is a line where the procedure result is not yet described, the process returns to step S71, where the specification registration unit 20 describes the next procedure result. If there is no line where the procedure result is not yet described, the process proceeds to step S73.

[0105] The specification registration unit 20 divides the event and determines the procedure result and state transition (S73).

[0106] The specification registration unit 20 determines whether or not there are any lines in the target model where the procedure result and state transition are not yet described (S74). If there are any lines where the procedure result and state transition are not yet described, the process returns to step S73. If there are no lines where the procedure result and state transition are not yet described, the process proceeds to step S75.

[0107] The specification registration unit 20 determines whether there is a state to add to the target model (S75). If there is a state to add, the process proceeds to step S76. If there is no state to add, the process shown in FIG. 13 ends.

[0108] In step S76, the specification registration unit 20 adds a state to the target model, and determines a state transition due to an existing (already registered) event for the added state (S76).

[0109] FIG. 14 is a diagram illustrating a processing example of an event registration (procedure result) process corresponding to at least one of the embodiments of the present disclosure.

[0110] In step S71, an entry is made in the procedure result field for the "Order" model. Entering means setting a set value. Here, when the "Prepare for Shipping" event occurs, the business procedure on the information system side is an inventory check. Because inventory is not always available in reality, the procedure results of the business procedure are divided into two cases: when inventory is available and when inventory is not available. Regarding the arrival of goods, in reality, all goods may arrive, or only some goods may arrive (with the remaining goods arriving at different times). Therefore, the procedure results are divided into two cases: when some goods arrive and when all goods arrive. In this way, when considering the specific business procedure at the time an event occurs, if the outcome of the procedure can branch into two or more outcomes, the event is divided. As an example shown in Figure 14, the process in step S73 divided the event "Prepare for Shipping" (number 2) into four events: number 2, number 2-1, number 2-2, and number 2-3. Then, the procedure results and state transitions are determined and set as set values.

[0111] In step S75, it is determined that a state of waiting for arrival needs to be added to the model "order", so in step S76, state S11 (waiting for arrival) is added. The state transition due to existing events of the added state S11 (waiting for arrival) is set as the setting value. The existing events here refer to the events numbered 1 to 8, and also include the events numbered 2-1, 2-2, and 2-3 after division.

[0112] That is, when there are multiple procedure results in a business procedure corresponding to an event to a model, the specification registration unit 20 divides the event to the model into multiple events corresponding to the procedure results in the state transition specification, and accepts registration in the state transition specification of the states that are added as a result of the event being divided into multiple events and the state transitions related to the added states.

[0113] 15 is a flowchart illustrating a constraint condition registration process according to at least one of the embodiments of the present disclosure. The constraint condition registration process corresponds to step S39 in FIG.

[0114] The specification registration unit 20 registers event constraints (occurrence order) (S81). More specifically, it registers in the system specification 110 what prerequisite events must have already occurred before a certain event occurs. For example, an order occurrence event must have already occurred before a deposit event. Therefore, the above event constraints are registered so that a case in which a deposit event occurs even though an order occurrence event has not occurred can be extracted as a contradiction in the specification.

[0115] The above event constraint that specifies the order in which multiple events occur is referred to as the first constraint. In step S92, which will be described later, the specification verification unit 30 checks whether events in the state transition specification may occur in an order different from the order specified in the first constraint.

[0116] The specification registration unit 20 registers the event constraint (occurrence time) (S82). More specifically, the specific time when the event occurs is registered in the system specification 110. This makes it possible to extract an event that occurs at a time different from the registered time as a contradiction in the specification.

[0117] The above event constraint that specifies the timing of an event occurrence is referred to as the second constraint. In step S92 described below, the specification verification unit 30 checks whether an event may occur at a time different from the time specified in the second constraint in the state transition specification.

[0118] The specification registration unit 20 registers the event constraints (model CRUD) (S83). CRUD is a coined word made up of the initial letters of Create, Refer, Update, and Delete (D). That is, the specification registration unit 20 registers in the system specification 110 what information, objects, etc. are created, referred to, updated, or deleted in the information system's processing in response to the occurrence of an event for the target model. This allows for the extraction of a clearly irrational sequence of events from a CRUD perspective as a contradiction in the specification when multiple events are arranged in chronological order. For example, an event sequence in which information is referred to (R), updated (U), or deleted (D) before it has yet to be created (C) is clearly irrational. Similarly, an event sequence in which information is referred to (R) or updated (U) after it has been deleted (D) is clearly irrational. The registered CRUD information is used to check whether such an event sequence is clearly irrational.

[0119] That is, the model includes a model that generates, references, updates, or deletes information in response to the occurrence of an event. The above event constraint that specifies the order in which information is created, read, updated, or deleted by the model is referred to as the third constraint. In step S92, which will be described later, the specification verification unit 30 checks whether information is created, read, updated, or deleted in an order different from the order specified in the third constraint in the state transition specification.

[0120] The specification registration unit 20 registers the event constraints (secondary model CRUD) (S84). The contents of the information to be registered are the same as those in step S83. In step S84, for the secondary model, what data is created, referenced, updated, or deleted in the processing of the information system in response to the occurrence of an event is registered in the system specification 110.

[0121] That is, the secondary model includes a model that generates, references, updates, or deletes information in response to the occurrence of an event. The event constraint that specifies the order in which information is created, read, updated, or deleted by the secondary model is referred to as the fourth constraint. In step S92, which will be described later, the specification verification unit 30 checks whether information is created, read, updated, or deleted in an order different from the order specified in the fourth constraint in the state transition specification.

[0122] 16 is a flowchart illustrating a system verification process according to at least one embodiment of the present disclosure. The system verification process corresponds to step S13 in FIG.

[0123] The specification verification unit 30 checks for unspecified items (S91). For example, if there is a point in the target model or sub-model where the state transition destination is not set for each event, the specification verification unit 30 extracts that point as a contradiction.

[0124] The specification verification unit 30 checks for constraint violations (S92). More specifically, the specification verification unit 30 checks all combinations of events and state transitions based on the formalized specification data registered in the system specifications 110. If, in checking all of these combinations, an inconsistency based on the various event constraints (see FIG. 15) registered by the specification registration unit 20 is discovered, the inconsistency is extracted as a contradiction.

[0125] The specification verification unit 30 outputs the inconsistencies (S93). That is, the inconsistencies extracted in step S91 or step S92 are output via an output device. For example, if the output device is a monitor, a list of the extracted inconsistencies is displayed on the monitor as the check results.

[0126] Based on the output information indicating the inconsistencies, the person in charge corrects the inconsistencies. Based on the correction input by the person in charge, the specification registration unit 20 registers various information in the system specification 110 in the same manner as described above with reference to Figures 5 to 15 (S94).

[0127] FIG. 17 is a conceptual diagram illustrating a format of specification verification result data corresponding to at least one of the embodiments of the present disclosure.

[0128] The specification verification result data 120 includes specification contradiction information. The specification contradiction information is used in the contradiction output process in step S93. Fig. 16 shows a format that expresses the contradictions regarding state transitions in the specification contradiction information.

[0129] 17 has the following items: model 1, state name 1, model 2, state name 2, name of the event that occurred, and reason for the transition being impossible. That is, when a transition from a certain state of model 1 (state name 1) to a certain state of model 2 (state name 2) fails, the name of the event that occurred that caused the transition and the reason for the state transition being impossible are recorded as specification contradiction information in the specification verification result data 120. Note that for contradictions related to state transitions within the same model, the item for model 1 or model 2 can be left blank, or the same model as that set for model 1 can be set for model 2.

[0130] The format of the specification contradiction information is not limited to that shown in FIG. 17, and a person skilled in the art may set a format according to the content of the contradiction as appropriate.

[0131] 18 is a flowchart illustrating a system specification comparison and verification process according to at least one embodiment of the present disclosure. The system specification comparison and verification process corresponds to step S14 in FIG.

[0132] The specification comparison unit 40 performs a system specification comparison process (S101). The system specification comparison process will be described in detail later. The results of the system specification comparison process are stored as specification comparison result data 130, and the data management unit 10 manages the specification comparison result data 130.

[0133] The specification comparison unit 40 outputs the differences in the system specifications (S102). That is, the differences in the system specifications extracted in step S101 are output via an output device. For example, if the output device is a monitor, a list of the extracted differences is displayed on the monitor as the check result.

[0134] Based on the output information indicating the differences, the person in charge modifies the system specifications. Based on the modification input by the person in charge, the specification registration unit 20 registers various information in the system specifications 110 in the same manner as described above with reference to Figures 5 to 15 (S103).

[0135] Next, the details of the system specification comparison process will be explained. The system specification comparison is performed between the specifications of multiple systems based on the formalized specification data shown in FIG. 2. For example, the system 1 formalized specification data 111 and the system 2 formalized specification data 112 shown in FIG. 1 are compared. Note that the specifications of three or more types of systems may be compared simultaneously. The following explanation will be given using an example where the specifications of two types of systems are compared.

[0136] The specification comparison unit 40 compares the model configurations (S111). More specifically, it compares the lists of models present in the systems between the specifications of multiple systems. This comparison corresponds to a model configuration comparison in which a list of models present in the state transition specifications is compared with a list of models present in the comparison state transition specifications to extract any excess or deficiency of models.

[0137] The specification comparison unit 40 compares the event configurations (S112). More specifically, it compares the event lists for each model between the specifications of multiple systems. This comparison corresponds to an event configuration comparison in which, for each model in the state transition specification, the event list is compared with the model in the comparison state transition specification corresponding to the model to extract any excess or deficiency of events.

[0138] The specification comparison unit 40 compares the state configurations (S113). More specifically, it compares the state lists for each model between the specifications of multiple systems. This comparison corresponds to a state configuration comparison in which, for each model in the state transition specification, the list of states is compared with the model in the comparison state transition specification corresponding to that model to extract any excess or deficiency of states.

[0139] The specification comparison unit 40 compares the transition destination configurations (S114). More specifically, the transition destinations when the same event occurs for each model are compared between the specifications of multiple systems. This comparison corresponds to a transition destination comparison in which, for each model in the state transition specification, the transition destination states for the corresponding events are compared with the model in the comparison state transition specification, and differences in the transition destinations are extracted.

[0140] The specification comparison unit 40 compares the constraints (S115). More specifically, the list of registered event constraints (violations) is compared between the specifications of a plurality of systems.

[0141] Here, the system specifications including the data related to the event constraints are stored in advance as the above-mentioned formalized specification data in a format conforming to a predetermined standard in the system specifications 110. Therefore, the specification comparison unit 40 can mechanically perform the above-mentioned comparison between the specifications of a plurality of systems.

[0142] The above-mentioned comparison of constraints corresponds to a constraint comparison in which a comparison event constraint, which is an event constraint corresponding to a comparison state transition specification, is stored in advance, and the specification comparison unit 40 compares a list of violations between the event constraint corresponding to the state transition specification and the comparison event constraint to extract excesses and deficiencies in violations.

[0143] FIG. 19 is a conceptual diagram illustrating a format of specification comparison result data, according to at least one embodiment of the present disclosure.

[0144] The specification comparison result data 130 includes specification contradiction information, difference information (model configuration comparison), difference information (event configuration comparison), difference information (state configuration comparison), difference information (transition destination comparison), and difference information (constraint comparison). Note that the classification of each piece of information and the information format shown in Fig. 19 are merely examples, and a person skilled in the art may appropriately set the classification and format according to the content of the specification comparison result to be obtained.

[0145] The specification contradiction information includes, as items, a system name 1, a system name 2, and difference information. The difference information in the specification contradiction information corresponds to at least one of difference information (model configuration comparison), difference information (event configuration comparison), difference information (state configuration comparison), difference information (transition destination comparison), and difference information (constraint comparison).

[0146] The difference information (model configuration comparison) includes the model name and the name of the system that does not have it as items. For example, if system A has a model "Deposit," but system B does not have a model "Deposit," the difference information (model configuration comparison) will be (Deposit, System B). Note that the handling of the item "Name of the system that does not have it" is the same for other difference information described below, so detailed explanation will be omitted hereafter to avoid duplication.

[0147] The difference information (event configuration comparison) includes items such as the event name, the business procedure name, the model name, and the name of the system that does not have the event.

[0148] The difference information (state configuration comparison) includes items such as the model name, the state name, and the name of the system that does not have the item.

[0149] The difference information (transition destination comparison) includes the following items: event name, business procedure name, model name, state name, transition destination of system 1, and transition destination of system 2. The transition destination here means the state (state name) of the transition destination.

[0150] The difference information (constraint comparison) includes the following items: event name, business procedure name, constraint type, constraint content, and the name of the system that does not have the constraint. The constraint type refers to types such as "occurrence order," "occurrence time," "model CRUD," and "sub-model CRUD" in Figure 15.

[0151] The above-described embodiments of the present invention are merely illustrative examples of the present invention, and are not intended to limit the scope of the present invention to these embodiments alone. Those skilled in the art can implement the present invention in various other forms without departing from the scope of the present invention.

[0152] As described above, the specification verification support device 1 that supports specification verification of an information system includes a specification registration unit 20 that accepts registration of a state transition specification 111A that specifies state transitions due to events in each of a plurality of models, where the events include events that occur in other models due to the state transition of the model, and an event constraint 111B that specifies violations that should be considered when the event occurs. The specification verification support device 1 also includes a specification verification unit 30 that verifies whether any events that fall under the violations in the state transition specification 111A have occurred. This registers the state transition specification, including events that occur in other models due to the state transition of the model, and checks whether any events that fall under the violations in the state transition specification have occurred during verification of the system specification, thereby reducing the chance of overlooking errors in the system specification.

[0153] The specification verification support device 1 further includes a specification comparison unit 40 that stores in advance a comparison state transition specification for comparison with the state transition specification 111A, and compares the comparison state transition specification with the state transition specification 111A to extract differences. This makes it possible to support the discovery of errors in the system specifications by comparing the state transition specification with, for example, a state transition specification of a proven information system of the same type and presenting the differences.

[0154] The specification comparison unit 40 performs at least one of the following: a model configuration comparison that compares a list of models in the state transition specification 111A with a list of models in the comparison state transition specification to extract whether there are any excess or deficiencies in the models; an event configuration comparison that compares, for each model in the state transition specification 111A, a list of events with a model in the comparison state transition specification corresponding to that model to extract whether there are any excess or deficiencies in the events; a state configuration comparison that compares, for each model in the state transition specification 111A, a list of states with a model in the comparison state transition specification corresponding to that model to extract whether there are any excess or deficiencies in the states; and a transition destination comparison that compares, for each model in the state transition specification 111A, a model in the comparison state transition specification corresponding to that model to extract differences in the transition destinations for corresponding events. This makes it possible to compare models in the state transition specification and the comparison state transition specification and present the differences, thereby assisting in the discovery of errors in each model in the system specification.

[0155] The specification comparison unit 40 further stores in advance comparison event constraints, which are event constraints corresponding to the comparison state transition specification. The specification comparison unit 40 further performs constraint comparison to compare a list of violations between the event constraints corresponding to the state transition specification 111A and the comparison event constraints, and extracts any excess or deficiency of violations. This allows the system to present event violations between the state transition specification and the comparison state transition specification, thereby assisting in the discovery of errors related to the event constraints in the system specification.

[0156] The event constraints include a first constraint that specifies the order in which multiple events occur. The specification verification unit 30 checks whether events in the state transition specification 111A occur in an order different from the order specified in the first constraint. This makes it possible to easily find errors in the system specifications regarding the order in which events occur.

[0157] The event constraint includes a second constraint that specifies when an event occurs. The specification verification unit 30 checks whether an event can occur at a time different from the time specified in the second constraint in the state transition specification 111A. This makes it possible to easily find errors in the system specifications regarding the time when an event occurs.

[0158] The models include models that generate, reference, update, or delete information in response to the occurrence of an event. The event constraints include a third constraint that specifies the order in which information is created, read, updated, or deleted by the model. The specification verification unit 30 checks whether information is created, read, updated, or deleted in an order different from the order specified in the third constraint in the state transition specification. This makes it possible to verify the consistency of the order of events across models, such as when information created in one model is read by another model.

[0159] The state transition specification 111A defines transitions by defining secondary states derived from a specific state of a model as states of sub-models of the model. This prevents an explosive increase in the number of combinations of model states and events in the state transition specification including events between models.

[0160] The secondary model includes a model that generates, references, updates, or deletes information in response to the occurrence of an event. The event constraint includes a fourth constraint that specifies the order in which information is created, read, updated, or deleted by the secondary model. The specification verification unit 30 checks whether information is created, read, updated, or deleted in an order different from the order specified in the fourth constraint in the state transition specification. This makes it possible to verify the consistency of the order of events, including the secondary model.

[0161] When a business procedure corresponding to an event to a model has multiple procedure results, the specification registration unit 20 divides the event to the model into multiple events corresponding to the procedure results in the state transition specification 111A, and accepts registration of states that are added as a result of the event being divided into multiple events and state transitions related to the added states in the state transition specification 111A. This makes it possible to support the registration of state transition specifications that can execute verification of system specifications that include events that occur in other models due to state transitions of a model.

[0162] In a specification verification support method for supporting specification verification of an information system, a device 1 having a processor and a memory accepts registration of a state transition specification 111A that specifies state transitions due to events in each of a plurality of models, where the events include events that occur in other models due to the state transition of the model, and an event constraint 111B that specifies violations that should be considered when the event occurs, and verifies whether any event that corresponds to the violation has occurred in the state transition specification 111A. In this way, the state transition specification that includes events that occur in other models due to the state transition of the model is registered, and in verifying the system specification, it is checked whether any event that corresponds to the violation has occurred according to the state transition specification, thereby reducing the oversight of errors in the system specification.

[0163] A specification verification support program that supports specification verification of an information system causes a device 1 equipped with a processor and a memory to accept registration of a state transition specification 111A that specifies state transitions due to events in each of a plurality of models, where the events include events that occur in other models due to the state transition of the model, and an event constraint 111B that specifies violations that should be considered when the event occurs, and to verify whether any events that fall under the violations in the state transition specification have occurred.As a result, the state transition specification that includes events that occur in other models due to the state transition of the model is registered, and in verifying the system specification, it is confirmed whether any events that fall under the violations in the state transition specification have occurred, thereby reducing the chance of errors in the system specification being overlooked. [Explanation of symbols]

[0164] 1...specification verification support device, 10...data management unit, 20...specification registration unit, 30...specification verification unit, 40...specification comparison unit

Claims

1. A specification verification support device that supports specification verification of an information system, comprising: a specification registration unit that accepts registration of state transition specifications that define state transitions due to events in each of a plurality of models, the events including events that occur in other models due to state transitions of the models, and event constraints that define violations that should be considered when the events occur; a specification verification unit that verifies whether or not an event corresponding to the violation in the state transition specification occurs; a specification comparison unit that pre-stores a comparison state transition specification for comparison with the state transition specification, and compares the state transition specification with the comparison state transition specification to extract differences; A specification verification support device having the above configuration.

2. The specification comparison unit a model configuration comparison that compares a list of models in the state transition specification with a list of models in the comparison state transition specification to extract excesses and deficiencies of models; an event configuration comparison for comparing a list of events for each model in the state transition specification with a model in the comparison state transition specification corresponding to the model, and extracting excess or deficiency of events; a state configuration comparison for comparing a list of states for each model in the state transition specification with a model in the comparison state transition specification corresponding to the model, and extracting excess or deficiency of states; a transition destination comparison for comparing, for each model in the state transition specification, a model in the comparison state transition specification corresponding to the model, with a transition destination state for a corresponding event, and extracting a difference in the transition destination; Execute at least one of The specification verification support device according to claim 1.

3. a comparison event constraint corresponding to the comparison state transition specification is further stored in advance; the specification comparison unit further performs a constraint comparison to compare a list of violations between the event constraint corresponding to the state transition specification and the comparison event constraint, and extracts excesses and deficiencies of violations. The specification verification support device according to claim 1.

4. A specification verification support device for supporting specification verification of an information system, comprising: a specification registration unit that accepts registration of state transition specifications that define state transitions due to events in each of a plurality of models, the events including events that occur in other models due to state transitions of the models, and event constraints that define violations that should be considered when the events occur; a specification verification unit that verifies whether or not an event corresponding to the violation in the state transition specification occurs; and The model includes a model that generates, references, updates, or deletes information in response to an occurrence of an event; the event constraints include a third constraint that specifies the order in which information is created, read, updated, and deleted by the model; the specification verification unit checks whether or not information is created, read, updated, or deleted in an order different from the order defined in the third constraint in the state transition specification. Specification verification support device.

5. A specification verification support device for supporting specification verification of an information system, comprising: a specification registration unit that accepts registration of state transition specifications that define state transitions due to events in each of a plurality of models, the events including events that occur in other models due to state transitions of the models, and event constraints that define violations that should be considered when the events occur; a specification verification unit that verifies whether or not an event corresponding to the violation in the state transition specification occurs; and When a business procedure corresponding to an event to a model has a plurality of procedure results, the specification registration unit divides the event to the model into a plurality of events corresponding to the procedure results in the state transition specification, and accepts registration of states that are added as a result of the event being divided into a plurality of events and state transitions related to the added states in the state transition specification. Specification verification support device.

6. A specification verification support method for supporting specification verification of an information system, comprising:

1. An apparatus comprising a processor and a memory, A system that accepts registration of a state transition specification that specifies a state transition due to an event for each of a plurality of models, the state transition specification including an event that occurs in another model due to the state transition of the model, and an event constraint that specifies a violation that should be considered when the event occurs, Verifying whether or not an event corresponding to the violation in the state transition specification has occurred; storing in advance a comparison state transition specification for comparison with the state transition specification, and comparing the state transition specification with the comparison state transition specification to extract differences; A specification verification support method that performs the above.

7. A specification verification support method for supporting specification verification of an information system, comprising:

1. An apparatus comprising a processor and a memory, A system that accepts registration of a state transition specification that specifies a state transition due to an event for each of a plurality of models, the state transition specification including an event that occurs in another model due to the state transition of the model, and an event constraint that specifies a violation that should be considered when the event occurs, verifying whether or not an event corresponding to the violation in the state transition specification has occurred; It is a way of doing things, The model includes a model that generates, references, updates, or deletes information in response to an occurrence of an event; the event constraints include a third constraint that specifies the order in which information is created, read, updated, and deleted by the model; confirming whether or not the state transition specification allows information to be created, read, updated, or deleted in an order different from the order specified in the third constraint; Specification verification support method.

8. A specification verification support method for supporting specification verification of an information system, comprising:

1. An apparatus comprising a processor and a memory, A system that accepts registration of a state transition specification that specifies a state transition due to an event for each of a plurality of models, the state transition specification including an event that occurs in another model due to the state transition of the model, and an event constraint that specifies a violation that should be considered when the event occurs, verifying whether or not an event corresponding to the violation in the state transition specification has occurred; It is a way of doing things, When a business procedure corresponding to an event to a model has multiple procedure results, the state transition specification divides the event to the model into multiple events corresponding to the procedure results, and accepts registration of states that are added as a result of the event being divided into multiple events and state transitions related to the added states in the state transition specification. Specification verification support method.

9. A specification verification support program for supporting specification verification of an information system, An apparatus comprising a processor and a memory, A system that accepts registration of a state transition specification that specifies a state transition due to an event for each of a plurality of models, the state transition specification including an event that occurs in another model due to the state transition of the model, and an event constraint that specifies a violation that should be considered when the event occurs, Verifying whether or not an event corresponding to the violation in the state transition specification has occurred; storing in advance a comparison state transition specification for comparison with the state transition specification, and comparing the state transition specification with the comparison state transition specification to extract differences; A specification verification support program that helps you do this.

10. A specification verification support program for supporting specification verification of an information system, comprising: An apparatus comprising a processor and a memory, A system that accepts registration of a state transition specification that specifies a state transition due to an event for each of a plurality of models, the state transition specification including an event that occurs in another model due to the state transition of the model, and an event constraint that specifies a violation that should be considered when the event occurs, verifying whether or not an event corresponding to the violation in the state transition specification has occurred; It is a program to make it happen, The model includes a model that generates, references, updates, or deletes information in response to an occurrence of an event; the event constraints include a third constraint that specifies the order in which information is created, read, updated, and deleted by the model; checking whether or not information is created, read, updated, or deleted in an order different from the order specified in the third constraint in the state transition specification; Specification verification support program.

11. A specification verification support program for supporting specification verification of an information system, comprising: An apparatus comprising a processor and a memory, A system that accepts registration of a state transition specification that specifies a state transition due to an event for each of a plurality of models, the state transition specification including an event that occurs in another model due to the state transition of the model, and an event constraint that specifies a violation that should be considered when the event occurs, verifying whether or not an event corresponding to the violation in the state transition specification has occurred; It is a program to make it happen, When a business procedure corresponding to an event to a model has a plurality of procedure results, the event to the model is divided into a plurality of events corresponding to the procedure results in the state transition specification, and states that are added as a result of the event being divided into a plurality of events and state transitions related to the added states are registered in the state transition specification. Specification verification support program.

Images