JP4619245B2 - 設計検証方法、装置、論理及びシステム - Google Patents

Description

本発明は、一般に設計及び製品の検証に関し、より詳細には、ハイレベルの設計及び製品の検証に関する。

ハードウェア及びソフトウェア技術の進歩は、より複雑な設計の基礎を提供してきた。しかしながら、既知の設計テスト技術は、非効率かつ不完全なものである。例えば、現状では回路設計を評価する効率的かつ包括的技術は存在しない。

本発明の課題は、設計及び製品のハイレベルな検証を行うための技術が提供される。

上記課題を解決するため、本発明による技術は、強力な表現機能を有するメッセージ図を用いたハイレベルな抽象化における設計及び製品のテスト及び検証を可能にする。

本発明は、設計のハイレベルな検証のための方法であって、設計に関する入力を受信するステップと、前記入力に応答して、複数のプロセス間で通信されるメッセージの関係を記述するメッセージ図を生成するステップと、前記メッセージ図から該メッセージ図により特定されるメッセージのシーケンスからなる少なくとも１つのシナリオを決定するステップと、前記シナリオに従って前記メッセージ図により特定される前記メッセージの少なくとも一部を送受信するよう動作可能な状態マシーンを生成するステップと、前記状態マシーンを利用して前記設計の実現形態をテストするステップとから構成されることを特徴とする。

また本発明は、設計のハイレベルな検証のための装置であって、設計に関する入力を受信するよう動作可能なユーザインタフェースと、前記入力に応答して、複数のプロセス間で通信されるメッセージの関係を記述するメッセージ図を生成し、前記メッセージ図から該メッセージ図により特定されるメッセージのシーケンスからなる少なくとも１つのシナリオを決定し、前記シナリオに従って前記メッセージ図により特定される前記メッセージの少なくとも一部を送受信するよう動作可能な状態マシーンを生成し、前記状態マシーンを利用して前記設計の実現形態をテストするよう動作可能なコントローラとから構成されることを特徴とする。

また本発明は、設計のハイレベルな検証のための論理であって、当該論理は、メディアに符号化され、実行時に、設計に関する入力を受信するステップと、前記入力に応答して、複数のプロセス間で通信されるメッセージの関係を記述するメッセージ図を生成するステップと、前記メッセージ図から該メッセージ図により特定されるメッセージのシーケンスからなる少なくとも１つのシナリオを決定するステップと、前記シナリオに従って前記メッセージ図により特定される前記メッセージの少なくとも一部を送受信するよう動作可能な状態マシーンを生成するステップと、前記状態マシーンを利用して前記設計の実現形態をテストするステップとを動作可能であることを特徴とする。

さらに本発明は、設計のハイレベルな検証のためのシステムであって、設計に関する入力を受信する手段と、前記入力に応答して、複数のプロセス間で通信されるメッセージの関係を記述するメッセージ図を生成する手段と、前記メッセージ図から該メッセージ図により特定されるメッセージのシーケンスからなる少なくとも１つのシナリオを決定する手段と、前記シナリオに従って前記メッセージ図により特定される前記メッセージの少なくとも一部を送受信するよう動作可能な状態マシーンを生成する手段と、前記状態マシーンを利用して前記設計の実現形態をテストする手段とから構成されることを特徴とする。

本発明によると、設計及び製品の指定、テスト及び検証に利用されるツールが提供される。開発ツールは、設計者がハイレベルの抽象化における入出力プロトコルを指定することを可能にする。例えば、包括的でハイレベルな「ゴールデンモデル（ｇｏｌｄｅｎ ｍｏｄｅｌ）」設計記述を提供するようメッセージ図が生成されるかもしれない。これらのメッセージ図は、設計及び／または製品のテストに利用される状態マシーンを生成するのに利用されてもよい。メッセージ図はまた、状態マシーン用いてテストされるシナリオを特定するのに利用されてもよい。ある実施例によると、状態マシーンは、記述言語により自動的に生成され、生成時にシミュレーションの準備がされていてもよい。さらに、状態マシーンは、仕様のすべての機能をテストすることが可能とされてもよい。ある実施例によると、上記技術は設計が規格に準拠することを確実なものとするかもしれない。さらに、設計のテスト及び検証に費やされる時間は、大きく低減されるかもしれない。

本発明の他の技術的効果は、以下の図面、説明及び請求項から当業者には容易に明らかとなるであろう。さらに、特定の効果が列挙される一方、各種実施例はこれら列挙された効果のすべてまたは一部を含むかもしれない。

図１は、検証装置１２、信号インタフェース１４及びテスト対象装置１６から構成されるテストシステム１０を示す。一般に、検証装置１２は、ハイレベルの設計及び製品検証を提供する。より詳細には、検証装置１２は、設計仕様書として機能するメッセージ図を生成するツールを有する。検証装置１２はまた、設計の実現形態の動作を検証するため、メッセージ図に基づく状態マシーンを生成するためのツールを有する。従って特定の実施例によると、検証装置１２は、テスト対象装置１６がメッセージ図により示される設計仕様書に従って動作するか判断するため、テスト対象装置１６と信号インタフェース１４を介し通信する。

検証装置１２は、ハイレベルの設計及び製品の検証を提供するよう動作可能なハードウェアとソフトウェアの任意の適切な組み合わせを表す。特定の実施例によると、検証装置１２は、オペレーティングシステム及び１以上のアプリケーションプログラムを実行する汎用コンピュータであってもよい。他の実施例によると、検証装置１２は、特殊設計された装置、複数接続された汎用コンピュータあるいは適切なハードウェアとソフトウェアの他の任意の適切な組み合わせであってもよい。

信号インタフェース１４は、検証装置１２とテスト対象装置１６とを接続するための装置を表す。信号インタフェース１４は、検証装置１２により通信される信号をテスト対象装置１６による利用に適した信号に変換するようにしてもよい。このため、信号インタフェース１４は、ハードウェア及び／またはソフトウェアを有するようにしてもよい。ここで、テストシステム１０の他の実施例では、信号インタフェース１４を省略してもよい。例えば、検証装置１２とテスト対象装置１６が互換的な信号を使用する場合、信号インタフェース１４を省略してもよい。

テスト対象装置１６は、検証装置１２によるテスト及び検証対象となるハードウェアコンポーネントまたはシステム及び／またはソフトウェアモジュールを表す。ある実施例によると、テスト対象装置１６は、製品開発中に製造される設計プロトタイプである。他の実施例によると、テスト対象装置１６は、検証装置１２によって生成される状態マシーンである。

動作に関して、検証装置１２は、ハイレベルの設計仕様及び設計要求のキャプチャをサポートする。例えば、形式的でない自然言語により典型的には記述される要求は、形式的な視覚的言語を用いて指定されてもよい。形式的な視覚的言語は、何れか適切なプログラミング言語または他のツールを用いて生成されてもよい。例えば、ＭＳＣ（Ｍｅｓｓａｇｅ Ｓｅｑｕｅｎｃｅ Ｃｈａｒｔ）、ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）のシーケンス図モデル、ロンドンのインペリアルカレッジで開発されたＬＴＳＡ（Ｌａｂｅｌｅｄ Ｔｒａｎｓｉｔｉｏｎ Ｓｙｓｔｅｍ Ａｎａｌｙｚｅｒ）、あるいは他の何れか適切な視覚的モデリング言語またはツールなどの各種視覚的設計言語の何れかが利用または変更されてもよい。形式的な視覚的言語を利用して、ハイレベルの設計仕様が生成されてもよい。例えば、検証装置１２が、設計の何れの部分がハードウェアにより製造され、何れの部分がソフトウェアにより製造されるかに関する決定がなされる前に、設計プロセスの初期の段階において設計仕様を記録するよう設計者によって利用されてもよい。

メッセージ図を用いて設計をキャプチャするのに開発ツールを設計者に利用可能にする検証装置１２によって、ハイレベルの抽象化が実現されるようにしてもよい。ここで用いられる「メッセージ図」には、プロセス間のメッセージの通信の任意の図解的表現が含まれる。さらに、ここで用いられる「プロセス」とは、情報を通信することが可能なコンカレント処理を表す。従って、プロセスは、メッセージを通信可能な物理的または概念的に独立したエンティティと関連付けされてもよい。

ある実施例によると、メッセージ図は階層的に構成されてもよい。例えば、メッセージ図は、有向グラフ及び複数のグラニュラーメッセージ図（ｇｒａｎｕｌａｒ ｍｅｓｓａｇｅ ｄｉａｇｒａｍ）を含むものであってもよい。この有向グラフは、設計のコンパクト表示を可能にするかもしれない。有向グラフは、複数のグラニュラーメッセージ図をグラニュラーメッセージ図間の関係を示すブランチ及びマージを有するフローチャートに構成するものであってもよい。この関係は、グラニュラーメッセージ図を１以上のシーケンスに順序付けするものであってもよい。他方、各グラニュラーメッセージ図は、プロセス間の関係を示すものであるかもしれない。グラニュラーメッセージ図は、プロセス間で通信されるメッセージを特定し、少なくとも一部のメッセージが通信される順序を示すものであってもよい。

ある実施例によると、設計は、複数のグラニュラーメッセージ図を含む単一の有向グラフによって表されてもよい。しかしながら他の実施例によると、設計は単一の平坦化されたメッセージ図によって表されてもよい。この平坦化されたメッセージ図は、プロセス間で通信されるメッセージの順序を示すものであってもよい。さらに、さらなる他の実施例によると、設計は、互いに埋め込まれた複数の有向グラフと複数のグラニュラーメッセージ図によって表されてもよい。

上述のように、有向グラフとグラニュラーメッセージ図を生成するのに開発ツールが利用されてもよい。ある実施例によると、この開発ツールは、設計者が有向グラフを生成するのを可能にするものであってもよい。例えば、設計者は形状を用いてグラニュラーメッセージ図を描くことによって有向グラフを生成するようにしてもよい。その後、設計者は矢印を用いて形状間を接続することによって、グラニュラーメッセージ図の間の関係を示すようにしてもよい。これらの矢印は、有向グラフを介した可能なパスを示すものであってもよい。さらに、設計者は有向グラフのグラニュラーメッセージ図をラベル付けするようにしてもよい。

設計者はまた、開発ツールを用いてグラニュラーメッセージ図を生成するようにしてもよい。グラニュラーメッセージ図には、プロセスとメッセージが含まれる。設計者は、各形状から延びたラインを有する形状を利用してプロセスを描くことによってグラニュラーメッセージ図を生成するようにしてもよい。このとき、設計者は、プロセス間で通信されるメッセージを示すのに矢印を利用してプロセス間の関係を示すようにしてもよい。例えば、あるプロセスラインと他のプロセスラインを接続するのに矢印が描かれてもよい。さらに、設計者によってプロセスとメッセージがラベル付けされてもよい。メッセージが通信される順序は、矢印の位置によって表されるようにしてもよい。

