JP2011044131A - 設計検証プログラム、設計検証方法および設計検証装置 - Google Patents

Abstract

【課題】効率的な検証工程の情報を提供すること。
【解決手段】生成部２は、設計対象の設計仕様が備える複数の処理手順（処理のシナリオ）が備える処理単位それぞれに設計仕様の検証対象となる部位（検証対象部位）を識別する識別情報（ラベル）を関連付けた、検証用情報を生成する。処理優先度付与部３は、識別情報７の入力に応じて、検証用情報に処理優先度を付与する。出力部４は、処理優先度が付与された検証用情報６ａ、６ｂを識別する情報を、処理優先度を明示して出力する。
【選択図】図１

Description

本発明は設計検証プログラム、設計検証方法および設計検証装置に関する。

近年、設計技術の進歩により、ソフトウェアやハードウェアの開発対象が大規模化している。
設計開発時には、開発対象に対する動作検証を行い、開発対象の動作を確認しつつ、設計を進めることが行われている。

前述した開発対象の大規模化により、開発工程全体における検証工程の占める割合が増加する傾向にある。
一方で、納期短縮等による設計期間の短縮化や、工数が当初の見積もりより大きくなる等の理由により、設計期間が足りなくなることはしばしばある。

このため、検証効率の向上のため、例えば、検証工程の検証項目を抽出し、設計期間の短縮化を図る技術が知られている。

米国特許第７２７５２３１号明細書 特開２００６−８５７１０号公報 特開２００４−１８５５９２号公報

抽出した全ての検証工程についての検証を順不同に実行すると、優先的に検証したい工程が最後の方に存在した場合、エラーを検出するまでに時間がかかり、検証の処理効率が低くなる。

このため、膨大な数の検証工程から検証したい工程を優先的に検証したい場合は、設計者や検証者（ユーザ）の経験により、膨大な数の検証工程から検証を行うための検証手順を選択して検証を行うことが行われている。

しかしながら、設計者や検証者の経験が浅い場合、適切な検証手順の選択を誤る場合があり、誤って選択された検証手順によっては、やはり検証の処理効率が低いという問題がある。

本発明はこのような点に鑑みてなされたものであり、効率的な検証工程の情報を提供することができる設計検証プログラム、設計検証方法および設計検証装置を提供することを目的とする。

上記目的を達成するために、開示の設計検証プログラムが提供される。この設計検証プログラムは、コンピュータに、生成手順、処理優先度付与手順、出力手順を実行させる。
生成手順では、設計対象の設計仕様が備える複数の処理手順が備える処理単位それぞれに設計仕様の検証対象部位を識別する識別情報を関連付けた検証用情報を生成する。

処理優先度付与手順では、識別情報の入力に応じて、検証用情報に処理優先度を付与する。
出力手順では、処理優先度が付与された検証用情報を識別する情報を、処理優先度を明示して出力する。

開示の設計検証プログラムによれば、効率的な検証工程の情報を提供することができる。

第１の実施の形態の設計検証装置を説明する図である。 第１の実施の形態の設計検証装置を説明する図である。 実施の形態のシステムを示す図である。 実施の形態のＬＳＩの設計仕様の構成を示す図である。 ＬＳＩの設計仕様のデータ構造の一例を示す図である。 メッセージ・シーケンス・チャート間の関係と階層構造を説明する図である。 メッセージ・シーケンス・チャートの構成を説明する図である。 メッセージ・シーケンス・チャートの他の例を示す図である。 設計検証装置のハードウェア構成例を示す図である。 設計検証装置の機能を示すブロック図である。 設計検証装置の全体処理を示すフローチャートである。 検証用シナリオ生成処理を示すフローチャートである。 検証用シナリオ生成処理を示すフローチャートである。 ラベル付与処理を示すフローチャートである。 優先順位付与処理を示すフローチャートである。 ＬＳＩの設計仕様のデータ構造の具体例を示す図である。 メッセージ・シーケンス・チャートの具体例を示す図である。 ＬＳＩの設計仕様にラベルを付与する具体例を示す図である。 ＬＳＩの設計仕様にラベルを付与する具体例を示す図である。 ＬＳＩの設計仕様にラベルを付与する具体例を示す図である。 ラベルを付与したＬＳＩの設計仕様のデータ構造例を示す図である。 ＬＳＩの設計仕様にラベルを付与する他の具体例を示す図である。 有限ステートマシンに変換する処理を説明するメッセージ・シーケンス・チャートを示す図である。 図２３に示すメッセージ・シーケンス・チャートに関連する状態マトリックスを示す図である。 状態マトリックスに関する状態図を示す図である。 有限ステートマシンにラベルを付与する具体例を示す図である。 有限ステートマシンにラベルの付与が終了したときの状態を示す図である。 状態マトリックスに関する状態図を示す図である。 有限ステートマシンのデータ構造例を示す図である。 検証用シナリオ格納部に格納されている検証用シナリオを示す図である。 優先順位が付与された検証用シナリオのデータ構造を示す図である。 優先順位が付与された検証用シナリオのデータ構造を示す図である。 優先順位リストの具体例を示す図である。 第３の実施の形態のシステムを示すブロック図である。 第３の実施の形態の設計検証装置の全体処理を示すフローチャートである。 第３の実施の形態の検証用シナリオ生成処理を示すフローチャートである。 検証用シナリオ抽出処理を示すフローチャートである。 第３の実施の形態のＬＳＩの設計仕様のデータ構造の具体例を示す図である。 第３の実施の形態のメッセージ・シーケンス・チャート間の関係と階層構造を説明する図である。 シナリオ「照会」のメッセージ・シーケンス・チャートを示す図である。 第３の実施の形態のＬＳＩの設計仕様にラベルを付与する具体例を示す図である。 第３の実施の形態のＬＳＩの設計仕様にラベルを付与する具体例を示す図である。 ラベル付与が完了した状態の有向グラフを示す図である。 ラベルを付与したＬＳＩの設計仕様のデータ構造例を示す図である。 オブジェクト名をラベルに追加する具体例を示す図である。 有限ステートマシンにラベルの付与が終了したときの状態を示す図である。 メッセージ名と送受信側のオブジェクト名をラベルに追加した状態の有限ステートマシンのデータ構造を示す図である。 抽出した検証用シナリオの集合積を行う様子を示す図である。 抽出した検証用シナリオの集合積を行う様子を示す図である。

以下、実施の形態を、図面を参照して詳細に説明する。
まず、第１の実施の形態の設計検証装置について説明し、その後、第２の実施の形態以降、設計検証装置をより具体的に説明する。

＜第１の実施の形態＞
図１および図２は、第１の実施の形態の設計検証装置を説明する図である。
実施の形態の設計検証装置１は、生成部２と、処理優先度付与部３と、出力部４とを有している。

生成部２は、設計対象の設計仕様が備える複数の処理手順（処理のシナリオ）が備える処理単位それぞれに、設計仕様の検証対象となる部位（検証対象部位）を識別する識別情報（ラベル）を関連付けた、検証用情報を生成する。この検証用情報は、処理手順を検証（例えば処理手順の成否を検証）するものである。

ここで、設計対象は、設計検証装置１によるテストおよび検証対象となるハードウェアコンポーネントまたはシステムやソフトウェアモジュールである。
この設計対象の設計仕様は、実装が守るべき約束事を記したものであり、少なくとも１つの機能により実現される。

図１では、機能５ａと機能５ｂとを有する設計仕様５を示している。機能５ａは、機能５ａを実現する２つの処理手順５０ａと処理手順５０ｂを有している。
処理手順５０ａは、機能５ａの基本動作についての処理手順であり、処理手順５０ｂは、基本動作に取って替わる代替動作についての処理手順である。

図１では、処理手順５０ａは枝構造を有しており、ノードとなる部分に基本動作の実行すべき処理単位が設定されている。この処理単位としては、例えば、機能５ａの実現に関わっている全てのオブジェクト間のやり取りを明確にした仕様であるメッセージ・シーケンス・チャート（Message Sequence Chart）等が挙げられる。なお、メッセージ・シーケンス・チャートについては、特許文献１と特許文献２を参照のこと。

処理手順５０ａと処理手順５０ｂとの関係は、図２に示す構造体６によって示される。
この構造体６を用いることで、設計仕様５をコンパクトに表示することができる。
構造体６は、第１のシーケンス、第２のシーケンス、および、第３のシーケンスと、これら各シーケンス間の関係を示すブランチ（branch）およびマージ（merge）を有している。

各シーケンスのブロックを接続する矢印は、機能が実行される順序を記述する。
処理手順５０ａは、第１のシーケンス、第２のシーケンスの順番に処理が行われることを示している。

処理手順５０ｂは、第１のシーケンス、第３のシーケンスの順番に処理が行われることを示している。
従って、構造体６は、これら２つの処理手順が第１のシーケンスまで同じ動作を有するが、それ以降の動作は異なっていることを示す。

構造体６のエッジは有向であり、ガード条件が付与されている。
ガード条件は、各シーケンスの終了後、ガード条件が成立すればエッジ先のシーケンスに遷移することを示している。

図２では、第１のシーケンスの処理後、ｉ＞０のガード条件が成立すれば、第２のシーケンスに移行する。一方、ｉ＜＝０のガード条件が成立すれば、第３のシーケンスに移行する。

図１に示す機能５ａの場合、生成部２は、処理手順５０ａ、すなわち、基本動作に対し、処理手順５０ａが備える第１のシーケンスおよび第２のシーケンスそれぞれに設計仕様の検証対象部位を識別する識別情報を関連付けた検証用情報を生成する。

検証対象部位は、例えば、機能、処理手順、処理単位等が挙げられる。図２では、第１のシーケンス、第２のシーケンスそれぞれに、機能５ａを識別する識別情報「機能＃１」、処理手順５０ａを識別する識別情報「基本動作」を関連付ける。

また、生成部２は、処理手順５０ｂ、すなわち、代替動作に対し、処理手順５０ｂが備える第１のシーケンスおよび第３のシーケンスそれぞれに設計仕様の検証対象部位を関連付けた検証用情報を生成する。

図２では、第１のシーケンス、第３のシーケンスそれぞれに、機能５ａを識別する識別情報「機能＃１」、処理手順５０ｂを識別する識別情報「代替動作」を関連付ける。
この結果、第１のシーケンスには、識別情報「機能＃１：基本動作」、「機能＃１：代替動作」が関連付けられる。第２のシーケンスには、識別情報「機能＃１：基本動作」が関連付けられる。第３のシーケンスには、識別情報「機能＃１：代替動作」が関連付けられる。

そして、生成部２は、同じ識別情報を備えるシーケンスを抽出し、抽出したシーケンスの集合をそれぞれ検証用情報とする。
図２では、識別情報「基本動作」を備える第１のシーケンスおよび第２のシーケンスの集合を１つの検証用情報とする。また、識別情報「代替動作」を備える第１のシーケンスおよび第３のシーケンスの集合を１つの検証用情報とする。

再び図１に戻って説明する。
処理優先度付与部３は、識別情報７の入力に応じて、検証用情報に処理優先度を付与する。

例えば、識別情報７として、「基本動作」および「代替動作」が入力されたものとする。
図１に示すように、基本動作の処理優先度が代替動作の処理優先度より高い場合、検証用情報６ａに、検証用情報６ｂより高い優先度「１」を付与する。また、検証用情報６ｂに優先度「２」を付与する。

出力部４は、処理優先度が付与された検証用情報６ａ、６ｂを識別する情報を、処理優先度を明示して出力する。
図１では、優先度「１」に検証用情報６ａを示す検証用情報＃１を関連付けたレコードと、優先度「２」に検証用情報６ｂを示す検証用情報＃２を関連付けたレコードとを備える出力結果８を出力する。

このような設計検証装置１によれば、生成部２が、検証用情報６ａ、６ｂを生成し、処理優先度付与部３が、設計仕様の複数の検証対象部位およびこれら検証対象部位の処理優先度情報の入力に応じて、検証用情報毎に処理優先度を付与するようにした。

これにより、検証対象の単位に応じて行うべき処理優先度を容易に把握することができる。従って、ユーザは、この処理優先度の順に検証用情報を用いて検証対象の検証を行うことにより、効率よく検証を行うことができる。

なお、本実施の形態では、処理優先度付与部３が、生成部２によって生成された検証用情報６ａ、６ｂを直接処理したが、これに限らず、検証用情報６ａ、６ｂを格納する格納部を設け、ユーザの検証対象部位の入力を待機して処理を行うようにしてもよい。

以下、実施の形態をより具体的に説明する。
＜第２の実施の形態＞
図３は、実施の形態のシステムを示す図である。

システム１００は、設計検証装置１０と、信号インタフェース２００とテスト対象装置３００とを有している。
設計検証装置１０は、テスト対象装置３００が設計仕様に従って動作するか判断するため、設計仕様が備えるシナリオ毎に、これらシナリオを検証するための検証用シナリオを生成する。

そして、設計検証装置１０は、検証用シナリオに優先順位を付与する。
さらに、設計検証装置１０は、優先順位が付与された検証用シナリオを利用して、テスト対象装置３００がこの検証用シナリオに従って動作するか否かを判断するため、信号インタフェース２００を介しテスト対象装置３００と通信する。

この際、付与した優先順位に従って、検証用シナリオをテスト対象装置３００に流す。
信号インタフェース２００は、設計検証装置１０とテスト対象装置３００とを接続するための装置を表す。信号インタフェース２００は、設計検証装置１０により通信される信号を設計検証装置１０による利用に適した信号に変換する。

なお、例えば、設計検証装置１０とテスト対象装置３００が互換的な信号を使用する場合、信号インタフェース２００は省略されてもよい。
テスト対象装置３００は、設計検証装置１０によるテストおよび検証対象となるハードウェアコンポーネントまたはシステムやソフトウェアモジュールを表す。

テスト対象装置３００は、製品開発中に製造される設計プロトタイプであってもよいし、設計検証装置１０によって生成されるステートマシン（State Machine）であってもよい。以下、テスト対象装置３００がＬＳＩ（Large Scale Integration）である場合を例にとって説明する。

＜ＬＳＩの設計仕様＞
図４は、実施の形態のＬＳＩの設計仕様の構成を示す図である。
前述したように、設計仕様とは、実装が守るべき約束事を記したものであり、複数の機能により実現される。

なお、設計仕様は、リスト構造で表現される。このリスト構造は、例えば、ＸＭＬ（Extensible Markup Language）形式で表現される。
各機能ブロック２１、２２、２３には、それぞれ１つの機能が対応付けられている。対応付けられた各機能は、例えば、ソフトウェアにより呼び出されるハードウェアで実現する機能であり、または、ハードウェアに依存するソフトウェアで実現する機能である。

各機能ブロック２１、２２、２３は、それぞれ、１つまたは複数のシナリオブロックを有している。例えば、機能ブロック２１は、シナリオブロック２１ａとシナリオブロック２１ｂとを有している。

各シナリオブロック２１ａ、２１ｂには、それぞれ、１つのシナリオが対応付けられている。対応付けられた各シナリオは、機能の実体であり、呼び出し時の条件により複数存在する。

より詳しくは、シナリオは、機能を実現するために実行される一連の操作を定義するものである。言い換えると、シナリオは、オブジェクト間で送受信されるメッセージの順序および組み合わせを表すものである。

各シナリオブロック２１ａ、２１ｂは、それぞれ、１つまたは複数のメッセージ・シーケンス・チャートブロック（以下、「ＭＳＣブロック」と言う）を有している。例えば、シナリオブロック２１ａは、ＭＳＣブロック２１１ａと、ＭＳＣブロック２１２ａとを有している。

ＭＳＣブロック２１１ａ、２１２ａには、それぞれ、１つのメッセージ・シーケンス・チャートが対応付けられている。
メッセージ・シーケンス・チャートは、シナリオが備えるサブ機能群である。具体的には、メッセージ・シーケンス・チャートは、機能の実現に関わっている全てのオブジェクト間のやり取りを明確にしたものである。このオブジェクトは、ＬＳＩ２０が備える機能や、このＬＳＩ２０を含むシステムに干渉する外部環境を含む。

＜ＬＳＩの設計仕様のデータ構造＞
次に、ＬＳＩ２０の設計仕様のデータ構造を説明する。
図５は、ＬＳＩの設計仕様のデータ構造の一例を示す図である。

