JP2010128513A - モデル検査装置及びモデル検査方法 - Google Patents

Abstract

【課題】不要反例の検出を低減し、反例解析の効率を向上させることができるモデル検査装置を提供する。
【解決手段】本発明に係るモデル検査装置は、モデルデータと検査式とを入力し、検査条件を満たさない状態遷移を検出した場合は、その状態遷移を反例データとして出力するモデル検査部と、検査式から注目状態を抽出する一方、モデルデータから遷移条件を抽出する遷移条件抽出部と、注目状態に遷移するための遷移条件が常に発生しているか否か、或いは全く発生していないか否かを判定する反例判定部と、遷移条件が常に発生しているときには、「遷移条件が常には発生しないとすれば」という前提条件を、また遷移条件が全く発生していないときには、「遷移条件がいつかは必ず発生するとすれば」という前提条件を検査条件に付加して検査式を更新する検査式更新部と、を備えたことを特徴とする。
【選択図】 図７

Description

本発明は、モデル検査装置及びモデル検査方法に係り、特に、状態モデルに対して検査を行うモデル検査装置及びモデル検査方法に関する。

今日、ソフトウェアが複雑化してきたことにより、ソフトウェア自体のみならずソフトウェア作成の基となるシステム仕様に誤りが混入しやすくなってきている。また、システム仕様の複雑化に伴って、人の手では、システム仕様を網羅した検証が困難になってきている。経験や知識のない誤りは発見しづらく、また、後工程で発見された誤りは取り除くために膨大なコストがかかる。このため、システム仕様の誤りを可能な限り人の手を借りずに網羅的に検証し、誤りを早期に取り除くための仕組みが必要不可欠となってきている。

システム仕様を状態遷移モデルで表現すると共に検証条件を論理式で記述し、状態遷移モデルが論理式を満たすかどうかを検証することで仕様の正しさを証明する手法として、モデル検査と呼ばれる手法が知られている（特許文献１、２等）。
特開２００７−１１６０５号公報 特開２００７−４１６７７号公報

モデル検査では、状態遷移モデルとして記述されたシステム仕様と、時相論理式で記述された検査式をモデル検査装置に入力し、状態遷移モデルの動作（即ちシステム仕様）が検査式で表される検証条件を満たすか否かを網羅的に検査する。検証条件を満たさない動作（状態やイベント等）が検出された場合にはその動作は「反例」としてモデル検査装置から出力される。また、反例が検出された場合、その反例に至る直前の一連の動作もログデータとして出力される。モデル検査装置から出力される反例やログデータを人が解析することにより、システム仕様の誤りの発見とその修復を効率よく行うことができる。

しかしながら、従来のモデル検査では、システム仕様に誤りが無く、かつ検査式も検査すべき内容を正しく記述しているにもかかわらず、“まれ”に起こるという程度を超えて、明らかに考慮が不要な反例（以下、不要反例と呼ぶ）がモデル検査装置によってしばしば検出される。不要反例は、それを人が見て判断すれば、システム仕様と検査式とから当然に起こりうる反例であり、システム仕様の誤り発見には寄与しないような反例である。

従来のモデル検査では、不要反例が多く検出されることにより、本来の反例（システム仕様の誤りに起因する反例）の解析作業の妨げとなっていた。

本発明は上記事情に鑑みてなされたものであり、不要反例の検出を低減し、反例解析の効率を向上させることができるモデル検査装置及びモデル検査方法を提供することを目的とする。