グラニュラーメッセージ図では、追加的な設計機能及び要求が示されてもよい。同時的なイベントが示されてもよい。例えば、あるプロセスによって送受信される２以上のメッセージが、同時に送受信されることが必要とされるかもしれない。ここで用いられる「同時的」とは、必ずしも「完全な同時性」を意味する必要はなく、「ある所定の期間内」を意味するものであってもよい。この期間は、時間量として規定されてもよい。例えば、この期間は密接に同期したハードウェアの動作を説明するのに用いられる極めて短い期間であってもよい。ある実施例によると、２以上のイベントが同時に発生することを示すため、グラニュラーメッセージ図においてイベント周辺にボックスが描かれてもよい。

他の先進的機能は、タイムアウトを表す機能に関するものである。タイムアウトは、実行の中断を要する。タイムアウトに関する期間は、ユーザによって予め決定または特定されていてもよい。ある実施例によると、タイムアウトが発生すべきであるということを示すため、ボックスがグラニュラーメッセージ図において描かれてもよい。ボックスのラベルは、タイムアウトに関する期間を示すものであってもよい。ここで、ある実施例によると、タイムアウトと同時的イベントが組み合わされるようにしてもよい。例えば、タイムアウト期間の完了により、メッセージが同時的に送受信されてもよい。

さらなる他の先進的な機能は、順序付けされていないメッセージの同期化に関するものである。ある実施例によると、関連しないメッセージ間の順序を生成するため、同期エッジがグラニュラーメッセージ図に含まれてもよい。この同期エッジは、通信されるメッセージを実際に表すものでなく、代わりに２つのプロセス間で通信される他のメッセージの順序を単に表すものであってもよい。ある実施例によると、２つの関連しないメッセージを同期化するため、第３のメッセージが同期エッジとして図示及びラベル付けされてもよい。この同期エッジは、第１メッセージと第２メッセージとの順序付けされた関係を生成するものであってもよい。これら２つの関係は、第１メッセージと第２メッセージとの間の関係を示すものであってもよい。

検証装置１２を用いて、入出力動作の観察を通じて動作が検証可能なシステムをテストするようにしてもよい。例えば、環境とやりとりするように動作が規定される応答システムは、入出力動作を純粋に介して検証することができる。従って、メッセージ図におけるメッセージ交換を記述することによって、応答システムはメッセージを用いて検証されてもよい。メッセージ図が応答システムをモデル化する抽象レベルでは、メッセージを外部に送信する１以上の送信プロセスと、メッセージを外部から受信する１以上の受信プロセスとして動作を抽象化するようにしてもよい。同期メッセージは、信号順序付け制約を課すため、送信及び受信モジュール間で送信されてもよい。応答システムの例として、多数のタイプの通信プロトコルのプロトコル及び物理的レイヤ仕様があげられる。そのようなプロトコルの一部には、ＰＣＩ−ｅｘｐｒｅｓｓ、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）、Ｆｉｒｅｗｉｒｅ及び他の適切なプロトコル及び規格があげられる。

従ってある実施例によると、メッセージ図は設計の抽象的かつ形式的なゴールデンモデルとして扱われ、設計の機能的特徴をテストするのに利用されてもよい。例えば、検証装置１２は、メッセージ図を用いて設計及び製品の検証に用いられるソフトウェアコードを生成するようにしてもよい。ソフトウェアコードは、メッセージ図に従ってテスト対象装置１６とやりとりするための状態マシーンとして機能するようにしてもよい。テスト対象装置１６がメッセージ図に従って状態マシーンとやりとりする場合、テスト対象装置１６は、メッセージ図の基礎となる規格に準拠すると言われるかもしれない。テスト対象装置１６が、メッセージ図に従って状態マシーンとよりとりするのに失敗すると、当該エラーは特定及び検討されるようにしてもよい。従ってある実施例によると、生成されたコードは設計の実現形態の動作をテスト及び検証するのに利用されるゴールデンモデル（ｇｏｌｄｅｎ ｍｏｄｅｌ）として利用されてもよい。生成されたコードは、テスト対象装置１６とやりとりするものであるため、ラベル付けされたインタラクタコードであってもよい。

インタラクタコードを生成するため、検証装置１２のユーザは、送信プロセスの役割を実現するモジュールと、受信プロセスの役割を実現するもう１つのモジュールを特定するものであってもよい。ある実施例によると、これらの入力を用いて、検証装置１２は、メッセージ図において指定されるシステムと通信するための外部として機能するインタラクタコードを生成するようにしてもよい。具体的には、何れかのシナリオに対して、インタラクタコードは送信プロセスによって送信されたすべてのメッセージを受信し、受信プロセスによって受信されたすべてのメッセージを送信するものであってもよい。このように、インタラクタコードは、システムからの適切な予想されないメッセージを解析することによって、システムの動作を検証することができる。ある実施例によると、インタラクタコードは、Ｖｅｒｉｌｏｇなどのハードウェア記述言語により生成されてもよい。さらに、インタラクタコードは、１以上のシナリオに従ってテスト対象装置１６とやりとりする状態マシーンを生成するようにしてもよい。

ここで用いられる「シナリオ」とは、プロセス間で通信されるメッセージの順序及び組み合わせを表す。開発ツールは、メッセージ図を用いてシナリオを特定するかもしれない。例えば、有向グラフを介した各パスは、当該パスにおいてグラニュラーメッセージ図により特定されるメッセージから構成されるシナリオを表す。多数のグラニュラーメッセージ図を含むメッセージ図などの複雑なメッセージ図では、複数のシナリオが可能であるかもしれない。

設計をテストするのに利用されるシナリオを特定するのに、様々な方法が利用可能である。例えば、設計のテストは、有向グラフの各グラニュラーメッセージ図の特定及びテストが含まれてもよい。他の方法では、有向グラフに示される順序により２つのグラニュラーメッセージ図のすべての組み合わせを特定及びテストすることが求められるであろう。この方法は、それが有向グラフのすべてのエッジがテストされることを要求するため、エッジカバレッジと呼ばれるかもしれない。エッジカバレッジは、グラニュラーメッセージ図の各遷移のテストを可能にする。ある実施例によると、エッジカバレッジは、有向グラフの郵便配達員の経路を生成するための郵便配達員アルゴリズムの利用を伴う。設計をテストするさらなる他の方法は、有向グラフを介した可能なすべてのパスの特定及びテストを必要とするであろう。開発ツールは、上記方法の何れかに従って設計をテストするためのシナリオを特定することができるようにしてもよい。しかしながら、有向グラフのすべての可能なパスの特定及びテストは、当該有向グラフのサイズ及び詳細に応じて数千または数十万のシナリオを伴うことを要するかもしれない。従って、エッジカバレッジは、設計をテストするための有用かつ効率的な手段を提供する。

上記方法に加えて、開発ツールは他の方法を用いて他のシナリオを特定およびテストすることができるかもしれない。例えば、ユーザは開発ツールに有向グラフを介しパスをテストするよう指示してもよい。さらに、開発ツールは、テストのためユーザによって特定される２つのグラニュラーメッセージ図の間のすべてのシナリオを特定するようにしてもよい。

上述のインタラクタコードを利用して、状態マシーンは、検証装置１２上で実行され、信号インタフェース１４を介しテスト対象装置１６とやりとりするようにしてもよい。仕様がメッセージ図において規定されているとき、当該仕様に従ってテスト対象装置１６がメッセージを送受信するか判断するため、検証装置１２とテスト対象装置１６との間の信号インタフェース１４を介しメッセージを通信するようにしてもよい。シナリオで特定されるメッセージシーケンスを用いて、１以上のテストが実行されてもよい。例えば、エッジカバレッジに従って生成されるシナリオが、テスト対象装置１６をテストするのに利用されてもよい。

従って、テストシステム１０は、設計の実施形態がテスト及び検証されることを可能にする。検証装置１２は、設計のゴールデンモデルを表すメッセージ図を生成し、このメッセージに基づきインタラクタコードを生成し、当該メッセージ図に基づき１以上のシナリオを特定する。インタラクタコード及びシナリオを利用して、検証装置１２は、テスト対象装置１６がメッセージ図により規定される仕様に従っているか判断するため、信号インタフェース１４を介しテスト対象装置１６とやりとりする。

図２は、検証装置１２の一例となる機能コンポーネントを示すブロック図である。図示された実施例では、検証装置１２は、プロセッサ４０、ユーザインタフェース４２、ネットワークインタフェース４４及びメモリ４６を含む。これらの機能コンポーネントは、設計及び製品のハイレベルの検証を提供するよう動作可能である。

プロセッサ４０は、情報の制御及び処理を実行することが可能な任意のハードウェア及び／または論理要素を表す。プロセッサ４０は、検証装置１２内の要素の動作及び管理を制御する。例えば、プロセッサ４０は、ユーザインタフェース４２、ネットワークインタフェース４４及びメモリ４６から受信した情報を処理するよう動作する。従って、プロセッサ４０は、プログラマブル論理装置、コントローラ及び／または他の任意の適切な処理装置であってもよい。

ユーザインタフェース４２は、検証装置１２と情報を入出力するためのハードウェアを表す。例えば、ユーザインタフェースは、メッセージ図の開発に関する検証装置１２のユーザからの入力を受け取るようにしてもよい。ユーザインタフェース４２はまた、メッセージ図、インタラクタコード及び／またはシナリオに関する情報を検証装置のユーザに表示するようにしてもよい。従って、ユーザインタフェース４２は、キーボード、マウス、ディスプレイ、及び／または情報を入出力するための他の適切な装置を含むものであってもよい。

ネットワークインタフェース４４は、検証装置１２に接続された装置から情報を受信及び通信するよう動作可能なハードウェア及び／またはソフトウェアを表す。例えば、ネットワークインタフェース４４は、信号インタフェース１４及び／またはテスト対象装置１６と通信するものであってもよい。従って、ネットワークインタフェース４４は、検証装置１２に接続される要素と情報を通信する任意の適切なハードウェアまたは制御論理を含む。

メモリ４６は、情報を格納するのに適した揮発性または不揮発性のローカルまたはリモート装置の組み合わせの何れかを表す。メモリ４６は、プロセッサ４０による処理及びユーザインタフェース４２及び／またはネットワークインタフェース４４を用いた通信のため、データ及び他の情報を永久的または一時的に格納する。例えば、メモリ４６は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、磁気記憶装置、光記憶装置、あるいは他の何れか適切な情報記憶装置、または上記装置の組み合わせを含むものであってもよい。図示されるように、メモリ４６は、１以上のメモリモジュールを含むものであってもよい。