前述したように、ＬＳＩ２０の設計仕様は、複数の機能により実現される。図５では、図４に示した設計仕様をツリー構造で示し、そのうちの１つの機能を示している。
前述したように、機能ブロック２１に対応付けられている機能は、シナリオブロック２１ａに対応付けられているシナリオＡ１とシナリオブロック２１ｂに対応付けられているシナリオＡ２とを有している。

シナリオＡ１、Ａ２は、それぞれ、「基本動作」、「代替動作」、「例外動作」のいずれか１つの属性を有している。その属性が、種類として記載されている。
また、各シナリオＡ１、Ａ２それぞれには、実行条件として、事前条件、事後条件、不変条件（の１つまたは複数）が定義されている場合がある。

事前条件とは、機能を実現する一連の操作の実行前に満たすべき（真となる）条件である。
事後条件とは、一連の操作の実行後に満たすべき条件である。

不変条件とは、事後条件が発生するまでの間（一連の操作の実行中）に要求される条件である。
図５では、シナリオＡ１は、基本動作についてのシナリオであり、事前条件と、事後条件と、不変条件とを有している。

シナリオＡ２は、シナリオＡ１に対する代替動作についてのシナリオであり、基本動作と同様に、事前条件と、事後条件と、不変条件とを有している。
ＭＳＣブロック２１１ａ、２１２ａに対応付けられているメッセージ・シーケンス・チャートは、メッセージ・シーケンス・チャートを識別するための名前（識別名）を有している。ＭＳＣブロック２１１ａに対応付けられているメッセージ・シーケンス・チャートの識別名は、「ＭＳＣ１の動作」であり、ＭＳＣブロック２１２ａに対応付けられているメッセージ・シーケンス・チャートの識別名は、「ＭＳＣ２の動作」である。

メッセージ・シーケンス・チャートは、実行条件として、事前条件、事後条件、不変条件（の１つまたは複数）が定義されている場合がある。
メッセージ・シーケンス・チャート「ＭＳＣ１の動作」は、事前条件と、不変条件と、事後条件とを有している。

メッセージ・シーケンス・チャート「ＭＳＣ２の動作」は、事前条件と、不変条件と、事後条件とを有している。
なお、シナリオブロック２１ｂも少なくとも１つのＭＳＣブロックを有しているが、図５ではその図示を省略している。

ところで、ＬＳＩ２０の設計仕様は、複数のメッセージ・シーケンス・チャートを含む単一の有向グラフによって表されてもよいし、単一の平坦化されたメッセージ図によって表されてもよい。

この平坦化されたメッセージ・シーケンス・チャートは、オブジェクト間で通信されるメッセージの順序を示すものである。
さらに、ＬＳＩ２０の設計仕様は、互いに埋め込まれた複数の有向グラフと複数のメッセージ・シーケンス・チャートによって表されてもよい。

図６は、メッセージ・シーケンス・チャート間の関係と階層構造を説明する図である。
本実施の形態では、ＬＳＩ２０の設計仕様は、有向グラフ３０によって、階層的に形成されている。

この有向グラフ３０を用いることで、ＬＳＩ２０の設計仕様をコンパクトに表示することができる。
前述したように、有向グラフ３０は、複数のメッセージ・シーケンス・チャートと、これらメッセージ・シーケンス・チャート間の関係を示すブランチおよびマージを有している。この関係は、メッセージ・シーケンス・チャートを１以上のシーケンスに順序付けするものである。

他方、各メッセージ・シーケンス・チャートは、オブジェクト間の関係を示すものである。メッセージ・シーケンス・チャートは、オブジェクト間で通信されるメッセージを特定し、少なくとも一部のメッセージが通信される順序を示すものである。

有向グラフ３０は、将来的なユーザを認証するため、ある機能によって実行される複数の機能の関係を記述する。これら機能は、形状によって表されるメッセージ・シーケンス・チャートによって規定される。各メッセージ・シーケンス・チャートは、機能によって表現されている。各ブロックを接続する矢印は、機能が実行される順序を記述する。

また、有向グラフ３０のエッジは有向であり、ガード条件が付与されている場合がある。
図６に示すように、有向グラフ３０は、各自がメッセージ・シーケンス・チャート３２、メッセージ・シーケンス・チャート３３およびｈメッセージ・シーケンス・チャート３４によって表される独立したメッセージ・シーケンス・チャートによって規定される３つの機能を有している。

ここで、ｈメッセージ・シーケンス・チャート３４は、複数のメッセージ・シーケンス・チャートの階層構造をまとめて表したものである。
初期状態ブロック３１は、仮想的な状態であり、エントリポイントを有向グラフ３０に提供する。具体的には、どのメッセージ・シーケンス・チャートが最初に「起動」されるかを指定する。

従って、初期状態ブロック３１とメッセージ・シーケンス・チャート３２との間の矢印は、メッセージ・シーケンス・チャート３２に関連するメッセージ・シーケンス・チャートが有向グラフ３０へのエントリ後に直面することを示す。

メッセージ・シーケンス・チャート３２により表されるメッセージ・シーケンス・チャートに規定されるメッセージの通信後、メッセージ・シーケンス・チャート３３またはｈメッセージ・シーケンス・チャート３４のいずれかに実行が継続される。

従って、有向グラフ３０は、２つのシナリオを含む。
１つのシナリオは、初期状態ブロック３１、メッセージ・シーケンス・チャート３２およびメッセージ・シーケンス・チャート３３を介し進行するパスに関する。

他のシナリオは、初期状態ブロック３１、メッセージ・シーケンス・チャート３２およびｈメッセージ・シーケンス・チャート３４を介し進行するパスに関する。
従って、有向グラフ３０は、これら２つのシナリオがメッセージ・シーケンス・チャート３２まで同じ動作を有するが、メッセージ・シーケンス・チャート３２からの動作は異なっていることを示す。

有向グラフ３０のエッジは有向であり、ガード条件が付与されている。
ガード条件は、メッセージ・シーケンス・チャートに記述されたメッセージのシーケンスの終了後、ガード条件が成立すればエッジ先のメッセージ・シーケンス・チャート、または、その階層内のメッセージ・シーケンス・チャートへ遷移する。

図６では、メッセージ・シーケンス・チャート３２の処理後、ｉ＞０のガード条件が成立すれば、メッセージ・シーケンス・チャート３３に移行する。一方、ｉ＜＝０のガード条件が成立すれば、ｈメッセージ・シーケンス・チャート３４に移行する。

この情報は、２つのシナリオの共通部分が設計に関する有向グラフ３０を完全にテストするのに繰り返される必要はないため、検証および検証目的に有用に利用される。
ここで、有向グラフ３０が有する各メッセージ・シーケンス・チャートは、同一のオブジェクト群を利用してもよい。さらに、あるメッセージ・シーケンス・チャートによって規定される各メッセージが、次のメッセージ・シーケンス・チャートがパスに沿って実行可能となる前に実行される必要があるということを示すルールが、有向グラフ３０に関連して設けられていてもよい。

次に、メッセージ・シーケンス・チャートの一般的な構成を説明する。
＜メッセージ・シーケンス・チャート＞
図７は、メッセージ・シーケンス・チャートの構成を説明する図である。

前述したように、メッセージ・シーケンス・チャートは、機能の実現に関わっている全てのオブジェクト間のやり取りを明確にしたものである。
メッセージ・シーケンス・チャートは、ＬＳＩが備えるハードウェアブロック、または、システムと干渉する外部環境であるオブジェクトを有している。

図７に示すメッセージ・シーケンス・チャート（ＭＳＣ）４０には、複数のオブジェクトとして、ハードウェア（ＨＷ）４１、４２、４３が設けられている。
これらのオブジェクトが生成された後、データ・イベント・メッセージはオブジェクト間で通信されるものとして示される。

このデータ・イベント・メッセージは、ユーザにより指定されるものである。ユーザは当該メッセージがどのオブジェクト間で通信されるか指定することができる。
例えば、ユーザにより、１つのオブジェクトが選択され、その後に図示しないポインティングツールを用いて第２のオブジェクトが選択される。

メッセージ・シーケンス・チャート４０の生成時には、送信イベントを有する第１オブジェクトと受信イベントを有する第２オブジェクトからなる示された２つのオブジェクトの間においてデータ・イベント・メッセージが生成される。このようにして、データ・イベント・メッセージｍ１〜ｍ４の矢印が、メッセージ・シーケンス・チャート４０に示されるハードウェア４１、４２、４３間で送受信されるデータ・イベント・メッセージｍ１〜ｍ４の４個のメッセージを表すよう生成される。

具体的には、オブジェクトライン４４、４５、４６を相互接続する水平矢印は、データ・イベント・メッセージが、オブジェクト間で送受信されることを示す。
各データ・イベント・メッセージは、送信オブジェクトと受信オブジェクトを関連付けている。オブジェクトライン４４、４５、４６とデータ・イベント・メッセージｍ１〜ｍ４とが交差する位置は、イベントと呼ばれる。

各データ・イベント・メッセージは、送信オブジェクトに関連する送信イベントと、受信オブジェクトに関連する受信イベントを含む。例えば、データ・イベント・メッセージｍ１は、オブジェクトライン４５とオブジェクトライン４４とを接続する。

このため、データ・イベント・メッセージｍ１は、ハードウェア４１および送信オブジェクトと、ハードウェア４２および受信オブジェクトとを関連付ける。
さらに、データ・イベント・メッセージｍ１のオブジェクトライン４４との交点は送信イベントを生成し、データ・イベント・メッセージｍ１とオブジェクトライン４５との交点は受信イベントを生成する。

ここで、メッセージ・シーケンス・チャートによって特定される関係について、以下の２つのルールが設けられている。
第１のルール：任意のデータ・イベント・メッセージｍに対して、送信イベント（ｓ（ｍ））は、対応する受信イベント（ｒ（ｍ））の前に発生する。

従って、ｓ（ｍ）＜ｒ（ｍ）となる。
第２のルール：オブジェクトライン上のイベントは、上から下に順序付けされる。
これら２つのルールは、メッセージ・シーケンス・チャートがオブジェクト間で送受信されるデータ・イベント・メッセージの順序を記述することを示している。

例えば、第１のルールにより、メッセージ・シーケンス・チャート４０は、データ・イベント・メッセージｍ１に関する送信イベントが同じメッセージに関する受信イベントの前に発生することを示している。

また、第２のルールにより、メッセージ・シーケンス・チャート４０は、データ・イベント・メッセージｍ２に関する送信イベントが、データ・イベント・メッセージｍ４に関する受信イベントの前に発生するということを示している。

図７に示すデータ・イベント・メッセージの送信は受信より先に起きる。
ハードウェア４１の時間軸ではデータ・イベント・メッセージｍ１とデータ・イベント・メッセージｍ２とが、この順番に送信される。その後、データ・イベント・メッセージｍ４が受信される。

ハードウェア４２の時間軸ではデータ・イベント・メッセージｍ１が受信された後、データ・イベント・メッセージｍ３が受信される
ハードウェア４３の時間軸ではデータ・イベント・メッセージｍ２が受信されてから、データ・イベント・メッセージｍ３とデータ・イベント・メッセージｍ４とを、この順番に送信する。

ここで、上記ルールは推移的である。例えば、イベントｅ１がイベントｅ２（ｅ１＜ｅ２）の前に発生し、イベントｅ２がイベントｅ３（ｅ２＜ｅ３）の前に発生する場合、イベントｅ１は、イベントｅ３（ｅ１＜ｅ３）の前に発生する。

しかしながら、これら２つのルールは、全てのデータ・イベント・メッセージの間の順序付けされた関係を規定するものではない。
例えば、４つのオブジェクトを含むが、２つのデータ・イベント・メッセージしか含まないメッセージ・シーケンス・チャートを考える。

第１のデータ・イベント・メッセージが第１オブジェクトと第２オブジェクトとの間で送受信され、第２のデータ・イベント・メッセージが第３オブジェクトと第４オブジェクトとの間で送受信される場合、これら２つのデータ・イベント・メッセージの間の順序付けされた関係はこれら２つのルールによっては規定されない。この場合、２つのデータ・イベント・メッセージは任意の順序で発生する。

図７では、ハードウェア４２とハードウェア４３は時間軸の順序関係を共有しないため、データ・イベント・メッセージｍ１とデータ・イベント・メッセージｍ２の受信順序は図７に表現した順序と異なってもかまわない。

ハードウェア４１とハードウェア４２は時間軸の順序関係を共有しないため、データ・イベント・メッセージｍ３とデータ・イベント・メッセージｍ４の受信順序は、図７に表現した順序と異なってもかまわない。

図８は、メッセージ・シーケンス・チャートの他の例を示す図である。
メッセージ・シーケンス・チャート４０ａには、複数のオブジェクトとして、ハードウェア４１、４２、４３が設けられている。

メッセージ・シーケンス・チャート４０ａは、同時性制約、タイムアウト制約および同期エッジの３つの（先進的）機能を有している。
同時性制約およびタイムアウト制約については、イベントを包囲するボックスが描画されている。

同時性制約を示すボックス４７には、このボックス４７がこれらのイベントを同時イベントにグループ化することを示す「ｓｉｍｕｌ」がラベル付けされている。
ボックス４７は、データ・イベント・メッセージｍ５とデータ・イベント・メッセージｍ６に関する送信イベントをグループ化している。

タイムアウト制約を示すボックス４８には、タイムアウト制約のタイムアウト値を表す整数がラベル付けされている。
実行がタイムアウト制約に直面すると、示されたタイムアウト期間が経過するまで実行が停止される。時限実行モデルでは、タイムアウト期間が経過して始めて実行が継続する。

従って、データ・イベント・メッセージｍ７は、ボックス４８のラベルに付されている「３」時刻単位後経過した後に、送信される。
同期エッジは、データ・イベント・メッセージの順序を特定するために用いられる。同期エッジの表示は、名前「ｓｙｎｃｈ」が同期エッジに利用可能であるという点を除いて、データ・イベント・メッセージと同様に描かれている。

「ｓｙｎｃｈ」とラベル付けされたデータ・イベント・メッセージ（以下、「同期メッセージ」と言う）を利用して、順序付けされた関係を確立する。例えば、ハードウェア４２に関する送信イベントと、ハードウェア４１に関する受信イベントを含む同期エッジを考える。同期メッセージは、ハードウェア４２がデータ・イベント・メッセージｍ８を受信した後に送信されるものとして示される。同期メッセージは、また、データ・イベント・メッセージｍ９が送信されるまでにハードウェア４１により受信されるものとして示される。

メッセージ・シーケンス・チャート４０ａによれば、ハードウェア４２におけるデータ・イベント・メッセージｍ８の受信は、ハードウェア４１におけるデータ・イベント・メッセージｍ９の送信前に発生する必要がある。

ここで、同期エッジは関連性のないオブジェクト間の関係を生成する。しかしながら、ある実施例によると、同期エッジによって関連するオブジェクト間において実際にメッセージは送受信されない。

同期メッセージは、データ・イベント・メッセージｍ７およびデータ・イベント・メッセージｍ８と、データ・イベント・メッセージｍ５およびデータ・イベント・メッセージｍ６とを比較して、これらの間の順序を生成するものではない。

しかしながら、同期メッセージは、データ・イベント・メッセージｍ７とデータ・イベント・メッセージｍ８に関する受信イベントの後にデータ・イベント・メッセージｍ９に関する送信イベントを発生させる。

次に、設計検証装置１０の構成を説明する。
＜設計検証装置＞
図９は、設計検証装置のハードウェア構成例を示す図である。

設計検証装置１０は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０９を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、外部補助記憶装置１０６、インタフェース１０７および通信インタフェース１０８が接続されている。

ＣＰＵ１０１は、入力インタフェース１０５、外部補助記憶装置１０６、インタフェース１０７および通信インタフェース１０８から受信した情報を処理するよう動作する。
ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。

ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。また、ＨＤＤ１０３内には、ＸＭＬ（Extensible Markup Language）形式で表現されたリスト構造や、プログラムファイルが格納される。

グラフィック処理装置１０４には、モニタ１０４ａが接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１０４ａの画面に表示させる。入力インタフェース１０５には、キーボード１０５ａとマウス１０５ｂとが接続されている。入力インタフェース１０５は、キーボード１０５ａやマウス１０５ｂから送られてくる信号を、バス１０９を介してＣＰＵ１０１に送信する。

