JP2011180632A - Device, method and program for verification - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To allow even a general designer not knowing model verification technology well to perform model verification by facilitating creation of an input model. <P>SOLUTION: In this verification device 20, a domain specialization model (a verification target) generation part 24 generates the domain specialization model (the verification target) wherein a specification of a specific system is described according to a domain specialization model grammar from a UML (Unified Modeling Language) model 13 (the verification target) wherein the specification of the system is described in UML based on a "UML model To domain specialization model mapping rule". A model verification code generation part 27 generates a model verification code wherein the specification of the system is described, from the domain specialization model (the verification target) based on a "domain specialization model To model verification code mapping rule". A model verification execution part 30 executes Spin with the model verification code as input, and acquires data indicating a counter example of the specification of the system as a verification result (the counter example). <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a verification apparatus, a verification method, and a verification program. The present invention particularly relates to a design model verification method.

  Conventionally, in design specification verification using a model verification tool such as Spin (also referred to as “model checking tool”), the designer performs model verification by coding the behavior specification according to the description grammar of the model verification tool. . However, it is very difficult for general designers to understand and strictly code the description grammar unique to the tool. Therefore, there is a technique for improving the ease of description by describing the behavior in a unique diagram format (unique model) (see, for example, Patent Document 1). In addition, there is a technique for generating a model verification code in accordance with a tool description grammar from a UML (Unified / Modeling / Language) model (see, for example, Non-Patent Document 1).

JP 2008-305079 A

Yoshioka Nobukazu, Aoki Toshiaki and Tahara Yasuyuki, “Design Model Verification by SPIN”, Modern Science Co., Ltd., September 30, 2008, pp. 218-223

  Conventionally, in verification of design specifications using model verification tools, it is difficult for general designers to code behavior specifications according to the description grammar that depends on model verification tools. With this technique, a code (also referred to as “model verification code”) is generated, and this code is input to a model verification tool to execute model verification. However, in the technology using the above-mentioned original model, it is necessary to understand the specifications of the original diagram format, and thus there is a problem that the initial cost of the designer is large at the time of introduction. Further, in the technology using the above UML model, since UML is too general, there is a problem that a common description that can be subsets in a specific field must be described from the beginning each time and is redundant. .

  Also, the counterexample (for example, deadlock) model output as a verification result by the model verification tool includes model verification code level data and model verification tool internal data. And the elements of the input model (the above-mentioned original model and UML model) do not correspond, and there is a problem that it is difficult to analyze the output model.

  In order to overcome these challenges, knowledge and experience related to model verification are required, so it is difficult to introduce model verification technology to development sites.

  An object of the present invention is, for example, to facilitate the semantic analysis of a counterexample model that is created or output as an input model so that even a general designer who is not familiar with model verification technology can perform model verification.

A verification apparatus according to one aspect of the present invention includes:
A verification device that verifies the specifications of a specific system using a model verification code that describes the specifications of the system to be verified,
First mapping information indicating a correspondence relationship between elements of a general-purpose modeling language commonly used to describe the specifications of an arbitrary system and elements of a domain-specific modeling language used to describe the specifications of the specific system A database that stores in advance in a storage device second mapping information indicating a correspondence relationship between the elements of the domain-specific modeling language and the elements constituting the model verification code;
The input device accepts input of first general model data describing the specifications of the specific system in the general modeling language, and based on the first mapping information stored in the database, from the first general model data, A first domain-specific model generation unit that generates first domain-specific model data in which a specification of a specific system is described in the domain-specific modeling language by a processing device;
Based on the second mapping information stored in the database, the model verification code describing the specifications of the specific system is processed from the first domain specific model data generated by the first domain specific model generation unit A model verification code generator generated by the device;
A model verification execution unit that verifies the specifications of the specific system with a processing device using the model verification code generated by the model verification code generation unit, and acquires verification result data indicating a verification result; To do.

  In one aspect of the present invention, the first domain specific model generation unit of the verification device accepts input of first general model data in which a specification of a specific system is described in a general modeling language, and based on the first mapping information First domain specific model data in which the specifications of the specific system are described in a domain specific modeling language is generated from the first general model data. The model verification code generation unit of the verification apparatus generates a model verification code describing the specifications of the specific system from the first domain specific model data based on the second mapping information. The model verification execution unit of the verification apparatus verifies the specification of the specific system using the model verification code, and acquires verification result data indicating the verification result. This makes it easy to create an input model, so that even a general designer who is not familiar with model verification technology can perform model verification.