開発ツール４８は、実行時に検証装置１２のユーザとやりとりすることが可能な適切なソフトウェア、実行可能なファイル及び／または論理モジュールを含む。例えば、開発ツール４８は、ユーザがメッセージ図を開発し、インタラクタコードを生成し、設計を検証するためのシナリオを特定することを可能にする。有向グラフデータベース５０は、グラニュラーメッセージ図の間の関係を記述する有向グラフを格納する。グラニュラーメッセージ図データベース５２は、プロセスとプロセス間で通信されるメッセージとの間の関係を記述するグラニュラーメッセージ図を格納する。インタラクタコードデータベース５４は、有向グラフデータベース５０に格納されている有向グラフとグラニュラーメッセージ図データベース５２に格納されているグラニュラーメッセージ図とに基づき、検証装置１２によって自動生成される設計を検証するのに用いられるインタラクタコードを格納する。シナリオデータベース５６は、設計を検証するのにインタラクタコードによって用いられるシナリオを特定するファイルを格納する。解析モジュール５８は、実行時に検証装置１２とのやりとりにおいてテスト対象装置１６の動作を解析することが可能なソフトウェア、実行可能なファイル及び／または適切な論理モジュールを含む。

動作に関して、検証装置１２のユーザは、開発ツール４８を用いて有向グラフデータベース５０に格納される有向グラフと、グラニュラーメッセージ図データベース５２に格納されるグラニュラーメッセージ図を生成する。ユーザは、プロセス及びメッセージのグラフィカル表示を特定及び生成するため、ユーザインタフェース４２を介し入力を通信するようにしてもよい。さらに、ユーザは、開発ツール４８によってサポートされている先進的機能を利用して、同時性制約、タイムアウト制約及び同期エッジを生成するようにしてもよい。従って、開発ツール４８を利用して、ユーザは設計の仕様を生成するようにしてもよい。

さらに、ユーザは開発ツール４８にインタラクタコードを生成し、それをインタラクタコードデータベース５４に格納させるようにしてもよい。例えば、ユーザはインタラクタコードを生成するため、開発ツール４８の選択肢を選択するようにしてもよい。ユーザは、受信プロセスと送信プロセスを特定するよう促されてもよい。その後、開発ツール４８は、インタラクタコードを自動生成するようにしてもよい。ある実施例によると、インタラクタコードは、テスト対象装置１６の動作を検証するようテスト対象装置１６とやりとりする状態マシーンとして動作してもよい。インタラクタコードは、テスト対象装置１６との間のメッセージの送受信を行う時点を判断するため、１以上のシナリオを利用してもよい。

ユーザは、有向グラフのグラニュラーメッセージ図の関係に基づき、シナリオデータベース５６においてシナリオを開発ツール４８に特定及び格納させるようにしてもよい。１以上のシナリオが様々な方法によりメッセージ図を解析することによって決定されてもよい。シナリオはまた、有向グラフのすべてのエッジを追跡することによって決定されてもよい。代わりに、または加えて、開発ツール４８は、有向グラフのグラニュラーメッセージ図を示すユーザから受信した入力に基づき、シナリオを特定するようにしてもよい。例えば、有向パスを介し特定のパスを特定するユーザによってシナリオが生成されてもよい。シナリオはまた、有向グラフの２つのグラニュラーメッセージ図の間のすべてのパスを決定することに基づき特定されてもよい。さらに、２つのグラニュラーメッセージ図に含まれるメッセージのすべての可能な組み合わせを特定するため、２つのグラニュラーメッセージ図を構成することによって特定されてもよい。

解析モジュール５８は、テスト対象装置１６のパフォーマンスを解析するようにしてもよい。例えば、解析モジュール５８は、予想されない時点にテスト対象装置１６からメッセージが通信される時点を特定してもよい。解析モジュール５８はまた、メッセージが期待されるときに、テスト対象装置１６からメッセージが通信されない時点を特定してもよい。テスト対象装置１６の機能を利用して、解析モジュール５８は、テスト対象装置１６が有向グラフとグラニュラーメッセージ図によって表される仕様に従うものであるか判断してもよい。

従って検証装置１２の要素は、ハイレベルの抽象化において設計及び製品を検証するよう動作するようにしてもよい。ユーザは、開発ツール４８とやりとりして、有向グラフとグラニュラーメッセージ図を生成するようにしてもよい。開発ツール４８は、インタラクタコードを生成し、有向グラフとグラニュラーメッセージ図に基づきシナリオを特定してもよい。インタラクタコードは、ネットワークインタフェース４４を介しテスト対象装置１６とやりとりする状態マシーンとして動作するようにしてもよい。解析モジュール５８は、テスト対象装置１６が設計仕様に従っているか判断するためインタラクタコードとやりとりするとき、テスト対象装置１６によって通信されるメッセージを解析してもよい。

本例は検証装置１２の具体的機能コンポーネントを含んでいるが、検証装置１２は、ハイレベルの抽象化において設計及び製品を検証するため、列挙された機能コンポーネントの一部またはすべてを含むコンポーネントの任意の集まり及び構成を含むものであってもよい。さらに、検証装置１２は、ハードウェア及び／または論理の任意の適切な組み合わせ及び構成を用いて各機能コンポーネントを実現し、コンピュータ可読媒体に格納されているコンピュータプログラムを用いて何れかの機能を実現するよう構成される。さらに、検証装置１２は、スタンドアローン装置として実現されてもよいし、あるいは検証装置１２の特徴が各種装置に分散化されていてもよい。

図３Ａは、有向グラフ６０を示す。有向グラフ６０は、ＡＴＭカード及びＰＩＮ（Ｐｅｒｓｏｎａｌ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ）を用いてＡＴＭの将来的なユーザを認証するＡＴＭ（Ａｕｔｏｍａｔｉｃ Ｔｅｌｌｅｒ Ｍａｃｈｉｎｅ）の簡単化された記述を提供する。有向グラフ６０は、将来的なユーザを認証するためＡＴＭによって実行される複数の機能の関係を記述する。これら機能は、形状によって表されるグラニュラーメッセージ図によって規定される。図示されるように、これらの形状はボックスであってもよい。ボックスを接続する矢印は、機能が実行される順序を記述する。

有向グラフ６０は、各自がクエリボックス６４、プロシード（ｐｒｏｃｅｅｄ）ボックス６６及びターミネート（ｔｅｒｍｉｎａｔｅ）ボックス６８によって表される独立したグラニュラーメッセージ図によって規定される３つの機能を含む。開始ボックス６２は、エントリポイントを有向グラフ６０に提供する。従って、開始ボックス６２とクエリボックス６４の間の矢印は、クエリボックス６４に関連するグラニュラーメッセージ図が有向グラフ６０へのエントリ後に直面することを示す。クエリボックス６４により表されるグラニュラーメッセージ図に規定されるメッセージの通信後、プロシードボックス６６またはターミネートボックス６８の何れかに実行が継続される。

従って、有向グラフ６０は２つのシナリオを含む。１つのシナリオは、開始ボックス６２、クエリボックス６４及びプロシードボックス６６を介し進行するパスに関する。この第１のシナリオは、将来的なユーザによって提供されるＰＩＮを受付けるＡＴＭと関連付けされてもよい。他のシナリオは、開始ボックス６２、クエリボックス６４及びターミネートボックス６８を介しパスに進む。この第２のシナリオは、将来的なユーザによって提供されるＰＩＮを拒否するＡＴＭに関連付けされてもよい。従って、有向グラフ６０は、これら２つのシナリオがクエリボックス６４まで同じ動作を有するが、クエリボックス６４は異なっていることを示す。この情報は、２つのシナリオの共通部分が設計に関する有向グラフ６０を完全にテストするのに繰り返される必要はないため、検証及び検証目的に有用に利用されてもよい。

クエリボックス６４における有向グラフ６０のブランチは、非決定的なものであるかもしれないということに留意すべきである。言い換えると、有向グラフ６０は、クエリボックス６４の後にプロシードボックス６６とターミネートボックス６８の何れが選択されるべきか示すものでなくてもよい。しかしながら代わりに、より表現性の高いモデルが利用されてもよい。パスをアノテートし、実行中にどのパスが採用されるべきかより正確に記述するため、変数が利用されてもよい。例えば、決定的なモデル化を提供するため、グラニュラーメッセージ図の間の遷移に関連して、保護及び状態が利用されてもよい。

ここで、有向グラフ６０のボックスによって表される各グラニュラーメッセージ図は、同一のプロセス群を利用してもよいということに留意すべきである。さらに、あるグラニュラーメッセージ図によって規定される各メッセージが、次のグラニュラーメッセージ図をパスに沿って実行可能となる前に実行される必要があるということを求めるルールが、有向グラフ６０に関連して利用されてもよい。

図３Ｂは、クエリボックス６４に関するグラニュラーメッセージ図を示す。グラニュラーメッセージ図は、複数のプロセス及びメッセージの表示を含む。これらのプロセスは、ユーザインタフェース７０、ＡＴＭボックス７２及びデータベースボックス７４によって表される。各プロセスはまた、ユーザインタフェースライン７６、ＡＴＭライン７８及びデータベースライン８０を含むプロセスラインを含む。プロセスラインを相互接続する水平矢印は、メッセージがプロセス間で通信されることを示す。

各メッセージは、送信プロセスと受信プロセスを関連付けする。プロセスラインとメッセージが交差する位置は、イベントと呼ばれるかもしれない。このとき、各メッセージは送信プロセスに関連する送信イベントと、受信プロセスに関連する受信イベントを含む。例えば、メッセージ「ｉｎｓｅｒｔ＿ｃａｒｄ」は、ＡＴＭライン７８とユーザインタフェースライン７６を接続する。このため、メッセージ「ｉｎｓｅｒｔ＿ｃａｒｄ」は、ＡＴＭ及び送信プロセスとユーザインタフェース及び受信プロセスを関連付ける。さらに、メッセージ「ｉｎｓｅｒｔ＿ｃａｒｄ」のＡＴＭプロセスライン７８との交点は送信イベントを生成し、メッセージ「ｉｎｓｅｒｔ＿ｃａｒｄ」とユーザインタフェースプロセスライン７６との交点は受信イベントを生成する。

グラニュラーメッセージ図によって特定される関係をさらに理解するため、以下の２つのルールが理解されるべきである。
１．任意のメッセージｍに対して、送信イベント（ｓ（ｍ））は、対応する受信イベント（ｒ（ｍ））の前に発生する。従って、ｓ（ｍ）＜ｒ（ｍ）となる。
２．プロセスライン上のイベントは、上から下に順序付けされる。
これら２つのルールは、グラニュラーメッセージ図がプロセス間で通信されるメッセージの順序を記述することを示している。例えば、第１のルールを用いて、グラニュラーメッセージ図は、メッセージ「ｉｎｓｅｒｔ＿ｃａｒｄ」に関する送信イベントが同じメッセージに関する受信イベントの前に発生するということを要求するようグラニュラーメッセージ図は理解される。第２のルールを用いて、グラニュラーメッセージ図は、メッセージ「ｉｎｓｅｒｔ＿ｃａｒｄ」に関する送信イベントが、メッセージ「ｃａｒｄ＿ｉｎｓｅｒｔｅｄ」に関する受信イベントの前に発生するということを要求するよう理解される。