外部補助記憶装置１０６は、記録媒体に書き込まれた情報を読み取ったり、記録媒体に情報を書き込んだりする。外部補助記憶装置１０６で読み書きが可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等が挙げられる。磁気記録装置としては、例えば、ＨＤＤ、フレキシブルディスク（ＦＤ）、磁気テープ等が挙げられる。光ディスクとしては、例えば、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等が挙げられる。光磁気記録媒体としては、例えば、ＭＯ（Magneto-Optical disk）等が挙げられる。

インタフェース１０７は、設計検証装置１０に接続された装置から情報を送受信するよう動作可能なハードウェアである。具体的には、インタフェース１０７は、信号インタフェース２００およびテスト対象装置３００と通信する。

通信インタフェース１０８は、ネットワーク４００に接続されている。通信インタフェース１０８は、ネットワーク４００を介して、他のコンピュータとの間でデータの送受信を行う。

以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。このようなハードウェア構成の設計検証装置１０内には、以下のような機能が設けられる。

図１０は、設計検証装置の機能を示すブロック図である。
設計検証装置１０は、検証用シナリオ生成部１１と、検証用シナリオ格納部１２と、優先順位付与部１３と、出力部１４とを有している。

検証用シナリオ生成部１１は、図４および図５にて説明したＬＳＩ２０の設計仕様のデータを有している。また、検証用シナリオ生成部１１は、シナリオブロック２１ａ、２１ｂに対応付けられたシナリオを実現するメッセージ・シーケンス・チャートのデータも有している。なお、メッセージ・シーケンス・チャートは、設計検証装置１０の外部から読み込むようにしてもよい。

検証用シナリオ生成部１１は、入力されたＬＳＩ２０の設計仕様に従って、シナリオ毎に検証用シナリオを生成する。
検証用シナリオは、ＬＳＩ２０の設計仕様の各シナリオが備えるメッセージ・シーケンス・チャートそれぞれに設計仕様のラベル（検証対象部位を識別する識別情報）を関連付けた情報である。なお、検証対象部位としては、例えば、機能、シナリオ、メッセージ・シーケンス・チャート等が挙げられる。

この検証用シナリオは、優先順位付与部１３の処理対象となる中間的なデータである。
また、検証用シナリオ生成部１１は、検証用シナリオを生成する際に作成するデータを一時記憶する機能も有している。

検証用シナリオ格納部１２は、検証用シナリオ生成部１１により生成された検証用シナリオを保管する機能を有している。
優先順位付与部１３は、ユーザにより入力されるパターンを参照し、検証用シナリオに優先順位（処理優先度）を付与する。

このパターンは、項目として、識別情報と同様の情報を有している。例えば、機能名、シナリオ名、シナリオの種類（基本動作、代替動作、例外動作）、メッセージ・シーケンス・チャート名、上記の論理的な組み合わせのうちの少なくとも１つを有している。

また、パターンには処理優先度情報を有していてもよい。
処理優先度情報を有するシナリオの種類のパターンの一例としては、例外動作より基本動作を優先するパターン（基本動作＞例外動作）等が挙げられる。また、処理優先度情報を有するメッセージ・シーケンス・チャート名のパターンの一例としては、問い合わせより認証成功を優先するパターン（認証成功＞問い合わせ）が挙げられる。さらに、認証成功より認証失敗を優先するパターン（認証失敗＞認証成功＞問い合わせ）等が挙げられる。

出力部１４は、優先順位付与部１３が付与した優先順位の順番に検証用シナリオを並べる。
また、出力部１４は、優先順位を付与した検証用シナリオのシナリオ名を、予め用意されたフォーマットに従って作成したリスト（優先順位リスト）を出力する。

なお、出力部１４は、ユーザにより入力されたソート条件に従って検証用シナリオを並べるようにしてもよい。
また、図示していないが、設計検証装置１０は、他にもメッセージ・シーケンス・チャートを生成するツールや、設計の実現形態の動作を検証するため、メッセージ・シーケンス・チャートに基づくステートマシン（State Machine）を生成するためのツールを有していてもよい。

次に、設計検証装置１０の全体処理を説明する。
図１１は、設計検証装置の全体処理を示すフローチャートである。
まず、検証用シナリオ生成部１１が、ユーザにより入力されたＬＳＩ２０の設計仕様に基づいて、検証用シナリオ生成処理を行って検証用シナリオを生成する（ステップＳ１）。生成した検証用シナリオは、検証用シナリオ格納部１２に格納する。

次に、優先順位付与部１３が、ユーザにより入力されたパターンおよび検証用シナリオ格納部１２に格納されている検証用シナリオに基づいて、優先順位付与処理を行って検証用シナリオに優先順位を付与する（ステップＳ２）。

次に、出力部１４が、ソート処理を行って付与した優先順位の順番に検証用シナリオを並べる（ステップＳ３）。
そして、出力部１４が、優先順位を付与した検証用シナリオのシナリオ名を、優先順位リストとして出力する（ステップＳ４）。

以上で、全体処理の説明を終了する。
なお、検証用シナリオ生成処理を予め行って生成した検証用シナリオを検証用シナリオ格納部１２に格納しておいて、ユーザによるパターンの入力を待って優先順位付与処理以降を行うようにしてもよい。また、ユーザによるパターンの入力時に、検証用シナリオ生成処理を開始するようにしてもよい。

次に、ステップＳ１に示す検証用シナリオ生成処理を説明する。
図１２および図１３は、検証用シナリオ生成処理を示すフローチャートである。
まず、ＬＳＩ２０の設計仕様にラベルを付与する（ステップＳ１１）。この処理については、後に詳述する。

次に、ステップＳ１１にて付与された設計仕様において、メッセージ・シーケンス・チャートを備える有向グラフを平坦化（Flatten）する（ステップＳ１２）。具体的には、有向グラフの階層構造を取り払う。

次に、平坦化した有向グラフからメッセージ・シーケンス・チャートを１つ選択する（ステップＳ１３）。
次に、選択したメッセージ・シーケンス・チャートを有限ステートマシン（FSM）に変換する（ステップＳ１４）。これにより、一連のメッセージ・シーケンス・チャートを組み合わせたデータ・イベント・メッセージのやり取りを有限ステートマシンで表現する。この処理については、後に詳述する。

次に、変換された有限ステートマシンの各ステートに、メッセージ・シーケンス・チャートに付されていたラベルを付与する（ステップＳ１５）。
ステップＳ１４およびステップＳ１５の処理により、有限ステートマシンの各ステートにラベルが付与される。各ステートにラベルが付与された有限ステートマシンは、検証用シナリオ生成部１１が一時記憶する。

次に、未処理のメッセージ・シーケンス・チャートが存在するか否かを判断する（ステップＳ１６）。
未処理のメッセージ・シーケンス・チャートが存在する場合（ステップＳ１６のＹｅｓ）、ステップＳ１３に移行して未処理のメッセージ・シーケンス・チャートを選択し、選択したメッセージ・シーケンス・チャートについて、ステップＳ１４以降の処理を引き続き行う。

一方、未処理のメッセージ・シーケンス・チャートが存在しない場合（ステップＳ１６のＮｏ）、ステップＳ１１にてラベルが付与された設計仕様を参照し、設計仕様が備えるメッセージ・シーケンス・チャートを１つ選択する（ステップＳ１７）。

次に、メッセージ・シーケンス・チャートの制約（synchやtimeout等）から、選択したメッセージ・シーケンス・チャートの有限ステートマシンの不要なステートを刈る（ステップＳ１８）。この処理は後に詳述する。

次に、未処理のメッセージ・シーケンス・チャートが存在するか否かを判断する（ステップＳ１９）。
未処理のメッセージ・シーケンス・チャートが存在する場合（ステップＳ１９のＹｅｓ）、ステップＳ１７に移行し、未処理のメッセージ・シーケンス・チャートを選択する。そして、選択したメッセージ・シーケンス・チャートについてステップＳ１８以降の処理を引き続き行う。

一方、未処理のメッセージ・シーケンス・チャートが存在しない場合（ステップＳ１９のＮｏ）、ステップＳ１１にてラベルが付与されたＬＳＩ２０の設計仕様を参照し、設計仕様が備える機能を選択する（図１３のステップＳ２０）。

次に、選択された機能からシナリオを選択する（ステップＳ２１）。
次に、ステップＳ１５にてラベルが付与された有限ステートマシンから、選択したシナリオと同じラベルを有する有限ステートマシンを抽出する（ステップＳ２２）。

次に、選択したシナリオと同じラベルを有する有限ステートマシンの部分（以下、「部分有限ステートマシン」と言う）を抽出する（ステップＳ２３）。検証用シナリオ生成部１１は、抽出した有限ステートマシンの部分を一時記憶する。

次に、ステップＳ２３にて抽出した有限ステートマシンの部分から検証用シナリオを生成し、生成した検証用シナリオを検証用シナリオ格納部１２に格納する（ステップＳ２４）。なお、有限ステートマシンの部分から検証用シナリオを生成する方法は、後に詳述する。

次に、ステップＳ２０にて選択した機能に、未処理のシナリオが存在するか否かを判断する（ステップＳ２５）。
未処理のシナリオが存在する場合（ステップＳ２５のＹｅｓ）、ステップＳ２１に移行し、未処理のシナリオを選択し、選択したシナリオについてステップＳ２２以降の処理を引き続き行う。

一方、ステップＳ２０にて選択した機能に、未処理のシナリオが存在しない場合（ステップＳ２５のＮｏ）、ＬＳＩ２０の設計仕様に、未処理の機能が存在するか否かを判断する（ステップＳ２６）。

未処理の機能が存在する場合（ステップＳ２６のＹｅｓ）、ステップＳ２０に移行し、未処理の機能を選択し、選択した機能についてステップＳ２１以降の処理を引き続き行う。

一方、未処理の機能が存在しない場合（ステップＳ２６のＮｏ）、処理を終了する。
以上で、検証用シナリオ生成処理の説明を終了する。
次に、ステップＳ１１のラベルの付与の処理（ラベル付与処理）を詳しく説明する。

図１４は、ラベル付与処理を示すフローチャートである。
まず、ＬＳＩ２０の設計仕様を参照し、機能を１つ選択する（ステップＳ３１）。
次に、選択した機能からシナリオを１つ選択する（ステップＳ３２）。

次に、選択したシナリオに付属するメッセージ・シーケンス・チャートを１つ選択する（ステップＳ３３）。
次に、選択したメッセージ・シーケンス・チャートに、ステップＳ３１にて選択した機能名（現在選択されている機能名）およびステップＳ３２にて選択したシナリオ名（現在選択されているシナリオ名）をラベルとして付与する（ステップＳ３４）。また、既にラベルが付与されている場合は、ラベルを追加する。

なお、ラベルには、機能名・シナリオ名に加え、メッセージ・シーケンス・チャート名を付するようにしてもよい。
次に、当該シナリオ内に未処理のメッセージ・シーケンス・チャートが存在するか否かを判断する（ステップＳ３５）。

当該シナリオ内に未処理のメッセージ・シーケンス・チャートが存在する場合（ステップＳ３５のＹｅｓ）、ステップＳ３３に移行し、当該シナリオ内の未処理のメッセージ・シーケンス・チャートを選択し、選択したメッセージ・シーケンス・チャートについてステップＳ３４以降の処理を引き続き行う。

一方、当該シナリオ内に未処理のメッセージ・シーケンス・チャートが存在しない場合（ステップＳ３５のＮｏ）、未処理のシナリオが存在するか否かを判断する（ステップＳ３６）。

未処理のシナリオが存在する場合（ステップＳ３６のＹｅｓ）、ステップＳ３２に移行し、未処理のシナリオを選択し、選択したシナリオについてステップＳ３３以降の処理を引き続き行う。

一方、未処理のシナリオが存在しない場合（ステップＳ３６のＮｏ）、未処理の機能が存在するか否かを判断する（ステップＳ３７）。
未処理の機能が存在する場合（ステップＳ３７のＹｅｓ）、ステップＳ３１に移行し、未処理の機能を選択し、選択した機能についてステップＳ３２以降の処理を引き続き行う。

一方、未処理の機能が存在しない場合（ステップＳ３７のＮｏ）、処理を終了する。
以上で、ラベル付与処理の説明を終了する。
次に、図１１のステップＳ２に示す優先順位付与処理を説明する。

図１５は、優先順位付与処理を示すフローチャートである。
まず、パラメータｉ＝１にセットする（ステップＳ４１）。
次に、入力されたパターンの中から、優先順位の最も高い項目を選択する（ステップＳ４２）。例えば、入力されたパターンが、（基本動作＞例外動作）である場合は、基本動作を選択する。

次に、選択した項目を含むラベルが全てのステートに付与されている検証用シナリオを全て取得する（ステップＳ４３）。
次に、取得した全ての検証用シナリオの優先順位をｉとする（ステップＳ４４）。

次に、パラメータｉを更新（ｉ＝ｉ＋１）する（ステップＳ４５）。
次に、優先順位の項目が残っているか否かを判断する（ステップＳ４６）。
残っている場合（ステップＳ４６のＹｅｓ）、ステップＳ４２に移行し、未処理の項目のうち最も優先順位の高い項目を選択し、ステップＳ４３以降の処理を引き続き行う。

一方、残っていない場合（ステップＳ４６のＮｏ）、処理を終了する。
以上で、優先順位付与処理の説明を終了する。
＜具体例＞
次に、ラベル付与処理の具体例を説明する。

図１６は、ＬＳＩの設計仕様のデータ構造の具体例を示す図である。
図１６に示すＬＳＩ２０の設計仕様は、ＡＴＭ（Automatic Teller Machine）取引に関する機能を表している。

この設計仕様は、ＡＴＭカードおよびＰＩＮ（Personal Identification Number）を用いてＡＴＭの将来的なユーザを認証する簡単化された記述を提供する。
具体的には、機能ブロック５１にはＡＴＭ取引開始機能が設定されている。

図１６に示すＬＳＩ２０の設計仕様には、２つのシナリオが用意されている。
第１のシナリオは、機能ブロック５１が有する機能、シナリオブロック５１ａに対応付けられているシナリオ、シナリオブロック５１ａに対応付けられているシナリオを実現するための検証用シナリオを開始、進行するパスに関する。

この検証用シナリオは、ＭＳＣブロック５１１ａ、５１２ａに対応付けられているメッセージ・シーケンス・チャートによって実現される。
この第１のシナリオは、将来的なユーザによって提供されるＰＩＮを受け付けるＡＴＭと関連付けされている。

第２のシナリオは、機能ブロック５１に対応付けられている機能、シナリオブロック５１ｂに対応付けられているシナリオ、シナリオブロック５１ｂに対応付けられているシナリオを実現するための検証用シナリオを開始、進行するパスに関する。

この検証用シナリオは、ＭＳＣブロック５１１ｂ、５１２ｂに対応付けられているメッセージ・シーケンス・チャートによって実現される。
この第２のシナリオは、将来的なユーザによって提供されるＰＩＮを拒否するＡＴＭと関連付けされている。

以下、第１のシナリオをシナリオ「成功」と言い、第２のシナリオをシナリオ「失敗」と言う。
図１７は、メッセージ・シーケンス・チャートの具体例を示す図である。

図１７（ａ）〜図１７（ｃ）は、それぞれ、検証用シナリオに関するメッセージ・シーケンス・チャートを示す図である。
図１７（ａ）に示すメッセージ・シーケンス・チャート４０ｂは、ＭＳＣブロック５１１ａに対応付けられているメッセージ・シーケンス・チャートの識別名「問い合わせ」に関するメッセージ・シーケンス・チャート（以下、単にメッセージ・シーケンス・チャート「問い合わせ」と言う）である。

図１７（ａ）に示すオブジェクトは、ユーザインタフェース（Ｉ／Ｆ）４１ａ、ＡＴＭ４２ａおよびデータベース４３ａによって表される。
各オブジェクトはまた、ユーザインタフェースライン４４ａ、ＡＴＭライン４５ａおよびデータベースライン４６ａを含むオブジェクトラインを含む。

前述したルールを利用して、メッセージ・シーケンス・チャート４０ｂは、以下の処理を行う。
まず、ＡＴＭ４２ａはカード挿入依頼メッセージ（Ｉｎｓｅｒｔ＿Ｃａｒｄ）をユーザインタフェース４１ａに送信する（ステップＳ５１）。