上記課題を解決するため、本発明に係るモデル検査装置は、検査対象となる状態遷移モデルが記述されたモデルデータと、所定の状態に関する検査条件が時相論理式によって表現された検査式とを入力し、前記状態遷移モデルにおける夫々の状態の遷移が前記検査条件を満たすか否かを検査し、前記夫々の状態の遷移の中に前記検査条件を満たさない状態遷移を検出した場合は、その状態遷移を反例データとして出力するモデル検査部と、前記検査条件に関わる所定の状態を前記検査式から注目状態として抽出する一方、抽出した前記注目状態に遷移するための遷移条件を前記モデルデータから抽出する遷移条件抽出部と、前記モデル検査部から出力される前記反例データを解析し、前記遷移条件が常に発生しているか否か、或いは全く発生していないか否かを判定する反例判定部と、前記遷移条件が常に発生していると判定された場合には、「前記遷移条件が常には発生しないとすれば」という前提条件を前記検査条件に付加して前記検査式を更新し、前記遷移条件が全く発生していないと判定された場合には、「前記遷移条件がいつかは必ず発生するとすれば」という前提条件を前記検査条件に付加して前記検査式を更新する検査式更新部と、を備えたことを特徴とする。

また、上記課題を解決するため、本発明に係るモデル検査方法は、検査対象となる状態遷移モデルが記述されたモデルデータと、所定の状態に関する検査条件が時相論理式によって表現された検査式とを入力し、前記状態遷移モデルにおける夫々の状態の遷移が前記検査条件を満たすか否かを検査し、前記夫々の状態の遷移の中に前記検査条件を満たさない状態遷移を検出した場合は、その状態遷移を反例データとして出力し、前記検査条件に関わる前記所定の状態を前記検査式から注目状態として抽出する一方、抽出した前記注目状態に遷移するための遷移条件を前記モデルデータから抽出し、前記反例データを解析し、前記遷移条件が常に発生しているか否か、或いは全く発生していないか否かを判定し、前記遷移条件が常に発生していると判定された場合には、「前記遷移条件が常には発生しないとすれば」という前提条件を前記検査条件に付加して前記検査式を更新し、前記遷移条件が全く発生していないと判定された場合には、「前記遷移条件がいつかは必ず発生するとすれば」という前提条件を前記検査条件に付加して前記検査式を更新する、ステップを備えたことを特徴とする。

本発明に係るモデル検査装置及びモデル検査方法によれば、不要反例の検出を低減し、反例解析の効率を向上させることができる。

本発明に係るモデル検査装置及びモデル検査方法の実施形態について、添付図面を参照して説明する。

図１は、一般的なモデル検査装置の動作概念を模式的に示した図である。システム仕様は状態遷移モデルとして表現することが可能であり、システムがとりうる状態と、状態を遷移させるイベントやガード条件によって表すことができる。状態遷移モデルは、所定のモデル記述言語によってモデルデータとして記述することが可能であり、このモデルデータが検査対象としてモデル検査装置に入力される。

一方、システム仕様が所定の検査条件を満たすか否かを判定するための検査条件は、所定の言語で記述した検査式としてモデル検査装置に入力される。

モデル検査装置では、モデルデータが取りうる総ての状態遷移の組み合わせに対して検査式を満たすか否かを判定する。検査式を満たさない状態が発見された場合は、その状態が反例としてモデル検査装置から出力される。また、その状態へ至る過程もログデータをして出力される。反例やログデータがモデル検査装置の検査結果となる。

通常、検査式は時相論理式を用いて「満たすべき条件」を表現する。図２は、時相論理式で表現される検査式の概念を示す図である。時相論理式は、いくつかの時相論理記号と、述語ｐを用いて表現することができる。

時相論理記号としては、例えば「＆＆」、「ＩＩ」、「！」、「−＞」、「＜＞」、「[]」等がある。「＆＆」は「かつ」を意味する。「ＩＩ」は、「または」を意味する。「！」は、否定を意味する。「−＞」は、「ならば」を意味する。「＜＞」は、「いつか」を意味する。「[]」は、「常に」を意味する。

一方、述語ｐは、論理値「Ｔ（真）」と「Ｆ（偽）」を規定することができる条件を表す任意の述語である。

例えば、ｐとして「故障する」という述語を定義すると、「いつかは故障する」という検査条件に対応する検査式は、「＜＞ｐ」となる。また、この検査条件を図で表現すると図２（ａ）のように表される。