2 is a configuration diagram of a design model verification method according to Embodiment 1. FIG. 6 is a diagram illustrating a meta model of a domain specific model according to Embodiment 1. FIG. It is a figure which shows the relationship between the domain specialization model grammar which concerns on Embodiment 1, and each mapping rule. 4 is a table showing an example of (a) schema and (b) table data of “UML model To domain specific model mapping rule” according to the first exemplary embodiment. 4 is a table showing an example of (a) schema and (b) table data of “domain specific model To model verification code mapping rule” according to the first exemplary embodiment. 10 is a table showing an example of (a) schema and (b) table data of “verification result To domain specific model mapping rule” according to the first exemplary embodiment. 7 is a table showing an example of (a) schema and (b) table data of “domain specific model ToUML model mapping rule” according to the first exemplary embodiment. 2 is a diagram illustrating an example of a hardware configuration of a verification device according to Embodiment 1. FIG. FIG. 4 is a class diagram illustrating an example of a domain specific model grammar according to the first embodiment. 3 is a composite structure diagram illustrating an example of a domain-specific model grammar according to Embodiment 1. FIG. 10 is a table showing an example of “UML model To domain specific model mapping rule” according to the first exemplary embodiment. 7 is a table showing an example of “domain specific model To model verification code mapping rule” according to the first exemplary embodiment. 10 is a table showing an example of “verification result To domain specific model mapping rule” according to the first exemplary embodiment. 10 is a table showing an example of “domain specific model ToUML model mapping rule” according to the first exemplary embodiment. 3 is a flowchart showing the operation of the entire verification apparatus according to the first embodiment. 4 is a class diagram illustrating an example of a UML model (verification target) according to Embodiment 1. FIG. 6 is an activity diagram illustrating an example of a UML model (verification target) according to Embodiment 1. FIG. 6 is an activity diagram illustrating an example of a UML model (verification target) according to Embodiment 1. FIG. It is a flowchart which shows the detailed process of step S101 of FIG. 5 is a diagram illustrating an example of a first stage domain specialization model (verification target) according to Embodiment 1. FIG. 5 is a diagram illustrating an example of a first stage domain specialization model (verification target) according to Embodiment 1. FIG. It is a figure which shows an example of the domain specialization model (verification object) of the 2nd step which concerns on Embodiment 1. FIG. It is a figure which shows an example of the domain specialization model (verification object) of the 2nd step which concerns on Embodiment 1. FIG. 3 is a diagram illustrating an example of a model verification code according to Embodiment 1. FIG. It is a figure which shows an example of the verification result (counterexample) which concerns on Embodiment 1. FIG. It is a flowchart which shows the detailed process of FIG.15 S104. It is a figure which shows an example of the domain specialization model (counterexample) of the 1st step which concerns on Embodiment 1. FIG. It is a figure which shows an example of the domain specialization model (counterexample) of the 2nd step which concerns on Embodiment 1. FIG. It is a figure which shows an example of the UML model (counterexample) which concerns on Embodiment 1. FIG.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