カード挿入依頼メッセージの受信後、ユーザインタフェース４１ａは、カード挿入メッセージ（Ｃａｒｄ＿Ｉｎｓｅｒｔｅｄ）をＡＴＭ４２ａに送信する（ステップＳ５２）。
カード挿入メッセージの送信後、ユーザインタフェース４１ａは、入力されたパスワード（ＰＩＮ）をＡＴＭ４２ａに送信する（ステップＳ５３）。

ＡＴＭ４２ａが、パスワードを受信した後、ＡＴＭ４２ａは認証依頼（ＰＩＮ＿ｖｅｒｉｆｙ）メッセージをデータベース４３ａに送信する（ステップＳ５４）。
図１７（ｂ）に示すメッセージ・シーケンス・チャート４０ｃは、ＭＳＣブロック５１２ａに対応付けられているメッセージ・シーケンス・チャートの識別名「認証成功」に関するメッセージ・シーケンス・チャート（以下、単にメッセージ・シーケンス・チャート「認証成功」と言う）である。

メッセージ・シーケンス・チャート４０ｃは、ユーザインタフェース４１ａ、ＡＴＭ４２ａおよびデータベース４３ａに関するメッセージ・シーケンス・チャートにおいて用いられる同一のオブジェクトの表示を含む。

前述したルールを利用して、メッセージ・シーケンス・チャート４０ｃは、以下の処理を行う。
すなわち、データベース４３ａは、ユーザデータをＡＴＭ４２ａに送信する（ステップＳ５５）。ＡＴＭ４２ａがユーザデータを受信した後、ＡＴＭ４２ａは、メニュー表示をユーザインタフェース４１ａに送信する（ステップＳ５６）。

図１７（ｃ）に示すメッセージ・シーケンス・チャート４０ｄは、ＭＳＣブロック５１２ｂに対応付けられているメッセージ・シーケンス・チャートの識別名「認証失敗」に関するメッセージ・シーケンス・チャート（以下、単にメッセージ・シーケンス・チャート「認証失敗」と言う）である。

メッセージ・シーケンス・チャート４０ｄは、ユーザインタフェース４１ａ、ＡＴＭ４２ａおよびデータベース４３ａに関連するメッセージ・シーケンス・チャートで用いられる同一のオブジェクトの表現を含む。

前述したルールを利用して、メッセージ・シーケンス・チャート４０ｄは、以下の処理を行う。
データベース４３ａは、エラーをＡＴＭ４２ａに送信する（ステップＳ５７）。ＡＴＭ４２ａがエラーを受信した後、ＡＴＭ４２ａは、エラーメッセージをユーザインタフェース４１ａに送信する（ステップＳ５８）。

図１８〜図２０は、ＬＳＩの設計仕様にラベルを付与する具体例を示す図である。
まず、ＬＳＩ２０の設計仕様を参照し、機能ブロック５１に対応付けられている機能「ＡＴＭ取引開始」を選択する。

次に、選択した機能からシナリオブロック５１ａに対応付けられているシナリオ「成功」を選択する。
次に、選択したシナリオ「成功」に対応付けられているメッセージ・シーケンス・チャート「問い合わせ」を選択する。

次に、選択したメッセージ・シーケンス・チャート「問い合わせ」にラベルを付与する。
前述したように、ラベルとして、現在選択されている機能名および現在選択されているシナリオ名を付与する。またラベルは、機能名・シナリオ名：シナリオの種類の順に付与する。従って、図１８に示す例では、「ＡＴＭ取引開始・成功：基本動作」のラベル５１１ａ１を付与する。

図１８ではここまでの例を示している。
次に、当該シナリオブロック５１ａ内に未処理のメッセージ・シーケンス・チャートが存在するか否かを判断すると、未処理のメッセージ・シーケンス・チャート「認証成功」が存在する。従って、このメッセージ・シーケンス・チャート「認証成功」を選択する。

次に、選択したメッセージ・シーケンス・チャート「認証成功」に「ＡＴＭ取引開始・成功：基本動作」のラベル５１２ａ１を付与する。
次に、当該シナリオブロック５１ａ内に未処理のメッセージ・シーケンス・チャートが存在するか否かを判断すると、当該シナリオブロック５１ａ内に未処理のメッセージ・シーケンス・チャートは存在しない。

従って、機能ブロック５１内に未処理のシナリオが存在するか否かを判断すると、シナリオブロック５１ｂの未処理のシナリオ「失敗」が存在する。
そこで、このシナリオ「失敗」を選択する。

次に、選択したシナリオ「失敗」に対応付けられているメッセージ・シーケンス・チャート「問い合わせ」を選択する。
次に、選択したメッセージ・シーケンス・チャート「問い合わせ」に「ＡＴＭ取引開始・失敗：例外動作」のラベルを付与する。ここでは、既にラベル５１１ａ１が付与されているので、「ＡＴＭ取引開始・失敗：例外動作」のラベルをラベル５１１ａ１に追加する。

図１９ではここまでの例を示している。
次に、当該シナリオ内に未処理のメッセージ・シーケンス・チャートが存在するか否かを判断すると、未処理のメッセージ・シーケンス・チャート「認証失敗」が存在する。従って、このメッセージ・シーケンス・チャート「認証失敗」を選択する。

次に、選択したメッセージ・シーケンス・チャート「認証失敗」に「ＡＴＭ取引開始・失敗：例外動作」のラベル５１２ｂ１を付与する。
次に、当該シナリオブロック５１ｂ内に未処理のメッセージ・シーケンス・チャートが存在するか否かを判断すると、当該シナリオブロック５１ｂ内に未選択のメッセージ・シーケンス・チャートは存在しない。

従って、機能ブロック５１内に未処理のシナリオが存在するか否かを判断すると、未処理のシナリオは存在しない。
従って、処理を終了する。

図２０は、ここまでの処理を示している。
図２１は、ラベルを付与したＬＳＩの設計仕様のデータ構造例を示す図である。
ラベルを付与したＬＳＩ２０のデータ６０は、ＸＭＬ形式で表現されている。

記述６１は、メッセージ・シーケンス・チャート４０ｂに関する記述部分を示している。また、記述６２は、メッセージ・シーケンス・チャート４０ｃに関する記述部分を示している。また、記述６３は、メッセージ・シーケンス・チャート４０ｄに関する記述部分を示している。

ここで、記述６１ａ、６２ａ、６３ａは、それぞれ、ラベル付与処理によって追記された行である。ラベル付与処理によって追記された行には、ラベル名であることを識別するＸＭＬタグ＜label name＞が付されている。また、タグ内の内容は、それぞれ付与されたラベルの内容を示している。

なお、前述したように、ラベルには、機能名・シナリオ名：シナリオの種類に加え、メッセージ・シーケンス・チャート名を付与するようにしてもよい。これにより、優先順位のパターンとしてメッセージ・シーケンス・チャート名が入力された場合においてもシナリオに優先順位を付与することができる。

図２２は、ＬＳＩの設計仕様にラベルを付与する他の具体例を示す図である。
図２２に示すラベル５１１ａ１、５１２ａ１、５１２ｂ１には、いずれも機能名・シナリオ名：シナリオの種類に加え、メッセージ・シーケンス・チャート名が付与されている。

次に、ステップＳ１４の、メッセージ・シーケンス・チャートを有限ステートマシンに変換する処理を、具体例を用いて説明する。
図２３は、有限ステートマシンに変換する処理を説明するメッセージ・シーケンス・チャートを示す図である。

有向グラフを有限ステートマシンに変換するため、有向グラフの備える各メッセージ・シーケンス・チャートによって規定されるイベントを用いて、有限ステートマシンのステートを特定する。

メッセージ・シーケンス・チャートは可能なイベント順序を規定し、各オブジェクトにおいて完了されたイベントは状態に対応する。例えば、初期状態はいずれのオブジェクトにおいても完了されないイベントに対応する。最終状態は、各オブジェクトにおいて完了した全てのイベントに対応する。

ここで、メッセージ・シーケンス・チャート７０を検討すると、メッセージ・シーケンス・チャート７０の一部が、オブジェクトの一部のイベント群を考慮することによって有限ステートマシンに投影される。

図２３に示すオブジェクトは、送信オブジェクト７１、長距離送信オブジェクト７２、受信オブジェクト７３および長距離受信オブジェクト７４によって表される。
例えば、メッセージ・シーケンス・チャート７０では、有限ステートマシンが、送信オブジェクト７１と受信オブジェクト７３に対して生成される。図示されるように、送信オブジェクト７１は送信イベントｔ１〜ｔ５を有している。受信オブジェクト７３は、受信イベントｒ１〜ｒ６を有している。

ここで、送信オブジェクト７１と受信オブジェクト７３は、メッセージを交換することなく、２つの同期エッジによって関連付けされる。
図２４は、図２３に示すメッセージ・シーケンス・チャートに関連する状態マトリックスを示す図である。

状態マトリックス８０を利用して、有限ステートマシンの生成方法をさらに説明する。
２つのみしかオブジェクトが存在しない場合、メッセージ・シーケンス・チャート７０の有限ステートマシンは、２次元の状態マトリックス８０として可視化することができる。

状態マトリックス８０の各ブロックは、送信オブジェクト７１が送信イベントｔｉを終了させ、受信オブジェクト７３が受信イベントｒｊを終了させた状態に対応している。
このため、状態マトリックス８０の各ブロックは、状態（ｔｉ，ｒｊ）を規定する。

ここで、状態マトリックス８０の原点は、左上隅に設けられている。初期状態は、記号⊥を用いて各オブジェクトに対して示される。
状態マトリックス８０の左上隅の状態が初期状態であるため、状態遷移は各状態から右下にトレースすることによって特定される。最終状態は、右下隅に示す状態となる。

送信オブジェクト７１と受信オブジェクト７３とが２つの同期エッジによっては関連付けされていない場合、状態マトリックス８０は、（ｎ×ｍ）の完全な２次元の状態マトリックスとなる（ただし、ｎは、送信オブジェクト７１により送信されるメッセージの個数であり、ｍは、受信オブジェクト７３によって受信されるメッセージの個数である）。

しかしながら、メッセージ・シーケンス・チャート７０の同期エッジの存在は、状態マトリックス８０に示されるような有効な状態の個数を減少させる。
同期エッジにより、状態マトリックス８０に示される一部の状態は有効とはならず、２次元マトリックスから「クロスアウト（cross out）」させることが可能である。

例えば、送信イベントｔ３が送信オブジェクト７１から受信オブジェクト７３への同期エッジに対応する送信イベントであると仮定する。
受信イベントｒ３は、同一の同期エッジに関連する対応する受信イベントである。受信イベントｒ２の後に発生する受信オブジェクト７３におけるいずれのイベントも、送信イベントｔ３の後に発生する必要がある。従って、受信イベントｒ３〜ｒ６は送信イベントｔ３の前に発生することはできない。

このオブジェクトを利用して、無効状態に対応する状態マトリックス８０の領域８１は、クロスアウトされる。同様のオブジェクトを用いて、メッセージ・シーケンス・チャート７０の第２同期エッジに関連する領域８２をクロスアウトする。

残りのマトリックスは、メッセージ・シーケンス・チャート７０を正確に表している。送信イベントｔ２や受信イベントｒ１等の状態は、送信オブジェクト７１が送信イベントｔ２を終了させ、受信オブジェクト７３が受信イベントｒ１を終了させた状態を表す。

図２５は、状態マトリックスに関する状態図を示す図である。
状態図９０に示す１つのステート９１は、図２４に示した状態マトリックス８０の１つの領域に対応している。

ステート９１内の値は、状態を示している。
状態図９０の各水平方向への遷移は、メッセージの受信に対応している。このため有限ステートマシンによるメッセージの送信として実現される。

同様に、状態図９０の各垂直方向への遷移は、メッセージの送信に対応している。このため、有限ステートマシンによるメッセージの受信待機として実現される。
現在、状態図９０の水平方向への遷移と垂直方向への遷移の両方が行われうる状態（ｉ，ｊ）であるとき、水平方向への遷移は適切なメッセージを送信することにより行われる。

その後、垂直方向への遷移が予想されるメッセージが受信されたか判断することによって試行される。後者の状態が満たされる場合、垂直方向への遷移が行われてもよく、次の状態は状態（ｉ＋１，ｊ＋１）となる。

後者の状態が満たされていない場合、水平方向への遷移のみが行われ、次の状態は（ｉ＋１，ｊ）となる。
オブジェクトが永久に待機することがないように、メッセージの受信待機中にタイマが利用される。

すなわち、適切なタイムアウト期間後に待機は終了する。垂直または水平のみの遷移しかある状態から行うことができない場合、これらの動作のみが生成される。
遷移方向が生成可能な有限ステートマシンに影響する１つの変数である一方、他の変数はあるステートに関する特定のタイプのイベントである。

例えば、図２３に示す送信オブジェクト７１と受信オブジェクト７３において、オブジェクトラインに関連する各イベントは３つのタイプのうちの１つである。送信オブジェクト７１では、これらのタイプはメッセージ送信イベント、タイマ始動イベントおよびタイムアウト信号受信イベントである。

受信オブジェクト７３では、これらのタイプは、メッセージ受信イベント、タイマ始動イベントおよびタイムアウト信号受信イベントである。各オブジェクトのこれら３つのタイプのイベントは、有限ステートマシンの各ステートに対して生成されるコードが当該状態の正確な組み合わせに依存するため、有限ステートマシン変換中に考慮される９つの組み合わせを生じさせる。

これらの技術を利用して、有限ステートマシンがメッセージ・シーケンス・チャートに対して生成される。
シナリオに対する有限ステートマシンを生成するため、有限ステートマシンがパスに沿って各メッセージ・シーケンス・チャートに対して生成され、必要に応じて合成される。例えば、１つのメッセージ・シーケンス・チャートの終わりの次の状態は、パスに沿った次のメッセージ・シーケンス・チャートの開始状態となる。

信号および変数宣言の全てを組み合わせることによって、有限ステートマシンを自動的に生成、編集することができる。また、生成、編集された有限ステートマシンを用いてテスト対象装置３００の動作をシミュレートすることができる。

次に、ステップＳ１５に示す有限ステートマシンにラベルを付与する処理を具体的に説明する。
図２６は、有限ステートマシンにラベルを付与する具体例を示す図である。

まず、前述した方法にて生成した有限ステートマシン９０ａのステート１つ１つに対し、対応するメッセージ・シーケンス・チャートのラベルを付与する。
図２６では、メッセージ・シーケンス・チャート「問い合わせ」から有限ステートマシンのステートＳｔ１、Ｓｔ２、Ｓｔ３、Ｓｔ４が生成されている。

ここで、メッセージ・シーケンス・チャート「問い合わせ」には、「ＡＴＭ取引開始・成功：基本動作」のラベルと「ＡＴＭ取引開始・失敗：例外動作」のラベルとが付与されている。

従って、これらステートＳｔ１、Ｓｔ２、Ｓｔ３、Ｓｔ４それぞれにも、「ＡＴＭ取引開始・成功：基本動作」のラベルと「ＡＴＭ取引開始・失敗：例外動作」のラベルとを付与する。

図２７は、有限ステートマシンにラベルの付与が終了したときの状態を示す図である。
図２７では、メッセージ・シーケンス・チャート「認証成功」からステートＳｔ５、Ｓｔ６が生成されている。

ここで、メッセージ・シーケンス・チャート「認証成功」には、「ＡＴＭ取引開始・成功：基本動作」のラベルが付与されている。
従って、これらステートＳｔ５、Ｓｔ６それぞれにも、「ＡＴＭ取引開始・成功：基本動作」のラベルを付与する。

また、メッセージ・シーケンス・チャート「認証失敗」からステートＳｔ７、Ｓｔ８が生成されている。
ここで、メッセージ・シーケンス・チャート「認証失敗」には、「ＡＴＭ取引開始・失敗：例外動作」のラベルが付与されている。

従って、これらステートＳｔ７、Ｓｔ８それぞれにも、「ＡＴＭ取引開始・失敗：例外動作」のラベルを付与する。
次に、ステップＳ１８のメッセージ・シーケンス・チャートの制約から有限ステートマシンの状態を刈る処理を、具体例を用いて説明する。