「常に故障している」に対応する検査式は、「[]ｐ」となり、この検査条件を図で表現すると、図２（ｂ）のように表される。また、「いつか常に故障する」（或いは同じことを別の表現でいうと「あるときから常に故障する」）に対応する検査式は、「＜＞[]ｐ」となり、この検査条件を図で表現すると、図２（ｃ）のように表される。

また、「いつか故障する可能性が常にある」に対応する検査式は、「[]＜＞ｐ」であり、この検査条件は、図２（ｄ）のように表される。このように、モデル検査装置に入力される検査式は、時相論理記号と述語ｐによって記述される。

他方、モデル検査装置に入力される状態遷移モデルのモデルデータは、「状態」、「イベント」、及び「ガード条件」によって表現される。このうち、「イベント」と「ガード条件」は、必ず両者が揃って必要というわけではなく、いずれか一方のみでもよい。

図３は、状態遷移モデルの一例を示す図である。この状態遷移モデルでは、４つの「状態」（Ｓ１、Ｓ２、Ｓ３、及びＳ４）が規定されている。また、「イベント」として、「exit」キーの押下に対応する”exit”イベント、「enter」キーの押下に対応する”enter”イベント、及びキー押下なしに対応する”nothing”イベントの３つの「イベントが規定されている。

また、ガード条件としてｇ１が規定されており、「ガード条件ｇ１が真ならば」は、[ｇ１]と表記し、「ガード条件ｇ１が偽ならば」は、[！ｇ１]と表記している。

この状態遷移モデルでは、例えば、状態「Ｓ１」にあるとき、キー押下がなければ状態「Ｓ１」を維持し、「enter」キーが押下されると状態「Ｓ２」に遷移する。状態「Ｓ２」において、「enter」キーが押下され、そのとき「ガード条件ｇ１が真ならば」状態「Ｓ２」を維持する。一方、「enter」キーが押下され、そのとき「ガード条件ｇ１が偽ならば」状態「Ｓ２」から状態「Ｓ３」に遷移する。

モデル検査装置は、入力された状態遷移モデルがとりうるすべての振る舞いに対して、入力された検査式に対応する検査条件を満たすか否かを検査し、検査条件を満たさない事象が発生した場合は、「検査条件を満たさない」という事実を示す具体例を反例として出力すると共に、反例の直前の状態やイベントの遷移系列をシーケンシャルにログデータとして出力する。

図４は、反例とログデータの出力例を示す図である。この例では、「２つのプロセスＰ１、Ｐ２の状態の組み合わせがＳ４、Ｓ５となることはない」という検査条件を、ある状態遷移モデルを表すモデルデータ（図示せず）と共にモデル検査装置に入力している。上記の検査条件を検査式で表現すると、例えば、「[](！(Ｐ１_State==Ｓ４＆＆Ｐ２_State==Ｓ５))」となる。

入力した状態遷移モデルの振る舞いがこの検査条件を満たさなかった場合、図４の右側に例示するような反例とログデータが出力される。反例出力の最下欄には、プロセスＰ２の状態がＳ５であり、プロセスＰ１の状態がＳ４であることが示されている。これは明らかに上記の検査条件を満たしていないため、反例として出力される。また、この反例の直前の状態、イベント、ガード条件もログデータとして出力されることも例示している。

出力された反例とログデータは人によって解析され、この解析によって状態遷移モデルとして表現されているシステム仕様の誤りを早期に発見し、訂正することができる。

しかしながら、モデル検査装置が、次に示すような不要反例を頻繁に出力すると、この不要反例はシステム仕様の有意な解析に何ら寄与せず、むしろ本来の反例解析作業の妨げとなる。

図５は、このような不要反例の一例を示す図である。本例で検査の対象となる状態遷移モデルは、図５の上方に示す状態遷移図で表されるものとする。即ち、この状態遷移モデルでは、状態Ａにあるとき、イベントｅ１が発生しても状態Ａを維持し続けるが、イベントｅ２が発生しかつガード条件ｇ１が真になると状態Ａから状態Ｂに遷移する。また、状態Ｂにあるとき、イベントｅ３が発生すると状態Ｂから状態Ａに戻る。