Embodiment 1 FIG.
FIG. 1 is a configuration diagram of a design model verification method 10 that facilitates creation of an input model and analysis of the output counterexample result according to the present embodiment.

  In FIG. 1, SE11 (system engineer) is a system development designer. The domain engineer 12 is a creator of a domain specific model grammar and four types of mapping rules, and is an expert in UML grammar, domain, and model verification code description grammar.

  The UML model 13 (verification target) is modeled by the SE 11 in accordance with the domain-specific model grammar for the specification to be verified, and is input to the verification device 20. The UML model 13 (verification target) is an example of first general-purpose model data in which specifications of a specific system are described in a general-purpose modeling language (also referred to as “specification description language”). The general-purpose modeling language is a language that is commonly used to describe the specifications of an arbitrary system. In the present embodiment, UML is used as an example of a general-purpose modeling language, but other general-purpose modeling languages may be used.

  The verification apparatus 20 includes a UML grammar DB 21 (database), a domain-specific model grammar DB 22, a model verification code description grammar DB 23, a domain-specific model (verification target) generation unit 24, “UML model To domain-specific model mapping”. "Rule" DB25, domain-specific model (verification target) DB26, model verification code generation unit 27, "domain-specific model To model verification code mapping rule" DB28, model verification code DB29, model verification execution unit 30, DB 31 for verification result (counterexample), domain specific model (counterexample) generating unit 32, DB33 for "verification result To domain specific model mapping rule", DB34 for domain specific model (counterexample), UML model (counterexample) generating unit 35, “Domain specific model ToUML model mapping Equipped with a DB36 of Lumpur ".

  Although not shown, the verification device 20 includes hardware such as a processing device, a storage device, an input device, and an output device. The hardware is used by each unit of the verification device 20. For example, the processing device is used to perform calculation, processing, reading, writing, and the like of data and information in each unit of the verification device 20. The storage device stores the data and information, the input device inputs the data and information, and the output device uses the data and information. The storage device is used in particular for storing data in each DB 21, 22, 23, 25, 26, 28, 29, 31, 33, 34, 36.

  When the verification target UML model 13 defined by SE11 is input, the verification device 20 operates each unit as described below and outputs a counter example UML model 14.

  First, the domain-specific model (verification target) generation unit 24 uses the “UML model To domain-specific model mapping rule”, which is a mapping rule between the UML model and the domain-specific model, to convert the UML model 13 (verification target) into the domain. Convert to a specialized model (verification target). The domain-specific model (verification target) is the first domain-specific model data in which the specifications of a specific system described in the first general-purpose model data are described in a domain-specific modeling language (also referred to as “domain-specific modeling language”). It is an example. The domain-specific modeling language is a language used to describe the specifications of a specific system, unlike the general-purpose modeling language described above.

  Next, the model verification code generation unit 27 performs model verification on the domain specific model (verification target) using the “domain specific model To model verification code mapping rule” which is a mapping rule between the domain specific model and the model verification code. Convert to code. The model verification code is a description of the specification of a specific system described in the first domain specific model data in a language (for example, Promela) that can be interpreted by a model verification tool (for example, Spin). The model verification tool is a program that, when a model verification code is input, verifies the specification of the system to be verified described in the model verification code, and detects and outputs a counterexample of the specification.

  Next, the model verification execution unit 30 performs model verification with the generated model verification code as an input, and outputs a verification result (counterexample). At this time, the model verification execution unit 30 executes the model verification tool and acquires verification result data indicating a verification result (counterexample).

  Next, the domain-specific model (counterexample) generating unit 32 uses the “verification result To domain-specific model mapping rule”, which is a mapping rule between the verification result and the domain-specific model, to domain-specify the verification result (counterexample). Convert to model (counterexample). The domain-specific model (counterexample) is an example of second domain-specific model data in which a counterexample detected by the model verification tool is described in a domain-specific modeling language.

  Finally, the UML model (counterexample) generating unit 35 uses the “domain-specific model ToUML model mapping rule”, which is a mapping rule between the domain-specific model and the UML model, to convert the domain-specific model (counterexample) into the UML model 14 ( Convert to counterexample). The UML model 14 (counterexample) is an example of second general model data in which a counterexample detected by the model verification tool is described in a general modeling language.

  The UML grammar DB 21 is a DB that stores data (UML metamodel) defining UML description specifications. The UML metamodel (UML grammar) is developed by OMG (Object Management Group).

  The domain specific model grammar DB 22 is a DB that stores a description specification (meta model) of a domain specific model (also referred to as a “domain specific model”) of each domain. The domain-specific model metamodel (domain-specific model grammar) is an extension of the UML metamodel (UML grammar) and is defined in advance by the domain engineer 12. Here, FIG. 2 shows a meta model of the domain specific model. In FIG. 2, SE description constituent elements and SE description behavior elements of the meta model of the domain specific model mean elements when SE 11 defines an input model (verification target). The implicit component and the implicit behavior element are added to the domain specialization model when the domain specialization model (verification target) generation unit 24 and the domain specialization model (counterexample) generation unit 32 perform conversion to the domain specialization model. Is an element that is not used when SE11 defines an input model. In other words, the implicit component and the implicit behavior element are elements that are sub-set in the domain and do not need to be defined in UML. These SE description component, SE description behavior element, implicit configuration element, and implicit behavior element are elements used in the domain specific model (verification target). The action element is an element used in the domain specific model (counterexample). In the domain specific model (counterexample), SE description constituent element, SE description behavior element, implicit constituent element, and implicit behavior element are used in addition. When the domain-specific model (counterexample) generating unit 32 converts the verification result into the domain-specific model (counterexample), the domain-specific model (only by conversion based on the “verification result To domain-specific model mapping rule”) ( The model element of (counterexample) is insufficient, and the element of the output model does not correspond to the element of the input model. Therefore, the domain-specific model (counterexample) generation unit 32 uses the relationship corresponding to the verification trace of the meta-model of the domain-specific model in the domain-specific model grammar and the relationship with another element from the relationship with the missing element. By tracing, the missing elements are identified and supplemented.

  When defining the domain-specific model grammar, the domain engineer 12 combines four types of mapping rules (“UML model To domain-specific model mapping rule”, “domain-specific model To model verification code mapping rule”, “ The verification result To domain specific model mapping rule "and" domain specific model ToUML model mapping rule ") are also defined. FIG. 3 shows the relationship between the domain specific model grammar and each mapping rule. In FIG. 3, “UML model To domain specific model mapping rule” and “domain specific model ToUML model mapping rule” are mapping rules that define the correspondence between the elements of the UML grammar and the elements of the domain specific model grammar. . “Domain-specific model To model verification code mapping rule” and “Verification result To domain-specific model mapping rule” are mapping rules that define the correspondence between domain-specific model grammar elements and model verification code description grammar elements. is there.

  Of the above four types of mapping rules, “UML model To domain specific model mapping rule” and “Domain specific model ToUML model mapping rule” are correspondences between elements of general-purpose modeling language and elements of domain specific modeling language. It is an example of the 1st mapping information which shows. The “domain specific model To model verification code mapping rule” is an example of second mapping information indicating a correspondence relationship between elements of the domain specific modeling language and elements constituting the model verification code. The “verification result To domain specific model mapping rule” is an example of third mapping information indicating a correspondence relationship between elements constituting the verification result data and elements of the domain specific modeling language. Each mapping rule is stored in advance in the storage device by the DBs 25, 28, 33, and 36.

  The model verification code description grammar DB 23 is a DB that stores a description grammar of a program that can be interpreted by the model verification tool and a specification of a verification result. In order to perform model verification, a model (specification) to be verified is coded in accordance with the description grammar and input to the model verification execution unit 30.

  The domain specific model (verification target) generation unit 24 refers to the mapping rule and domain specific model grammar of “UML model To domain specific model mapping rule” corresponding to the domain of the input UML model 13 (verification target). Then, the UML model 13 (verification target) is converted into a domain specific model (verification target). The domain-specific model (verification target) generation unit 24 is an example of a first domain-specific model generation unit.

  The DB 25 of “UML model To domain specific model mapping rule” is a DB that stores the mapping rule between the UML model and the domain specific model. Here, FIG. 4A shows a schema of “UML model To domain specific model mapping rule”. For example, table data as shown in FIG. 4B is stored in the DB 25 of “UML model To domain specific model mapping rule”. This mapping rule is defined and stored in advance by the domain engineer 12 with reference to the UML grammar and the domain specific model grammar.

  The domain-specific model (verification target) DB 26 temporarily stores the domain-specific model to be verified generated by the domain-specific model (verification target) generation unit 24 until the model verification code generation unit 27 loads it. It is DB to do.

  The model verification code generation unit 27 refers to the mapping rule of the “domain specific model To model verification code mapping rule” corresponding to the domain of the domain specific model (verification target), and models the domain specific model (verification target). Convert to verification code.

  The DB 28 of “domain specific model To model verification code mapping rule” is a DB that stores a mapping rule between a domain specific model (verification target) and a model verification code. Here, FIG. 5A shows the schema of the “domain specific model To model verification code mapping rule”. For example, table data as shown in FIG. 5B is stored in the DB 28 of the “domain specific model To model verification code mapping rule”. This mapping rule is defined and stored in advance by the domain engineer 12 with reference to the domain specific model grammar and the model verification code description grammar.

  The model verification code DB 29 is a DB that temporarily stores the model verification code generated by the model verification code generation unit 27 until the model verification execution unit 30 loads it. The model verification code is a program described by a code that can be interpreted by the model verification tool.

  The model verification execution unit 30 is a part for executing a command of an existing model verification tool such as Spin, and inputs a model verification code loaded from the model verification code DB 29 and outputs a verification result (counterexample).

  The verification result (counterexample) DB 31 is a DB that temporarily stores the verification result (counterexample) output from the model verification execution unit 30 until the domain-specific model (counterexample) generation unit 32 loads it.

  The domain-specific model (counterexample) generation unit 32 refers to the mapping rule and domain-specific model grammar of the “verification result To domain-specific model mapping rule” corresponding to the domain of the verification result (counterexample), and the verification result (counterexample) ) Into a domain-specific model (counterexample). The domain specific model (counterexample) generation unit 32 is an example of a second domain specific model generation unit.

  The DB 33 of “verification result To domain specific model mapping rule” is a DB that stores the mapping result of the verification result and the domain specific model. Here, FIG. 6A shows a schema of the “verification result To domain specific model mapping rule”. For example, table data as shown in FIG. 6B is stored in the DB 33 of “verification result To domain specific model mapping rule”. This mapping rule is defined and stored in advance by the domain engineer 12 with reference to the model verification code description grammar and the domain specific model grammar.

  The domain specialization model (counterexample) DB 34 temporarily stores the domain specialization model (counterexample) generated by the domain specialization model (counterexample) generation unit 32 until the UML model (counterexample) generation unit 35 loads it. It is DB to do.

  The UML model (counterexample) generating unit 35 refers to the mapping rule of the “domain-specific model ToUML model mapping rule” corresponding to the domain of the domain-specific model (counterexample), and converts the domain-specific model (counterexample) into the UML model 14. Convert to (counterexample). The UML model (counterexample) generation unit 35 is an example of a general-purpose model generation unit.

  The DB 36 of “domain specific model ToUML model mapping rule” is a DB that stores a mapping rule between the domain specific model and the UML model. Here, FIG. 7A shows a schema of “domain specific model ToUML model mapping rule”. For example, table data as shown in FIG. 7B is stored in the DB 36 of the “domain specific model ToUML model mapping rule”. This mapping rule is defined and stored in advance by the domain engineer 12 with reference to the domain specific model grammar and the UML grammar.

  The UML model 14 (counterexample) is a counterexample UML model generated by the UML model (counterexample) generation unit 35.

  As described above, in the design model verification method 10 according to the present embodiment, the UML model 13 (verification target) described by the SE 11 based on the domain specific model grammar and the constraint defining the property to be verified are input as counter examples. A UML model 14 is generated.

  FIG. 8 is a diagram illustrating an example of a hardware configuration of the verification device 20.

  In FIG. 8, the verification device 20 is a computer and includes an LCD 901 (Liquid / Crystal / Display), a keyboard 902 (K / B), a mouse 903, an FDD 904 (Flexible / Disk / Drive), and a CDD 905 (Compact / Disc / Drive). , A hardware device such as a printer 906 is provided. These hardware devices are connected by cables and signal lines. Instead of the LCD 901, a CRT (Cathode / Ray / Tube) or other display device may be used. Instead of the mouse 903, a touch panel, a touch pad, a trackball, a pen tablet, or other pointing devices may be used.

  The verification apparatus 20 includes a CPU 911 (Central Processing Unit) that executes a program. The CPU 911 is an example of a processing device. The CPU 911 includes a ROM 913 (Read / Only / Memory), a RAM 914 (Random / Access / Memory), a communication board 915, an LCD 901, a keyboard 902, a mouse 903, an FDD 904, a CDD 905, a printer 906, and an HDD 920 (Hard / Disk) via a bus 912. Connected with Drive) to control these hardware devices. Instead of the HDD 920, a flash memory, an optical disk device, a memory card reader / writer, or other storage medium may be used.

  The RAM 914 is an example of a volatile memory. The ROM 913, the FDD 904, the CDD 905, and the HDD 920 are examples of nonvolatile memories. These are examples of the storage device. The communication board 915, the keyboard 902, the mouse 903, the FDD 904, and the CDD 905 are examples of input devices. The communication board 915, the LCD 901, and the printer 906 are examples of output devices.

  The communication board 915 is connected to a LAN (Local / Area / Network) or the like. The communication board 915 is not limited to a LAN, but is an IP-VPN (Internet, Protocol, Private, Network), a wide area LAN, an ATM (Asynchronous / Transfer / Mode) network, a WAN (Wide / Area / Network), or the Internet. It does not matter if it is connected to. LAN, WAN, and the Internet are examples of networks.

  The HDD 920 stores an operating system 921 (OS), a window system 922, a program group 923, and a file group 924. The programs in the program group 923 are executed by the CPU 911, the operating system 921, and the window system 922. The program group 923 includes programs that execute the functions described as “˜units” in the description of the present embodiment. The program is read and executed by the CPU 911. The file group 924 includes data, information, and signal values described as “˜data”, “˜information”, “˜ID (identifier)”, “˜flag”, and “˜result” in the description of this embodiment. And variable values and parameters are included as items of “˜file”, “˜database”, and “˜table”. The “˜file”, “˜database”, and “˜table” are stored in a storage medium such as the RAM 914 or the HDD 920. Data, information, signal values, variable values, and parameters stored in a storage medium such as the RAM 914 and the HDD 920 are read out to the main memory and the cache memory by the CPU 911 via a read / write circuit, and extracted, searched, referenced, compared, and calculated. It is used for processing (operation) of the CPU 911 such as calculation, control, output, printing, and display. During the processing of the CPU 911 such as extraction, search, reference, comparison, calculation, calculation, control, output, printing, and display, data, information, signal values, variable values, and parameters are temporarily stored in the main memory, cache memory, and buffer memory. Remembered.

  The arrows in the block diagrams and flowcharts used in the description of this embodiment mainly indicate input / output of data and signals. Data and signals are recorded in memory such as RAM 914, FDD904 flexible disk (FD), CDD905 compact disk (CD), HDD920 magnetic disk, optical disk, DVD (Digital Versatile Disc), or other recording media Is done. Data and signals are transmitted by a bus 912, a signal line, a cable, or other transmission media.

  In the description of the present embodiment, what is described as “to part” may be “to circuit”, “to device”, “to device”, and “to step”, “to process”, “to”. ~ Procedure "," ~ process ". That is, what is described as “˜unit” may be realized by firmware stored in the ROM 913. Alternatively, what is described as “˜unit” may be realized only by software, or only by hardware such as an element, a device, a board, and wiring. Alternatively, what is described as “to part” may be realized by a combination of software and hardware, or a combination of software, hardware and firmware. Firmware and software are stored as programs in a recording medium such as a flexible disk, a compact disk, a magnetic disk, an optical disk, and a DVD. The program is read by the CPU 911 and executed by the CPU 911. That is, the program causes the computer to function as “to part” described in the description of the present embodiment. Or a program makes a computer perform the procedure and method of "-part" described by description of this Embodiment.

  Hereinafter, the operation of the verification apparatus 20 (the verification method according to the present embodiment and the processing procedure of the verification program according to the present embodiment) will be described using the following printer / scanner acquisition specification as an example. In this example, it is assumed that Spin is used as the model verification tool, but other model verification tools may be used.