図２８は、状態マトリックスに関する状態図を示す図である。
同期イベントは、実際の動作イベントの部分的順序付けを外部または他の装置により限定するのに利用されているだけであるため、状態図９０から削除してもよい。同期イベントを削除することにより、図２８に示される簡単化された状態図９２が得られる。

図２９は、有限ステートマシンのデータ構造例を示す図である。
有限ステートマシンのデータ１１０は、ＸＭＬ形式で表現されている。
記述１１０ａは、有限ステートマシン９０ａの識別子に関する記述部分を示している。当該記述１１０ａには、有限ステートマシンであることを識別する有限ステートマシンタグ＜fsm name＞が付されている。また、タグ内の内容は、それぞれ付与されたラベルの内容を示している。

また、記述１１１〜１１８は、それぞれ各ステートＳｔ１〜Ｓｔ８に関する記述部分を示している。
また、記述１１９は、各ステートＳｔ１〜Ｓｔ８に関する遷移方向を示している。

次に、図１６に示すＬＳＩ２０の設計仕様および図２７に示すラベル付与済みの有限ステートマシンを用いてシナリオ毎の検証用シナリオを生成する具体例を説明する。
まず、図１６に示す設計仕様から機能ブロック５１に対応付けられている機能「ＡＴＭ取引開始」を選択する。

次に、選択した機能「ＡＴＭ取引開始」からシナリオ「成功」を選択する。
次に、選択したシナリオ「成功」と同じラベルを備える有限ステートマシンを抽出する。

具体的には、図２７に示す有限ステートマシンを抽出する。
次に、選択したシナリオと同じラベルを持つ有限ステートマシンの部分を抽出する。
図２７に示すように、シナリオ「成功」は、「ＡＴＭ取引開始・成功：基本動作」のラベルを備えているため、このラベルと同じラベルを備えるステートＳｔ１、Ｓｔ２、Ｓｔ３、Ｓｔ４、Ｓｔ５、Ｓｔ６を抽出する。

次に、抽出した有限ステートマシンの部分を、シナリオ「成功」を検証する検証用シナリオとして検証用シナリオ格納部１２に格納する。
次に、選択した機能に未処理のシナリオが残っているか否かを判断すると、シナリオ「失敗」が残っている。

従って、選択した機能「ＡＴＭ取引開始」からシナリオ「失敗」を選択する。
次に、選択したシナリオ「失敗」と同じラベルを備える有限ステートマシンを抽出する。

具体的には、図２７に示す有限ステートマシンを抽出する。
次に、選択したシナリオと同じラベルを持つ有限ステートマシンの部分を抽出する。
図２７に示すように、シナリオ「失敗」は、「ＡＴＭ取引開始・失敗：例外動作」のラベルを備えているため、このラベルと同じラベルを備えるステートＳｔ１、Ｓｔ２、Ｓｔ３、Ｓｔ４、Ｓｔ７、Ｓｔ８を抽出する。

次に、抽出した部分有限ステートマシンを、シナリオ「失敗」を検証する検証用シナリオとして検証用シナリオ格納部１２に格納する。
次に、選択した機能に未処理のシナリオが残っているか否かを判断すると、残っていない。

次に、未処理の機能が残っているか否かを判断すると、残っていない。
従って、処理を終了する。
図３０は、検証用シナリオ格納部に格納されている検証用シナリオを示す図である。

図３０に示すように、シナリオ「成功」を検証する検証用シナリオＳｃ１およびシナリオ「失敗」を検証する検証用シナリオＳｃ２が存在する。
次に、検証用シナリオ生成処理におけるステップＳ２４の有限ステートマシンの部分から検証用シナリオを生成する方法を詳しく説明する。

＜検証用シナリオの生成＞
前述した具体例では、有限ステートマシンの部分から検証用シナリオを容易に作成することができた。

しかしながら、有限ステートマシンの部分のステートがループしている場合等がある。 この場合、検証用シナリオ生成部１１は、有限ステートマシンの部分を、いくつかの構成単位に「切断」または分割した、検証用シナリオを生成する。

例えば、有限ステートマシンの部分は、パスにおいて再出現するステートに従って切断されてもよい。代わりに、または加えて、「少なくとも最小数または最大数以下のステートが各検証用シナリオにおいて特定されることを要求する」という制約を有する複数の検証用シナリオに切断されてもよい。

例えば、以下の有限ステートマシンの部分が抽出されたものとする。
Ｓｔ２→Ｓｔ４→Ｓｔ６→Ｓｔ７→Ｓｔ２→Ｓｔ３→Ｓｔ６→Ｓｔ７→Ｓｔ２→Ｓｔ３→Ｓｔ５→Ｓｔ７→Ｓｔ２→Ｓｔ３→Ｓｔ５→Ｓｔ２
有限ステートマシンの部分を分割する１つの論理的方法は、再出現するステートを切断することである。

例えば、ステートＳｔ２は、この長い有限ステートマシンの部分を４つの検証用シナリオに切断するのに利用される。
（１）Ｓｔ２→Ｓｔ４→Ｓｔ６→Ｓｔ７
（２）Ｓｔ２→Ｓｔ３→Ｓｔ６→Ｓｔ７
（３）Ｓｔ２→Ｓｔ３→Ｓｔ５→Ｓｔ７
（４）Ｓｔ２→Ｓｔ３→Ｓｔ５→Ｓｔ２
より長い検証用シナリオを生成するため、検証用シナリオ生成部１１は、ステートＳｔ２を用いて切断処理を実行すると共に、各検証用シナリオが少なくとも５つのステートを含むことを要求することができる。

これらの制約を用いて、以下の２つの検証用シナリオが特定される。
（５）Ｓｔ２→Ｓｔ４→Ｓｔ６→Ｓｔ７→Ｓｔ２→Ｓｔ３→Ｓｔ６→Ｓｔ７
（６）Ｓｔ２→Ｓｔ３→Ｓｔ５→Ｓｔ７→Ｓｔ２→Ｓｔ３→Ｓｔ５→Ｓｔ２
次に、優先順位付与処理の具体例を説明する。

まず、パラメータｉ＝１に設定する。
次に、パターンの中から、優先順位の最も高い項目を取り出す。
ここでは、パターンに基本動作を例外動作よりも優先するパターン（基本動作＞例外動作）が設定されているものとする。従って、優先順位の最も高い基本動作をパターンから取り出す。

次に、検証用シナリオ格納部１２を参照し、基本動作を含むラベルが全てのステートに付与されている検証用シナリオを全て取得する。
図３０に示すように、本具体例では、基本動作を含むラベルが全てのステートに付与されている検証用シナリオＳｃ１を取得する。

そして、取得した検証用シナリオＳｃ１の優先順位を「ｉ＝１」に設定する。また、パラメータｉ＝１＋１＝２とする。
優先順位項目がパターンに残っているか否かを判断すると、まだ残っているので、次に優先順位の高い例外動作を取り出す。

次に、検証用シナリオ格納部１２を参照し、例外動作を含むラベルが全てのステートに付与されている検証用シナリオを全て取得する。
図３０に示すように、本具体例では、例外動作を含むラベルが全てのステートに付与されている検証用シナリオＳｃ２を取得する。

そして、取得した検証用シナリオＳｃ２の優先順位を「ｉ＝２」に設定する。また、パラメータｉ＝２＋１＝３とする。
優先順位項目が残っているか否かを判断すると、もう残っていないので、処理を終了する。

図３１および図３２は、優先順位が付与された検証用シナリオのデータ構造を示す図である。
図３１は、検証用シナリオＳｃ１のデータ構造を示している。

３行目は、＜fsm name=“ＡＴＭ取引開始ＦＳＭ” type=“scenario” priority=“1”＞と記述されている。この「type=“scenario”」が検証用シナリオであることを示している。また、「priority=“1”」が、検証用シナリオの優先順位を示している。

図３２は、検証用シナリオＳｃ２のデータ構造を示している。
３行目は、＜fsm name=“ＡＴＭ取引開始ＦＳＭ” type=“scenario” priority=“2”＞と記述されている。この「type=“scenario”」が検証用シナリオであることを示している。また、「priority=“2”」が、検証用シナリオの優先順位を示している。

次に、出力されるシナリオ名のイメージを説明する。
図３３は、優先順位リストの具体例を示す図である。
優先順位リスト１４ａには、優先順位の欄と検証用シナリオの欄が設けられている。

優先順位の欄には、優先順位を識別する値が設定されている。
検証用シナリオの欄の１行目には、優先順位の欄の「１」に対応する「priority=“1”」を有する検証用シナリオＳｃ１が設定されている。また、検証用シナリオの欄の２行目には、優先順位の欄の「２」に対応する「priority=“2”」を有する検証用シナリオＳｃ２が設定されている。

パターンの欄には、入力されたパターンを識別する情報が設定されている。
以上述べたように、設計検証装置１０によれば、検証用シナリオ生成部１１が、ＬＳＩ２０の設計仕様が備える複数のシナリオが備えるメッセージ・シーケンス・チャートそれぞれにラベルを関連付けた検証用シナリオを生成するようにした。

具体的には、以下の処理を行った。
メッセージ・シーケンス・チャートそれぞれに、ラベルを関連付けた。これにより、１つのシナリオが備えるメッセージ・シーケンス・チャートを特定することができる。

そして、メッセージ・シーケンス・チャートから有限ステートマシンの生成を行った。ただし、有限ステートマシンを生成する際、各ステートに対応するメッセージ・シーケンス・チャートのラベルを付与するようにした。これにより、１つのシナリオが備えるステートを特定することができる。

そして、ＬＳＩ２０の設計仕様の各シナリオに対応する有限ステートマシンを抽出し、抽出した各有限ステートマシンの検証用シナリオを生成するようにした。
これにより、入力されるパターンの入力に対応する（設計・検証の段階に応じた）検証用シナリオを生成することができる。

そして、優先順位付与部１３が、ユーザが指定した優先順位のパターンの入力に応じて、検証用シナリオに優先順位を付与するようにした。
そして、出力部１４が、優先順位が付与された検証用シナリオを識別する情報を、処理順位とともに出力するようにした。

これにより、ユーザは、この優先順位リスト１４ａに記載された順番にシナリオを実行することにより、効率的に設計検証を行うことができる。
また、優先順位付与部１３は、パターンの入力に応じて、入力されたパターンにより示される検証対象部位に関連する全ての検証用シナリオに同じ優先順位を付与するようにした。

これにより、設計検証に必要な全ての検証用シナリオに同じ優先順位が付与される。従って、検証漏れをなくすことができるため、処理を簡易なものとすることができる。
また、優先順位付与部１３は、処理優先度情報を有するパターンの入力に応じて、検証用シナリオに処理優先度情報に応じた優先順位を付与するようにした。

これにより、より細かい処理優先度の付与の処理を実行できる。
なお、入力されるパターン項目としては特に限定されないが、例えば以下に示す例が挙げられる。
（１）検証を開始して間もない場合は、シナリオの基本パス、代替パス、例外パスの順に検証用シナリオに優先順位を付けるのが好ましい。従って、パターンの項目として「基本動作＞代替動作＞例外動作」を入力するのが好ましい。
（２）不具合修正後のリグレッションテストの場合は、不具合を発見したシナリオを最優先に検証し、その次に修正した箇所を直接検証するシナリオを検証し、その他のシナリオを検証するのが好ましい。従って、パターン項目として「不具合を発見したシナリオ名＞修正した箇所を直接検証するシナリオ名＞その他のシナリオ名」を入力するのが好ましい。
（３）設計最終段階では、例外ケースを集中的に確認したいことが多い。この場合には、シナリオの例外パスを優先的に検証し、その次に代替パス、基本パスを検証するのが好ましい。従って、パターン項目として「例外動作＞代替動作＞基本動作」を入力するのが好ましい。
（４）設計の途中で機能に仕様変更があったとき、その機能が関わる箇所のシナリオを優先的に検証するのが好ましい。従って、パターン項目として「その機能が関わる箇所のシナリオ」を入力するのが好ましい。

ところで、検証作業の効率化を図るための検証方法として、カバレッジドリブン検証が知られている。
カバレッジドリブン検証とは検証対象の設計情報から測定可能なプロパティと検証終了基準を予め決め、検証をその基準を満たすまで行う検証方法である。典型的なプロパティとして、実装の「行数」や「分岐」が用いられる。なお、カバレッジを用いた検証方法をサポートする手法としてＯＶＭ（Open Verification Methodology）やＶＭＭ（Verification Methodology Manual）等が知られている。

実用レベルの検証網羅性を確保するためには、いくつかの検証用のカバレッジ基準を採用し、それぞれの数値を総合して十分かどうかを判断することが行われる。
ここで、カバレッジ基準とは、検証の網羅性の尺度（Metricsとも呼ばれる）となるものである。このカバレッジ基準は、ＬＳＩの設計または検証の状況に応じて動的に変化する。

なお、カバレッジ基準が変更される状況としては、例えば、プログラムを変更した際に、その変更によって予想外の影響が現れていないか否かを検証するリグレッションテスト（regression test）時や、仕様を変更したとき等が挙げられる。

以下に示す第３の実施の形態の設計検証装置は、カバレッジ基準の入力に基づいて、そのカバレッジ基準を満たす検証用シナリオを出力する装置である。
＜第３の実施の形態＞
次に、第３の実施の形態のシステムについて説明する。

以下、第３の実施の形態のシステムについて、前述した第２の実施の形態との相違点を中心に説明し、同様の事項については、その説明を省略する。
図３４は、第３の実施の形態のシステムを示すブロック図である。

図３４に示す第３の実施の形態のシステムは、設計検証装置１０ａが、カバレッジ基準が変更されたときに、その変更要件を検証することができる検証用シナリオを生成する機能を有している点が、第２の実施の形態と異なっている。

カバレッジ基準を定義する際には、まず尺度を定義する。
本実施の形態では、ＬＳＩ２０の仕様から尺度として使える項目（測定可能である）として、機能、シナリオ、シナリオの種類、データ・イベント・メッセージ、メッセージの送り手のオブジェクトと受け手とのオブジェクトのセット、オブジェクト等が挙げられる。

本実施の形態では、機能は、該当機能に含まれる全てのシナリオを利用することとする。シナリオは、該当するシナリオを利用することとする。シナリオの種類は、ＬＳＩ２０の仕様に含まれる該当シナリオの種類を全て利用することとする。データ・イベント・メッセージは、特定のメッセージを利用することとする。これは、該当するメッセージが含まれる全てのシナリオを利用することに等しい。オブジェクトは、特定のオブジェクトが含まれる全ての検証用シナリオを利用することとする。

また、尺度を構成する要素を論理式として組み合わせたカバレッジ基準を定義することもできる。これらの要素の論理式を組み合わせることで、カバレッジ基準の細かな調整が可能になる。

なお、論理式としては、特に限定されないが、例えば、ＡＮＤ、ＯＲ、ＮＯＴ、ＮＡＮＤ、ＮＯＲ等が挙げられる。
第３の実施の形態の設計検証装置１０ａは、検証用シナリオ生成部１１、優先順位付与部１３の代わりに、検証用シナリオ生成部１１ａとシナリオ抽出部１５とを有している。

検証用シナリオ生成部１１ａは、検証用シナリオ生成部１１が有する機能に加え、検証用シナリオを生成する際に、メッセージ名と送受信側のオブジェクト名をラベルに追加する機能を有している。

シナリオ抽出部１５は、入力されるカバレッジ基準に基づいて、検証用シナリオ格納部１２に格納された検証用シナリオから、入力されたカバレッジ基準を満たす検証用シナリオを抽出する。なお、カバレッジ基準の入力は、ユーザが入力するようにしてもよいし、ユーザが予め用意したカバレッジ基準から選択するものであってもよい。

また、出力部１４は、シナリオ抽出部１５によって抽出されたカバレッジ基準を満たす検証用シナリオのシナリオ名を出力する。
次に、設計検証装置１０ａの全体処理を説明する。

図３５は、第３の実施の形態の設計検証装置の全体処理を示すフローチャートである。
まず、検証用シナリオ生成部１１ａが、ユーザにより入力されたＬＳＩ２０の設計仕様に基づいて、検証用シナリオ生成処理を行って検証用シナリオを生成する（ステップＳ１ａ）。生成した検証用シナリオは、検証用シナリオ格納部１２に格納する。