この状態遷移モデルに対して、「いつかは状態Ｂになる」という検査条件の反例を探したいとする。「いつかは状態Ｂになる」に対応する検査式は、「<>state == B」等で表現される。

このとき、例えば、エベントｅ１が永久に発生し続けると、所定の検査時間を経過しても検査が終了しないため、従来のモデル検査装置では図５の右上に示したような反例を出力する。また、例えば、ガード条件ｇ１が永久に真にならないとすると、従来のモデル検査装置では図５の右下にしめしたような反例を出力する。

これらの反例は、システム仕様から人が判断すれば自明の反例であり、システム仕様の有意な解析に何ら寄与せず、本来の反例解析作業の妨げとなるだけである。このような反例を不要反例と呼んでいる。

本実施形態に係るモデル解析装置１は、このような不要反例の発生を防止、或いは低減するものであり、図６はモデル解析装置１の動作概念を示す図である。

まず、ステップＳＴ（１）として、モデルデータと検査式をモデル検査装置１に入力する。ここで入力する検査式は従来から使用されている検査式であり、例えば、検査条件「いつかは状態Ｂになる」に対応する検査式、「<>state == B」、などである。

ステップＳＴ（２）でモデル検査を行う。入力されたモデルデータに検査式を満たさない状態等がある場合は、ステップＳＴ（３）に進む。

ステップＳＴ（３）では、出力された反例をモデル検査装置１が解析し、反例が不要反例であるか否かを判定する。不要反例ではないと判定された場合（即ち、有意な反例であると判定された場合）は、ステップＳＴ（３）’にて、出力された反例が検査結果としてモデル検査装置１から出力される。

一方、不要反例であると判定された場合には、ステップＳＴ（４）にて、モデル検査装置１が、その不要反例の発生を防止すべく検査式の改良を行い、改良された検査式で再度ステップＳＴ（２）のモデル検査を行う。このモデル検査では、検査式が改良されているため、不要反例が検出されることがなく、有意な反例のみがモデル検査装置１から出力されることになる。

図７は、上記の動作を実現する本実施形態に係るモデル検査装置１の構成例を示す図である。

モデル検査装置１は、モデル検査部１０、遷移条件抽出部１１、反例判定部１２、検査式更新部１３、ユーザインタフェース部１４等を備えて構成される。

モデル検査装置１には、検査対象となる状態遷移モデルが所定の記述言語で記述されたモデルデータが入力され、適宜の記憶媒体に保存される。また、この状態遷移モデルの中の特定の状態に関する検査条件が時相論理式によって表現された検査式も入力され、適宜の記憶媒体に保存される。

モデル検査部１０は、入力された状態遷移モデル（モデルデータ）における夫々の状態の遷移が検査条件を満たすか否かを入力された検査式に基づいて検査し、夫々の状態の遷移の中に検査条件を満たさない状態遷移を検出した場合は、その状態遷移を反例データとして出力する。また、その状態遷移へ至る状態の遷移系列（ログデータ）も反例データをして出力する。モデル検査部１０から出力された反例データは、適宜の記憶媒体に保存される。

遷移条件抽出部１１は、検査式から検査条件に関する所定の状態を注目状態として特定し抽出する。また、抽出した注目状態に遷移するための遷移条件を前記モデルデータから抽出する。ここで、遷移条件とは、ある状態から注目状態へ遷移するための「イベント」や「ガード条件」のことである。

反例判定部１２は、モデル検査部１０から出力された反例データを解析し、遷移条件抽出部が抽出した上記の遷移条件が常に発生しているか否か、或いは全く発生していないか否かを判定する。

検査式更新部１３は、遷移条件が常に発生していると判定された場合には、「その遷移条件が常には発生しないとすれば」という前提条件を検査条件に付加して保存されている検査式を更新する。また、遷移条件が全く発生していないと判定された場合には、「前記遷移条件がいつかは必ず発生するとすれば」という前提条件を検査条件に付加して保存されている検査式を更新する。