Behavior specification (acquisition specification) when acquiring a printer / scanner: User A and user B work by using two resources of a printer and a scanner. The procedure for user A and user B to use the printer and scanner is as follows. Note that if the other side has already acquired the resource that one side has attempted to acquire, it waits until the resource is released and becomes free.
User A acquires resources in the order of printer → scanner, uses two resources simultaneously, and then releases resources in the order of printer → scanner.
User B acquires resources in the order of scanner → printer, uses the two resources simultaneously, and then releases resources in the order of printer → scanner.

  Examples of domain-specific model grammars for acquiring shared resources when the domain of the acquisition specification of the printer / scanner is “shared resource acquisition” are shown in FIGS. For example, meta model data defined by the class diagram of FIG. 9 and the composite structure diagram of FIG. 10 is stored in the domain specific model grammar DB 22. Examples of four types of mapping rules corresponding to the domain-specific model grammar for acquiring shared resources are shown in FIGS. For example, table data as shown in FIG. 11 is stored in the DB 25 of “UML model To domain specific model mapping rule”. For example, table data as shown in FIG. 12 is stored in the DB 28 of the “domain specific model To model verification code mapping rule”. For example, table data as shown in FIG. 13 is stored in the DB 33 of the “verification result To domain specific model mapping rule”. For example, table data as shown in FIG. 14 is stored in the DB 36 of “domain specific model ToUML model mapping rule”. Each mapping rule is created from the defined domain-specific model grammar, UML grammar, and model verification code description grammar.

  FIG. 15 is a flowchart showing the overall operation of the verification apparatus 20.

  First, the SE 11 refers to the domain specific model grammar of the domain related to the specification to be verified, defines the UML model 13 (verification target) according to the grammar, and inputs it to the domain specific model (verification target) generation unit 24. . FIGS. 16 to 18 show the UML model 13 (verification target) in the case of the resource acquisition specification of the printer / scanner. SE11 inputs, for example, the UML model 13 (verification target) defined in the class diagram of FIG. 16, the activity diagram of user A in FIG. 17, and the activity diagram of user B in FIG.

  As shown in FIG. 16, the UML model 13 (verification target) includes user A (User A) and user B (User B) as elements. As shown in FIGS. 17 and 18, the UML model 13 (verification target) includes a printer and a scanner as elements. As shown in FIG. 17, in this UML model 13 (verification target), after a user A (User A) acquires (print) a printer and a scanner (scanner) in order, the printer (printer) and the scanner It is described that (scanner) is released in order. Also, as shown in FIG. 18, in this UML model 13 (verification target), after user B (UserB) acquires (scanner) and printer (printer) in order, the printer (printer) and scanner It is described that (scanner) is released in order.

  In step S101 of FIG. 15, the domain specific model (verification target) generation unit 24 uses the input device to input the UML model 13 (verification target) in which the acquisition specifications of the printer / scanner are described in UML as the specifications of a specific system. Accept. Based on the “UML model To domain specific model mapping rule” stored in the DB 25, the domain specific model (verification target) generation unit 24 obtains the printer / scanner acquisition specifications from the UML model 13 (verification target). A domain-specific model (verification target) described in the domain-specific modeling language (that is, according to the domain-specific model grammar stored by the DB 22) is generated by the processing device. Then, the domain specialization model (verification target) generation unit 24 stores the generated domain specialization model (verification target) in the DB 26.

  Here, the detailed process of step S101 is shown in FIG.

  In FIG. 19, the domain specific model (verification target) generation unit 24 extracts the elements of the input UML model 13 (verification target) and sets the “UML model To domain specific model mapping rule” of the corresponding domain. With reference to the UML model 13 (verification target), the UML model 13 (verification target) is converted into a first stage domain specific model (verification target) (step S201). FIG. 20 shows the first stage of the user A generated from the UML model 13 (verification target) of the user A shown in FIGS. 16 and 17 in accordance with the “UML model To domain specific model mapping rule” shown in FIG. It is an example of a domain specialization model (verification object). Similarly, FIG. 21 shows the user B's generated from the UML model 13 (verification target) of user B shown in FIGS. 16 and 18 according to the “UML model To domain specific model mapping rule” shown in FIG. It is an example of the domain specialization model (verification object) of the 1st step. As shown in FIGS. 20 and 21, the domain specialization model (verification target) at the first stage includes SE description constituent elements such as UserType and Resource, and SE description behavior elements such as get and release.

  Next, the domain specialization model (verification target) generation unit 24 refers to the domain specialization model grammar of the corresponding domain, and adds an implicit element to the first stage domain specialization model (verification target). A second stage domain specialization model (verification target) is generated and stored in the DB 26 of the domain specialization model (verification target) (step S202). FIG. 22 is an example of the second stage domain specialization model (verification target) of user A generated from the first stage domain specialization model (verification target) of user A shown in FIG. Similarly, FIG. 23 is an example of the second stage domain specialization model (verification target) of user B generated from the first stage domain specialization model (verification target) of user B shown in FIG. . As shown in FIGS. 22 and 23, the domain-specific model (verification target) in the second stage includes not only the SE description component and the SE description behavior element but also a state that is an implicit component. In the second stage domain specialization model (verification target), when a resource (Resource) is acquired, the state becomes “used” and the resource (Resource) is It is described that when released, the state becomes idle. These descriptions are omitted in the UML model 13.

  As shown in FIGS. 22 and 23, this domain-specific model (verification target) includes, as elements, user A (userA), user B (userB), printer (printer), scanner (scanner), and in use (used). ) And idle (idle). As shown in FIG. 22, in this domain specific model (verification target), user A (user A) obtains (gets) a printer (printer) and a scanner (scanner) in order, and each resource (Resource) is obtained. After changing the state (used) to “used”, the printer (printer) and the scanner (scanner) are released in order, and the state (state) of each resource (Resource) is set to an idle state. It is described to change. In addition, as shown in FIG. 23, in this domain specific model (verification target), user B (user B) obtains (gets) a scanner (scanner) and a printer (printer) in order and obtains each resource (Resource). After changing the state (used) to “used”, the printer (printer) and the scanner (scanner) are released in order, and the state (state) of each resource (Resource) is set to an idle state. It is described to change.

  In step S102 of FIG. 15, the model verification code generation unit 27 is generated by the domain specific model (verification target) generation unit 24 based on the “domain specific model To model verification code mapping rule” stored in the DB 28. From the domain-specific model (verification target), a processing unit generates a model verification code describing the acquisition specifications of the printer / scanner.

  Specifically, the model verification code generation unit 27 loads the domain specific model (verification target) from the DB 26 of the domain specific model (verification target). The model verification code generation unit 27 extracts the elements of the loaded domain specific model (verification target), refers to the “domain specific model To model verification code mapping rule” of the corresponding domain, and performs the domain specific model Each element of (verification target) is converted into a corresponding model verification code. Then, the model verification code generation unit 27 embeds each model verification code element in the model verification code template, generates a model verification code, and stores it in the model verification code DB 29. FIG. 24 is an example of a model verification code generated from the domain specific model (verification target) shown in FIGS. 22 and 23 in accordance with the “domain specific model To model verification code mapping rule” shown in FIG. . In the drawing, the white portions are portions embedded by the model verification code generation unit 27, and the other portions are templates.

  As shown in FIG. 24, this model verification code includes, as elements, a printer (Printer), a scanner (Scanner), a user A (UserA), and a user B (UserB). In this model verification code, as in the domain-specific model (verification target), when a printer (Scanner) or a scanner (Scanner) is acquired (Get), the state (printer_state or scanner_state) is in use (Used). And that the state (printer_state or scanner_state) becomes idle when the printer (Printer) or scanner (Scanner) is released (Release). Further, in this model verification code, after the user A (User A) acquires the printer and the scanner in order (printer_ch! Get, scanner_ch! Get), the printer and the scanner are released in order (printer_ch! Release, scanner_ch! Release). It is described. Further, in this model verification code, after the user B (UserB) acquires the scanner and the printer in order (scanner_ch! Get, printer_ch! Get), the printer and the scanner are released in order (printer_ch! Release, scanner_ch! Release). It is described.

  In step S103 of FIG. 15, the model verification execution unit 30 uses the model verification code generated by the model verification code generation unit 27 to verify the acquired specifications of the printer / scanner with the processing device, and obtains a verification result (counterexample). To do. At this time, the model verification execution unit 30 executes Spin as a model verification tool for detecting a counter-example of the acquisition specification of the printer / scanner described in the model verification code generated by the model verification code generation unit 27, and Data indicating the counterexample is acquired as a verification result (counterexample).

  Specifically, the model verification execution unit 30 loads the model verification code from the DB 29 of the model verification code. Then, the model verification execution unit 30 executes the verification command of the model verification tool (Spin) with the loaded model verification code as an input, and stores the execution result (counterexample) in the DB 31 of the verification result (counterexample). FIG. 25 is an example of a verification result (counterexample) output when the verification tool is executed by inputting the model verification code shown in FIG.

  As shown in FIG. 25, a counterexample is detected here. In this counterexample, first, the process number 4 transmits a Get message to the process number 1 (printer_ch! Get), and the process number 1 is this Get message. (C? Get). That is, the user A (User A) has acquired (Get) the printer (Printer). Next, process number 3 transmits a Get message to process number 2 (scanner_ch! Get), and process number 2 receives this Get message (c? Get). That is, user B (User B) has acquired (Get) the scanner (Scanner). If neither the user A (User A) nor the user B (User B) acquire the other resource, the acquired resource is not released, so that a deadlock has occurred at this point.

  In step S104 of FIG. 15, the domain specific model (counterexample) generation unit 32 verifies the verification result acquired by the model verification execution unit 30 based on the “verification result To domain specific model mapping rule” stored in the DB 33. From the (counterexample), a domain specific model (counterexample) describing the counterexample detected by Spin according to the domain specific model grammar is generated by the processing device.

  Here, the detailed process of step S104 is shown in FIG.

  In FIG. 26, the domain specific model (counterexample) generating unit 32 loads the verification result (counterexample) from the DB 31 of the verification result (counterexample). Then, the domain-specific model (counterexample) generation unit 32 performs lexical analysis on the loaded verification result (counterexample) and extracts elements necessary for output (step S301). The domain-specific model (counterexample) generation unit 32 refers to the “verification result To domain-specific model mapping rule” of the corresponding domain, and converts the verification result (counterexample) into the first stage domain-specific model (counterexample). Conversion is performed (step S302). FIG. 27 is an example of the first stage domain specialization model (counterexample) generated from the verification result (counterexample) shown in FIG. 25 in accordance with the “verification result To domain specialization model mapping rule” shown in FIG. is there. As shown in FIG. 27, the domain specialization model (counterexample) at the first stage includes elements such as message and state in addition to elements such as UserType and Resource, but the instance name of the state object is insufficient.

  Next, the domain specialization model (counterexample) generation unit 32 refers to the corresponding domain specialization model grammar and identifies the elements that are missing in the first stage domain specialization model (counterexample). Are extracted and added to the first stage domain specialization model (counterexample) to generate the second stage domain specialization model (counterexample). Then, the domain-specific model (counterexample) generation unit 32 stores the generated domain-specific model (counterexample) in the DB 34 (step S303). The elements to be added are the other elements in the domain-specific model grammar from the information related to the missing elements and the domain-specific model grammar related to the verification trace of the meta-model of the domain-specific model in the domain-specific model grammar. It can be extracted by searching for the corresponding element from the list. As described above, in the case of the printer / scanner acquisition specification example, the missing element in the first stage domain specific model (counterexample) is the instance name of the state object. The domain specific model (counterexample) generation unit 32 extracts a relation (relation between the state class and the message class) corresponding to the verification trace of the meta model of the domain specific model shown in FIG. Then, the domain specific model (counterexample) generation unit 32 determines the instance name of the state class when the instance name of the message class is “get” based on the association between the instance of the state class and the instance of the message class illustrated in FIG. 10. Is “used”, it is determined that the missing element (instance name of the state object) in the first stage domain specialization model (counterexample) is “used”.

  In step S105 of FIG. 15, the UML model (counterexample) generation unit 35 is generated by the domain specific model (counterexample) generation unit 32 based on the “domain specific model ToUML model mapping rule” stored in the DB 36. From the domain-specific model (counterexample), a UML model 14 (counterexample) describing the counterexample detected by Spin in UML is generated by the processing device.

  Specifically, the UML model (counterexample) generation unit 35 loads a domain specific model (counterexample) from the DB 34 of the domain specific model (counterexample). Then, the UML model (counterexample) generation unit 35 extracts the elements of the loaded domain specialization model (counterexample) and refers to the corresponding “domain specialization model ToUML model mapping rule” to obtain the domain specialization model ( Counterexample) is converted into UML model 14 (counterexample) and output. FIG. 29 is an example of the UML model 14 (counterexample) generated from the domain-specific model (counterexample) shown in FIG. 28 in accordance with the “domain-specific model ToUML model mapping rule” shown in FIG.

  As shown in FIG. 29, in this UML model 14 (counterexample), a printer (printer) is acquired by a user A (userA), and the printer (printer) is in an unused (used) state (used). If a scanner is acquired by user B (user B) and the scanner status changes from idle to used, a deadlock occurs. It is described.

