(57)【特許請求の範囲】
【請求項１】
仕様記述言語を用いて表した仕様要件を論理的に結合することにより記述された要求仕様と、前記要求仕様をソフトウェアとして設計した設計仕様との間の整合性を検証する、設計検証装置であって、
前記要求仕様において用いている記号と、前記設計仕様において用いている記号との間の対応関係を記述した記号対応表を生成する、記号対応付け部、
前記設計仕様が前記要求仕様を満たしているか否かを検査するための検査式として、前記仕様要件のうち前記記号対応表が記述している記号を含むものを抽出する、検査式定義部、
前記検査式を用いて前記設計仕様が前記要求仕様を満たしているか否かを検査する検査部、
を備え、
前記要求仕様は、前記仕様要件として、第１前件と第１後件を有する第１要件、第２前件と第２後件を有する第２要件、を記述しており、
前記検査式定義部は、前記第１後件と前記第２前件が同じ論理式を表している場合は、前記第１前件を前件として有し前記第２後件を後件として有する結合論理式を、前記検査式として抽出する
ことを特徴とする設計検証装置。
【請求項２】
仕様記述言語を用いて表した仕様要件を論理的に結合することにより記述された要求仕様と、前記要求仕様をソフトウェアとして設計した設計仕様との間の整合性を検証する、設計検証装置であって、
前記要求仕様において用いている記号と、前記設計仕様において用いている記号との間の対応関係を記述した記号対応表を生成する、記号対応付け部、
前記設計仕様が前記要求仕様を満たしているか否かを検査するための検査式として、前記仕様要件のうち前記記号対応表が記述している記号を含むものを抽出する、検査式定義部、
前記検査式を用いて前記設計仕様が前記要求仕様を満たしているか否かを検査する検査部、
を備え、
前記記号対応付け部は、前記要求仕様が記述している論理式と前記設計仕様が記述している論理式との間の対応関係を記述した対応関係データを受け取り、
前記記号対応付け部は、前記対応関係データが記述している対応関係から、前記要求仕様において用いている記号と、前記設計仕様において用いている記号との間の対応関係を抽出することにより、前記記号対応表を生成する
ことを特徴とする設計検証装置。
【請求項３】
仕様記述言語を用いて表した仕様要件を論理的に結合することにより記述された要求仕様と、前記要求仕様をソフトウェアとして設計した設計仕様との間の整合性を検証する、設計検証装置であって、
前記要求仕様において用いている記号と、前記設計仕様において用いている記号との間の対応関係を記述した記号対応表を生成する、記号対応付け部、
前記設計仕様が前記要求仕様を満たしているか否かを検査するための検査式として、前記仕様要件のうち前記記号対応表が記述している記号を含むものを抽出する、検査式定義部、
前記検査式を用いて前記設計仕様が前記要求仕様を満たしているか否かを検査する検査部、
を備え、
前記要求仕様は、前件と後件によって表される論理式を、前件と後件によって表される複数の別の論理式へ分割することによって形成される、ツリー形式の論理構造によって記述されている
ことを特徴とする設計検証装置。
【請求項４】
前記検査式定義部は、前記結合論理式のうち前記第１前件と前記第２後件が前記記号対応表のなかに記述されているものを、前記検査式として抽出する
ことを特徴とする請求項１記載の設計検証装置。
【請求項５】
前記検査部は、前記結合論理式を前記検査式として用いることにより、前記第１要件と前記第２要件を一括して検査する
ことを特徴とする請求項４記載の設計検証装置。
【請求項６】
前記検査部は、前記検査式を埋め込んだプログラムを実行することにより前記検査式が表す現象が実行過程において成立するか否かを検証するか、または、前記検査式が論理的に成立するか否かを形式検証することにより、前記設計仕様が前記要求仕様を満たしているか否かを検査する
ことを特徴とする請求項１から３のいずれか１項記載の設計検証装置。
【請求項７】
前記設計検証装置は、前記検査部による検査結果を出力する出力部を備える
ことを特徴とする請求項１から３のいずれか１項記載の設計検証装置。
【請求項８】
前記出力部は、前記要求仕様において用いている記号のうち前記記号対応表が記述しているものについて、その旨を前記検査結果に加えて出力する
ことを特徴とする請求項７記載の設計検証装置。
【請求項９】
前記設計検証装置は、前記検査部による検査結果を出力する出力部を備え、
前記出力部は、前記結合論理式を前記検査式として用いることにより、前記第１要件と前記第２要件を一括して検査した旨を、前記検査結果として出力する
ことを特徴とする請求項５記載の設計検証装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、要求仕様と設計仕様との間の整合性を検証する技術に関する。
【背景技術】
【０００２】
システム開発においては、初期の段階で要求仕様が定義される。要求仕様に基づき、システム、ハードウェア、ソフトウェアが設計される。設計結果は要求仕様を満たす必要がある。【０００３】
下記特許文献１は、鉄道保安機能を実現する連動装置の設計を検証する技術を開示している。同文献においては、要求仕様と設計仕様を形式的言語による記述に変換し、両者の内容の等価性を形式的に検証する。両者が等価であれば設計が正しく、等価でなければ設計に誤りがあると判定し、その判定結果を出力する。【０００４】
下記特許文献２は、プラントの安全を保護するための保護論理を検証する技術を開示している。同文献においては、要求仕様にしたがって設計され代数仕様を用いて記述された設計仕様が、要求仕様と適合しているか否かを検証する。【０００５】
設計が要求仕様に適合しているか否かを検証する際には、要求仕様の記述が正確かつ十分に記載されていることも重要である。下記特許文献３においては、要求仕様を上位要件（例えばシステムの機能の観点）から下位要件（例えばハードウェアやソフトウェアの機能に関する要件）に分解するツリー形式でモデル化し、さらに命題論理を用いて各要件を記述することにより、要件をあいまいさなく表現し、かつ上位要件に対する下位要件の完全性を自動検証している。このようにツリー形式で要件を表現することは、システムに対する要件をあますことなく記載する上で有効である。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平１０−１６７７６号公報
【特許文献２】特開平６−２７４５６２号公報
【特許文献３】特開２０１４−１７４７３０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
要求仕様と設計仕様は、それぞれに適した記法で表現されるので、多くの場合において異なる記法で表現される。例えば要求仕様は振る舞いを１つの記号で表現しているのに対し、設計仕様は状態を１つの変数で表現し、振る舞いを手続き的に表現している場合がある。この場合、両者を自動的に対応付けることが困難である。例えば１つの要件内の記号と、設計内の記号との間の対応付けができない場合、その要件の論理式は、設計に対する検査式として用いることができない。また、同一の対象・振る舞いが、要求仕様と設計仕様との間で異なる記号によって表現されることも多々ある。【０００８】
本発明は、上記のような課題に鑑みてなされたものであり、要求仕様と設計仕様が互いに異なる記法によって表現されている場合であっても、設計仕様が要求仕様に適合しているか否かを自動的に検査することを促進する技術を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明に係る設計検証装置は、要求仕様と設計仕様との間の記号が対応付けされている論理式を用いて、設計仕様が要求仕様に適合しているか否かを検査する。
【発明の効果】
【００１０】
本発明に係る設計検証装置によれば、要求仕様と設計仕様が互いに異なる記法によって記述されている場合であっても、設計仕様が要求仕様を満たしているか否かを自動的に検査することができる。
【図面の簡単な説明】
【００１１】
【図１】実施形態１に係る設計検証装置１００の構成図である。
【図２】要求仕様データ２１０が記述している要求仕様の例を示すツリー構造である。
【図３】設計仕様データ２２０が記述している設計仕様の例を示すブロック図である。
【図４】設計仕様データ２２０の振る舞いをプログラミング言語（Ｃ言語）で表現した例である。
【図５】対応関係データ２３０の具体例である。
【図６】設計検証装置１００の動作を説明するフローチャートである。
【図７】ステップＳ６０１において生成される記号対応表の例である。
【図８】ステップＳ２６０２の詳細を説明するフローチャートである。
【図９】出力部１４０が検査部１３０による検査結果を画面表示した例である。
【図１０】設計仕様データ２２０をモデル検査器ＳＰＩＮの記述言語Ｐｒｏｍｅｌａで表現した例である。
【図１１】コンピュータを用いて設計検証装置１００を実装した場合におけるシステム構成図である。
【発明を実施するための形態】
【００１２】
＜実施の形態１＞
図１は、本発明の実施形態１に係る設計検証装置１００の構成図である。設計検証装置１００は、設計仕様が要求仕様を満たしているか否かを検証する装置である。設計検証装置１００は、要求仕様データ２１０、設計仕様データ２２０、対応関係データ２３０を入力データとして受け取る。設計検証装置１００は、記号対応付け部１１０、検査式定義部１２０、検査部１３０、出力部１４０を備える。
【００１３】
要求仕様データ２１０は、設計対象であるシステムに対する要件の集合を記述したデータである。各要件は命題変数などの記号を用いて形式仕様記述言語で表現することができる。要求仕様データ２１０は、上位要件を下位要件に分解するツリー形式で表現されている。ツリーのノードが各要件に相当する。ツリー形式で記述された要件の例については後述する。
【００１４】
設計仕様データ２２０は、設計対象システムの設計仕様を記述したデータである。設計仕様データ２２０の具体例としては、システムアーキテクチャ、ソフトウェアアーキテクチャ、ハードウェア仕様、ソフトウェア仕様などを記述したデータが挙げられる。設計仕様データ２２０は、シミュレーション可能なプログラミング言語、形式仕様記述言語などによって表現することができる。
【００１５】
対応関係データ２３０は、要求仕様データ２１０が用いている記号と、設計仕様データ２２０が用いている記号との間の論理的な対応関係を記述したデータである。ここでいう記号とは、各仕様が要件を記述するために用いている論理式、またはその論理式内で用いているプログラム変数、などのことである。例えば各仕様が同一の要素を異なる記号・変数で表現している場合や、同一の振る舞いについて異なる表現をしたりしている場合において、対応関係データ２３０はこれらの間の対応関係を記述することができる。対応関係データ２３０の具体例については後述する。
【００１６】
記号対応付け部１１０は、要求仕様データ２１０が用いている記号と、設計仕様データ２２０が用いている記号とを対応付け、その対応関係を記号対応表として出力する。記号対応表の具体例については後述する。
【００１７】
検査式定義部１２０は、設計仕様データ２２０によって記述されている設計仕様が要求仕様データ２１０によって記述されている要求仕様に適合しているか否かを検査するための検査式を定義する。検査式は、例えばプログラムの一部として組み込んで実行することによりその検査式が表す論理が成立するか否かを検証する論理式として定義することができる。その他、形式仕様記述言語として検査式を定義することもできる。検査式を定義する手順については後述する。
【００１８】
検査部１３０は、検査式定義部１２０が定義した検査式を用いて、設計仕様データ２２０を検査する。設計仕様データ２２０がプログラミング言語によって記述されている場合はそのプログラムをシミュレーション実行することにより検査する。設計仕様データ２２０が形式仕様記述言語によって記述されている場合は形式検証によって検査する。検査式定義部１２０は、設計仕様データ２２０の記述形式に応じて検査式を定義する。
【００１９】
出力部１４０は、検査部１３０による検査結果を出力する。例えば検査結果を記述したデータを出力することもできるし、検査結果を画面表示することもできる。その他適当な出力形式を用いることもできる。検査結果の出力例については後述する。
【００２０】
図２は、要求仕様データ２１０が記述している要求仕様の例を示すツリー構造である。要求仕様データ２１０は、最上位の要件２１１をルートとするツリー構造を有する。要件２１１〜２１６は、命題論理を用いて、“Ａ→Ｂ”の形で記述されている（ＡとＢは命題変数）。Ａを前件、Ｂを後件と呼ぶ。この記述方法は、時相論理式“Ａ→◇Ｂ”（◇は「いつか」の意味）に対してシンタックスシュガー（糖衣構文）を導入して簡略化したものである。各要件の論理式は、複数の命題を論理和や論理積によって論理的に結合したものであってもよい。
【００２１】
要件２１１〜２１６の記述に用いられる命題変数は、記号辞書５９に定義されている。ここでは命題変数の例として、Ｅ「電源に異常がある」、Ｄ「異常が検出される」、Ｍ「警告表示が指示される」、ＷＮ「警告が表示される」、Ｚ「駆動回路が停止する」を例示した。
【００２２】
要件２１１は“Ｅ→ＷＮ＆＆Ｚ”と記述されている。この意味は「電源に異常があれば、警告が表示され、かつ、駆動回路が停止する」である。要件２１１は、下位の要件２１２〜２１４に分解されている。要件２１２は“Ｅ→Ｍ”「電源に異常があれば、警告表示が指示される」、要件２１３は“Ｍ→ＷＮ”「警告表示が指示されれば、警告が表示される」、要件２１４は「電源に異常があれば、駆動回路が停止する」である。要件２１２は、下位の要件５２１５〜２１６に分解されている。要件２１５は“Ｅ→Ｄ”「電源に異常があれば、異常が検出される」、要件２１６は“Ｄ→Ｍ”「異常が検出されれば、警告表示が指示される」である。
【００２３】
図３は、設計仕様データ２２０が記述している設計仕様の例を示すブロック図である。設計仕様データ２２０が記述している機能ブロックは、電源２２１、駆動回路２２２、診断２２３、表示２２４を有する。電源線２２８は、電源２２１と駆動回路２２２の間、および電源２２１と診断２２３の間を接続する。表示２２４に対する電源供給は簡単のため省略している。
【００２４】
電圧２２５は、電源線２２８の電圧を通知する信号線である。停止指示２２６は、駆動回路２２２に対して停止指示を送信する信号線である。警告指示２２７は、表示２２４に対して警告指示を送信する信号線である。電圧２２５は電圧ｖ、停止指示２２６は停止指示（の有無）ｓ、警告指示２２７は警告指示（の有無）ｃとして表現されている。電圧２２５は電源線２２８から診断２２３に接続され、停止指示２２６は診断２２３から駆動回路２２２に接続され、警告指示２２７は診断２２３から表示２２４に接続されている。
【００２５】
図４は、設計仕様データ２２０の振る舞いをプログラミング言語（Ｃ言語）で表現した例である。図４に示すプログラムは、設計仕様データ２２０に内包されるものであってもよいし、設計仕様データ２２０とは別に記述したものであってもよい。ただし設計検証装置１００に対して設計仕様データ２２０として入力される実質的な内容は、図４に示すように検査部１３０が検査することができるプログラム言語や仕様記述言語によって記述されたものである。
【００２６】
図４のプログラムは、関数ｐｏｗｅｒ（）、ｄｉａｇ（）、ｄｉｓｐ（）を有する。これら関数はそれぞれ電源２２１、診断２２３、表示２２４に対応している。駆動回路２２２に対応する関数は、便宜上省略した。関数ｍａｉｎ（）は、１回分のシミュレーションを実行する関数である。電圧ｖは実システムの１０倍の値を取るようにスケーリングされている。
【００２７】
関数ｐｏｗｅｒ（）において、電圧ｖが０〜１００の値を取り、その初期値は５０、±２の範囲で変動するように更新される。関数ｄｉａｇ（）において、診断２２３の動作可否を示すフラグ変数ｅｎａが、電圧ｖが３０より大きく６０未満のときにＴＲＵＥ（動作可）、それ以外ではＦＡＬＳＥ（動作不可）にセットされる。診断２２３が動作可であり電圧ｖが４０以下または６０以上であれば、電圧異常を示すフラグｅｒｒをＴＲＵＥ（異常あり）にセットする。さらに、警告指示の有無を示すフラグｃをｅｒｒと同じ値にセットする。関数ｄｉｓｐ（）において、警告指示フラグｃがＴＲＵＥであれば、警告表示の有無を示すフラグＷＮをＴＲＵＥにセットする。
【００２８】
図５は、対応関係データ２３０の具体例である。対応関係データ２３０は、要求仕様データ２１０と同じ記法を用いて記述される。対応関係２３１は、論理式“Ｅ＝＝（ｖ＞＝６０｜｜ｖ＜＝４０）”を定義している。すなわち、要求仕様データ２１０が記述している記号“Ｅ”が表す論理命題は、設計仕様データ２２０においては“電圧ｖが６０以上または電圧ｖが４０以下”と等価であることを示す。対応関係２３２は、論理式“Ｍ＝＝ｃ”を定義している。すなわち、要求仕様データ２１０が記述している記号“Ｍ”が表す論理命題は、設計仕様データ２２０においては警告指示ｃと等価であることを示す。
【００２９】
図６は、設計検証装置１００の動作を説明するフローチャートである。記号対応付け部１１０は、記号対応表を生成する（Ｓ６０１）。検査式定義部１２０は、設計仕様データ２２０を検証するための検査式を定義する（Ｓ６０２）。ステップＳ６０２の詳細は後述する。検査部１３０は、検査式定義部１２０が定義した検査式を用いて設計仕様データ２２０を検査する（Ｓ６０３）。出力部１４０は、検査部１３０による検査結果を出力する（Ｓ６０４）。
【００３０】
図７は、ステップＳ６０１において生成される記号対応表の例である。図７に示す記号対応表によれば、要求仕様データ２１０が記述している記号Ｅ、ＷＮ、Ｍは、それぞれ設計仕様データ２２０が記述している記号ｖ、ＷＮ、ｃに対応するものとして取り扱われることになる。１行目は対応関係２３１に基づき生成したものである。３行目は対応関係２３２に基づき生成したものである。
【００３１】
記号対応表を生成する方法は次の通りである。記号対応付け部１１０は、対応関係データ２３０の各論理式（図５の対応関係２３１と２３２）について、式に含まれる記号それぞれが、要求仕様データ２１０と設計仕様データ２２０のいずれかに含まれているか否かを検索する。当該論理式に含まれる記号が全て、要求仕様データ２１０と設計仕様データ２２０のいずれかに存在するのであれば、当該論理式に含まれる記号のうち要求仕様データ２１０に含まれる記号を要求仕様側に分類し、設計仕様データ２２０に含まれる記号を設計仕様側に分類し、これらを記号対応表の１行分のレコードとして登録する。
【００３２】
要求仕様データ２１０の記号と設計仕様データ２２０の記号が１対１に対応している場合のみならず、１対複数（例として、論理式がＥ＝ｖ１＋ｖ２）、複数対１、複数対複数である場合であっても、同様の手法により記号対応表を生成することができる。例えば対応関係データ２３０が記述している論理式がＥ＝ｖ１＋Ｖ２である場合、要求仕様側として“Ｅ”、設計仕様側として“ｖ１，ｖ２”などと記述したレコードを記号対応表に記録すればよい。後述するように、記号対応表は要求仕様と設計仕様との間で対応する記号が存在することが確認できれば足りるからである。
【００３３】
さらに記号対応付け部１１０は、要求仕様データ２１０と設計仕様データ２２０が同じ記号を用いている場合も、それらの記号は対応しているものとしてその対応関係を記号対応表に登録する。図７の２行目（ＷＮ）がこれに該当する。
【００３４】
図８は、ステップＳ６０２の詳細を説明するフローチャートである。検査式は要件仕様と同様に、“Ｘ→Ｙ”（ＸならばＹ）の形で定義される。ＸとＹは命題を表す変数である。検査式は、要求仕様データ２１０が記述している要件と同様に時相論理式を簡略化して記述されている。以下図８にしたがって検査式定義部１２０の動作を説明する。
【００３５】
（図８：ステップＳ８０１）
検査式定義部１２０は、初期設定を実施する。具体的には、検査式や仮検査式を初期化するなどの処理がこれに相当する。仮検査式とは、以後のステップにおいて検査式の候補となる論理式である。
【００３６】
（図８：ステップＳ８０２）
検査式定義部１２０は、要求仕様データ２１０に含まれる要件のうち、前件の記号が全て記号対応表に登録されているものを抽出する。検査式定義部１２０は、抽出された要件の論理式を仮検査式として一時保存する。
【００３７】
（図８：ステップＳ８０２：補足）
設計検証装置１００は、要求仕様データ２１０が記述している記号と設計仕様データ２２０が記述している記号との間の対応関係が取れている論理式を、検査式として用いる。本ステップは、前件について対応関係が取れているか否かをいったんチェックすることにより、検査式の候補を絞り込むためのものである。
【００３８】
（図８：ステップＳ８０３）
検査式定義部１２０は、仮検査式の数を調べる。仮検査式の数が０より大きい場合は、ステップＳ８０４〜Ｓ８０９を各仮検査式について実施する。仮検査式の数が０である場合は、検査式なしとして本フローチャートを終了する。
【００３９】
（図８：ステップＳ８０４〜Ｓ８０５）
検査式定義部１２０は、現在処理している仮検査式の後件を前件として有する要件を、要求仕様データ２１０から１つ検索する。ただしステップＳ８０２やステップＳ８０４においてこれまで取り扱った要件は検索対象から除く。条件に該当する要件が存在する場合はステップＳ８０６へ進み、存在しない場合はステップＳ８０７へ進む。
【００４０】
（図８：ステップＳ８０６）
検査式定義部１２０は、仮検査式の後件を、ステップＳ８０４において検索により得られた要件が有する後件と置き換える。例えば、仮検査式が“Ｘ→Ｙ”であり、ステップＳ８０４において得られた要件が“Ｙ→Ｚ”である場合は、仮検査式を“Ｘ→Ｚ”に更新する。これにより、論理式“Ｘ→Ｙ”と“Ｙ→Ｚ”を結合して新たな論理式“Ｘ→Ｚ”を得たことになる。この結合された論理式を検査式として用いることにより、要件“Ｘ→Ｙ”と“Ｙ→Ｚ”を一括して検証することができる。より詳細な例については後述する。
【００４１】
（図８：ステップＳ８０７）
検査式定義部１２０は、仮検査式の後件の記号が全て記号対応表に登録されているか否かを照合する。後件の全記号が登録されていればステップＳ８０８に進み、そうでなければステップＳ８０９に進む。本ステップにより、前件と後件ともに記号が対応付けられている論理式を、検査式として抽出することができる。
【００４２】
（図８：ステップＳ８０８〜Ｓ８０９）
検査式定義部１２０は、ステップＳ８０７において記号が対応していると判断された仮検査式を、正式な検査式として登録する。ただし、既に登録済である場合は重複登録する必要はない。検査式定義部１２０は、ステップＳ８０７において記号が対応していないと判断された仮検査式を、検査式の候補から破棄する。
【００４３】
以下では、検査式定義部１２０が図２の要求仕様データ２１０から検査式を抽出する手順を説明する。説明の簡易のため、図５の対応関係２３１のみが与えられ、対応関係２３２は与えられていないことを前提とする。したがって記号対応表は、図７の１行目と２行目のみとなる。
【００４４】
ステップＳ８０２において、検査式定義部１２０は、記号対応表内に含まれる記号ＥまたはＷＮを前件として有する要件を、要求仕様データ２１０から抽出する。抽出された要件は仮検査式として取り扱われる。ここでは要件２１１、２１２、２１４、２１５がこれに該当する。これら要件について、図８のフローチャートにしたがってどのように処理されるかを説明する。
【００４５】
要件２１１については、その後件（ＷＮ＆＆Ｚ）を前件として有するその他要件が存在しないので、ステップＳ８０４において抽出されないので、ステップＳ８０５とステップＳ８０７の判定結果がＮｏとなり、ステップＳ８０９において破棄される。
【００４６】
要件２１２については、その後件（Ｍ）を前件として有する要件２１３がステップＳ８０４において抽出されることになる。したがって、論理式“Ｅ→Ｍ”と“Ｍ→ＷＮ”を結合することができるので、ステップＳ８０６において仮検査式が “Ｅ→ＷＮ”に更新される。ステップＳ８０８において、“Ｅ→ＷＮ”が検査式として登録される。
【００４７】
要件２１４については、要件２１１と同様にステップＳ８０９において破棄される。
【００４８】
要件２１５については、その後件（Ｄ）を前件として有する要件２１６がステップＳ８０４において抽出されることになる。したがって、ステップＳ８０６において仮検査式が “Ｅ→Ｍ”に更新される。さらに更新後の仮検査式の後件（Ｍ）を前件として有する要件２１３が抽出されるので、仮検査式は“Ｅ→ＷＮ”となる。ただしこの仮検査式は既に登録されているので、ステップＳ８０８において登録されない。
【００４９】
対応関係２３２がさらに与えられている場合は、記号対応表内に含まれる記号Ｍを前件として有する要件２１３が仮検査式として抽出される。この場合、最終的な検査式は“Ｅ→Ｍ”および“Ｍ→ＷＮ”となる。
【００５０】
以下では、検査部１３０が設計仕様データ２２０を検査する方法を説明する。検査部１３０は、検査実行前に、記号対応表を用いて検査式を書き換える。“Ｅ→ＷＮ”は、“（ｖ＜＝４０｜｜ｖ＞＝６０）→ＷＮ”と書き換えられる。検査部１３０は、設計仕様データ２２０の挙動をシミュレーションするために、設計仕様データ２２０をコンパイルし、所定回数だけ繰り返し実行する。検査部１３０は、１回の実行ごとに、検査式が成立するか否かを判定する。前件（ｖ＜＝４０｜｜ｖ＞＝６０）が真であるのに後件（ＷＮ）が偽であるケースが１回でも生じた場合は、検査式“Ｅ→ＷＮ”を不合格と判定する。シミュレーション中に前件（Ｅ）が１度も真にならない場合は、検査結果は「確認不可」とする。不合格でも確認不可でもなくシミュレーションを完了したら、検査式は合格と判定する。
【００５１】
図４に示した設計仕様データ２２０は、電圧ｖが６０のときｅｒｒ＝ＴＲＵＥとなるように記述されているので、本来であれば電圧異常とみなされるはずである。他方で電圧ｖが６０のときｅｎａ＝ＦＡＬＳＥとなるので、ｅｒｒ＝ＴＲＵＥが実行されず、したがってｃ＝ＦＡＬＳＥのままなので、ＷＮ＝ＦＡＬＳＥとなる。そうすると電圧ｖが６０のとき、要件Ｅ（ｖ＜＝４０｜｜ｖ＞＝６０）がＴＲＵＥであってもＷＮ＝ＦＡＬＳＥとなるので、検査式は成立しないことになる。すなわち、検査式“Ｅ→ＷＮ”は不合格と判定される。出力部１４０は、検査式が満たされなかった条件（ここでは電圧ｖ＝６０）を、検査結果と併せて出力する。電圧ｖのその他の値についても同様に検査式が成立するか否かを検証する。
【００５２】
検査部１３０が設計仕様データ２２０を検査することにより、要求仕様データ２１０と設計仕様データ２２０との整合性（矛盾の有無）を、自動的に検査することができる。また、要求仕様データ２１０と設計仕様データ２２０は同一の対象・振る舞いを異なる記号で表現しているが、このような場合であっても、両者の記号の対応付け、確認可能な検査式の生成、検査実行を自動的に実施することができる。
【００５３】
図９は、出力部１４０が検査部１３０による検査結果を画面表示した例である。ここでは図２で説明した要求仕様データ２１０を入力として検査し、検査式“Ｅ→ＷＮ”が満たされた例を示した（検査式欄１４２）。
【００５４】
要求仕様欄１４１は、要求仕様データ２１０のツリー構造に対して、検査結果を反映したものである。記号対応表に記載のある記号は、下線が引かれている。満たされた検査式を生成する際に使用した要件（先に説明した例においては要件２１２と２１３）は太線枠で囲まれている。さらに検査式が満たされることによりこれらの下位要件（要件２１５と２１６）も間接的に満たされたものとみなすことができるので、同様に太線枠で囲まれている。下位要件が全て満たされている要件は、満たされたものとして表示してもよい。例えば要件２１５と要件２１６が検査式として取り扱われて満たされた場合、要件２１２は満たされたものとして表示してもよい。
【００５５】
要求仕様欄１４１により、上位要件を下位要件に分解するツリー形式の要求仕様データ２１０について、設計仕様データ２２０が要件を満たす範囲を提示するとともに、検査されていない範囲を提示することができる。これによりユーザは、要求仕様データ２１０や設計仕様データ２２０の確認・見直しを効率的にすることができる。例えばユーザは、満たされていない要件については、要求仕様データ２１０または設計仕様データ２２０を修正することができる。また、検査式に関係していない要件（すなわち検査されていない要件）については、必要に応じて、対応関係データ２３０を増補することにより、検査されるようにすることができる。
【００５６】
＜実施の形態２＞
実施形態１においては、命題論理を用いて要件や検査式を記述しているが、これに代えて時相論理式を用いて記述してもよい。時相論理式を用いて要件を記述する場合、図８で説明した検査式定義部１２０の処理手順が若干変わる。例えば時相論理としてＬＴＬ（Ｌｉｎｅａｒ  Ｔｅｍｐｏｒａｌ  Ｌｏｇｉｃ）が用いられており、要件が例えば“Ｘ→◇Ｙ”の形で記述されている場合、ステップＳ８０４において“Ｘ→◇Ｙ”と“Ｙ→◇Ｚ”が論理的につながり、ステップＳ８０６において仮検査式は“Ｘ→◇Ｚ”に更新される。対応関係２３１を与えて対応関係２３２を与えない場合、ステップＳ８０８において登録される検査式は“Ｅ→◇ＷＮ”となる。さらに検査式定義部１２０は、図８のフローチャートによって得られた検査式を□（いつも）で囲い、最終的な検査式は“□（Ｅ→◇ＷＮ）”とする。
【００５７】
図１０は、設計仕様データ２２０をモデル検査器ＳＰＩＮの記述言語Ｐｒｏｍｅｌａで表現した例である。ここでは図４と同じ振る舞いを記述した例を示した。形式検証の一種であるモデル検査は、シミュレーションより厳密な検査を実施することができる。
【００５８】
検査部１３０は、設計仕様データ２２０と、時相論理による検査式“□（Ｅ→◇ＷＮ）”とを併せてモデル検査器ＳＰＩＮに入力して実行可能な検査器を生成させ、検査を実行させる。モデル検査器は、検査式の合否と、検査式が満たされない場合は検査式に違反する実行パスを反例として出力する。図１０に示す設計仕様データ２２０については、電圧ｖが６０以上になってもＷＮが真とならない場合が反例として得られるので、検査結果は不合格である。出力部１４０は、図９と同様に検査式、検査結果、反例を出力する。
【００５９】
＜実施の形態３＞
実施形態１〜２で説明した設計検証装置１００の各機能部（記号対応付け部１１０〜出力部１４０）は、ソフトウェアとして実装することができる。設計検証装置１００は、各機能部を実行するプロセッサ、表示画面、主演算装置、主記憶装置（メインメモリ）、記憶媒体（ハードディスク等）、入力装置（キーボードやポインティングデバイス等）を備えるコンピュータを用いて構成することができる。
【００６０】
図１１は、コンピュータを用いて設計検証装置１００を実装した場合におけるシステム構成図である。記号対応付け部１１０〜出力部１４０は、設計検証プログラム３１３１として実装されている。設計検証プログラム３１３１は、例えばコンピュータ２１上のＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）３１３に格納されており、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）３１１によって読み出され、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）３１２を一時記憶領域として実行される。コンピュータ２１は、設計検証プログラム３１３１によって規定された処理を実行する。各入力データ（要求仕様データ２１０〜対応関係データ２３０）、検査部１３０からの出力データ、中間処理結果などの電子データは、コンピュータ３１上のハードディスク３１４に格納される。検査実行指示などのユーザ操作は、入力装置２２から実施できる。
【００６１】
出力部１４０からの出力は、例えばディスプレイなどの表示装置３３やハードディスク３１４に対して出力されるが、これに限られるものではない。例えば出力部１４０は、図示しない外部コンピュータへのネットワークを介した出力、ＣＤ−ＲＯＭなどの外部記憶媒体へのデータファイル形式での出力、などの出力形式を用いてもよい。
【００６２】
＜本発明の変形例について＞
本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【００６３】
以上の実施形態において、要求仕様データ２１０と設計仕様データ２２０とで同じ記号を利用している場合、これらの記号は対応しているものとして取り扱うことを説明した。ただしこれらの記号間に対応関係があるとするか否かは、設計検証装置１００の設計者や利用者に選択させてもよい。
【００６４】
以上の実施形態において、要求仕様欄１４１は、検査結果として図９以外の適当な表示形式を用いてもよい。例えば検査式を生成する際に関係した要件（説明した例においては、要件２１２、２１３、２１５、２１６）について、検査式が満たされたことを示す印（例：チェックマーク）、満たされなかったことを示す印（例：×印）を付与してもよい。いずれの検査式にも関係していない要件については、その旨を示す印（例：クエスチョンマーク）を付けて表示してもよい。
【００６５】
以上の実施形態において、対応関係データ２３０は、例えば要求仕様データ２１０または設計仕様データ２２０の設計者が与えることもできるし、適当な手段によって要求仕様データ２１０と設計仕様データ２２０を比較することにより自動生成することができるのであればそれによって与えてもよい。
【符号の説明】
【００６６】
１００：設計検証装置
１１０：記号対応付け部
１２０：検査式定義部
１３０：検査部
１４０：出力部
２１０：要求仕様データ
２２０：設計仕様データ
２３０：対応関係データ
【図１】
0006731062.tif 000002
【図２】
0006731062.tif 000003
【図３】
0006731062.tif 000004
【図４】
0006731062.tif 000005
【図５】
0006731062.tif 000006
【図６】
0006731062.tif 000007
【図７】
0006731062.tif 000008
【図８】
0006731062.tif 000009
【図９】
0006731062.tif 000010
【図１０】
0006731062.tif 000011
【図１１】
0006731062.tif 000012