ユーザインタフェース部１４は、ディスプレイ装置等の表示手段と、キーボードやマウス等のデータ入力手段等を備えて構成されるものである。検査式更新部１３は、検査式を更新する前に更新の許可をユーザインタフェース部１４を介してユーザに求め、ユーザインタフェース部１４から許可を示すデータがユーザから入力されたとき、検査式を更新するようにしてもよい。

図８は、モデル検査装置１で行うモデル検査方法のより具体的な処理の例を示すフローチャートである。

ステップＳＴ１０からステップＳＴ１３までの処理は、遷移条件抽出部１１が主に行う処理である。

まず、ステップＳＴ１０、及びステップＳＴ１１で、モデルデータと検査式を入力する。ステップＳＴ１２では、入力した検査式から注目する状態を特定する。例えば、検査条件が「いつかは状態Ｂになる」である場合は、この検査条件に対応する検査式は、「<>state == B」となる。遷移条件抽出部１１では、この検査式から、注目状態が「Ｂ」であることを特定する。

ステップＳＴ１３では、モデルデータから、注目状態に遷移するための遷移条件、具体的には、注目状態に遷移するための「イベント」と「ガード条件」を抽出する。

図９は、入力したモデルデータの一例を状態遷移図で表したものであり、特に、注目状態「Ｂ」を中心とした状態遷移図を示す図である。この図は、ステップＳＴ１２で特定された注目状態Ｂへ遷移するためには、１）イベント「ｅ１」が起こり、かつ、そのときガード条件ｇ１が「真」になっていること、２）イベント「ｅ２」が起こること、又は、３）ガード条件ｇ１が「真」になっていること、の３つの条件のうち少なくとも１つの条件が満たされることが必要であることを示している。

ステップＳＴ１３では、入力したモデルデータからこれらのイベント（本例では、ｅ１とｅ２）及びガード条件（本例では、ｇ１とｇ２）を抽出し、それぞれをイベントリスト及びガードリストとして、適宜の記憶手段に保存する。

一方、ステップＳＴ１４では、モデル検査部１０が、入力した検査式とモデルデータとに基づいてモデル検査を実行し、反例データを出力する。

ステップＳＴ１５乃至ステップＳＴ１８は、状態遷移抽出部１１から出力されたイベントリスト及びガードリストと、モデル検査部１０から出力された反例データを解析し、イベントリスト及びガードリストにリストアップされている遷移条件が常に発生しているか否か、或いは全く発生していないか否かを判定する。この判定は、反例判定部１２で行う。

具体的には、次の４つの判定を行う。ステップＳＴ１５では、第１の判定を行っており、注目状態に遷移するイベントが常に起こっているか否かを判定する。あるイベントが常に起こっているという反例は、図５の右上に示したように不要反例の１つであり、第１の判定では出力された反例がこの種の不要反例に該当するか否かを判定している。本例の場合、ステップＳＴ１５では、ｅ１、又はｅ２が常に起こっているか否かを判定する。

ステップＳＴ１６は、第２の判定を行っており、第１の判定とは逆に、注目状態に遷移するイベントが全く起こっていないか否かを判定する。注目状態に遷移するイベントが全く起こっていないという反例も有意な反例とはいえず、不要反例に該当する。本例の場合、ステップＳＴ１６では、イベントｅ１、又はｅ２が全く起こっていないか否かを判定する。

ステップＳＴ１７は、第３の判定を行っており、ガード条件が常に「偽」になっているか否かを判定する。ガード条件が常に「偽」になっている状況は、上記のイベントが全く発生しない状況と類似しており、このような状況を示す反例も有意な反例とはいえず、不要反例に該当する。本例の場合、ステップＳＴ１７では、ガード条件ｇ１、又はｇ２が常に「偽」になっているか否かを判定する。

ステップＳＴ１８は、第４の判定を行っており、ガード条件が常に「真」になっているか否かを判定する。ガード条件が常に「真」になっている状況は、イベントが常に起こっている状態と類似しており、このような状況を示す反例もやはり有意な反例とはいえず、不要反例に該当する。本例の場合、ステップＳＴ１８では、ガード条件ｇ１、又はｇ２が常に「真」になっているか否かを判定する。