As described above, according to the present embodiment, the following effects can be obtained.
-Domain engineer 12 defines in advance a common description (implicit element in domain-specific model grammar) as a subset, and common description (implicit element in domain-specific model grammar) is domain-specific. As the model (verification target) generation unit 24 performs the verification target model defined by SE11, the SE description constituent element and the SE description behavior element of the meta model (domain specific model grammar) of the domain specific model Therefore, the amount of description can be reduced as compared with general-purpose UML.
-The domain-specific model grammar is an extension of UML, which is known as a general modeling language. Therefore, for SE11 with UML knowledge, a new description grammar is created only for the definition of the model to be verified. There is no need to learn.
The domain-specific model (counterexample) generation unit 32 performs model conversion by referring to the “verification result To domain-specific model mapping rule” and adds elements that are insufficient to the domain-specific model (counterexample) generated by model conversion. Thus, since the elements of the input model and the output model correspond to each other, semantic analysis of the output model becomes easier than before.

  10 Design model verification method, 11 SE, 12 Domain engineer, 13, 14 UML model, 20 Verification device, 21, 22, 23, 25, 26, 28, 29, 31, 33, 34, 36 DB, 24 Domain specialization Model (verification target) generation unit, 27 Model verification code generation unit, 30 Model verification execution unit, 32 Domain specific model (counterexample) generation unit, 35 UML model (counterexample) generation unit, 901 LCD, 902 keyboard, 903 mouse, 904 FDD, 905 CDD, 906 printer, 911 CPU, 912 bus, 913 ROM, 914 RAM, 915 communication board, 920 HDD, 921 operating system, 922 window system, 923 program group, 924 file group.