ここで、上記ルールは推移的であるということに留意されたい。例えば、イベントｅ１がイベントｅ２（ｅ１＜ｅ２）の前に発生し、イベントｅ２がイベントｅ３（ｅ２＜ｅ３）の前に発生する場合、イベントｅ１はイベントｅ３（ｅ１＜ｅ３）の前に発生する。しかしながら、これら２つのルールは、すべてのメッセージの間の順序付けされた関係を規定するものではないかもしれない。例えば、４つのプロセスを含むが、２つのメッセージしか含まないグラニュラーメッセージ図を考える。第１メッセージが第１プロセスと第２プロセスとの間で通信され、第２メッセージが第３プロセスと第４プロセスとの間で通信される場合、これら２つのメッセージの間の順序付けされた関係はこれら２つのルールによっては規定されないであろう。この場合、２つのメッセージは任意の順序で発生するかもしれない。

上述の順序付けルールを利用して、示されたグラニュラーメッセージ図をメッセージがｉｎｓｅｒｔ＿ｃａｒｄ、ｃａｒｄ＿ｉｎｓｅｒｔｅｄ、ＰＩＮ及びＰＩＮ＿ｖｅｒｉｆｙの順序で通信されることを要求するものとして解釈することができる。言い換えると、ＡＴＭはｉｎｓｅｒｔ＿ｃａｒｄメッセージをユーザインタフェースに送信する。ｉｎｓｅｒｔ＿ｃａｒｄメッセージの受信後、ユーザインタフェースは、ｃａｒｄ＿ｉｎｓｅｒｔｅｄメッセージをＡＴＭと通信する。ｃａｒｄ＿ｉｎｓｅｒｔｅｄメッセージの通信後、ユーザインタフェースはＰＩＮメッセージをＡＴＭと通信する。ＡＴＭボックス７２がＰＩＮメッセージを受信した後、ＡＴＭはＰＩＮ＿ｖｅｒｉｆｙメッセージをデータベースと通信する。ここに示される動作は、図示されたグラフに関して上述されたシナリオの両方に共通な動作である。

図３Ｃは、プロシードボックス６６に関するグラニュラーメッセージ図を示す。このグラニュラーメッセージ図は、クエリボックス６４に関するグラニュラーメッセージ図において用いられるのと同一のプロセスの表示であるユーザインタフェースボックス７０、ＡＴＭボックス及びデータベースボックス７４を含む。

上述の順序付けルールを利用して、グラニュラーメッセージ図をメッセージがＯＫ及びｍｅｎｕの順序で通信されることを要求するものとして解釈することができる。言い換えると、データベースは、ＯＫメッセージをＡＴＭと通信する。ＡＴＭがＯＫメッセージを受信した後、ＡＴＭはメッセージメニューをユーザインタフェースと通信する。

図３Ｄは、ターミネートボックス６８に関するグラニュラーメッセージ図を示す。このグラニュラーメッセージ図は、クエリボックス６４に関連するグラニュラーメッセージ図で用いられるのと同一のプロセスの表示であるユーザインタフェースボックス７０、ＡＴＭボックス７２及びデータベースボックス７４を含む。

上述の順序付けルールを利用して、グラニュラーメッセージ図をメッセージがｎｏｔ＿ＯＫ及びｒｅｊｅｃｔｅｄの順序で通信される必要があるものとして解釈することができる。言い換えると、データベースは、ｎｏｔ＿ＯＫメッセージをＡＴＭと通信する。ＡＴＭがｎｏｔ＿ＯＫメッセージを受信した後、ＡＴＭはｒｅｊｅｃｔｅｄメッセージをユーザインタフェースと通信する。

図４Ａは、有向グラフの確立、シナリオの特定及びインタラクタコードの生成を行うための環境を示す。ウィンドウ１００は、開発ツール４８によって生成されてもよい。ウィンドウ１００は、キャンバス１０２と共に複数のボタン及びメニューを有する。キャンバス１０２は、ユーザが有向グラフを構成するための領域を提供する。ボタン１２０及び１２２を含むウィンドウ１００の各種機能は、有向グラフの構成に関する情報を入力するため、ユーザによって操作されてもよい。さらに、ボタン１２４、１２６、１２８及び１３０は、有向グラフによって規定されるシナリオを開発ツール４８に特定させるようにユーザによって操作されてもよい。さらに、メニューオプション１３４は、インタラクタコードを生成するための選好を指定するのにユーザによって操作されてもよい。

キャンバス１０２において、ユーザは有向グラフを生成するかもしれない。ここで、図示されるようなボックス１０４は、有向グラフへのエントリポイントを特定するのに利用される開始ボックスである。ボックス１０４は、開発ツール４８によって自動的に生成され、各有向グラフのキャンバス１０２に表示される。図示されるように、キャンバス１０２は、ボックス１０６、１０８、１１０、１１２、１１４及び１１６により示されるグラニュラーメッセージ図の複数の表示を含む。グラニュラーメッセージ図のこれらの表示を生成するため、ユーザはボタン１２０を選択するようにしてもよい。ある実施例によると、ボタン１２０の選択は、ダイアログウィンドウにユーザによる生成されるグラニュラーメッセージ図の名前を促すものであってもよい。

ボックス１０６が生成された後、ボックス１０６はボックス１０４と接続されてもよい。例えば、ユーザはボタン１２２を選択してもよい。ボタン１２２を選択した後、ユーザはボックス１０４を、その後にボックス１０６をそれぞれ選択するようにしてもよい。この順序でこれら２つのボックスを選択した後、ボックス１０４からボックス１０６に矢印が描かれてもよい。矢印１１８を描くことによって、ユーザはボックス１０６の実行前に少なくとも１つのシナリオがボックス１０４の実行に関係していることを示す。同様の手続を利用して、キャンバス１０２に示される有向グラフなどの複雑な有向グラフが生成されてもよい。ここで、キャンバス１０２は、すべてのボックスがグラニュラーメッセージ図を表し、トップレベルのみが有向グラフとなる階層の１つのレベルを示している。しかしながら、平坦化されたメッセージ図を含む他の様々なタイプのメッセージ図が生成されてもよい。

グラニュラーメッセージ図を表すボックスの生成後、開発ツール４８はユーザにプロセス及び／またはグラニュラーメッセージ図に関するメッセージを規定するよう促すようにしてもよい。プロセス及びメッセージを規定するため、ユーザは編集のためキャンバス１０２に示されるグラニュラーメッセージ図の１つを選択するようにしてもよい。例えば、ユーザはキャンバス１０２のボックス１０６をダブルクリックするようにしてもよい。グラニュラーメッセージ図の構成に関するさらなる詳細が、以下において与えられる。

有向グラフが生成された後、ウィンドウ１００を用いてシナリオを特定し、特定されたシナリオに基づきインタラクタコードを生成するようにしてもよい。様々な方法を利用して、シナリオを特定し、ウィンドウ１００を用いてインタラクタコードを生成するようにしてもよい。例えば、ユーザはボタン１２４を選択し、有向グラフを介したパスの識別を含むファイルを特定する。このファイルは、グラニュラーメッセージ図に関するボックスを特定するものであってもよい。開発ツール４８は、当該ファイルを読み込み、示されたシナリオが有効であることを検証するようにしてもよい。シナリオが有効であると検証された後、開発ツール４８は、当該シナリオに基づきインタラクタコードを生成するようにしてもよい。上述のように、開発ツール４８は、テスト対象装置１６のテストにおいて検証装置１２によって利用されるインタラクタコードを生成するようにしてもよい。

他の例として、ユーザはボタン１２６を選択し、ユーザによる有向グラフを介したパスの特定を可能にするようにしてもよい。ある実施例によると、ボタン１２６及び／またはボタン１２８の選択は、開発ツール４８に有向グラフの２つのボックス間のすべての可能なパスを特定させるかもしれない。開発ツール４８は、これら特定されたシナリオに基づきインタラクタコードを生成するようにしてもよい。

開発ツール４８によって、シナリオが特定されてもよい。例えば、ユーザはボタン１２８を選択し、開発ツール４８に有向グラフを介し最適な経路を特定させるようにしてもよい。ある実施例によると、有向グラフを介した最適経路は有向グラフのエッジカバレッジを伴うものであってもよい。上述のように、エッジカバレッジは、有向グラフの郵便配達員の経路を特定する郵便配達員アルゴリズムの利用を伴うものであってもよい。郵便配達員の経路は、有向グラフの各エッジを少なくとも１回はカバーする。１つのシナリオが、郵便配達員の経路の要求を満足するものとして特定されるかもしれない。しかしながら、強連結有向グラフは長いシナリオを生成するであろうということに留意されたい。従って、郵便配達員の経路が特に複雑な有向グラフに対し長いものであるかもしれないので、開発ツール４８は郵便配達員シナリオがいくつかの構成単位に「切断」または分割されることを許容するかもしれない。例えば、郵便配達員シナリオは、パスにおいて再出現するグラニュラーメッセージ図に従って切断されてもよい。代わりに、または加えて、郵便配達員シナリオは、少なくとも最小数または最大数以下のグラニュラーメッセージ図が各構成要素シナリオにおいて特定されることを要求する制約を有する複数のシナリオに切断されてもよい。

郵便配達員アルゴリズムを図４Ａに示される有向グラフに適用することにより、以下のシナリオが特定されるかもしれない。

他のシナリオもまた各エッジを少なくとも１度は訪れるかもしれないが、このシナリオは各エッジが少なくとも１度訪問されるという要求を満足する最短シナリオである。ユーザが１つの長いシナリオを利用することを所望しない場合、このシナリオはいくつかのセクションに分割されてもよい。シナリオを分割する１つの論理的方法は、再出現するグラニュラーメッセージ図に関するシナリオを切断することである。例えば、Ｖ２はこの長いシナリオを４つの構成要素シナリオに切断するのに利用されるかもしれない。

より長い構成要素シナリオを生成するため、ユーザは切断処理がＶ２を用いて実行されると共に、各シナリオが少なくとも５つのグラニュラーメッセージ図を含むことを要求することができる。これらの制約を用いて、以下の２つの構成要素シナリオが特定されるかもしれない。

これらの方法を利用して生成されたシナリオはまた、インタラクタコードを生成するのに利用されてもよい。

シナリオを特定し、インタラクタコードを生成する他の方法は、ボタン１３０を選択するウィンドウ１００のユーザに関するものである。ボタン１３０の選択により、開発ツール４８は有向グラフのすべての可能なシナリオに対しインタラクタコードを特定及び生成するかもしれない。