ステップＳＴ１９乃至ステップＳＴ２２は、反例判定部１２での判定結果を受けて、遷移条件が常に発生していると判定された場合には、「その遷移条件が常には発生しないとすれば」という前提条件を検査条件に付加して保存されている検査式を更新し、遷移条件が全く発生していないと判定された場合には、「前記遷移条件がいつかは必ず発生するとすれば」という前提条件を検査条件に付加して保存されている検査式を更新する処理である。具体的には、前述した第１乃至第４の判定結果に応じて、ステップＳＴ１９乃至ステップＳＴ２２の夫々で検査式の更新を行う。

ステップＳＴ１９では、第１の判定によって、注目状態に遷移するイベントが常に起こっている、と判定された場合、「該当するイベントが常には起こり続けないとすれば」という前提条件を検査式の先頭に付加する。例えば、常に起こり続けているイベントがｅ１であるとする。この場合、「いつかは状態Ｂになる」という現在の検査条件を、「イベントｅ１が常には起こり続けないとすると、いつかは状態Ｂになる」という検査条件に変更し、更新する。検査式で表現すると、「<>state == B」という現在の検査式を、「(! [] event==e1) -> (<>state == B)」という検査式に変更し、ステップＳＴ２３で保存されている検査式を更新する。更新された検査式を用いて再度モデル検査を行うと、イベントｅ１が常に起こっているという不要反例の出力を排除することができる。

ステップＳＴ２０では、第２の判定によって、注目状態に遷移するイベントが全く起こっていない、と判定された場合、「該当するイベントがいつかは必ず起こるとすれば」という前提条件を検査式の先頭に付加する。例えば、全く起こっていないイベントがｅ１であるとする。この場合、「いつかは状態Ｂになる」という現在の検査条件を、「イベントｅ１がいつかは必ず起こるとすれば、いつかは状態Ｂになる」という検査条件に変更し、更新する。検査式で表現すると、「<>state == B」という現在の検査式を、「([] <> event==e1) -> (<>state == B)」という検査式に変更し、ステップＳＴ２３で保存されている検査式を更新する。更新された検査式を用いて再度モデル検査を行うと、イベントｅ１が全く起こっていないという不要反例の出力を排除することができる。

ステップＳＴ２１では、第３の判定によって、注目状態に遷移するガード条件が常に偽になっている、と判定された場合、「該当するガード条件がいつかは必ず真になるとすれば」という前提条件を検査式の先頭に付加する。例えば、常に偽になっているガード条件がｇ１であるとする。この場合、「いつかは状態Ｂになる」という現在の検査条件を、「ガード条件ｇ１がいつかは必ず真になるとすれば、いつかは状態Ｂになる」という検査条件に変更し、更新する。検査式で表現すると、「<>state == B」という現在の検査式を、「([] <> g1) -> (<>state == B)」という検査式に変更し、ステップＳＴ２３で保存されている検査式を更新する。更新された検査式を用いて再度モデル検査を行うと、ガード条件ｇ１が常に偽になっているという不要反例の出力を排除することができる。

ステップＳＴ２２では、第４の判定によって、注目状態に遷移するガード条件が常に真になっている、と判定された場合、「該当するガード条件がいつかは必ず偽になるとすれば」という前提条件を検査式の先頭に付加する。例えば、常に真になっているガード条件がｇ１であるとする。この場合、「いつかは状態Ｂになる」という現在の検査条件を、「ガード条件ｇ１がいつかは必ず偽になるとすれば、いつかは状態Ｂになる」という検査条件に変更し、更新する。検査式で表現すると、「<>state == B」という現在の検査式を、「([] <> !g1) -> (<>state == B)」という検査式に変更し、ステップＳＴ２３で保存されている検査式を更新する。更新された検査式を用いて再度モデル検査を行うと、ガード条件ｇ１が常に真になっているという不要反例の出力を排除することができる。