Claims (7)

A verification device that verifies the specifications of a specific system using a model verification code that describes the specifications of the system to be verified,
First mapping information indicating a correspondence relationship between elements of a general-purpose modeling language commonly used to describe the specifications of an arbitrary system and elements of a domain-specific modeling language used to describe the specifications of the specific system A database that stores in advance in a storage device second mapping information indicating a correspondence relationship between the elements of the domain-specific modeling language and the elements constituting the model verification code;
The input device accepts input of first general model data describing the specifications of the specific system in the general modeling language, and based on the first mapping information stored in the database, from the first general model data, A first domain-specific model generation unit that generates first domain-specific model data in which a specification of a specific system is described in the domain-specific modeling language by a processing device;
Based on the second mapping information stored in the database, the model verification code describing the specifications of the specific system is processed from the first domain specific model data generated by the first domain specific model generation unit A model verification code generator generated by the device;
A model verification execution unit that verifies the specifications of the specific system with a processing device using the model verification code generated by the model verification code generation unit, and acquires verification result data indicating a verification result; Verification device to do.   The model verification execution unit executes a model verification tool for detecting a counter example of the specification of the system described in the model verification code by a processing device, and acquires data indicating the counter example as the verification result data, The verification device according to claim 1. The database further stores, in a storage device in advance, third mapping information indicating a correspondence relationship between elements constituting the verification result data and elements of the domain-specific modeling language,
The verification device further includes:
A second domain in which counterexamples detected by the model verification tool are described in the domain-specific modeling language from the verification result data acquired by the model verification execution unit based on the third mapping information stored in the database A second domain specialized model generation unit that generates specialized model data in the processing device;
A counterexample detected by the model verification tool from the second domain specific model data generated by the second domain specific model generation unit based on the first mapping information stored in the database. The verification apparatus according to claim 2, further comprising: a general-purpose model generation unit configured to generate the second general-purpose model data described in the above item by a processing device.   The verification apparatus according to claim 2, wherein the model verification tool is Spin.   5. The verification apparatus according to claim 1, wherein the universal modeling language is UML (Unified / Modeling / Language). A verification method that verifies the specifications of a specific system using a model verification code that describes the specifications of the system to be verified,
First mapping information indicating a correspondence relationship between elements of a general-purpose modeling language commonly used to describe the specifications of an arbitrary system and elements of a domain-specific modeling language used to describe the specifications of the specific system And a computer having a database that stores in advance a second mapping information indicating a correspondence relationship between elements of the domain-specific modeling language and elements constituting the model verification code. The input of first generic model data described in the generic modeling language is received by an input device, and based on the first mapping information stored in the database, the specification of the specific system is determined from the first generic model data. Process first domain specific model data described in domain specific modeling language Generated by the apparatus,
Based on the second mapping information stored by the database, the computer generates a model verification code that describes the specifications of the specific system from the generated first domain specific model data by a processing device,
A verification method characterized in that the computer verifies the specifications of the specific system using a generated model verification code by a processing device, and acquires verification result data indicating a verification result. A verification program that verifies the specifications of a specific system using a model verification code that describes the specifications of the system to be verified,
First mapping information indicating a correspondence relationship between elements of a general-purpose modeling language commonly used to describe the specifications of an arbitrary system and elements of a domain-specific modeling language used to describe the specifications of the specific system And a second mapping information indicating a correspondence relationship between the elements of the domain-specific modeling language and the elements constituting the model verification code, and executed by a computer including a database that stores in advance in a storage device,
The input device accepts input of first general model data describing the specifications of the specific system in the general modeling language, and based on the first mapping information stored in the database, from the first general model data, A first domain-specific model generation process for generating first domain-specific model data in which a specific system specification is described in the domain-specific modeling language with a processing device;
Based on the second mapping information stored in the database, the model verification code describing the specifications of the specific system is processed from the first domain specific model data generated by the first domain specific model generation process Model verification code generation processing generated by the device,
Using the model verification code generated by the model verification code generation process, the specification of the specific system is verified by a processing device, and the computer executes a model verification execution process for acquiring verification result data indicating the verification result A verification program characterized by that.

Images