次に、シナリオ抽出部１５が、検証用シナリオ抽出処理を行う（ステップＳ２ａ）。具体的には、入力されるカバレッジ基準に基づいて、検証用シナリオ格納部１２に格納された検証用シナリオから、カバレッジ基準を満たす検証用シナリオを抽出する。

そして、出力部１４が、抽出された検証用シナリオのシナリオ名を出力する（ステップＳ３ａ）。
以上で、全体処理の説明を終了する。

次に、第３の実施の形態の検証用シナリオ生成処理を説明する。
図３６は、第３の実施の形態の検証用シナリオ生成処理を示すフローチャートである。
ステップＳ１１〜ステップＳ１５：第２の実施の形態の検証用シナリオ生成処理と同様の処理を行う。

［ステップＳ１５ａ］
メッセージ名と送受信オブジェクト名をラベルに追加する。その後、ステップＳ１６に遷移する。

ステップＳ１６〜ステップＳ２６：第２の実施の形態の検証用シナリオ生成処理と同様の処理を行う。
以上で、第３の実施の形態の検証用シナリオ生成処理の説明を終了する。

なお、図３６では、ステップＳ２０以降の処理は、図１３のものと同様であるため図示を省略している。
次に、検証用シナリオ抽出処理を説明する。

図３７は、検証用シナリオ抽出処理を示すフローチャートである。
まず、入力されるカバレッジ基準から要素を１つ選択する（ステップＳ６１）。
次に、選択したカバレッジ基準に基づいて、検証用シナリオ格納部１２に格納された検証用シナリオから、カバレッジ基準を満たす検証用シナリオを抽出する（ステップＳ６２）。

次に、未選択の要素が存在するか否かを判断する（ステップＳ６３）。
未選択の要素が存在する場合（ステップＳ６３のＹｅｓ）、ステップＳ６１に移行し、未選択の要素を１つ選択する。その後、ステップＳ６２以降の処理を引き続き行う。

一方、未選択の要素が存在しない場合（ステップＳ６３のＮｏ）、すなわち、全ての要素を選択し終わった場合、ステップＳ６２にて抽出した検証用シナリオの集合から、カバレッジ基準の論理式を評価する（ステップＳ６４）。具体的には、入力されるカバレッジ基準が論理式を含んでいる場合は、その論理式を演算し、その演算結果を出力部１４に送る。また、入力されるカバレッジ基準の要素が１つだけである場合は、ステップＳ６２にて抽出した検証用シナリオの集合を出力部１４に送る。その後、処理を終了する。

以上で、検証用シナリオ抽出処理の説明を終了する。
次に、第３の実施の形態の設計検証装置１０ａの処理を具体例を用いて説明する。
図３８は、第３の実施の形態のＬＳＩの設計仕様のデータ構造の具体例を示す図である。

機能ブロック５２には残高照会機能が設定されている。また、機能ブロック５３には、（現金）引き出し機能が設定されている。
図３８に示すＬＳＩ２０の設計仕様には、５つのシナリオが用意されている。

本実施の形態の第１のシナリオは、機能ブロック５２に対応付けられている機能、シナリオブロック５２ａに対応付けられているシナリオ、シナリオブロック５２ａに対応付けられているシナリオを実現するための検証用シナリオを開始、進行するパスに関する。

この検証用シナリオは、ＭＳＣブロック５２１ａ〜５２５ａに対応付けられているメッセージ・シーケンス・チャートによって実現される。
この第１のシナリオは、将来的なユーザによって提供されるパスワードの入力（ＰＩＮ）を受け付けて残高を表示するＡＴＭと関連付けされている。

本実施の形態の第２のシナリオは、機能ブロック５２に対応付けられている機能、シナリオブロック５２ｂに対応付けられているシナリオ、シナリオブロック５２ｂに対応付けられているシナリオを実現するための検証用シナリオを開始、進行するパスに関する。

この第２のシナリオは、将来的なユーザによって提供されるパスワードの入力を拒否するＡＴＭと関連付けされている。
本実施の形態の第３のシナリオは、機能ブロック５３に対応付けられている機能、シナリオブロック５３ａに対応付けられているシナリオ、シナリオブロック５３ａに対応付けられているシナリオを実現するための検証用シナリオを開始、進行するパスに関する。

この第３のシナリオは、将来的なユーザによって提供されるパスワードの入力を拒否するＡＴＭと関連付けされている。
本実施の形態の第４のシナリオは、機能ブロック５３に対応付けられている機能、シナリオブロック５３ｂに対応付けられているシナリオ、シナリオブロック５３ｂに対応付けられているシナリオを実現するための検証用シナリオを開始、進行するパスに関する。

この第４のシナリオは、将来的なユーザによって提供されるパスワードの入力を受け付けて現金が引き出されたときのメッセージを表示するＡＴＭと関連付けされている。
本実施の形態の第５のシナリオは、機能ブロック５３に対応付けられている機能、シナリオブロック５３ｃに対応付けられているシナリオ、シナリオブロック５３ｃに対応付けられているシナリオを実現するための検証用シナリオを開始、進行するパスに関する。

この第５のシナリオは、将来的なユーザによって提供されるパスワードの入力を受け付けて残高不足メッセージを表示するＡＴＭと関連付けされている。
なお、図３８では、シナリオブロック５２ｂ、５３ａ、５３ｂ、５３ｃが有するＭＳＣブロックの図示を省略している。

以下、第１のシナリオをシナリオ「照会」と言う。第２のシナリオをシナリオ「照会認証失敗」と言う。第３のシナリオをシナリオ「引き出し認証失敗」と言う。第４のシナリオをシナリオ「引き出し成功」と言う。第５のシナリオをシナリオ「残高不足」と言う。

次に、第３の実施の形態の有向グラフを説明する。
図３９は、第３の実施の形態のメッセージ・シーケンス・チャート間の関係と階層構造を説明する図である。

有向グラフ３０ａは、初期状態ブロック３１ａ、メッセージ・シーケンス・チャート３２ａ〜３９ａ、１３０ａ、１３１ａによって表される１０個の機能を有している。この１０個の機能の組み合わせにより、図３８に示したシナリオブロック５２ａ、５２ｂ、５３ａ、５３ｂ、５３ｃに対応付けられているシナリオの処理が実現される。

例えば、メッセージ・シーケンス・チャート３２ａは、シナリオブロック５２ａが有するＭＳＣブロック５２１ａのメッセージ・シーケンス・チャート「Ｑｕｅｒｙ」に対応していることを示している。これは、シナリオブロック５２ａのシナリオ「照会」の処理が、メッセージ・シーケンス・チャート３２ａの処理を含んでいることを示している。

以下、各シナリオの処理の流れについて説明する。
シナリオ「照会」は、初期状態ブロック３１ａ、メッセージ・シーケンス・チャート３２ａ、３３ａ、３４ａ、３５ａ、３６ａを介し進行するパスに関する。具体的には、メッセージ・シーケンス・チャート３２ａの処理後、Ｖ＝＝ｔｒｕｅのガード条件が成立すれば、メッセージ・シーケンス・チャート３３ａに移行する。メッセージ・シーケンス・チャート３３ａの処理後、メッセージ・シーケンス・チャート３４ａに移行する。メッセージ・シーケンス・チャート３４ａの処理後、ｏｐｔｉｏｎ＝＝Ｂａｌａｎｃｅのガード条件が成立すれば、メッセージ・シーケンス・チャート３５ａに移行する。メッセージ・シーケンス・チャート３５ａの処理後、メッセージ・シーケンス・チャート３６ａに移行する。メッセージ・シーケンス・チャート３６ａの処理が終了すると、シナリオ「照会」の処理が終了する。

シナリオ「照会認証失敗」は、初期状態ブロック３１ａ、メッセージ・シーケンス・チャート３２ａ、３７ａを介し進行するパスに関する。具体的には、メッセージ・シーケンス・チャート３２ａの処理後、Ｖ＝＝ｆａｌｓｅのガード条件が成立すれば、メッセージ・シーケンス・チャート３７ａに移行する。メッセージ・シーケンス・チャート３７ａの処理が終了すると、シナリオ「照会認証失敗」の処理が終了する。

シナリオ「引き出し認証失敗」は、シナリオ「照会認証失敗」と同様の処理を行う。具体的には、メッセージ・シーケンス・チャート３２ａの処理後、Ｖ＝＝ｆａｌｓｅのガード条件が成立すれば、メッセージ・シーケンス・チャート３７ａに移行する。メッセージ・シーケンス・チャート３７ａの処理が終了すると、シナリオ「引き出し認証失敗」の処理が終了する。

シナリオ「引き出し成功」は、初期状態ブロック３１ａ、メッセージ・シーケンス・チャート３２ａ、３３ａ、３４ａ、３８ａ、３９ａ、１３０ａ、３６ａを介し進行するパスに関する。具体的には、メッセージ・シーケンス・チャート３２ａの処理後、Ｖ＝＝ｔｒｕｅのガード条件が成立すれば、メッセージ・シーケンス・チャート３３ａに移行する。メッセージ・シーケンス・チャート３３ａの処理後、メッセージ・シーケンス・チャート３４ａに移行する。メッセージ・シーケンス・チャート３４ａの処理後、ｏｐｔｉｏｎ＝＝Ｗｉｔｈｄｒａｗａｌのガード条件が成立すれば、メッセージ・シーケンス・チャート３８ａに移行する。メッセージ・シーケンス・チャート３８ａの処理後、Ｂａｌａｎｃｅ＞＝０のガード条件が成立すれば、メッセージ・シーケンス・チャート３９ａに移行する。メッセージ・シーケンス・チャート３９ａの処理が終了すると、メッセージ・シーケンス・チャート１３０ａに移行する。メッセージ・シーケンス・チャート１３０ａの処理が終了すると、メッセージ・シーケンス・チャート３６ａに移行する。メッセージ・シーケンス・チャート３６ａの処理が終了すると、シナリオ「引き出し成功」の処理が終了する。

シナリオ「残高不足」は、初期状態ブロック３１ａ、メッセージ・シーケンス・チャート３２ａ、３３ａ、３４ａ、３８ａ、１３１ａ、３６ａを介し進行するパスに関する。具体的には、メッセージ・シーケンス・チャート３２ａの処理後、Ｖ＝＝ｔｒｕｅのガード条件が成立すれば、メッセージ・シーケンス・チャート３３ａに移行する。メッセージ・シーケンス・チャート３３ａの処理後、メッセージ・シーケンス・チャート３４ａに移行する。メッセージ・シーケンス・チャート３４ａの処理後、ｏｐｔｉｏｎ＝＝Ｗｉｔｈｄｒａｗａｌのガード条件が成立すれば、メッセージ・シーケンス・チャート３８ａに移行する。メッセージ・シーケンス・チャート３８ａの処理後、Ｂａｌａｎｃｅ＜０のガード条件が成立すれば、メッセージ・シーケンス・チャート１３１ａに移行する。メッセージ・シーケンス・チャート１３１ａの処理が終了すると、メッセージ・シーケンス・チャート３６ａに移行する。メッセージ・シーケンス・チャート３６ａの処理が終了すると、シナリオ「残高不足」の処理が終了する。

次に、シナリオ「照会」を例にとって、処理の流れの詳細を説明する。
図４０は、シナリオ「照会」のメッセージ・シーケンス・チャートを示す図である。
図４０に示すメッセージ・シーケンス・チャート４０ｅは、シナリオ「照会」に関するメッセージ・シーケンス・チャートである。

このメッセージ・シーケンス・チャート４０ｅは、メッセージ・シーケンス・チャート３２ａ〜３６ａが有する全ての処理を示したものである。
図４０に示すオブジェクトは、ユーザインタフェース（Ｉ／Ｆ）４１ａ、ＡＴＭ４２ａおよびデータベース４３ａによって表される。

各オブジェクトはまた、ユーザインタフェースライン４４ａ、ＡＴＭライン４５ａおよびデータベースライン４６ａを含むオブジェクトラインを含む。
前述したルールを利用して、メッセージ・シーケンス・チャート４０ｅは、以下の処理を行う。

まず、ＡＴＭ４２ａはカード挿入依頼メッセージ（Ｉｎｓｅｒｔ＿Ｃａｒｄ）をユーザインタフェース４１ａに送信する（ステップＳ５１ａ）。
カード挿入依頼メッセージの受信後、ユーザインタフェース４１ａは、カード挿入メッセージ（Ｃａｒｄ＿Ｉｎｓｅｒｔｅｄ）をＡＴＭ４２ａに送信する（ステップＳ５２ａ）。

カード挿入メッセージの送信後、ユーザインタフェース４１ａは、入力されたパスワード（ＰＩＮ）をＡＴＭ４２ａに送信する（ステップＳ５３ａ）。
ＡＴＭ４２ａが、パスワードを受信した後、ＡＴＭ４２ａは認証依頼（Ｖ＝ＰＩＮ＿Ｖｅｒｉｆｙ）メッセージをデータベース４３ａに送信する（ステップＳ５４ａ）。ここまでが、メッセージ・シーケンス・チャート３２ａの有するシナリオである。

データベース４３ａは、ＯＫメッセージ（ＯＫ）をＡＴＭ４２ａに送信する（ステップＳ５５ａ）。ここまでが、メッセージ・シーケンス・チャート３３ａの有するシナリオである。

ＡＴＭ４２ａがＯＫメッセージを受信した後、ＡＴＭ４２ａは、メニュー表示（Ｍｅｎｕ）をユーザインタフェース４１ａに送信する（ステップＳ５６ａ）。
その後、ユーザインタフェース４１ａがオプション入力メッセージ（Ｏｐｔｉｏｎ＝Ｅｎｔｅｒ＿ｏｐｔｉｏｎ）を受け付けると、ＡＴＭ４２ａに送信する（ステップＳ５７ａ）。ここまでが、メッセージ・シーケンス・チャート３４ａの有するシナリオである。

ＡＴＭ４２ａがオプション入力メッセージを受信した後、ＡＴＭ４２ａは、残高照会要求メッセージ（Ｒｅｑ＿Ｂａｌａｎｃｅ）をデータベース４３ａに送信する（ステップＳ５８ａ）。

データベース４３ａは、残高照会情報（Ｂａｌａｎｃｅ＝Ｂａｌａｎｃｅ＿ｉｎｆｏ）をＡＴＭ４２ａに送信する（ステップＳ５９ａ）。
ＡＴＭ４２ａは、残高照会情報表示（Ｓｈｏｗ＿Ｂａｌａｎｃｅ）をユーザインタフェース４１ａに送信する（ステップＳ６０ａ）。ここまでが、メッセージ・シーケンス・チャート３５ａの有するシナリオである。

ＡＴＭ４２ａは、トランザクション終了メッセージ（Ｅｎｄ＿Ｔｒａｎｓａｃｔｉｏｎ＿Ｍｅｓｓａｇｅ）をユーザインタフェース４１ａに送信する（ステップＳ６１ａ）。
ＡＴＭ４２ａは、カード返却メッセージ（Ｒｅｔｕｒｎ＿ｃａｒｄ）をユーザインタフェース４１ａに送信する。ここまでが、メッセージ・シーケンス・チャート３６ａの有するシナリオである。

次に、第３の実施の形態のＬＳＩ２０の設計仕様にラベルを付与する具体例を説明する。
図４１、図４２は、第３の実施の形態のＬＳＩの設計仕様にラベルを付与する具体例を示す図である。

まず、ＬＳＩ２０の設計仕様を参照し、機能ブロック５２に対応付けられている機能「残高照会」を選択する。
次に、選択した機能ブロック５２からシナリオブロック５２ａに対応付けられているシナリオ「照会」を選択する。

次に、選択したシナリオ「照会」に含まれるメッセージ・シーケンス・チャート３２ａを選択する。
次に、選択したメッセージ・シーケンス・チャート３２ａにラベルを付与する。

前述したように、ラベルは、現在選択されている機能名および現在選択されているシナリオ名を付与する。またラベルは、機能名・シナリオ名：シナリオの種類の順に付与する。従って、図４１に示す例では、ラベル５２１ａ１として「残高照会・照会：基本動作」を付与する。

図４１は、ここまでの処理を示している。
以降、第２の実施の形態と同様に、メッセージ・シーケンス・チャートにラベルを付与する。

具体的には、選択したシナリオ「照会」に含まれるメッセージ・シーケンス・チャート３３ａを選択する。そして、選択したメッセージ・シーケンス・チャート３３ａに「残高照会・照会：基本動作」のラベルを付与する。