なお、ステップＳＴ２３における検査式の更新の前に、変更しようとする検査式をユーザインタフェース部１４のディスプレイ装置等に表示し、ユーザからの更新許可の入力の有無を判定するステップを設けても良い。この場合、ユーザから検査式更新の許可が入力されたときに限り検査式が更新されることになるため、装置による自動判定結果に人の判断が加わり、検査式の変更と更新の信頼性をより高めることができる。

以上説明してきたように、本実施形態に係るモデル検査装置１及びモデル検査方法によれば、不要反例の検出を低減することができる。この結果、本来求めていた有意な反例の解析に集中することが可能となり、反例解析の効率を向上させることができる。また、有意な反例であっても不要反例であっても、モデル検査装置が反例を出力するためには、ある程度の処理時間が必要となるが、不要反例が出力されるとこの処理時間は無駄な時間となる。本実施形態に係るモデル検査装置１及びモデル検査方法によれば、このような無駄な時間が無くなるため、反例解析に要する全体の時間が短縮される。

なお、本発明は上記の実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせても良い。

モデル検査装置の一般的動作概念を示す図。 時相論理式で表現される検査式の概念を示す図。 状態遷移モデルの一例を示す図。 モデル検査装置から出力される反例の一例を示す図。 モデル検査装置から出力される不要反例の一例を示す図。 本実施形態に係るモデル検査装置の動作概念を示す図。 本実施形態に係るモデル検査装置の構成例を示すブロック図。 本実施形態に係るモデル検査方法の処理例を示すフローチャート。 注目状態への遷移条件の概念を示す図。

符号の説明

１ モデル検査装置
１０ モデル検査部
１１ 遷移条件抽出部
１２ 反例判定部
１３ 検査式更新部
１４ ユーザインタフェース部

Claims (8)

1. 検査対象となる状態遷移モデルが記述されたモデルデータと、所定の状態に関する検査条件が時相論理式によって表現された検査式とを入力し、前記状態遷移モデルにおける夫々の状態の遷移が前記検査条件を満たすか否かを検査し、前記夫々の状態の遷移の中に前記検査条件を満たさない状態遷移を検出した場合は、その状態遷移を反例データとして出力するモデル検査部と、
   前記検査条件に関わる所定の状態を前記検査式から注目状態として抽出する一方、抽出した前記注目状態に遷移するための遷移条件を前記モデルデータから抽出する遷移条件抽出部と、
   前記モデル検査部から出力される前記反例データを解析し、前記遷移条件が常に発生しているか否か、或いは全く発生していないか否かを判定する反例判定部と、
   前記遷移条件が常に発生していると判定された場合には、「前記遷移条件が常には発生しないとすれば」という前提条件を前記検査条件に付加して前記検査式を更新し、
   前記遷移条件が全く発生していないと判定された場合には、「前記遷移条件がいつかは必ず発生するとすれば」という前提条件を前記検査条件に付加して前記検査式を更新する検査式更新部と、
   を備えたことを特徴とするモデル検査装置。
2. 前記遷移条件は、イベントの発生の有無であり、
   前記遷移条件抽出部は、抽出した前記注目状態に遷移するための前記イベントを前記モデルデータから抽出し、
   前記反例判定部は、前記注目状態に遷移するための前記イベントが常に起こっているか否か、或いは全く起こっていないか否かを判定し、
   前記検査式更新部は、前記イベントが常に起こっていると判定された場合には、「前記イベントが常には起こり続けないとすれば」という第１の前提条件を前記検査条件に付加して前記検査式を更新し、前記イベントが全く起こっていないと判定された場合には、「前記イベントがいつかは必ず起こるとすれば」という第２の前提条件を前記検査条件に付加して前記検査式を更新する、
   ことを特徴とする請求項１に記載のモデル検査装置。