シナリオの特定に加えて、開発ツール４８は、シナリオ干渉と呼ばれるものを実行するようにしてもよい。ここで、メッセージとグラニュラーメッセージ図は、上記特定された２つのルールからの演繹に基づき部分的に順序付けされた関係を有するということに留意されたい。これらのルールに従って順序付けされていないメッセージは、一実現形態において任意の順序で発生するかもしれない。例えば、２つのグラニュラーメッセージ図に含まれるメッセージのすべての可能な順序を特定するため、ユーザはこれら２つのグラニュラーメッセージ図に関する２つのボックスとボタン１３２を選択するようにしてもよい。これに応答して、開発ツール４８は、２つの開始されたグラニュラーメッセージ図のメッセージ間のすべての可能な順序付けされた関係を生成し、複数の新しいグラニュラーメッセージ図を生成するようにしてもよい。新しい各グラニュラーメッセージ図は、メッセージの可能な組み合わせを示すものであってもよい。設計者は、何れか可能な組み合わせが設計の実行に関する問題を生成するか判断するため、生成されたグラニュラーメッセージ図を解析するようにしてもよい。

これにより、ウィンドウ１００が開発ツール４８のユーザによって利用され、有向グラフを構成し、この有向グラフによって規定されるシナリオを特定し、これらのシナリオの少なくとも１つの基づきインタラクタコードを生成し、シナリオ干渉を実行するようにしてもよい。

図４Ｂは、設計及び製品の検証において用いられるインタラクタコードの生成に対する選好を指定するためのウィンドウを示す。ウィンドウ１４０は、送信プロセスを特定する領域１４２と、受信プロセスを特定する領域１４４とを含む。ある有向グラフが与えられると、開発ツール４８は有向グラフに指定されるシステムと通信する外部として機能するため、インタラクタコードを生成する。具体的には、何れかのシナリオに対して、インタラクタコードに従って動作する状態マシーンは、領域１４２において特定されるプロセスによって送信されるすべてのメッセージを受信し、領域１４４において特定されるプロセスによって受信されるすべてのメッセージを送信する。このように、状態マシーンは、テスト対象装置１６に対してメッセージを送受信することによって、テスト対象装置１６の動作を検証するかもしれない。テスト対象装置１６がシナリオによって特定されるグラニュラーメッセージ図に従ってメッセージを送信しない場合、エラーが生成及び平坦化されるかもしれない。解析モジュール５８は、テスト対象装置１６に不具合が存在するか判断するためエラーを解析してもよい。

ウィンドウ１４０は、ユーザがグラニュラーメッセージ図を特定するための領域１４６と、ユーザが切断長を特定するための領域１４８を含む。これらの入力は、シナリオを特定するとき、開発ツール４８によって利用されてもよい。上述のように、長いシナリオは領域１４６と１４８への入力に従って構成要素部分に切断または分割されてもよい。開発ツール４８は、領域１４６において特定されたノードにおいて長いシナリオを分けるかもしれない。さらに、切断リンクは構成要素シナリオの最小長を決定する領域１４８において特定されてもよい。

インタラクタコードの生成に関するファイルのディレクトリは、領域１５０と１５２を用いて特定されてもよい。例えば、領域１５０で指定されるディレクトリは、シナリオを特定するファイルを含むものであってもよい。さらに、インタラクタコードが格納されるディレクトリが、領域１５２において示されてもよい。

ユーザがウィンドウ１４０の適切な領域を記入すると、ユーザはボタン１２６を用いて選好を格納することを所望することを表示するようにしてもよい。ボタン１２８は、選好の格納を取消すのに利用されてもよい。

図４Ｃは、グラニュラーメッセージ図を確立するための環境を示す。ウィンドウ１６０は、開発ツール４８によって生成されてもよい。ウィンドウ１６０は、キャンバス１６２と共に複数のボタン及びメニューを含む。キャンバス１６２は、ユーザがグラニュラーメッセージ図を構成するための領域を提供する。ボタン１７２、１７４、１７６、１７８及び１８４を含むウィンドウ１６０の各種機能が、グラニュラーメッセージ図の構成に関する情報をユーザが入力するのに操作されてもよい。

キャンバス１６２では、ユーザは、グラニュラーメッセージ図を描くことが可能である。送信プロセス１６４、長距離受信プロセス１６６、受信プロセス１６８または長距離送信プロセス１７０などのプロセスを生成するため、ユーザはボタン１７２を選択するようにしてもよい。ボタン１７２の選択後、ダイアログボックスはユーザにプロセスの表示を生成する前に生成されるプロセスのラベルを要求するかもしれない。このため、キャンバス１２４に示されるプロセスを生成するため、ユーザはボタン１７２を４回選択し、示された名前により各プロセスを入力するようにしてもよい。開発ツール４８は、これらプロセスのグラフィカル表示を生成するようにしてもよい。図示されるように、一実施例はプロセス形状及び垂直プロセスラインを含む。しかしながら、各種表示を利用することが可能である。

ここで、何れか１つのグラニュラーメッセージ図にプロセスを含めることは、同じ有向グラフに含まれる他のグラニュラーメッセージ図において同一のプロセスを生成するかもしれないということに留意されたい。従って、これらのプロセスは、同一の有向グラフのグラニュラーメッセージ図に対し１度のみしか生成されなくてもよい。

これらのプロセスが生成された後、メッセージはプロセス間で通信されるものとして示されるかもしれない。メッセージの表示を描画するため、ユーザはボタン１７４を選択してもよい。ダイアログボックスは、図示されるメッセージの名前を受付け、ユーザは当該メッセージがどのプロセス間で通信されるか指定することが可能とされてもよい。例えば、ユーザは１つのプロセスを選択し、その後にポインティングツールを用いて第２のプロセスを選択するかもしれない。開発ツール４８は、送信イベントを有する第１プロセスと受信イベントを有する第２プロセスからなる示された２つのプロセスの間においてメッセージを生成するようにしてもよい。これにより、同様の技術を利用することにより、ｍｓ１〜ｍｓ１０の矢印が、グラニュラーメッセージ図に示されるプロセス間で通信されるｍｓ１〜ｍｓ１０の１０個のメッセージを表すよう生成されてもよい。

ここで、ボタン１７６はプロセスまたはメッセージを削除するのに利用されてもよい。例えば、ユーザは、メッセージの表示を選択し、選択されたメッセージを削除するのにボタン１７６を押下するかもしれない。同様に、ユーザはプロセスの表示を選択し、その後でボタン１７６を選択して選択したプロセスを削除するようにしてもよい。

上述のように、グラニュラーメッセージ図は、先進的な機能を有するようにしてもよい。例えば、ボタン１７８を用いることにより生成されるグラニュラーメッセージ図に制約が追加されてもよい。ある実施例によると、イベントをグループ化するためボックスがプロセスライン上に示されてもよい。あるボックスに含まれるイベントは、当該イベントが同時に発生すべきであると示すかもしれない。従って、ボタン１７８の選択後、ユーザはイベントを包囲するボックスを描画し、このボックスがこれらのイベントを同時イベントにグループ化することを示すため、当該ボックスを「ｓｉｍｕｌ」とラベル付けするようにしてもよい。図示されるように、同時性制約１８０は、図示されたグラニュラーメッセージ図に含まれていた。同時性制約１８０ａは、メッセージｍｓ３とｍｓ４に関する送信イベントをグループ化し、同時性制約１８０ｂは、メッセージｍｓ８とｍｓ９に関する受信イベントをグループ化する。

ボタン１７８はまた、タイムアウトを生成するのに利用されてもよい。実行がタイムアウト制約に直面すると、示されたタイムアウト期間が経過するまで実行が停止されてもよい。時限実行モデルでは、タイムアウト期間が経過して始めて実行が継続する。非時限実行モデルでは、タイムアウト制約は機能を示さない。タイムアウトを特定するため、制約の名前に対して整数が与えられるという点を除いて、ユーザは同時性制約を与えるのと同様のステップに従うかもしれない。この整数はタイムアウト値を表すであろう。ある実施例によると、ボックスがプロセスライン上に描画され、タイムアウトを示す数値によりラベル付けされるかもしれない。従ってボタン１７８を選択した後、ユーザはイベントを包囲するボックス、またはプロセスライン上のボックスを描き、当該ボックスにタイムアウトイベントの発生を示す数値によりラベル付けするようにしてもよい。図示されるように、タイムアウト制約１８２は、図示されたグラニュラーメッセージ図に含まれた。タイムアウト制約１８２ａが長さ２０のタイムアウトを示す一方、タイムアウト制約１８２ｂは長さ６のタイムアウトを示す。ここで、ユーザはタイムアウト制約１８２により利用される値と関連付けするための時間単位を指定するようにしてもよい。

タイムアウト制約と同時性制約が、タイムアウト制約に対するメッセージを生成することにより合成されてもよい。タイムアウトボックスのメッセージイベントが、タイムアウト期間の完了により同時発生する。例えば、タイムアウト制約１８２ｂは、受信プロセス１６８の受信イベントと一致する。従って、メッセージｍｓ７は、タイムアウト制約１８２ｂのラベルに指定された長さ６のタイムアウトの経過後まで受信プロセス１６８によって受信されないであろう。

ここで、制約ボックスを削除するため、ユーザは削除対象の制約ボックスを選択し、削除制約１８４を選択するようにしてもよい。このプロセスは、タイムアウト制約と同時性制約の両方に対して利用されてもよい。

イベントが共通のプロセスまたは共通のプロセスに関する遷移的な関係を介したプロセスを有するとき、順序付けされた関係を受信する。例えば、送信モジュールと受信モジュールがメッセージを通信しないが、グラニュラーメッセージ図によって規定される通信動作のすべてが外部とのものであるグラニュラーメッセージ図を考える。この場合、グラニュラーメッセージ図は、入力メッセージが出力メッセージとコンカレントであり、順序付けされた関係が設計によって課されないことを示す。

メッセージの順序を特定するため、同期エッジが利用されてもよい。同期エッジの表示は、名前「ｓｙｎｃｈ」が同期エッジに利用可能であるというという点を除いて、メッセージと同様に描かれてもよい。「ｓｙｎｃｈ」とラベル付けされたメッセージを利用して、推移的演繹を介し順序付けされた関係を確立してもよい。例えば、受信プロセス１６８に関する送信イベントと、送信プロセス１６４に関する受信イベントを含む同期エッジ１８６を考える。同期メッセージ１８６は、受信プロセス１６８がメッセージｍｓ６を受信した後に送信されるものとして示される。同期メッセージ１８６はまた、メッセージｍｓ３とｍｓ４が送信されるまでに送信プロセス１６４により受信されるものとして示される。従って推移的演繹を利用して、グラニュラーメッセージ図によると、プロセス１６８におけるメッセージｍｓ６の受信は、プロセス１６４におけるメッセージｍｓ３とｍｓ４の送信前に発生する必要がある。ここで、同期エッジは関連性のないプロセス間の関係を生成するようにしてもよい。しかしながら、ある実施例によると、同期エッジによって関連するプロセス間において実際にメッセージは通信されないかもしれない。同期メッセージ１８６は、メッセージｍｓ５とｍｓ６と比較して、メッセージｍｓ１とｍｓ２との間の順序を生成するものではない。しかしながら、同期メッセージ１８６は、メッセージｍｓ５とｍｓ６に関する受信イベントの後にメッセージｍｓ３とｍｓ４に関する送信イベントを発生させる。同期メッセージ１８６はまた、メッセージｍｓ７とｍｓ２との間の順序付けされた関係を実行するものでない。これらのメッセージの間の順序付けされた関係を実行するため、同期エッジ１８６は、プロセス１６４からプロセス１６８に指示されるべきである。