次に、選択したシナリオ「照会」に含まれるメッセージ・シーケンス・チャート３４ａを選択する。そして、選択したメッセージ・シーケンス・チャート３４ａに「残高照会・照会：基本動作」のラベルを付与する。

次に、選択したシナリオ「照会」に含まれるメッセージ・シーケンス・チャート３５ａを選択する。そして、選択したメッセージ・シーケンス・チャート３５ａに「残高照会・照会：基本動作」のラベルを付与する。

次に、選択したシナリオ「照会」に含まれるメッセージ・シーケンス・チャート３６ａを選択する。そして、選択したメッセージ・シーケンス・チャート３６ａに「残高照会・照会：基本動作」のラベルを付与する。

選択したシナリオ「照会」に含まれる各メッセージ・シーケンス・チャートについてラベルの付与が完了したので、次に、選択した機能ブロック５２からシナリオブロック５２ｂに対応付けられているシナリオ「認証失敗」を選択する。そして、選択したシナリオ「認証失敗」に含まれるメッセージ・シーケンス・チャートを順次、選択する。そして、選択したメッセージ・シーケンス・チャートにラベルを付与する。

図４２は、ここまでの処理を示している。図４２に示す例では、ラベル５２１ａ１に「残高照会・認証失敗：例外動作」が追加されている。なお、図４２では、説明を分かりやすくするために、メッセージ・シーケンス・チャート３３ａ、３４ａ、３５ａ、３６ａに付与されたラベルの図示を省略している。

選択したシナリオ「認証失敗」に含まれるメッセージ・シーケンス・チャートについて、ラベルの付与が完了すると、機能ブロック５２が有する全てのシナリオブロック５２ａ、５２ｂについてラベルの付与が完了する。

従って、ＬＳＩ２０の設計仕様を参照し、機能ブロック５３に対応付けられている機能「引き出し」を選択する。
そして、選択した機能ブロック５３からシナリオブロック５３ａに対応付けられているシナリオ「認証失敗」を選択する。そして、選択したシナリオ「認証失敗」に含まれるメッセージ・シーケンス・チャートを順次、選択する。そして、選択したメッセージ・シーケンス・チャートにラベルを付与する。

選択したシナリオ「認証失敗」に含まれる全てのメッセージ・シーケンス・チャートについて、ラベルの付与が完了すると、次に、選択した機能ブロック５３からシナリオブロック５３ｂに対応付けられているシナリオ「引き出し成功」を選択する。そして、選択したシナリオ「引き出し成功」に含まれるメッセージ・シーケンス・チャートを順次、選択する。そして、選択したメッセージ・シーケンス・チャートにラベルを付与する。

選択したシナリオ「引き出し成功」に含まれる全てのメッセージ・シーケンス・チャートについて、ラベルの付与が完了すると、次に、選択した機能ブロック５３からシナリオブロック５３ｃに対応付けられているシナリオ「残高不足」を選択する。そして、選択したシナリオ「残高不足」に含まれるメッセージ・シーケンス・チャートを順次、選択する。そして、選択したメッセージ・シーケンス・チャートにラベルを付与する。

選択したシナリオ「残高不足」に含まれる全てのメッセージ・シーケンス・チャートについて、ラベルの付与が完了すると、機能ブロック５３が有する全てのシナリオブロック５３ａ、５３ｂ、５３ｃについてラベルの付与が完了する。

従って、ＬＳＩ２０の設計仕様を参照する。他の機能が存在しないため、ラベル付与の処理を終了する。
図４３は、ラベル付与が完了した状態の有向グラフを示す図である。

例えば、メッセージ・シーケンス・チャート３２ａは、シナリオ「照会」、シナリオ「照会認証失敗」、シナリオ「引き出し認証失敗」、シナリオ「引き出し成功」、シナリオ「残高不足」の全てのシナリオに含まれているため、これら全てのシナリオに関するラベルが付与されている。また、メッセージ・シーケンス・チャート３５ａは、シナリオ「照会」のみに含まれているシナリオであるため、シナリオ「照会」に関するラベルが付与されている。

図４４は、ラベルを付与したＬＳＩの設計仕様のデータ構造例を示す図である。
ラベルを付与したＬＳＩ２０のデータ１６０は、ＸＭＬ形式で表現されている。
記述１６１は、メッセージ・シーケンス・チャート３２ａに関する記述部分を示している。また、記述１６２は、メッセージ・シーケンス・チャート３３ａに関する記述部分を示している。また、記述１６３は、メッセージ・シーケンス・チャート３７ａに関する記述部分を示している。

ここで、記述１６１ａ、１６２ａ、１６３ａは、それぞれ、ラベル付与処理によって追記された行である。ラベル付与処理によって追記された行には、ラベル名であることを識別するＸＭＬタグ＜label name＞が付されている。また、タグ内の内容は、それぞれ付与されたラベルの内容を示している。

次に、ステップＳ１５ａの具体例を説明する。
図４５は、オブジェクト名をラベルに追加する具体例を示す図である。
まず、第２の実施の形態と同様の方法にて生成した有限ステートマシン９０ｂのステート１つ１つに対し、対応するメッセージ・シーケンス・チャートのデータ・イベント・メッセージをラベルとして付与する。

図４５では、メッセージ・シーケンス・チャート３２ａから有限ステートマシンのステートＳｔ１１、Ｓｔ１２、Ｓｔ１３、Ｓｔ１４が生成されている。
ここで、メッセージ・シーケンス・チャート３２ａには、「残高照会・照会：基本動作」、「残高照会・認証失敗・例外動作」、「引き出し・引き出し成功：基本動作」、「引き出し・残高不足：代替動作」、「引き出し・認証失敗：例外動作」のラベルが付与されている。

従って、これらステートＳｔ１１、Ｓｔ１２、Ｓｔ１３、Ｓｔ１４それぞれにも、「残高照会・照会：基本動作」、「残高照会・認証失敗・例外動作」、「引き出し・引き出し成功：基本動作」、「引き出し・残高不足：代替動作」、「引き出し・認証失敗：例外動作」のラベルを付与する。

さらに、ステートＳｔ１１、Ｓｔ１２、Ｓｔ１３、Ｓｔ１４それぞれのラベルにメッセージ名とメッセージの送り手と受け手のオブジェクト名を追加する。
図４５では、ステートＳｔ１１のラベルには、メッセージ名「Ｉｎｓｅｒｔ＿Ｃａｒｄ」と、メッセージの送り手であるＡＴＭ４２ａと、メッセージの受け手であるユーザＩ／Ｆ４１ａを追加する。

ステートＳｔ１２のラベルには、メッセージ名「Ｃａｒｄ＿Ｉｎｓｅｒｔｅｄ」と、メッセージの送り手であるユーザＩ／Ｆ４１ａと、メッセージの受け手であるＡＴＭ４２ａを追加する。ステートＳｔ１３のラベルには、メッセージ名「ＰＩＮ」と、メッセージの送り手であるユーザＩ／Ｆ４１ａと、メッセージの受け手であるＡＴＭ４２ａを追加する。ステートＳｔ１４のラベルには、メッセージ名「Ｖ＝ＰＩＮ＿Ｖｅｒｉｆｙ」と、メッセージの送り手であるＡＴＭ４２ａと、メッセージの受け手であるデータベース４３ａを追加する。

以後、メッセージ・シーケンス・チャート３３ａ〜３９ａ、１３０ａ、１３１ａについても同様の処理を行う。なお、既にメッセージ名と、メッセージの送り手と、メッセージの受け手がラベルに付与されている場合は、付与処理を省略するようにしてもよいし、上書きするようにしてもよい。

図４６は、有限ステートマシンにラベルの付与が終了したときの状態を示す図である。
図４６では、メッセージ・シーケンス・チャート３３ａからステートＳｔ１５、・・・が生成されている。

ここで、メッセージ・シーケンス・チャート３３ａには、「残高照会・照会：基本動作」、「引き出し・引き出し成功：基本動作」、「引き出し・残高不足：代替動作」のラベルが付与されている。

従って、これらステートＳｔ１５にも、「残高照会・照会：基本動作」、「引き出し・引き出し成功：基本動作」、「引き出し・残高不足：代替動作」のラベルが付与されている。

さらに、ステートＳｔ１５のラベルには、メッセージ名「ＯＫ」と、メッセージの送り手であるデータベース４３ａと、メッセージの受け手であるＡＴＭ４２ａが追加されている。

また、メッセージ・シーケンス・チャート３７ａからステートＳｔ１６、Ｓｔ１７、Ｓｔ１８が生成されている。
ここで、メッセージ・シーケンス・チャート３７ａには、「残高照会・認証失敗：例外動作」、「引き出し・認証失敗：例外動作」のラベルが付与されている。

従って、これらステートＳｔ１６、Ｓｔ１７、Ｓｔ１８それぞれにも、「残高照会・認証失敗：例外動作」、「引き出し・認証失敗：例外動作」のラベルが付与されている。
さらに、ステートＳｔ１６のラベルには、メッセージ名「ＰＩＮ」と、メッセージの送り手であるデータベース４３ａと、メッセージの受け手であるＡＴＭ４２ａが追加されている。ステートＳｔ１７のラベルには、メッセージ名「Ｒｅｊｅｃｔｅｄ」と、メッセージの送り手であるＡＴＭ４２ａと、メッセージの受け手であるユーザＩ／Ｆ４１ａが追加されている。ステートＳｔ１８のラベルには、メッセージ名「Ｒｅｔｕｒｎ＿Ｃａｒｄ」と、メッセージの送り手であるＡＴＭ４２ａと、メッセージの受け手であるユーザＩ／Ｆ４１ａが追加されている。

図４７は、メッセージ名と送受信側のオブジェクト名をラベルに追加した状態の有限ステートマシンのデータ構造を示す図である。
有限ステートマシンのデータ１２０は、ＸＭＬ形式で表現されている。

記述１２０ａは、有限ステートマシン９０ｂの識別子に関する記述部分を示している。当該記述１２０ａには、有限ステートマシンであることを識別する有限ステートマシンタグ＜fsm name＞が付されている。また、タグ内の内容は、それぞれ付与されたラベルの内容を示している。

また、記述１２１〜１２４は、それぞれ各ステートＳｔ１１〜Ｓｔ１４に関する記述部分を示している。ステートＳｔ１５、・・・、Ｓｔ１６〜Ｓｔ１８に関する記述部分については、図示を省略している。

次に、図４０に示すメッセージ・シーケンス・チャート４０ｅ、図４３に示す有向グラフ３０ａ、および、図４６に示す有限ステートマシン９０ｂを用いて検証用シナリオ抽出処理の具体例を説明する。

＜検証用シナリオ抽出処理の具体例１＞
最初に、入力されたカバレッジ基準が（ｍｅｓｓａｇｅ＝”ＰＩＮ＿Ｅｒｒｏｒ”）である場合を例に説明する。

まず、カバレッジ基準の要素（ｍｅｓｓａｇｅ＝”ＰＩＮ＿Ｅｒｒｏｒ”）を選択する。
そして、選択した要素（ｍｅｓｓａｇｅ＝”ＰＩＮ＿Ｅｒｒｏｒ”）を有限ステートマシン９０ｂのステートに付与したラベルに含む検証用シナリオを抽出する。

図４６を参照すると、ステートＳｔ１６に付与したラベルに「ＰＩＮ＿Ｅｒｒｏｒ」が含まれている。従って、このラベルに含まれる「残高照会・認証失敗：例外動作」、「引き出し・認証失敗：例外動作」が付与されている検証用シナリオを検証用シナリオ格納部１２から抽出する。

次に、未選択の要素が存在するか否かを判断すると、存在しない。また、入力されるカバレッジ基準の要素が１つだけである。従って、抽出された検証用シナリオを、カバレッジ基準を満たす検証用シナリオとして、出力部１４に送る。これにより、出力部１４が、抽出された検証用シナリオのシナリオ名として「残高照会・認証失敗：例外動作」および「引き出し・認証失敗：例外動作」を出力する。

＜検証用シナリオ抽出処理の具体例２＞
次に、入力されたカバレッジ基準が、（ｍｅｓｓａｇｅ＝“Ｍｅｎｕ”）＆＆（ｓｃｅｎａｒｉｏｔｙｐｅ＝“ａｌｔｓｃｅｎａｒｉｏ”）である場合を例に説明する。なお、「＆＆」は集合積を示している。また、（ｓｃｅｎａｒｉｏｔｙｐｅ＝“ａｌｔｓｃｅｎａｒｉｏ”）は、代替動作を選択していることを示している。

まず、カバレッジ基準の要素（ｍｅｓｓａｇｅ＝“Ｍｅｎｕ”）を選択する。
そして、選択した要素（ｍｅｓｓａｇｅ＝“Ｍｅｎｕ”）を有限ステートマシン９０ｂのステートに付与したラベルに含む検証用シナリオを検証用シナリオ格納部１２から抽出する。

図４０に示すメッセージ・シーケンス・チャート４０ｅおよび図４３に示す有向グラフ３０ａを参照すると、メッセージ・シーケンス・チャート３４ａの中にのみ要素（ｍｅｓｓａｇｅ＝“Ｍｅｎｕ”）が含まれている。

従って、このメッセージ・シーケンス・チャート３４ａのラベルに含まれる「残高照会・照会：基本動作」、「引き出し・引き出し成功：基本動作」、「引き出し・残高不足：代替動作」が付与されている検証用シナリオを検証用シナリオ格納部１２から抽出する。

次に、未選択の要素が存在するか否かを判断すると、未選択の要素（ｓｃｅｎａｒｉｏｔｙｐｅ＝“ａｌｔｓｃｅｎａｒｉｏ”）が存在する。従って、カバレッジ基準の要素（ｓｃｅｎａｒｉｏｔｙｐｅ＝“ａｌｔｓｃｅｎａｒｉｏ”）を選択する。

そして、選択した要素（ｓｃｅｎａｒｉｏｔｙｐｅ＝“ａｌｔｓｃｅｎａｒｉｏ”）を有限ステートマシン９０ｂのステートに付与したラベルに含む検証用シナリオを検証用シナリオ格納部１２から抽出する。

代替動作を含むシナリオは、「引き出し・残高不足：代替動作」のみである。従って、「引き出し・残高不足：代替動作」をラベルに含む検証用シナリオを検証用シナリオ格納部１２から抽出する。

次に、未選択の要素が存在するか否かを判断すると、存在しない。そこで、抽出した検証用シナリオの集合の集合積を行う。
図４８は、抽出した検証用シナリオの集合積を行う様子を示す図である。

図４８では、要素（ｍｅｓｓａｇｅ＝“Ｍｅｎｕ”）に対応して抽出した検証用シナリオの集合５００と、要素（ｓｃｅｎａｒｉｏｔｙｐｅ＝“ａｌｔｓｃｅｎａｒｉｏ”）に対応して抽出した検証用シナリオの集合６００を図示している。

なお、図４８では、検証用シナリオを識別するために、付与されたラベルの機能名・シナリオ名：シナリオの種類を用いている。
これら２つに共通する検証用シナリオは、「引き出し・残高不足：代替動作」である。従って、共通する検証用シナリオ「引き出し・残高不足：代替動作」を、カバレッジ基準を満たす検証用シナリオ７００として、出力部１４に送る。これにより、出力部１４が、この検証用シナリオ７００のシナリオ名を出力する。

＜検証用シナリオ抽出処理の具体例３＞
次に、入力されたカバレッジ基準が、（ｍｅｓｓａｇｅ＝“Ｍｅｎｕ”）＆＆（ｏｂｊｅｃｔ＝“ＡＴＭ”）である場合を例に説明する。

まず、カバレッジ基準の要素（ｍｅｓｓａｇｅ＝“Ｍｅｎｕ”）を選択する。
そして、選択した要素（ｍｅｓｓａｇｅ＝“Ｍｅｎｕ”）を有限ステートマシン９０ｂのステートに付与したラベルに含む検証用シナリオを検証用シナリオ格納部１２から抽出する。

図４０に示すメッセージ・シーケンス・チャート４０ｅおよび図４３に示す有向グラフ３０ａを参照すると、メッセージ・シーケンス・チャート３４ａの中にのみ要素（ｍｅｓｓａｇｅ＝“Ｍｅｎｕ”）が含まれている。