3. 前記遷移条件は、ガード条件の真偽であり、
   前記遷移条件抽出部は、抽出した前記注目状態に遷移するための前記ガード条件を前記モデルデータから抽出し、
   前記反例判定部は、前記注目状態に遷移するための前記ガード条件が常に偽になっているか否か、或いは常に真になっているか否かを判定し、
   前記検査式更新部は、前記ガード条件が常に偽になっていると判定された場合には、「前記ガード条件がいつか必ず真になるとすれば」という第１の前提条件を前記検査条件に付加して前記検査式を更新し、前記ガード条件が常に真になっていると判定された場合には、「前記ガード条件がいつか必ず偽になるとすれば」という第２の前提条件を前記検査条件に付加して前記検査式を更新する、
   ことを特徴とする請求項１に記載のモデル検査装置。
4. 前記反例判定部において、前記注目状態に遷移するための前記遷移条件が常に発生している、或いは全く発生していないと判定された場合、前記検査式更新部にて前記検査式を更新するか否かをユーザに問い合わせるユーザインタフェース部、
   をさらに備えたことを特徴とする請求項１に記載のモデル検査装置。
5. 検査対象となる状態遷移モデルが記述されたモデルデータと、所定の状態に関する検査条件が時相論理式によって表現された検査式とを入力し、
   前記状態遷移モデルにおける夫々の状態の遷移が前記検査条件を満たすか否かを検査し、
   前記夫々の状態の遷移の中に前記検査条件を満たさない状態遷移を検出した場合は、その状態遷移を反例データとして出力し、
   前記検査条件に関わる前記所定の状態を前記検査式から注目状態として抽出する一方、抽出した前記注目状態に遷移するための遷移条件を前記モデルデータから抽出し、
   前記反例データを解析し、前記遷移条件が常に発生しているか否か、或いは全く発生していないか否かを判定し、
   前記遷移条件が常に発生していると判定された場合には、「前記遷移条件が常には発生しないとすれば」という前提条件を前記検査条件に付加して前記検査式を更新し、
   前記遷移条件が全く発生していないと判定された場合には、「前記遷移条件がいつかは必ず発生するとすれば」という前提条件を前記検査条件に付加して前記検査式を更新する、
   ステップを備えたことを特徴とするモデル検査方法。
6. 前記遷移条件は、イベントの発生の有無であり、
   前記遷移条件を抽出するステップでは、抽出した前記注目状態に遷移するための前記イベントを前記モデルデータから抽出し、
   前記判定するステップでは、前記注目状態に遷移するための前記イベントが常に起こっているか否か、或いは全く起こっていないか否かを判定し、
   前記検査式を更新するステップでは、前記イベントが常に起こっていると判定された場合には、「前記イベントが常には起こり続けないとすれば」という第１の前提条件を前記検査条件に付加して前記検査式を更新し、前記イベントが全く起こっていないと判定された場合には、「前記イベントがいつかは必ず起こるとすれば」という第２の前提条件を前記検査条件に付加して前記検査式を更新する、
   ことを特徴とする請求項５に記載のモデル検査方法。
7. 前記遷移条件は、ガード条件の真偽であり、
   前記遷移条件を抽出するステップでは、抽出した前記注目状態に遷移するための前記ガード条件を前記モデルデータから抽出し、
   前記判定するステップでは、前記注目状態に遷移するための前記ガード条件が常に偽になっているか否か、或いは常に真になっているか否かを判定し、
   前記検査式を更新するステップでは、前記ガード条件が常に偽になっていると判定された場合には、「前記ガード条件がいつか必ず真になるとすれば」という第１の前提条件を前記検査条件に付加して前記検査式を更新し、前記ガード条件が常に真になっていると判定された場合には、「前記ガード条件がいつか必ず偽になるとすれば」という第２の前提条件を前記検査条件に付加して前記検査式を更新する、
   ことを特徴とする請求項５に記載のモデル検査方法。
8. 前記判定ステップにおいて、前記注目状態に遷移するための前記遷移条件が常に発生している、或いは全く発生していないと判定された場合、前記検査式を更新するか否かをユーザに問い合わせる、
   ステップをさらに備えたことを特徴とする請求項５に記載のモデル検査方法。

Images