従って、ウィンドウ１００のグラニュラーメッセージ図は、同時性制約１８０、タイムアウト制約１８２及び同期エッジ１８６の３つの先進的機能を含む。

図５Ａは、グラニュラーメッセージ図２００を示す。グラニュラーメッセージ図２００を用いて、インタラクタコードを生成する一方法を示す。有向グラフをインタラクタコードに変換するため、有向グラフの各グラニュラーメッセージ図によって規定されるイベントを用いて、有限状態マシーンの状態を特定するようにしてもよい。グラニュラーメッセージ図は可能なイベント順序を規定し、各プロセスにおいて完了されたイベントは状態に対応する。例えば、初期状態は何れのプロセスにおいても完了されないイベントに対応する。最終状態は、各プロセスにおいて完了したすべてのイベントに対応する。

ここで、グラニュラーメッセージ図２００を検討すると、グラニュラーメッセージ図２００の一部がプロセスの一部のイベント群を考慮することによって有限状態マシーンに投影される。例えば、グラニュラーメッセージ図２００では、有限状態マシーンが送信プロセス２０２と受信プロセス２０４に対して生成されてもよい。図示されるように、送信プロセス２０２はイベントｓ１〜ｓ５を有し、受信プロセス２０４は、イベントｒ１〜ｒ６を有する。ここで、送信プロセス２０２と受信プロセス２０４は、メッセージを交換することなく、２つの同期エッジによって関連付けされる。

図５Ｂは、グラニュラーメッセージ図２００に関連する状態マトリックス２２０を示す。状態マトリックス２２０を利用して、インタラクタコードの生成方法をさらに説明する。２つのみしかプロセスがない場合、グラニュラーメッセージ図２００の状態マシーンは、２次元の状態マトリックスとして可視化することができる。状態マトリックス２２０の各ボックスは、送信プロセス２０２がイベントｓ_ｉを終了させ、受信プロセス２０４がイベントｒ_ｊを終了させた状態に対応している。このため、状態マトリックス２２０の各ボックスは、状態（ｓ_ｉ，ｒ_ｊ）を規定する。ここで、状態マトリックス２２０の原点は、初期状態が記号⊥を用いて各プロセスに対して示される左上隅である。状態マトリックス２２０の左上隅が初期状態であるため、状態遷移は各状態から右下にトレースすることによって特定されるかもしれない。最終状態は、右下隅となるであろう。

送信プロセス２０２と受信プロセス２０４が２つの同期エッジによっては関連付けされていない場合、状態マトリックス２２０は、ｎ×ｍの完全な２次元の状態マトリックスとなるであろう（ただし、ｎは送信プロセス２０２により送信されるメッセージの個数であり、ｍは受信プロセス２０４によって受信されるメッセージの個数である）。しかしながら、グラニュラーメッセージ図２００の同期エッジの存在は、状態マトリックス２２０に示されるような有効な状態の個数を減少させる。同期エッジにより、状態マトリックス２２０に示される一部の状態は有効とはならず、２次元マトリックスから「クロスアウト（ｃｒｏｓｓ ｏｕｔ）」させることが可能である。例えば、イベントｓ３が送信プロセス２０２から受信プロセス２０４への同期エッジに対応する送信イベントであると仮定する。イベントｒ３は、同一の同期エッジに関連する対応する受信イベントである。受信イベントｒ２の後に発生する受信プロセス２０４における何れのイベントも、イベントｓ３の後に発生する必要がある。従って、イベントｒ３〜ｒ６はイベントｓ３の前に発生することはできない。このプロセスを利用して、無効状態に対応する状態マトリックス２２０の領域２２２は、クロスアウトされるかもしれない。同様のプロセスを用いて、グラニュラーメッセージ図２００の第２同期エッジに関連する領域２２４をクロスアウトしてもよい。残りのマトリックスは、グラニュラーメッセージ図２００を正確に表す。ｓ_２やｒ_１などの状態は、送信プロセス２０２が送信イベントｓ_２を終了させ、受信プロセス２０４が受信イベントｒ_１を終了させた状態を表す。

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

有限状態マシーンを実現するため、インタラクタコードがＶｅｒｉｌｏｇなどの言語により生成されてもよい。インタラクタコードを生成するため、送信プロセス２０２と受信プロセス２０４の役割が逆転されてもよい。言い換えると、当該動作がメッセージの受け取りを求める場合、インタラクタコードはメッセージを送信すべきである。当該動作がメッセージの送信を求める場合、インタラクタコードはメッセージを待機するべきである。簡単化された状態図２６０の各水平遷移は、メッセージの受信に対応し、このためインタラクタコードによるメッセージの送信として実現される。同様に、簡単化された状態図２６０の各垂直遷移は、メッセージの送信に対応し、このため、インタラクタコードのメッセージの受信待機として実現される。

現在状態が簡単化された状態図２６０の水平遷移と垂直遷移の両方が行われうる状態（ｉ，ｊ）であるとき、水平遷移は適切なメッセージを送信することにより行われ、その後、垂直遷移が予想されるメッセージが受信されたか判断することによって試行されるようにしてもよい。後者の状態が満たされる場合、垂直遷移が行われてもよく、次の状態は状態（ｉ＋１，ｊ＋１）となる。後者の状態が満たされていない場合、水平遷移のみが行われ、次の状態は（ｉ＋１，ｊ）となる。プロセスが永久に待機することがないように、メッセージの受信待機中にタイマが利用されてもよい。言い換えると、適切なタイムアウト期間後に待機は終了されるようにしてもよい。垂直または水平のみの遷移しかある状態から行うことができない場合、これらの動作のみが生成されるようにしてもよい。

遷移方向が生成可能なインタラクタコードに影響する１つの変数である一方、他の変数はある状態に関する特定のタイプのイベントである。送信プロセス２０２と受信プロセス２０４において、プロセスラインに関連する各イベントは３つのタイプのうちの１つである。送信プロセス２０２では、これらのタイプはメッセージ送信イベント、タイマ始動イベント及びタイムアウト信号受信イベントである。受信プロセス２０４では、これらのタイプは、メッセージ受信イベント、タイマ始動イベント及びタイムアウト信号受信イベントである。各プロセスのこれら３つのタイプのイベントは、有限状態マシーンの各状態に対して生成されるコードが当該状態の正確な組み合わせに依存するため、コード生成中に考慮される９つの組み合わせを生じさせる。

これらの技術を利用して、インタラクタコードがグラニュラーメッセージ図に対して生成されてもよい。シナリオは有向グラフの単なるパスであることに留意されたい。シナリオに対するインタラクタコードを生成するため、コードがパスに沿って各グラニュラーメッセージ図に対して生成され、必要に応じて合成されるようにしてもよい。例えば、１つのグラニュラーメッセージ図の終わりの次の状態は、パスに沿った次のグラニュラーメッセージ図の開始状態となるべきである。信号及び変数宣言のすべてを組み合わせることによって、インタラクタコードが手動介入されることなくテスト対象装置１６に対して生成、編集及びシミュレートすることが可能である。

図６は、１以上のグラニュラーメッセージ図を有する有向グラフを構成するための方法２８０を示すフローチャートである。ステップ２８２において、検証装置１２は開発ツール４８をロードする。ステップ２８４において、開発ツール４８は新しい有向グラフを開く。ステップ２８６において、開発ツール４８は、ユーザが第１のグラニュラーメッセージ図を生成するよう指示したか判断する。

ユーザがグラニュラーメッセージ図を生成するよう指示すると、ステップ２８８において、ユーザはプロセスの表示を生成することを許可される。ステップ２９０において、ユーザはメッセージを用いてプロセスの表示をリンクさせるようにしてもよい。さらにステップ２９４において、ユーザは必要に応じて同期エッジを生成してもよい。ステップ２９６において、開発ツール４８は、ユーザが他のグラニュラーメッセージ図を生成することを所望しているか判断する。ユーザが他のグラニュラーメッセージ図を生成することを所望している場合、方法２８０はステップ２９０に戻る。

さらなるグラニュラーメッセージ図が生成されない場合、ステップ２９８において、ユーザはグラニュラーメッセージ図の表示をリンクさせる。例えば、グラニュラーメッセージ図の表示を互いに接続する矢印が生成されてもよい。これらの矢印は、グラニュラーメッセージ図に示される通信の可能な実行の順序を示す。ステップ３００において、開発ツール４８は、有向グラフとグラニュラーメッセージ図を含むプロジェクトファイルを保存してもよい。

これにより、方法２８０はハイレベルの抽象化における設計またはプロジェクトの検証に用いられるメッセージ図を生成するのに実行される各ステップの一実施例を示す。

図７は、有向グラフと１以上のグラニュラーメッセージ図を使用した設計の一実現形態を検証するための方法３２０を示すフローチャートである。ステップ３２２において、検証装置１２は開発ツール４８をロードする。ステップ３２４において、開発ツール４８は、完成された有向グラフとグラニュラーメッセージ図に関するプロジェクトファイルをロードする。

ステップ３２６において、ユーザは送信プロセスの役割を実行するプロセスを特定する。同様に、ステップ３２８において、ユーザは受信プロセスの役割を実行するプロセスを特定する。送信及び受信プロセスを特定することによって、ユーザはメッセージ図に指定されるシステムと通信するための外部として機能するプロセスを特定する。

ステップ３３０において、開発ツール４８は１以上のシナリオを決定する。例えば、開発ツール４８は、郵便配達員アルゴリズムを利用して、有向グラフのすべてのエッジをカバーするシナリオを特定してもよい。代わりに、または加えて、有向グラフの２つのグラニュラーメッセージ図を特定するユーザと、これら２つの特定されたグラニュラーメッセージ図の間のすべてのシナリオを決定する開発ツール４８によって、シナリオが生成されてもよい。さらに、ユーザは、有向グラフを介しパスを特定することによってシナリオを特定してもよい。他の例として、開発ツール４８は、有向グラフが与えられたとき、可能なすべてのシナリオを特定してもよい。

ステップ３３２において、開発ツール４８は特定されたシナリオを利用して、テスト対象装置１６を検証するためのインタラクタコードを生成する。上述のように、インタラクタコードは、テスト対象装置１６とやりとりする状態マシーンとして機能するかもしれない。ある実施例では、テスト対象装置１６は、製造されたハードウェアまたはソフトウェアプロダクツであってもよい。従って、インタラクタコードは、有向グラフとグラニュラーメッセージ図に従って製造された製品とやりとりするよう試みてもよい。あるいは、テスト対象装置１６は、インタラクタコード自体であってもよい。言い換えると、インタラクタコードは、設計がロウバストであるか判断するため、それの他のコピーと通信するよう試みてもよい。同様の方法により、設計の他の様々な実現形態がテストされるかもしれない。