従って、このメッセージ・シーケンス・チャート３４ａのラベルに含まれる「残高照会・照会：基本動作」、「引き出し・引き出し成功：基本動作」、「引き出し・残高不足：代替動作」が付与されている検証用シナリオを検証用シナリオ格納部１２から抽出する。

次に、未選択の要素が存在するか否かを判断すると、未選択の要素（ｏｂｊｅｃｔ＝“ＡＴＭ”）が存在する。従って、カバレッジ基準の要素（ｏｂｊｅｃｔ＝“ＡＴＭ”）を選択する。

そして、選択した要素（ｏｂｊｅｃｔ＝“ＡＴＭ”）を有限ステートマシン９０ｂのステートに付与したラベルに含む検証用シナリオを検証用シナリオ格納部１２から抽出する。

ここでは、「残高照会・照会：基本動作」、「残高照会・認証失敗：例外動作」、「引き出し・引き出し成功：基本動作」、「引き出し・残高不足：代替動作」、「引き出し・認証失敗：例外動作」をラベルに含む検証用シナリオを検証用シナリオ格納部１２から抽出する。

次に、未選択の要素が存在するか否かを判断すると、存在しない。そこで、抽出した検証用シナリオの集合の集合積を行う。
図４９は、抽出した検証用シナリオの集合積を行う様子を示す図である。

図４９では、要素（ｍｅｓｓａｇｅ＝“Ｍｅｎｕ”）に対応して抽出した検証用シナリオの集合５０１と、要素（ｏｂｊｅｃｔ＝“ＡＴＭ”）に対応して抽出した検証用シナリオの集合６０１を図示している。

なお、図４９では、検証用シナリオを識別するために、付与されたラベルの機能名・シナリオ名：シナリオの種類を用いている。
これら２つに共通するシナリオは、「残高照会・照会：基本動作」、「引き出し・引き出し成功：基本動作」、「引き出し・残高不足：代替動作」である。

従って、共通する検証用シナリオ「残高照会・照会：基本動作」、「引き出し・引き出し成功：基本動作」、「引き出し・残高不足：代替動作」を、カバレッジ基準を満たす検証用シナリオ７０１として、出力部１４に送る。これにより、出力部１４が、この検証用シナリオ７０１のシナリオ名を出力する。

この第３の実施の形態のシステムによれば、第２の実施の形態のシステムと同様の効果が得られる。
そして、第３の実施の形態のシステムによれば、さらに、設計・検証フェーズの中でカバレッジ基準を動的に変更することができる。

具体的には、カバレッジ基準の変更によって、変更したカバレッジ基準を満たす新たな検証用シナリオを容易に抽出することができる。
抽出された検証用シナリオを実行することにより、設計フェーズに応じた検証が可能となる。

また、既存の実装に着目したカバレッジ基準とは異なる視点（仕様のレベル）でカバレッジ基準を設定し、実装に着目したカバレッジ基準を用いた検証を補うことができる。従って、検証効率の向上を図ることができる。

なお、入力されるカバレッジ基準としては特に限定されないが、例えば以下に示す例が挙げられる。
（１）オブジェクトの仕様が変更されたときや、あるオブジェクトを集中的に検証したい場合は、変更されたオブジェクトを利用する全ての検証用シナリオを網羅するのが好ましい。従って、カバレッジ基準として「オブジェクト名」を入力するのが好ましい。
（２）データ・イベント・メッセージの実装の不具合を修正した後には、修正したデータ・イベント・メッセージが含まれる全ての検証用シナリオを網羅するのが好ましい。従って、カバレッジ基準として「データ・イベント・メッセージ名」を入力するのが好ましい。
（３）検証作業の初期段階では、基本動作が集中的に検証され、例外動作は集中的に検証されない場合がある。この場合、例外動作を含むシナリオを、設計期間の終盤に集中的に検証したい場合がある。この場合は、特定のオブジェクトを利用する例外動作を含む全ての検証用シナリオを網羅するのが好ましい。従って、カバレッジ基準として、「オブジェクト名」＆＆「代替動作」を入力するのが好ましい。

なお、設計検証装置１０、１０ａが行った処理が、複数の装置によって分散処理されるようにしてもよい。例えば、１つの装置が、検証用シナリオ生成処理を行って検証用シナリオを生成しておき、他の装置が、その検証用シナリオを用いて優先順位付与処理を行うようにしてもよい。

以上、本発明の設計検証プログラム、設計検証方法および設計検証装置を、図示の実施の形態に基づいて説明したが、本発明はこれに限定されるものではなく、各部の構成は、同様の機能を有する任意の構成のものに置換することができる。また、本発明に、他の任意の構成物や工程が付加されていてもよい。

また、本発明は、前述した各実施の形態のうちの、任意の２以上の構成（特徴）を組み合わせたものであってもよい。
例えば、第３の実施の形態にて生成した検証用シナリオを用いて、優先度を付与する処理を行うようにしてもよい。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、設計検証装置１０が有する機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等が挙げられる。磁気記録装置としては、例えば、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープ等が挙げられる。光ディスクとしては、例えば、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）等が挙げられる。光磁気記録媒体としては、例えば、ＭＯ（Magneto-Optical disk）等が挙げられる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

設計検証プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。

以上の第１〜第３の実施の形態に関し、さらに以下の付記を開示する。
（付記１） 設計対象の設計仕様が備える複数の処理手順が備える処理単位それぞれに前記設計仕様の検証対象部位を識別する識別情報を関連付けた検証用情報を生成する生成部と、
前記識別情報の入力に応じて、前記検証用情報に処理優先度を付与する処理優先度付与部と、
前記処理優先度が付与された前記検証用情報を識別する情報を、前記処理優先度を明示して出力する出力部と、
を有することを特徴とする設計検証装置。

（付記２） 前記生成部は、同じ前記識別情報を備える前記処理単位を抽出し、抽出した前記処理単位の集合をそれぞれ前記検証用情報とすることを特徴とする付記１記載の設計検証装置。

（付記３） 前記処理単位は、オブジェクト間で送受信される信号の関係を示すシーケンスを備えており、前記生成部は、前記シーケンスそれぞれに、前記識別情報を関連付けることを特徴とする付記１記載の設計検証装置。

（付記４） 前記生成部は、前記シーケンスに対応したステートマシンを生成し、生成した前記ステートマシンのステートそれぞれに当該ステートマシンの元となる前記シーケンスが備える前記識別情報を付与することを特徴とする付記３記載の設計検証装置。

（付記５） 前記識別情報は、前記検証対象部位を示す機能、前記処理手順、前記シーケンスのうちの少なくとも１つの情報を有しており、
前記生成部は、同じ前記識別情報を備える前記ステートマシンを抽出し、抽出した前記ステートマシンの部分を前記検証用情報とすることを特徴とする付記４記載の設計検証装置。

（付記６） 前記シーケンスの制約に基づいて、前記シーケンスそれぞれの処理に対応したステートの数を減らすことを特徴とする付記４記載の設計検証装置。
（付記７） 前記処理優先度付与部は、前記識別情報の入力に応じて、入力された前記識別情報により示される前記検証対象部位に関連する全ての前記検証用情報に同じ処理優先度を付与することを特徴とする付記１記載の設計検証装置。

（付記８） 前記処理優先度付与部は、複数の前記識別情報および前記識別情報により示される前記検証対象部位の処理優先度情報の入力に応じて、前記検証用情報に前記処理優先度情報に応じた前記処理優先度を付与することを特徴とする付記１記載の設計検証装置。

（付記９） 前記処理優先度付与部は、入力された前記識別情報の前記検証対象部位を優先的に処理する前記処理優先度を付与することを特徴とする付記７記載の設計検証装置。

（付記１０） コンピュータが、
設計対象の設計仕様が備える複数の処理手順が備える処理単位それぞれに前記設計仕様の検証対象部位を識別する識別情報を関連付けた検証用情報を生成し、
前記識別情報の入力に応じて、前記検証用情報に処理優先度を付与し、
前記処理優先度が付与された前記検証用情報を識別する情報を、前記処理優先度を明示して出力する、
ことを特徴とする設計検証方法。

（付記１１） コンピュータを、
設計対象の設計仕様が備える複数の処理手順が備える処理単位それぞれに前記設計仕様の検証対象部位を識別する識別情報を関連付けた検証用情報を生成する生成手段、
前記識別情報の入力に応じて、前記検証用情報に処理優先度を付与する処理優先度付与手段、
前記処理優先度が付与された前記検証用情報を識別する情報を、前記処理優先度を明示して出力する出力手段、
として機能させることを特徴とする設計検証プログラム。

（付記１２） 設計対象の設計仕様が備える複数の処理手順が備える処理単位それぞれに前記設計仕様の検証対象部位をオブジェクト単位で識別する識別情報を関連付けた検証用情報を生成する生成部と、
外部からの入力に応じて前記生成部によって生成された前記検証用情報のうち、少なくとも１つの前記検証用情報を選択する選択部と、
前記選択部によって選択された前記検証用情報を識別する情報を出力する出力部と、
を有することを特徴とする設計検証装置。

（付記１３） 前記識別情報は、オブジェクト間で送受信される信号を識別する信号名と前記オブジェクトを識別するオブジェクト名とを有し、
前記選択部は、オブジェクト名の前記入力に応じて、入力された前記オブジェクト名を含む前記識別情報が関連付けられた前記検証用情報を選択することを特徴とする付記１２記載の設計検証装置。

（付記１４） 前記選択部は、オブジェクト名の前記入力が論理式を含んでいる場合、前記論理式を満たす前記検証用情報を選択することを特徴とする付記１３記載の設計検証装置。

（付記１５） 前記生成部は、同じ前記識別情報を備える前記処理単位を抽出し、抽出した前記処理単位の集合をそれぞれ前記検証用情報とすることを特徴とする付記１２記載の設計検証装置。

（付記１６） 前記処理単位は、オブジェクト間で送受信される信号の関係を示すシーケンスを備えており、前記生成部は、前記シーケンスそれぞれに、前記識別情報を関連付けることを特徴とする付記１２記載の設計検証装置。

（付記１７） 前記生成部は、前記シーケンスに対応したステートマシンを生成し、生成した前記ステートマシンのステートそれぞれに当該ステートマシンの元となる前記シーケンスが備える前記識別情報を付与することを特徴とする付記１６記載の設計検証装置。

（付記１８） 前記識別情報は、前記検証対象部位を示す機能、前記処理手順、前記シーケンスのうちの少なくとも１つの情報を有しており、
前記生成部は、同じ前記識別情報を備える前記ステートマシンを抽出し、抽出した前記ステートマシンの部分を前記検証用情報とすることを特徴とする付記１７記載の設計検証装置。

（付記１９） 前記シーケンスの制約に基づいて、前記シーケンスそれぞれの処理に対応したステートの数を減らすことを特徴とする付記１７記載の設計検証装置。
（付記２０） コンピュータが、設計対象の設計仕様が備える複数の処理手順が備える処理単位それぞれに前記設計仕様の検証対象部位をオブジェクト単位で識別する識別情報を関連付けた検証用情報を生成し、
外部からの入力に応じて、生成された前記検証用情報のうち、少なくとも１つの前記検証用情報を選択する選択し、
選択された前記検証用情報を識別する情報を出力する、
ことを特徴とする設計検証方法。

（付記２１） コンピュータを、
設計対象の設計仕様が備える複数の処理手順が備える処理単位それぞれに前記設計仕様の検証対象部位をオブジェクト単位で識別する識別情報を関連付けた検証用情報を生成する生成手段、
外部からの入力に応じて前記生成手段によって生成された前記検証用情報のうち、少なくとも１つの前記検証用情報を選択する選択手段、
前記選択手段によって選択された前記検証用情報を識別する情報を出力する出力手段、
として機能させることを特徴とする設計検証プログラム。

１、１０、１０ａ 設計検証装置
２ 生成部
３ 処理優先度付与部
４、１４ 出力部
５ 設計仕様
５ａ、５ｂ 機能
６ 構造体
６ａ、６ｂ 検証用情報
７ 識別情報
８ 出力結果
１１、１１ａ 検証用シナリオ生成部
１２ 検証用シナリオ格納部
１３ 優先順位付与部
１４ａ 優先順位リスト
１５ シナリオ抽出部
２１、５１、５２、５３ 機能ブロック
２１ａ、２１ｂ、５１ａ、５１ｂ、５２ａ、５２ｂ、５３ａ、５３ｂ、５３ｃ シナリオブロック
３０、３０ａ 有向グラフ
３１、３１ａ 初期状態ブロック
３２、３３、３２ａ〜３９ａ、４０、４０ａ〜４０ｅ、７０、１３０ａ、１３１ａ メッセージ・シーケンス・チャート（ＭＳＣ）
３４ ｈメッセージ・シーケンス・チャート（ｈＭＳＣ）
４１、４２、４３ ハードウェア（ＨＷ）
４１ａ ユーザインタフェース
４２ａ ＡＴＭ
４３ａ データベース
４４、４５、４６ オブジェクトライン
４４ａ ユーザインタフェースライン
４５ａ ＡＴＭライン
４６ａ データベースライン
４７、４８ ボックス
５０ａ、５０ｂ 処理手順
６０、１１０、１２０、１６０ データ
６１、６２、６３、６１ａ〜６３ａ、１１０ａ、１１１〜１１９、１２０ａ、１２１〜１２４、１６１〜１６３、１６１ａ〜１６３ａ 記述
７１ 送信オブジェクト
７２ 長距離送信オブジェクト
７３ 受信オブジェクト
７４ 長距離受信オブジェクト
８０ 状態マトリックス
８１、８２ 領域
９１、Ｓｔ１〜Ｓｔ８ ステート
９０、９２ 状態図
９０ａ、９０ｂ 有限ステートマシン
１００ システム
２００ 信号インタフェース
２１１ａ、２１２ａ、３２１ａ、３２２ａ、５１１ａ、５１２ａ、５１１ｂ、５１２ｂ、５２１ａ〜５３０ａ ＭＳＣブロック
３００ テスト対象装置
４００ ネットワーク
５００、５０１、６００、６０１ 集合
５１１ａ１、５１２ａ１、５１２ｂ１、５２１ａ１ ラベル
７００、７０１ Ｓｃ１、Ｓｃ２ 検証用シナリオ
ｅ１、ｅ２、ｅ３ イベント
ｍ、ｍ１〜ｍ９ データ・イベント・メッセージ
ｒ１〜ｒ６、ｒｊ 受信イベント
ｔ１〜ｔ５、ｔｉ 送信イベント

Claims (5)

1. コンピュータに、
   設計対象の設計仕様が備える複数の処理手順が備える処理単位それぞれに前記設計仕様の検証対象部位を識別する識別情報を関連付けた検証用情報を生成する生成手順、
   前記識別情報の入力に応じて、前記検証用情報に処理優先度を付与する処理優先度付与手順、
   前記処理優先度が付与された前記検証用情報を識別する情報を、前記処理優先度を明示して出力する出力手順、
   を実行させることを特徴とする設計検証プログラム。
2. 前記生成手順では、同じ前記識別情報を備える前記処理単位を抽出し、抽出した前記処理単位の集合をそれぞれ前記検証用情報とすることを特徴とする請求項１記載の設計検証プログラム。
3. 前記処理単位は、オブジェクト間で送受信される信号の関係を示すシーケンスを備えており、前記生成手順では、前記シーケンスそれぞれに、前記識別情報を関連付けることを特徴とする請求項１記載の設計検証プログラム。
4. コンピュータが、
   設計対象の設計仕様が備える複数の処理手順が備える処理単位それぞれに前記設計仕様の検証対象部位を識別する識別情報を関連付けた検証用情報を生成し、
   前記識別情報の入力に応じて、前記検証用情報に処理優先度を付与し、
   前記処理優先度が付与された前記検証用情報を識別する情報を、前記処理優先度を明示して出力する、
   ことを特徴とする設計検証方法。
5. 設計対象の設計仕様が備える複数の処理手順が備える処理単位それぞれに前記設計仕様の検証対象部位を識別する識別情報を関連付けた検証用情報を生成する生成部と、
   前記識別情報の入力に応じて、前記検証用情報に処理優先度を付与する処理優先度付与部と、
   前記処理優先度が付与された前記検証用情報を識別する情報を、前記処理優先度を明示して出力する出力部と、
   を有することを特徴とする設計検証装置。

Images