ステップ３３４において、検証装置１２はインタラクタコードを利用して設計の一実現形態をテストする。有向グラフとグラニュラーメッセージ図に従って、メッセージが実現形態と通信されてもよい。また、メッセージは実現形態から受信されてもよい。ステップ３３６において、解析モジュール５８がテスト結果を解析する。解析には、有向グラフとグラニュラーメッセージ図に従って当該実現形態が通信に失敗した時点を決定することが含まれるかもしれない。ステップ３３８において、テスト結果と当該テスト結果の解析が出力されてもよい。例えば、テスト結果と解析は、さらなる解析のため開発ツール４８によってユーザに出力されてもよい。

方法３２０は、ハイレベルの抽象化における設計またはプロジェクトを検証するのに実行可能な各ステップの一実施例を示す。この設計の一実現形態は、有向グラフとグラニュラーメッセージ図に記録されている仕様に従って、当該実現形態がメッセージを通信するか解析することによりテストされてもよい。

上記フローチャートは、ハイレベルの抽象化における設計及び製品を検証するのに利用される方法を示す。しかしながら、これらのフローチャートは、単なる一例となる処理方法を示すものであり、本発明は上記機能を実行するのに適した任意の技術、要素及びアプリケーションを想定する。従って、フローチャートの各ステップの多くは、同時に及び／または図示されるものとは異なる順序により実行されてもよい。さらに、本方法が適切なものである限り、本方法は追加されたステップまたはより少数のステップを含むようにしてもよい。

本発明がいくつかの実施例により説明されたが、多数の改良及び変形が当業者には想到されるかもしれず、本発明はそのような改良及び変形を添付された請求項の範囲内のものとして包含する。
（付記１）
設計のハイレベルな検証のための方法であって、
設計に関する入力を受信するステップと、
前記入力に応答して、複数のプロセス間で通信されるメッセージの関係を記述するメッセージ図を生成するステップと、
前記メッセージ図から該メッセージ図により特定されるメッセージのシーケンスからなる少なくとも１つのシナリオを決定するステップと、
前記シナリオに従って前記メッセージ図により特定される前記メッセージの少なくとも一部を送受信するよう動作可能な状態マシーンを生成するステップと、
前記状態マシーンを利用して前記設計の実現形態をテストするステップと、
から構成されることを特徴とする方法。
（付記２）
付記１記載の方法であって、
前記メッセージ図は、前記プロセス間で通信されるメッセージの関係を示すグラフィカル表示から構成されることを特徴とする方法。
（付記３）
付記１記載の方法であって、
前記メッセージ図は、
複数のグラニュラーメッセージ図の間の関係を記述する有向グラフと、
各々が前記メッセージ図に記述される前記メッセージの一部の関係を記述する複数のグラニュラーメッセージ図と、
から構成されることを特徴とする方法。
（付記４）
付記３記載の方法であって、さらに、
２つのグラニュラーメッセージ図を接続する前記有向グラフの各エッジを少なくとも１回巡回する前記メッセージ図を介したパスを特定するステップと、
前記パスに基づき前記シナリオを決定するステップと、
を有することを特徴とする方法。
（付記５）
付記３記載の方法であって、さらに、
第１グラニュラーメッセージ図と第２グラニュラーメッセージ図との間のすべてのパスを特定するステップと、
特定された各パスに対してシナリオを決定するステップと、
を有することを特徴とする方法。
（付記６）
付記３記載の方法であって、さらに、
前記メッセージ図を介したパスの識別を受信するステップと、
前記特定されたパスに基づき前記シナリオを決定するステップと、
を有することを特徴とする方法。
（付記７）
付記３記載の方法であって、さらに、
２つのグラニュラーメッセージ図を特定するステップと、
前記２つのグラニュラーメッセージ図のメッセージ間の順序付けされた関係に基づき、前記２つのグラニュラーメッセージ図の可能なすべての組み合わせを生成するステップと、
を有することを特徴とする方法。
（付記８）
付記１記載の方法であって、さらに、
前記入力に応答して、複数のイベントがある期間内に発生することを要求する同時性制約を生成するステップを有することを特徴とする方法。
（付記９）
付記１記載の方法であって、さらに、
前記入力に応答して、実行がある期間停止することを要求するタイムアウト制約を生成するステップを有することを特徴とする方法。
（付記１０）
付記１記載の方法であって、さらに、
前記入力に応答して、順序付けされていないメッセージの間の順序を確立する同期エッジ表示を生成するステップを有することを特徴とする方法。
（付記１１）
付記１記載の方法であって、
前記実現形態は、製造された製品から構成され、
前記実現形態をテストするステップは、
前記状態マシーンと前記製造された製品を接続するステップと、
前記シナリオに従って前記製造された製品とのやりとりを試行するステップと、
から構成されることを特徴とする方法。
（付記１２）
付記１記載の方法であって、
前記実現形態は、前記シナリオに従って前記メッセージ図によって特定される前記メッセージの少なくとも一部を送受信するよう動作可能な第２の状態マシーンから構成され、
前記実現形態をテストするステップは、
前記状態マシーンと前記第２の状態マシーンを接続するステップと、
前記シナリオに従って前記第２の状態マシーンとのやりとりを試行するステップと、
から構成されることを特徴とする方法。
（付記１３）
付記１記載の方法であって、
前記入力は、マウス及びキーボードにより生成される表示系列から構成されることを特徴とする方法。
（付記１４）
設計のハイレベルな検証のための装置であって、
設計に関する入力を受信するよう動作可能なユーザインタフェースと、
前記入力に応答して、複数のプロセス間で通信されるメッセージの関係を記述するメッセージ図を生成し、前記メッセージ図から該メッセージ図により特定されるメッセージのシーケンスからなる少なくとも１つのシナリオを決定し、前記シナリオに従って前記メッセージ図により特定される前記メッセージの少なくとも一部を送受信するよう動作可能な状態マシーンを生成し、前記状態マシーンを利用して前記設計の実現形態をテストするよう動作可能なコントローラと、
から構成されることを特徴とする装置。
（付記１５）
付記１４記載の装置であって、
前記メッセージ図は、前記プロセスと前記メッセージとの関係を示すグラフィカル表示から構成されることを特徴とする装置。
（付記１６）
付記１４記載の装置であって、
前記メッセージ図は、
複数のグラニュラーメッセージ図の間の関係を記述する有向グラフと、
各々が前記メッセージ図に記述される前記メッセージの一部の関係を記述する複数のグラニュラーメッセージ図と、
から構成されることを特徴とする装置。
（付記１７）
付記１６記載の装置であって、
前記コントローラはさらに、２つのグラニュラーメッセージ図を接続する前記有向グラフの各エッジを少なくとも１回巡回する前記メッセージ図を介したパスを特定し、前記パスに基づき前記シナリオを決定するよう動作可能であることを特徴とする装置。
（付記１８）
付記１６記載の装置であって、
前記コントローラはさらに、第１グラニュラーメッセージ図と第２グラニュラーメッセージ図との間のすべてのパスを特定し、特定された各パスに対してシナリオを決定するよう動作可能であることを特徴とする装置。
（付記１９）
付記１６記載の装置であって、
前記コントローラはさらに、前記メッセージ図を介したパスの識別を受信し、前記特定されたパスに基づき前記シナリオを決定するよう動作可能であることを特徴とする装置。
（付記２０）
付記１６記載の装置であって、
前記コントローラはさらに、２つのグラニュラーメッセージ図を特定し、前記２つのグラニュラーメッセージ図のメッセージ間の順序付けされた関係に基づき、前記２つのグラニュラーメッセージ図の可能なすべての組み合わせを生成するよう動作可能であることを特徴とする装置。
（付記２１）
付記１４記載の装置であって、
前記コントローラはさらに、前記入力に応答して、複数のイベントがある期間内に発生することを要求する同時性制約を生成するよう動作可能であることを特徴とする装置。
（付記２２）
付記１４記載の装置であって、
前記コントローラはさらに、前記入力に応答して、実行がある期間停止することを要求するタイムアウト制約を生成するよう動作可能であることを特徴とする装置。
（付記２３）
付記１４記載の装置であって、
前記コントローラはさらに、前記入力に応答して、順序付けされていないメッセージの間の順序を確立する同期エッジ表示を生成するよう動作可能であることを特徴とする装置。
（付記２４）
付記１４記載の装置であって、
前記実現形態は、製造された製品から構成され、
前記実現形態のテストは、前記状態マシーンと前記製造された製品を接続し、前記シナリオに従って前記製造された製品とのやりとりを試行することから構成されることを特徴とする装置。
（付記２５）
付記１４記載の装置であって、
前記実現形態は、前記シナリオに従って前記メッセージ図によって特定される前記メッセージの少なくとも一部を送受信するよう動作可能な第２の状態マシーンから構成され、
前記実現形態のテストは、前記状態マシーンと前記第２の状態マシーンを接続し、前記シナリオに従って前記第２の状態マシーンとのやりとりを試行することから構成されることを特徴とする装置。
（付記２６）
付記１４記載の装置であって、
前記入力は、マウス及びキーボードにより生成される表示系列から構成されることを特徴とする装置。
（付記２７）
設計のハイレベルな検証のための論理であって、
当該論理は、メディアに符号化され、実行時に、
設計に関する入力を受信するステップと、
前記入力に応答して、複数のプロセス間で通信されるメッセージの関係を記述するメッセージ図を生成するステップと、
前記メッセージ図から該メッセージ図により特定されるメッセージのシーケンスからなる少なくとも１つのシナリオを決定するステップと、
前記シナリオに従って前記メッセージ図により特定される前記メッセージの少なくとも一部を送受信するよう動作可能な状態マシーンを生成するステップと、
前記状態マシーンを利用して前記設計の実現形態をテストするステップと、
を動作可能であることを特徴とする論理。
（付記２８）
付記２７記載の論理であって、
前記メッセージ図は、前記プロセス間で通信されるメッセージの関係を示すグラフィカル表示から構成されることを特徴とする論理。
（付記２９）
付記２７記載の論理であって、
前記メッセージ図は、
複数のグラニュラーメッセージ図の間の関係を記述する有向グラフと、
各々が前記メッセージ図に記述される前記メッセージの一部の関係を記述する複数のグラニュラーメッセージ図と、
から構成されることを特徴とする論理。
（付記３０）
付記２９記載の論理であって、実行時にさらに、
２つのグラニュラーメッセージ図を接続する前記有向グラフの各エッジを少なくとも１回巡回する前記メッセージ図を介したパスを特定するステップと、
前記パスに基づき前記シナリオを決定するステップと、
を動作可能であることを特徴とする論理。
（付記３１）
付記２９記載の論理であって、実行時にさらに、
第１グラニュラーメッセージ図と第２グラニュラーメッセージ図との間のすべてのパスを特定するステップと、
特定された各パスに対してシナリオを決定するステップと、
を動作可能であることを特徴とする論理。
（付記３２）
付記２９記載の論理であって、実行時にさらに、
前記メッセージ図を介したパスの識別を受信するステップと、
前記特定されたパスに基づき前記シナリオを決定するステップと、
を動作可能であることを特徴とする論理。
（付記３３）
付記２９記載の論理であって、実行時にさらに、
２つのグラニュラーメッセージ図を特定するステップと、
前記２つのグラニュラーメッセージ図のメッセージ間の順序付けされた関係に基づき、前記２つのグラニュラーメッセージ図の可能なすべての組み合わせを生成するステップと、
を動作可能であることを特徴とする論理。
（付記３４）
付記２７記載の論理であって、実行時にさらに、
前記入力に応答して、複数のイベントがある期間内に発生することを要求する同時性制約を生成するステップを動作可能であることを特徴とする論理。
（付記３５）
付記２７記載の論理であって、実行時にさらに、
前記入力に応答して、実行がある期間停止することを要求するタイムアウト制約を生成するステップを動作可能であることを特徴とする論理。
（付記３６）
付記２７記載の論理であって、実行時にさらに、
前記入力に応答して、順序付けされていないメッセージの間の順序を確立する同期エッジ表示を生成するステップを動作可能であることを特徴とする論理。
（付記３７）
付記２７記載の論理であって、
前記実現形態は、製造された製品から構成され、
前記実現形態をテストするステップは、
前記状態マシーンと前記製造された製品を接続するステップと、
前記シナリオに従って前記製造された製品とのやりとりを試行するステップと、
から構成されることを特徴とする論理。
（付記３８）
付記２７記載の論理であって、
前記実現形態は、前記シナリオに従って前記メッセージ図によって特定される前記メッセージの少なくとも一部を送受信するよう動作可能な第２の状態マシーンから構成され、
前記実現形態をテストするステップは、
前記状態マシーンと前記第２の状態マシーンを接続するステップと、
前記シナリオに従って前記第２の状態マシーンとのやりとりを試行するステップと、
から構成されることを特徴とする論理。
（付記３９）
付記２７記載の論理であって、
前記入力は、マウス及びキーボードにより生成される表示系列から構成されることを特徴とする論理。
（付記４０）
設計のハイレベルな検証のためのシステムであって、
設計に関する入力を受信する手段と、
前記入力に応答して、複数のプロセス間で通信されるメッセージの関係を記述するメッセージ図を生成する手段と、
前記メッセージ図から該メッセージ図により特定されるメッセージのシーケンスからなる少なくとも１つのシナリオを決定する手段と、
前記シナリオに従って前記メッセージ図により特定される前記メッセージの少なくとも一部を送受信するよう動作可能な状態マシーンを生成する手段と、
前記状態マシーンを利用して前記設計の実現形態をテストする手段と、
から構成されることを特徴とするシステム。
（付記４１）
付記４０記載のシステムであって、
前記メッセージ図は、前記プロセス間で通信されるメッセージの関係を示すグラフィカル表示から構成されることを特徴とするシステム。
（付記４２）
付記４０記載のシステムであって、
前記メッセージ図は、
複数のグラニュラーメッセージ図の間の関係を記述する有向グラフと、
各々が前記メッセージ図に記述される前記メッセージの一部の関係を記述する複数のグラニュラーメッセージ図と、
から構成されることを特徴とするシステム。
（付記４３）
付記４２記載のシステムであって、さらに、
２つのグラニュラーメッセージ図を接続する前記有向グラフの各エッジを少なくとも１回巡回する前記メッセージ図を介したパスを特定する手段と、
前記パスに基づき前記シナリオを決定する手段と、
を有することを特徴とするシステム。
（付記４４）
付記４２記載のシステムであって、さらに、
第１グラニュラーメッセージ図と第２グラニュラーメッセージ図との間のすべてのパスを特定する手段と、
特定された各パスに対してシナリオを決定する手段と、
を有することを特徴とするシステム。
（付記４５）
付記４２記載のシステムであって、さらに、
前記メッセージ図を介したパスの識別を受信する手段と、
前記特定されたパスに基づき前記シナリオを決定する手段と、
を有することを特徴とするシステム。
（付記４６）
付記４２記載のシステムであって、さらに、
２つのグラニュラーメッセージ図を特定する手段と、
前記２つのグラニュラーメッセージ図のメッセージ間の順序付けされた関係に基づき、前記２つのグラニュラーメッセージ図の可能なすべての組み合わせを生成する手段と、
を有することを特徴とするシステム。
（付記４７）
付記４０記載のシステムであって、さらに、
前記入力に応答して、複数のイベントがある期間内に発生することを要求する同時性制約を生成する手段を有することを特徴とするシステム。
（付記４８）
付記４０記載のシステムであって、さらに、
前記入力に応答して、実行がある期間停止することを要求するタイムアウト制約を生成する手段を有することを特徴とするシステム。
（付記４９）
付記４０記載のシステムであって、さらに、
前記入力に応答して、順序付けされていないメッセージの間の順序を確立する同期エッジ表示を生成する手段を有することを特徴とするシステム。
（付記５０）
付記４０記載のシステムであって、
前記実現形態は、製造された製品から構成され、
前記実現形態をテストする手段は、
前記状態マシーンと前記製造された製品を接続する手段と、
前記シナリオに従って前記製造された製品とのやりとりを試行する手段と、
から構成されることを特徴とするシステム。
（付記５１）
付記４０記載のシステムであって、
前記実現形態は、前記シナリオに従って前記メッセージ図によって特定される前記メッセージの少なくとも一部を送受信するよう動作可能な第２の状態マシーンから構成され、
前記実現形態をテストする手段は、
前記状態マシーンと前記第２の状態マシーンを接続する手段と、
前記シナリオに従って前記第２の状態マシーンとのやりとりを試行する手段と、
から構成されることを特徴とするシステム。
（付記５２）
付記４０記載のシステムであって、
前記入力は、マウス及びキーボードにより生成される表示系列から構成されることを特徴とするシステム。

設計及び製品のハイレベルな検証のための検証装置を有するテストシステムを示す。 検証装置の一例となる機能コンポーネントを示すブロック図である。 複数のグラニュラーメッセージ図を含む有向グラフを示す。 複数のプロセス及びメッセージを含むグラニュラーメッセージ図を示す。 複数のプロセス及びメッセージを含む第２のグラニュラーメッセージ図を示す。 複数のプロセス及びメッセージを含む第３のグラニュラーメッセージ図を示す。 有向グラフを構成する環境を示す。 設計及び製品の検証に利用されるインタラクタコードを生成するための選好を指定するためのウィンドウを示す。 グラニュラーメッセージ図を構成する環境を示す。 グラニュラーメッセージ図を示す。 状態マトリックスを示す。 状態図を示す。 簡単化された状態図を示す。 １以上のグラニュラーメッセージ図を有する有向グラフを構成するための方法を示すフローチャートである。 １以上のグラニュラーメッセージ図と有向グラフを利用した設計の一実現形態を検証するための方法を示すフローチャートである。

符号の説明

１０ テストシステム
１２ 検証装置
１４ 信号インタフェース
１６ テスト対象装置
４０ プロセッサ
４２ ユーザインタフェース
４４ ネットワークインタフェース
４８ 開発ツール
５０ 有向グラフデータベース
５２ グラニュラーメッセージ図データベース
５４ インタラクタコードデータベース
５６ シナリオデータベース
５８ 解析モジュール

Claims (11)

1. 設計に関する入力を受信するよう動作可能なユーザインタフェースと、
   前記入力に応答して、複数のプロセス間で通信されるメッセージの関係を記述するグラフィカル表示を生成し、前記グラフィカル表示から該グラフィカル表示により特定されるメッセージのシーケンスからなる少なくとも１つのシナリオを決定し、前記シナリオに従って前記グラフィカル表示により特定される前記メッセージの少なくとも一部を送受信するよう動作可能な状態マシーンを生成し、前記状態マシーンを利用して前記設計のプロトタイプをテストするよう動作可能なコントローラと、
   を有し、
   前記グラフィカル表示は、各メッセージ図が前記グラフィカル表示に記述される前記メッセージの一部の関係を記述する複数のメッセージ図と、該複数のメッセージ図の間の関係を記述する有向グラフとから構成される、
   ことを特徴とする設計を検証する装置。
2. 前記コントローラはさらに、２つのメッセージ図を接続する前記有向グラフの各エッジを少なくとも１回巡回する前記グラフィカル表示を介したパスを特定し、前記パスに基づき前記シナリオを決定するよう動作可能であることを特徴とする請求項１記載の装置。
3. 前記コントローラはさらに、第１メッセージ図と第２メッセージ図との間のすべてのパスを特定し、特定された各パスに対してシナリオを決定するよう動作可能であることを特徴とする請求項１記載の装置。
4. 前記コントローラはさらに、前記グラフィカル表示を介したパスの識別を受信し、前記特定されたパスに基づき前記シナリオを決定するよう動作可能であることを特徴とする請求項１記載の装置。
5. 前記コントローラはさらに、２つのメッセージ図を特定し、前記２つのメッセージ図のメッセージ間の順序付けされた関係に基づき、前記２つのメッセージ図の可能なすべての組み合わせを生成するよう動作可能であることを特徴とする請求項１記載の装置。
6. 前記コントローラはさらに、前記入力に応答して、複数のイベントがある期間内に発生することを要求する同時性制約を生成するよう動作可能であることを特徴とする請求項１記載の装置。
7. 前記コントローラはさらに、前記入力に応答して、実行がある期間停止することを要求するタイムアウト制約を生成するよう動作可能であることを特徴とする請求項１記載の装置。
8. 前記コントローラはさらに、前記入力に応答して、順序付けされていないメッセージの間の順序を確立する同期エッジ表示を生成するよう動作可能であることを特徴とする請求項１記載の装置。
9. 前記プロトタイプの前記テストは、前記状態マシーンと前記プロトタイプとを接続し、前記シナリオに従って前記プロトタイプとのやりとりを試行することを有することを特徴とする請求項１記載の装置。
10. 前記入力は、マウス及びキーボードにより生成される表示系列から構成されることを特徴とする請求項１記載の装置。
11. 設計に関する入力を受信する手段と、
    前記入力に応答して、複数のプロセス間で通信されるメッセージの関係を記述するグラフィカル表示を生成する手段と、
    前記グラフィカル表示から該グラフィカル表示により特定されるメッセージのシーケンスからなる少なくとも１つのシナリオを決定する手段と、
    前記シナリオに従って前記グラフィカル表示により特定される前記メッセージの少なくとも一部を送受信するよう動作可能な状態マシーンを生成する手段と、
    前記状態マシーンを利用して前記設計のプロトタイプをテストする手段と、
    を有し、
    前記グラフィカル表示は、各メッセージ図が前記グラフィカル表示に記述される前記メッセージの一部の関係を記述する複数のメッセージ図と、該複数のメッセージ図の間の関係を記述する有向グラフとから構成される、
    ことを特徴とする設計を検証するシステム。

Images