(57)【特許請求の範囲】
【請求項１】
ａ．複数の命令を含むソフトウェアのソースプログラムを提供するステップと、
ｂ．前記ソースプログラムを構文解析して複数の制御状態を識別し、該ソースプログラムを状態マシンフォーマットに変換するステップと、
ｃ．前記ソースプログラムの複数の命令に翻訳マップを適用するステップと、
ｄ．前記ソースプログラムの状態マシンフォーマットを検証プログラムに変換するステップと、
ｅ．前記検証プログラムに環境モデルを適用するステップと、
ｆ．検証ツールにおいて前記検証プログラムを用いて前記ソフトウェアをテストするステップとを有することを特徴とするソフトウェアテスト方法。
【請求項２】
前記ソースプログラムは、コンピュータにイベント駆動プログラムを実行させる第１ソースコードセグメントと、該イベント駆動プログラムを実行するコンピュータの順次的な制御を定義する少なくとも１つの命令集合を含む第２コードセグメントとを含み、
前記第１ソースコードセグメントは、前記イベント駆動システムに関連する複数の制御状態を定義する第１命令集合と、前記イベント駆動システムの複数のイベントを定義する第２命令集合と、前記イベント駆動システムの複数のアクションを定義する第３命令集合とを含み、
前記複数の制御状態の各制御状態は、前記第１ソースコードセグメントの第１命令集合内に識別子を有し、該識別子は、識別されるすべての制御状態に共通するプログラミング記号であることを特徴とする請求項１に記載の方法。
【請求項３】
前記翻訳マップは複数のマッピング命令を含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記ステップｃは、
前記複数のマッピング命令を前記ソースプログラムの複数の命令と比較して一致する命令を検出するステップと、
前記ソースプログラムの命令に一致するマッピング命令をモデルチェッカの入力言語に変換するステップとを有することを特徴とする請求項３に記載の方法。
【請求項５】
前記環境モデルは、前記イベント駆動システムの複数の動作属性を含むことを特徴とする請求項３に記載の方法。
【請求項６】
前記検証ツールは、モデルチェッカツールであることを特徴とする請求項２に記載の方法。
【請求項７】
前記モデルチェッカツールはＳＰＩＮモデルチェッカツールであることを特徴とする請求項６に記載の方法。
【請求項８】
複数の命令を含むソフトウェアのソースプログラムを提供する手段と、
前記ソースプログラムを構文解析して複数の制御状態を識別し、該ソースプログラムを状態マシンフォーマットに変換する手段と、
前記ソースプログラムの複数の命令に翻訳マップを適用する手段と、
前記ソースプログラムの状態マシンフォーマットを、モデルチェッカの入力言語によるモデルチェッカプログラムに変換する手段と、
前記モデルチェッカプログラムに環境モデルを適用する手段と、
モデルチェッカにおいて前記モデルチェッカプログラムを用いて前記ソフトウェアをテストする手段と、
前記ソフトウェアのテストの結果を表示する手段とを有することを特徴とするソフトウェアテスト装置。
【請求項９】
前記ソースプログラムは、コンピュータにイベント駆動プログラムを実行させる第１ソースコードセグメントと、該イベント駆動プログラムを実行するコンピュータの順次的な制御を定義する少なくとも１つの命令集合を含む第２コードセグメントとを含み、
前記第１ソースコードセグメントは、前記イベント駆動システムに関連する複数の制御状態を定義する第１命令集合と、前記イベント駆動システムの複数のイベントを定義する第２命令集合と、前記イベント駆動システムの複数のアクションを定義する第３命令集合とを含み、
前記複数の制御状態の各制御状態は、前記第１ソースコードセグメントの第１命令集合内に識別子を有し、該識別子は、識別されるすべての制御状態に共通するプログラミング記号であることを特徴とする請求項８に記載の装置。
【請求項１０】
前記翻訳マップは複数のマッピング命令を含むことを特徴とする請求項９に記載の装置。
【請求項１１】
前記翻訳マップを適用する手段は、
前記複数のマッピング命令を前記ソースプログラムの複数の命令と比較して一致する命令を検出する手段と、
前記ソースプログラムの命令に一致するマッピング命令をモデルチェッカの入力言語に変換する手段とを有することを特徴とする請求項１０に記載の装置。
【請求項１２】
前記環境モデルは、前記イベント駆動システムの複数の動作属性を含むことを特徴とする請求項１１に記載の装置。
【請求項１３】
複数の命令を記憶した機械可読媒体において、
前記複数の命令は、機械によって実行されるときに該機械がイベント駆動ソフトウェアをテストする方法を実行する命令を含み、
前記方法は、
ソフトウェアのソースプログラムを構文解析して複数の制御状態を識別し、該ソースプログラムを状態マシンフォーマットに変換するステップと、
前記ソースプログラムに翻訳マップを適用するステップと、
前記ソースプログラムの状態マシンフォーマットを検証プログラムに変換するステップと、
前記検証プログラムに環境モデルを適用するステップと、
前記検証プログラムを検証システムに入力することによって前記ソフトウェアをテストするステップとによりイベント駆動ソフトウェアをテストすることを特徴とする機械可読媒体。
【請求項１４】
前記ソースプログラムは、コンピュータにイベント駆動プログラムを実行させる第１ソースコードセグメントと、該イベント駆動プログラムを実行するコンピュータの順次的な制御を定義する少なくとも１つの命令集合を含む第２コードセグメントとを含み、
前記第１ソースコードセグメントは、前記イベント駆動システムに関連する複数の制御状態を定義する第１命令集合と、前記イベント駆動システムの複数のイベントを定義する第２命令集合と、前記イベント駆動システムの複数のアクションを定義する第３命令集合とを含み、
前記複数の制御状態の各制御状態は、前記第１ソースコードセグメントの第１命令集合内に識別子を有し、該識別子は、識別されるすべての制御状態に共通するプログラミング記号であることを特徴とする請求項１３に記載の機械可読媒体。
【請求項１５】
前記検証システムは前記検証プログラムをＳＰＩＮモデルチェッカに入力することを特徴とする請求項１４に記載の機械可読媒体。
【請求項１６】
前記イベント駆動システムは、通信ネットワークを通じて電話呼を接続することに関連する少なくとも１つのイベントを有する通信サービスアプリケーションであることを特徴とする請求項１５に記載の機械可読媒体。
【請求項１７】
前記状態マシンフォーマットは、ユーザによって定義される仕様を用いて変換されることを特徴とする請求項１６に記載の機械可読媒体。
【請求項１８】
少なくとも１つのメモリを有するコンピュータと、
前記メモリ内のプログラミング言語ステートメントの列を受け取る手段とを有するソフトウェアテストシステムにおいて、
前記プログラミング言語ステートメントの列は、前記コンピュータにイベント駆動システムを実行させる第１ソースコードセグメントおよび第２ソースコードセグメントを含み、
前記第１ソースコードセグメントは、前記イベント駆動システムの複数の制御状態を定義する第１命令集合と、前記イベント駆動システムの複数のイベントを定義する第２命令集合と、前記イベント駆動システムの複数のアクションを定義する第３命令集合とを含み、
前記複数の制御状態の各制御状態は、前記第１ソースコードセグメントの第１命令集合内に識別子を有し、該識別子は、識別されるすべての制御状態に共通するプログラミング記号であり、
前記第２ソースコードセグメントは、前記イベント駆動プログラムを実行する際のコンピュータの順次的な制御を定義する少なくとも１つの命令集合を含み、
前記ソフトウェアテストシステムはさらに、
前記第１ソースコードセグメントを構文解析して前記複数の制御状態を識別し、前記第１ソースコードセグメントおよび前記第２ソースコードセグメントを状態マシンフォーマットに変換する手段と、
前記第１ソースコードセグメントおよび前記第２ソースコードセグメントに翻訳マップを適用する手段と、
前記状態マシンフォーマットを、モデルチェッカの入力言語によるモデルチェッカプログラムに変換する手段と、
前記モデルチェッカプログラムに環境モデルを適用する手段と、
モデルチェッカにおいて前記モデルチェッカプログラムを用いて前記ソフトウェアをテストする手段と、
前記ソフトウェアのテストの結果を表示する手段とを有することを特徴とするソフトウェアテストシステム。
【請求項１９】
前記第１ソースコードセグメントおよび前記第２ソースコードセグメントを前記メモリ内のオブジェクトプログラムへとコンパイルする手段と、
前記コンピュータで前記オブジェクトプログラムを実行して前記イベント駆動システムを実現する手段とをさらに有することを特徴とする請求項１８に記載のソフトウェアテストシステム。
【請求項２０】
前記テストする手段は、前記イベント駆動システムの実行に関連してユーザによって定義される少なくとも１つのプロパティ集合を使用することを特徴とする請求項１９に記載のソフトウェアテストシステム。
【請求項２１】
前記モデルチェッカはＳＰＩＮモデルチェッカであることを特徴とする請求項１９に記載のソフトウェアテストシステム。
【請求項２２】
前記状態マシンフォーマットは、ユーザによって定義される仕様を用いて変換されることを特徴とする請求項２１に記載のソフトウェアテストシステム。
【請求項２３】
前記イベント駆動システムは、通信ネットワークを通じて電話呼を接続することに関連する少なくとも１つのイベントを有する通信サービスアプリケーションであることを特徴とする請求項１８に記載のソフトウェアテストシステム。
【請求項２４】
前記表示する手段によって表示される結果は、前記イベント駆動システムの少なくとも１つの完全なオートマトン表現を含むことを特徴とする請求項２１に記載のソフトウェアテストシステム。
【請求項２５】
前記翻訳マップはユーザによって指定されることを特徴とする請求項２０に記載のソフトウェアテストシステム。
【請求項２６】
前記翻訳マップ、前記環境モデル、および前記プログラミング言語ステートメントの列はそれぞれ、Ｃプログラミング言語で書かれることを特徴とする請求項２５に記載のソフトウェアテストシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータソフトウェアプログラムをテストすることに関し、特に、イベント駆動アプリケーションプログラムをテストする技術に関する。
【０００２】
【従来の技術】
周知のイベント駆動ソフトウェアシステム（当業者の間では「リアクティブシステム」ともいう。）では、あるイベントが発生され、そのイベントの発生に基づいて特定のアクションを実行する実行プロセスへ通信されると、ある機能が行われる。具体的には、イベント駆動ソフトウェアは、システム（例えばコンピュータ）に接続されている他のシステム、マシンあるいは周辺デバイスによって発生されたイベントに応答するそのシステムの動作を定義するために使用される。イベント駆動システムの周知の例には、通信アプリケーション、呼処理ソフトウェア、データ通信ソフトウェア、デバイスドライバ、およびコンピュータインタフェースアプリケーションがある。認識されるように、これらのタイプのイベント駆動システムは状態指向（ｓｔａｔｅ  ｏｒｉｅｎｔｅｄ）である。すなわち、システムの各状態において、あらかじめ定義されたイベントのセットから１つの特定のイベントが発生することが期待され、システムは、明確に定義された方法でそのイベントに応答するように設計される。
【０００３】
簡単にいえば、周知のように、状態マシンは、イベント刺激あるいは入力データの時系列を何らかのファンクションを通して応答あるいは出力データの時系列に変換する。例えば、イベント駆動システムでは、各時点で、各マシンは特定のいわゆる「制御状態」にある。この状態は、他のマシンによって発生されることが期待されるイベントと、それぞれのそのようなイベントの到着時に発生されることになる応答のタイプとを定義する。一般に、応答は、有限のプログラムコードの実行、新しいイベントの発生、および、入力イベントに応答する特定のマシンの新しい制御状態の識別を含む。このように、イベント駆動システムの状態マシンモデルは、システムのプログラマによるアプリケーションプログラムコードの開発において重要な役割を果たす。
【０００４】
一般に、イベント駆動アプリケーションソフトウェアは、周知のＣあるいはＣ＋＋プログラミング言語のような高水準汎用プログラミング言語や、周知のＩＴＵシステム記述言語（ＳＤＬ）のような専用言語で書かれる。このようなシステムのために実際のプログラムコードを開発する際には、関連するマシンの動作を状態マシンを用いて記述することが一般的である。高水準プログラミング言語（例えばＣ）を用いて、ソフトウェアプログラマは、特定のアプリケーションのためのイベント駆動ソフトウェアコードを書く。一般に、ソフトウェアプログラム開発は、アプリケーションの所望のオペレーションの論理記述を提供するいわゆるシステム仕様を調べることから始まる。仕様から作業を始めて、プログラマはオペレーションを実装するために必要なコードを書くことになる。
【０００５】
この従来のプログラミングプロセスの結果、アプリケーションプログラムは、イベント駆動システムのさまざまな制御状態の間の個々の視覚的コンテクストを含まない。すなわち、プログラムコードは、プログラム命令の列を有する１つの大きな「フラットな」ファイルと見なされる。さらに、もとの仕様がプログラム開発中に変化すると（例えば、追加機能がシステムに追加されると）、必要なプログラムコードおよび追加制御状態は一般に、かなり任意の順序でソースプログラムに追加される。プログラマが、プログラムソースコードから直接に制御状態間の論理フローを理解するためには、ソースを通じて手動で実行スレッドをたどる（例えば、分岐命令やｇｏｔｏステートメントをたどる）必要がある。認識されるように、このような論理フローをたどる（トレースする）ことは、特に非常に大きいソースコードプログラムでは、面倒で時間のかかる作業である。これはまた、いわゆる「バグ」を見つけるため、および、アプリケーションプログラムが所望の機能を実装しているかどうかを判定するための、ソフトウェアのテストにおける複雑さにつながる。
【０００６】
具体的には、このようなシステムのためのアプリケーションソフトウェアコードの開発におけるクリティカルな段階は、ソフトウェアの性質を検証して、システムの動作が設計目的に従っていることを確実にするための、コードのテストである。イベント駆動ソフトウェアをテストするためのいくつかの方法がある。例えば、Ｂｏｒｉｓ  Ｂｅｉｚｅｒ，  ”Ｂｌａｃｋ−Ｂｏｘ  Ｔｅｓｔｉｎｇ：  Ｔｅｃｈｎｉｑｕｅｓ  ｆｏｒ  Ｆｕｎｃｔｉｏｎａｌ  Ｔｅｓｔｉｎｇ  ｏｆ  Ｓｏｆｔｗａｒｅ  ａｎｄ  Ｓｙｓｔｅｍｓ”，  Ｊｏｈｎ  Ｗｉｌｅｙ  ａｎｄ  Ｓｏｎｓ，  １９８４、には、テスト目標のセットを定義し、そこから、限定されたテストシーケンスのセットを導出するという周知のテスト方式が記載されている。一般に、テストシーケンスのセットは、システム設計を調べることによりテストエンジニアによって手動プロセスで定義される。テストシーケンスのセットは、テスト対象のイベント駆動ソフトウェアに適用され、「合格」または「不合格」のいずれかがテスト結果として記録される。一般に、このテスト方法は一般的なソフトウェアテストに適用されるが、人的エラーを受けやすく不完全であることが当業者にはよく知られている。特に、テスト対象のイベント駆動ソフトウェアの可能な実行の数は非常に大きい。これに対して、リアルタイム実行でソフトウェアに対して実行可能なテストの数は、総テスト数のうちの単一のテストを実行するのに要する最小時間のようないくつかの実際的制約によって制限される。従って、一般に、この方法では、ほんの数百のテストを選択し適用することしかできない。この結果、テストカバレジに関して信頼度は非常に低い。
【０００７】
当業者に知られている第２のイベント駆動ソフトウェアテスト方法は、例えば、Ｄ．  Ｌｅｅ  ｅｔ  ａｌ．，  ”Ｐｒｉｎｃｉｐｌｅｓ  ａｎｄ  Ｍｅｔｈｏｄｓ  ｏｆ  Ｔｅｓｔｉｎｇ  Ｆｉｎｉｔｅ  Ｓｔａｔｅ  Ｍａｃｈｉｎｅｓ  −  Ａ  Ｓｕｒｖｅｙ”，  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ＩＥＥＥ，  Ｖｏｌ．８４，  ｐｐ．１０９０−１１２６，  １９９６、に記載されている。このテスト方法によれば、イベント駆動ソフトウェアプログラムに対する抽象的な状態マシンモデルを作成する。この状態マシンモデルは一般に、プログラムコードの高水準の記述のみを捕捉することにより、プログラムの詳細のほとんどを無視する。その後、周知のテストシーケンス生成アルゴリズム（例えば、Ｌｅｅの上記論文を参照）を状態マシンモデルに適用して、比較的小さいテストセットを導出し、テスト対象のソフトウェアに適用することができる。前述のテスト方法と同様に、この技術は、イベント駆動ソフトウェアの抽象モデルの手動作成に多くを依存している。従って、この技術は、テスト対象のソフトウェアと、適用可能なテストを導出するために用いられる抽象モデルとの間の形式的関係の不一致によって引き起こされる誤りに敏感である。さらに、イベント駆動ソフトウェアを変更すると、新しいテストの開発が必要となり、これは、面倒で時間のかかるものとなる。
【０００８】
第３の広く用いられているテスト方法（例えば、Ｃ．  Ｈ．  Ｗｅｓｔ，  ”Ｐｒｏｔｏｃｏｌ  Ｖａｌｉｄａｔｉｏｎ  ｂｙ  Ｒａｎｄｏｍ  Ｓｔａｔｅ  Ｅｘｐｌｏｒａｔｉｏｎ”，  Ｐｒｏｃ．  ６ｔｈ  ＩＦＩＰＷＧ  ６．１  Ｉｎｔ．  Ｗｏｒｋｓｈｏｐ  ｏｎ  Ｐｒｏｔｏｃｏｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ，  Ｔｅｓｔｉｎｇ，  ａｎｄ  Ｖｅｒｉｆｉｃａｔｉｏｎ，  Ｎｏｒｔｈ−Ｈｏｌｌａｎｄ  Ｐｕｂｌ．，  ｐｐ．２３３−２４２，  １９８６、を参照）では、ソフトウェアが所望の性質に従っていることを確定するために、イベント駆動ソフトウェアの完全な動作のランダムな検査を行う。完全なソフトウェア記述における項目数は非常に多くなるため、テスト目的でソフトウェアを網羅的に検査しようとしても無理である。従って、周知の統計的アルゴリズムを用いて、ソフトウェアの動作のランダムなサンプルを抽出して解析する。しかし、上記の他のテスト方式と同様にして認識されるように、このテスト方式の欠点は、完全なソフトウェア記述における無関係な項目の量が多いために、高水準の性質に従うようにソフトウェアの完全な動作の効率的な網羅的検査をすることができないことである。
【０００９】
【発明が解決しようとする課題】
従って、従来技術の上記の課題を解決し、イベント駆動ソフトウェアのプログラミング開発およびテストを改善するための技術が必要とされている。
【００１０】
【課題を解決するための手段】
本発明は、イベント駆動ソフトウェアを効率的にテストし、ソースコードの通常の保守、拡張および改定のプロセスの一部として、プログラムコードへの変更の妥当性を追跡することを可能にする技術を提供する。具体的には、本発明の実施例によれば、イベント駆動ソフトウェアコードは、本願発明が優先権主張する米国特許出願と同日に出願された米国特許出願（発明の名称：”Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  Ｆｏｒ  Ｄｅｖｅｌｏｐｉｎｇ  Ｅｖｅｎｔ  Ｄｒｉｖｅｎ  Ｓｏｆｔｗａｒｅ”。以下「関連米国特許出願」という。）に記載の原理に従って指定され書かれる。すなわち、本発明の実施例によれば、ソースコードプログラムは、制御依存（ｃｏｎｔｒｏｌ−ｓｅｎｓｉｔｉｖｅ）および非制御依存（ｎｏｎ−ｃｏｎｔｒｏｌ−ｓｅｎｓｉｔｉｖｅ）フォーマットで定義され構造化される。本発明によれば、イベント駆動ソースコードプログラムを構文解析してソースプログラムで定義される制御状態を抽出し、ソースコードを中間状態マシンフォーマットに変換する。その後、本発明によれば、モデルチェックの目的で、中間状態マシンフォーマットを、オートマトンフォーマットに変換する。
【００１１】
具体的には、好ましい実施例によれば、中間状態マシンフォーマットは、注釈（標記）付きオートマトンモデル（ａｎｎｏｔａｔｅｄ  ａｕｔｏｍａｔｏｎ  ｍｏｄｅｌ）に変換される。例えば、注釈付きオートマトンモデルは、特定のモデルチェッカの入力言語で書かれた検証プログラムである。重要な点であるが、本発明によれば、ソースコードプログラムの各ステートメントは、オートマトンモデル内の抽象（ａｂｓｔｒａｃｔｉｏｎ）にマッピングされる。このマッピングは、検証プロセスの初期段階で定義される翻訳マップを用いて実現される。このマップは、その後、新しいタイプの命令がソースプログラム内に導入される（例えば、プログラミングの誤りを修復するためにリビジョン（改訂）をした後）までは、改訂する必要はない。特に、このマッピングは、特定のステートメントからモデルチェッカのターゲット言語への固定された翻訳を指定する。従って、このマップに現れる命令は、その命令がソースコードに現れるどの場所でも、組織的にオートマトンモデルに変換される。
【００１２】
上記のマップに加えて、本発明によれば、いわゆる環境モデルが定義される。環境モデルは、イベント駆動アプリケーションが実行される特定のオペレーティング環境に関してしなければならない仮定の最小セットをカプセル化する。具体的には、モデルチェッカ入力言語がモデルチェッカに提供されると、環境モデルが適用される。その結果、本発明の好ましい実施例によれば、イベント駆動システムの性質の検証は、検証システムによるイベント駆動ソフトウェアのテストおよびチェックの間、環境モデルに従ってなされる。その後、イベント駆動システムがユーザの希望する実行の性質および動作に従っているかどうかを判断するために、テストおよびチェックの結果が周知の方法で出力される。
【００１３】
本発明によれば、モデル抽出プロセスおよびモデルチェッカの適用は、ユーザの介在を必要とせずに、イベント駆動システムプログラムコードから直接に動的に行うことが可能となる。
【００１４】
【発明の実施の形態】
本発明は、イベント駆動ソフトウェアをテストする技術を提供する。本発明のさまざまな特徴によれば、イベント駆動システムプログラムソースコードは、そのプログラムコードがユーザによって定義された所望の性質（プロパティ）に従っていることを検証する際に有用なオートマトンモデルに直接に変換される。具体的には、本発明の好ましい実施例によれば、イベント駆動システムプログラムコードは、特定のモデルチェッカのターゲット言語に翻訳（トランスレート）される。このような翻訳の結果、プログラムコードの実行がイベント駆動システムの動作に影響を与えるかどうか（例えば、プログラムコードの実行により新しいイベントが生成されるかどうか）に関するステートメントを含むモデルが得られる。従って、本発明の好ましい実施例のこのモデル抽出プロセスは、イベント駆動システムがユーザによって指定される所望の正当性性質に従っているかどうかを判断するための論理モデルチェッカへの入力として使用することができる。本発明によれば、モデル抽出プロセスと、モデルチェッカの適用とは、ユーザの介在を必要とせずに、問題としているイベント駆動システムプログラムコードから直接に動的に行うことが可能である。
【００１５】
本発明は、方法の形式で、および、そのような方法を実施する装置の形式で実現可能である。また、本発明は、有形の媒体（例えば、フロッピーディスク、ＣＤ−ＲＯＭ、ハードドライブ、またはその他の任意の機械可読な記憶媒体）に実現されたプログラムコードの形式で実現することも可能である。その場合、プログラムコードがマシン（例えばコンピュータ）にロードされマシンによって実行されるとき、そのマシンは本発明を実施する装置となる。また、本発明は、例えば、記憶媒体内にあり、マシンにロードされあるいはマシンによって実行され、あるいは、電線やケーブル、光ファイバ、または電磁放射などのような何らかの伝送媒体を通じて伝送されるプログラムコードの形式で実現することも可能である。その場合、プログラムコードがマシン（例えばコンピュータ）にロードされマシンによって実行されるとき、そのマシンは本発明を実施する装置となる。汎用プロセッサ上に実装されると、プログラムコードセグメントは、プロセッサと結合して、特定の論理回路と同様に動作する固有のデバイスとなる。
【００１６】
本発明の背景を示し理解を容易にするために、例示的なイベント駆動システムの概略を説明する。具体的には、図１は、例示的な通信ネットワークのブロック図である。この通信ネットワークは、認識されるように、無数のイベント駆動アプリケーションを含む。通信ネットワーク１００は、例えば、ＡＴ＆Ｔ  Ｃｏｒｐ．の周知の長距離網のような公衆交換電話網であり、加入者に長距離電話サービスを提供する。加入者は、例えば通信デバイス１０５−１〜１０５−６を通じて通信ネットワーク１００にアクセスする。通信デバイス１０５−１〜１０５−６は、例えば、宅内装置、有線電話機、パーソナルコンピュータ、セルラ電話機、ページャおよびファクシミリ機である。通信ネットワーク１００は、特に、複数の市外交換機（例えば、図１に示す市外交換機１１５、１２０、１２５、および１３０のような）を有する。これらの市外交換機は、周知のタイプの通信交換装置（例えば、Ｌｕｃｅｎｔ  Ｔｅｃｈｎｏｌｏｇｉｅｓ  Ｉｎｃ．（所在地：６００  Ｍｏｕｎｔａｉｎ  Ａｖｅ．，  Ｍｕｒｒａｙ  Ｈｉｌｌ，  ＮＪ  ０７９７４，  ＵＳＡ）から販売されているＮｏ．４ＥＳＳ（Ｒ）（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｗｉｔｃｈｉｎｇ  Ｓｙｓｔｅｍ：  電子交換システム）またはＮｏ．５ＥＳＳ（Ｒ））のいずれでもよい。図１に示すように、市外交換機１１５、１２０、１２５、および１３０はそれぞれ、ブロック１５０として示したいわゆる市外網を通じて、いくつかの他の交換機に接続される。また、各市外交換機は、複数の市内局（ＣＯ：ｃｅｎｔｒａｌ  ｏｆｆｉｃｅ）（例えば、ＣＯ１１０〜１１４）に、接続されることも可能である。このような通信ネットワークおよびＣＯの動作は周知であり、例えば、”Ｅｎｇｉｎｅｅｒｉｎｇ  ａｎｄ  Ｏｐｅｒａｔｉｏｎｓ  ｉｎ  ｔｈｅ  Ｂｅｌｌ  Ｓｙｓｔｅｍ”，  Ｓｅｃｏｎｄ  Ｅｄｉｔｉｏｎ，  Ｅｉｇｈｔｈ  Ｐｒｉｎｔｉｎｇ，  国際標準図書番号０−９３２７６４−０４−５（１９９３年）、に記載されているため、その詳細についてはここでは説明しない。略言すれば、ＣＯは、発呼者が特定の電話番号をダイヤルした通信デバイス（例えば１０５−１）で発信された電話呼を、通信ネットワーク１００の対応する市外交換機へ送るように動作する。ＣＯ（例えばＣＯ１１０）は、さらに、被呼者の通信デバイス（例えば１０５−６）へ、および、対応する市外交換機（例えば市外交換機１２５）から呼を受信するＣＯ（例えばＣＯ１１４）へ、呼接続を延長するように動作する。
【００１７】
通信ネットワーク１００の市外交換機１１５、１２０、１２５および１３０は、データリンク１３５を通じて相互接続される。データリンク１３５は、例えば、周知のＮｏ．７信号方式（ＳＳ７）信号網である。通信ネットワーク１００は、市外交換機が互いにデータメッセージを交換して、発呼者（例えば、通信デバイス１０５−１）と被呼者（例えば通信デバイス１０５−６）の間で通信ネットワーク１００を通じて接続を確立するように動作する。すなわち、接続は、発呼者と被呼者の間で呼が確立される（例えば、被呼者が「オフフック」になることによって呼に応答する）まで通信ネットワーク１００を通じて呼接続を延長することによって確立される。さらに、通信ネットワーク１００は、ネットワーク制御ポイント（ＮＣＰ：Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌ  Ｐｏｉｎｔ）といういくつかの集中データベースを有する。そのうちの１つをＮＣＰ１４０として示す。周知のように、ＮＣＰ１４０のようなＮＣＰは、周知の北米の「８００番」や「８８８番」無料電話番号サービスのような、ネットワークを通じてアクセスされ提供されるさまざまなサービス機能をサポートするように、通信ネットワーク１００内のさまざまな位置に戦略的に配置される。
【００１８】
認識されるように、通信ネットワーク１００およびこのネットワークの上記のさまざまな要素は、無数のイベント駆動アプリケーションを必要とする。例えば、市外交換機１１５、１２０、１２５および１３０の呼処理アプリケーションプログラムは、ネットワーク１００を通じての呼接続の延長を容易にするように開発されなければならない。具体的には、例えば、発呼者は、通信デバイス１０５−１を利用して発呼を行う。この場合、イベント駆動呼処理アプリケーションは、ほんの少し列挙するだけでも、オフフック、ダイヤル、アイドル、コネクト（接続）、リング（呼出し）、およびビジー（話中）のようなオペレーションすなわち制御状態を含むことになる。
【００１９】
上記のように、本発明の好ましい実施例によれば、イベント駆動ソフトウェアコードは、前掲の関連米国特許出願に記載の原理に従って指定され書かれる。従って、本発明の完全な理解を容易にするために、関連米国特許出願の発明のさまざまな特徴について以下でやや詳細に説明する。
【００２０】
関連米国特許出願の発明のさまざまな特徴によれば、イベント駆動ソフトウェアを定義し、構造化し、開発するためのプログラミング技法が提供される。具体的には、イベント駆動ソフトウェアは、２つの基本部分に構造化される。これらを、関連米国特許出願および本明細書では、制御依存コード（ｃｏｎｔｒｏｌ−ｓｅｎｓｉｔｉｖｅ  ｃｏｄｅ）および非制御依存コード（ｎｏｎ−ｃｏｎｔｒｏｌ−ｓｅｎｓｉｔｉｖｅ  ｃｏｄｅ）という。本発明によれば、制御依存コードは、制御状態の識別と、認識されなければならない生成されるイベントと、特定の状態における特定のイベントの到着に対する応答とを含む。さらに、システムを定義する制御依存コード内では、制御状態は、このプログラムコード全体を通じて単一の記号により一意的に識別される。非制御依存コードは、制御依存コードとは別個に指定され、デバイスドライバの呼出し、周辺装置の制御、テーブルの更新、変数定義などのような、イベント駆動システムをプログラミングするために必要な通常のシーケンシャルコードのためのものである。本発明によれば、ソフトウェア開発者は、コア制御機能（すなわち、状態、イベントおよび応答）と、イベント駆動システムの動作に直接に影響しない外部的事項とが明確に区別されるように、イベント駆動ソフトウェアアプリケーションコードを構造化することが可能となる。そのため、プログラマは、プログラムコード自体を表面的に調べることにより制御状態から制御状態への正確な実行フローを直接に判断することができる。これは、個々の制御状態が強力な視覚的コンテクストを有するからである。すなわち、本発明によれば、プログラムソースコードは、イベント駆動アプリケーションを定義する制御状態どうしが直接の論理的な（すなわち、因果的な）関係を有するように、構造化され定義される。この関係は、ソースコード自体を調べることにより直ちに明らかなものである。
【００２１】
具体的には、図２および図３に、発呼を処理する例示的なイベント駆動アプリケーションに対する通常のＣソースコードプログラム２００の例（プログラムコード行番号１〜２６８）を示す。認識されるように、ソースコードプログラム２００は、アプリケーションのいくつかの制御状態を定義する。例えば、コードセクション２０５〜２３０は、それぞれ、ｂｕｓｙ、ｃｏｎｎ、ｄｅａｄ、ｄｉｇｉｔｓ、ｉｄｌｅ、およびｒｉｎｇという制御状態のオペレーションを定義している。しかし、重要な点であるが、ソースコードプログラム２００を調べても、さまざまな制御状態どうしの間の実行スレッドを直ちに明らかに見ることはできない。高水準プログラミングの観点からは、ソースプログラムコード内に定義されたさまざまな制御状態間の直接のあるいは論理的な（すなわち、因果的な）関係はない。すなわち、上記のように、プログラマが制御状態から制御状態への論理フローをプログラムソースコードから直接に理解するためには、ソースを通じて実行スレッドをトレースする（例えば、分岐命令やｇｏｔｏステートメントをたどる）ことが必要である。認識されるように、このような論理フローのトレースは、特に非常に大きなソースコードプログラムでは、面倒で、非啓発的で、誤りの起きやすい、時間のかかる作業である。例えば、通信ネットワーク１００のすべての必要な呼処理機能を実装するソースコードは、数万行のオーダーになる。また、このようなソースコードでは、いわゆる「バグ」に対しての、および、アプリケーションプログラムが所望の機能を実装しているかどうかを判定するための、ソフトウェアのテストも複雑になる。重要な点であるが、この新規なプログラミング技法は、従来技術のさまざまな欠点を解決するように、イベント駆動ソフトウェアを定義し、構造化し、コーディングするものである。本発明によれば、制御依存コードは、制御状態の識別と、認識されなければならない生成されるイベントと、特定の状態における特定のイベントの到着に対する応答とを含む。さらに、システムを定義する制御依存コード内では、制御状態は、このプログラムコード全体を通じて単一の記号により一意的に識別される。非制御依存コードは、制御依存コードとは別個に指定され、デバイスドライバの呼出し、周辺装置の制御、テーブルの更新、変数定義などのような、イベント駆動システムをプログラミングするために必要な通常のシーケンシャルコードのためのものである。
【００２２】
本発明によれば、ソフトウェア開発者は、コア制御機能（すなわち、状態、イベントおよび応答）と、イベント駆動システムの動作に直接に影響しない外部的事項とが明確に区別されるように、イベント駆動ソフトウェアアプリケーションコードを構造化することが可能となる。そのため、プログラマは、プログラムコード自体を表面的に調べることにより制御状態から制御状態への正確な実行フローを直接に判断することができる。これは、個々の制御状態が強力な視覚的コンテクストを有するからである。すなわち、本発明によれば、プログラムソースコードは、イベント駆動アプリケーションを定義する制御状態どうしが直接の論理的な（すなわち、因果的な）関係を有するように、構造化され定義される。この関係は、ソースコード自体を調べることにより直ちに明らかなものである。
【００２３】
本発明の好ましい実施例によれば、本発明によるイベント駆動ソフトウェアの定義、構造化およびコーディングを容易にするために、周知のＡＮＳＩ標準Ｃプログラミング言語のプログラミング拡張を採用する。具体的には、本発明の好ましい実施例によれば、ＡＮＳＩ標準Ｃプログラミング言語の拡張は、単一の記号からなる。この記号として、例えば、周知のＡＳＣＩＩ記号”＠”を選択する。これは、プログラムコードの制御依存部分内のすべての制御状態をラベルするために用いられる。すなわち、記号”＠”は、プログラムソースコード内の制御状態に対応するすべてのラベルの最初の文字として使用される。すなわち、本発明によれば、”＠”ラベルを前置したプログラムステートメントは、プログラムコードにおけるある制御状態を識別する。この制御状態により、イベント駆動システムの現在の実行は、次のイベントの到着を待機する。次のイベントの到着後、そのイベントへの必要な応答のエンコードとともに、次のプログラムコードが実行され、その結果、新たな一意的に定義される制御状態への遷移が起こる。認識されるように、この応答および新たな制御状態は、内部テーブルに記憶された状態情報、変数、デバイス応答などのような動作上の事項に依存して処理される各イベントごとに異なる可能性がある。
【００２４】
図４は、本発明の原理によるソフトウェア開発の例示的なオペレーションの流れ図である。具体的には、プログラムされるイベント駆動システムに対する仕様が、例えばシステムエンジニアによって定義される（ブロック４１０）。当業者には認識されるように、このような仕様は、ソフトウェアプログラムが書かれ実装されるアプリケーション（例えば、イベント駆動システム）全体の記述を提供する。システム仕様から、開発中のイベント駆動システムを実装するための制御状態を識別する（ブロック４２０）ことができる。これにより、認識されなければならない生成されるイベントと、特定の状態における特定のイベントの到着に対する応答とが識別される。こうして、本発明によれば、ソースコードプログラムの定義、構造化、およびコーディング（ブロック４３０）は、上記のように、制御依存コードと非制御依存コードの２つの部分に分割される。
【００２５】
本発明によれば、システムを定義する制御依存コード内では、制御状態は、このプログラムコード全体を通じて単一の記号により一意的に識別される。上記のように、本発明の好ましい実施例によれば、プログラムソースコード全体の制御依存部分内の制御状態に対応するすべてのラベルの最初の文字として”＠”を使用する。すなわち、本発明によれば、”＠”ラベルを前置したプログラムステートメントは、プログラムコードにおける待機（ウェイト）状態を識別する。この状態で、イベント駆動システムの現在の実行は、次のイベントの到着を待機する。さらに、非制御依存コードは、制御依存コードとは別個に指定され、デバイスドライバの呼出し、周辺装置の制御、テーブルの更新、変数定義などのような、イベント駆動システムをプログラミングするために必要な通常のシーケンシャルコードのためのものである。
【００２６】
本発明によれば、ソフトウェア開発者は、コア制御機能（すなわち、状態、イベントおよび応答）と、イベント駆動システムの動作に直接に影響しない外部的事項とが明確に区別されるように、イベント駆動ソフトウェアアプリケーションコードを構造化することが可能となる。そのため、本発明の原理を適用する１つの実用的な結果として、プログラマは、プログラムコード自体を表面的に調べることにより制御状態から制御状態への正確な実行フローを直接に判断することができる。これは、個々の制御状態が強力な視覚的コンテクストを有するからである。すなわち、本発明によれば、プログラムソースコードは、イベント駆動アプリケーションを定義する制御状態どうしが直接の論理的な（すなわち、因果的な）関係を有するように、構造化され定義される。この関係は、ソースコード自体を調べることにより直ちに明らかなものである。重要な点であるが、本発明によれば、さらに、イベント駆動ソフトウェアのテストおよび検証（ブロック４４０）において、ソフトウェアが、ユーザによって指定された所望の性質を満足しているかどうかを判断することができるという利点がある。特に、本発明の目的であり、以下でさらに詳細に説明するのは、このようなイベント駆動ソフトウェアのテストである。
【００２７】
しかし、上記の関連米国特許出願の説明を続けると、本発明によれば、ソフトウェア開発者は、コア制御機能（すなわち、状態、イベントおよび応答）と、イベント駆動システムの動作に直接に影響しない外部的事項とが明確に区別されるように、イベント駆動ソフトウェアアプリケーションコードを構造化することが可能となる。例えば、図５および図６に、図２および図３の例示的な通信呼処理アプリケーションに対して、本発明により構造化され定義された例示的なＣソースコードプログラム５００（プログラムコード行番号１〜２５８）を示す。具体的には、本発明の好ましい実施例によって、制御状態５１０〜５５５は、すべてのラベルの最初の文字が記号”＠”である。これにより、ソースコードプログラム５００全体の制御依存部分内の制御状態であることを表す。こうして、ソースコードプログラム５００は、本発明によれば、制御状態（すなわち、制御状態５１０〜５５５）どうしの間に直接の論理的な（すなわち、因果的な）関係を有する。重要な点であるが、プログラマは、プログラムコード自体を表面的に調べることにより制御状態から制御状態への正確な実行フローを直接に判断することができる。これは、個々の制御状態が強力な視覚的コンテクストを有するからである。
【００２８】
例えば、ソースコードプログラム５００を表面的に調べることにより、制御状態５３５（すなわち、”＠ｄｉｇｉｔｓ”制御状態）におけるコードを見ると、その特定の制御状態にどのようにして到達するかを直ちに正確に確認することができる。すなわち、この特定のイベント駆動システムの呼出しおよび実行（すなわち、発呼の処理）で、電話機での数字のダイヤリングを可能にする制御状態が処理される。制御状態５３５はそのような状態であり、本発明の好ましい実施例によれば、コード５００の第１２５行から始まることが明確に識別可能である。制御状態５３５を見ると、この制御状態に到達する実行フローは、その上にコーディングされた制御状態５１０〜５３０を通った直後であることが直ちにわかる。さらに、別の制御状態を追加するために（例えば、さらにアプリケーション固有の機能を追加するために）ソースコードプログラム５００を改訂する必要がある場合、新しい制御状態は、すべての制御状態の間のコンテクストを失うことなく、既存の制御状態階層内の正確な位置に配置することができる。
【００２９】
ソースコードプログラム５００を見ることによって直接に認識される、制御状態どうしの間のこの論理的な（すなわち、因果的な）関係と、明確な実行フローとは、図７および図８ではさらに明らかである。図７および図８は、図５および図６の例示的なＣソースコードプログラム５００から導出される翻訳済みソースコードプログラム７００を示す。上記のように、本発明の好ましい実施例によれば、ＡＮＳＩ標準Ｃプログラミング言語の拡張は、単一の記号からなる。この記号として、例えば、記号”＠”を選択する。これは、プログラムコードの制御依存部分内のすべての制御状態をラベルするために用いられる。コード自体の実際の翻訳の手順（トランスレータ）は当業者には明らかである。すなわち、翻訳済みソースコードプログラム７００は、本発明によるイベント駆動アプリケーションプログラムの、実際の完全に翻訳されたＡＮＳＩ標準Ｃ表現である。例えば、図５の制御状態５１５（すなわち、”＠ｉｄｌｅ”）は、プログラムコードセクション７１０に翻訳され、制御状態５４５（すなわち、”＠ｒｉｎｇ”は、プログラムコードセクション７２０に翻訳される。
【００３０】
関連米国特許出願の発明の上記の利点は、コンピュータプログラミング技術において非常に有用であり、特に、イベント駆動ソフトウェアアプリケーションプログラミングの定義、構造化、および開発にとって有用である。もちろん、アプリケーションプログラムの開発の成功にとって重要なのは、期待される性質の定義されたセットに対するプログラムコードの有効なテストおよび検証である。本発明のさまざまな特徴が目的としており以下でさらに詳細に説明するのは、イベント駆動ソフトウェアのテストである。
【００３１】
本発明のさまざまな特徴は、イベント駆動ソフトウェアの効率的なテストを目的とするとともに、ソースコードの通常の保守、拡張および改訂のプロセスの一部として、プログラムコードへの将来の変更の妥当性を追跡することを可能にする。図９は、本発明の原理に従って、イベント駆動ソフトウェアをテストする例示的なオペレーションの流れ図である。具体的には、本発明の好ましい実施例によれば、イベント駆動ソフトウェアコードは、上記の関連米国特許出願の発明の原理により指定され書かれる。すなわち、好ましい実施例によれば、ソースコードプログラムは、制御依存および非制御依存フォーマットとして定義され構造化される（ブロック９１０）。本発明によれば、イベント駆動ソースコードプログラムを構文解析してソースプログラムで定義される制御状態を抽出し、ソースコードを中間状態マシンフォーマットに変換する（ブロック９２０）。その後、本発明によれば、モデルチェックの目的で、中間状態マシンフォーマットを、オートマトンフォーマットに変換する。
【００３２】
具体的には、好ましい実施例によれば、中間状態マシンフォーマットは、特定のモデルチェッカの入力言語による注釈付きオートマトンモデルに変換される（ブロック９４０）。好ましい実施例によれば、モデルチェッカツールは、Ｌｕｃｅｎｔ  Ｔｅｃｈｎｏｌｏｇｉｅｓ  Ｉｎｃ．のＢｅｌｌ  Ｌａｂｏｒａｔｏｒｉｅｓ  Ｄｉｖｉｓｉｏｎによって開発されそこから入手可能な周知の「ＳＰＩＮ」モデルチェッカである。これについてさらに詳細には、Ｇ．  Ｊ．  Ｈｏｌｚｍａｎｎ，  ”Ｔｈｅ  Ｍｏｄｅｌ  Ｃｈｅｃｋｅｒ  ＳＰＩＮ”，  ＩＥＥＥ  Ｔｒａｎｓ．  Ｏｎ  Ｓｏｆｔｗａｒｅ  Ｅｎｇｉｎｅｅｒｉｎｇ，  Ｖｏｌ．２３，  Ｎｏ．５，  ｐｐ．２７９−２９５，  Ｍａｙ  １９９７、に記載されている。重要な点であるが、本発明によれば、ソースコードプログラムの各ステートメントは、オートマトンモデル内の抽象（ａｂｓｔｒａｃｔｉｏｎ）にマッピングされる（ブロック９３０）。このマッピング（詳細は後述）は、検証プロセスの初期段階で定義される翻訳マップを用いて実現される。このマップは、その後、新しいタイプの命令がソースプログラム内に導入される（例えば、プログラミングの誤りを修復するためにリビジョン（改訂）をした後）までは、改訂する必要はない。特に、このマッピングは、特定のステートメントからモデルチェッカのターゲット言語への固定された翻訳を指定する。従って、このマップに現れる命令は、その命令がソースコードに現れるどの場所でも、組織的にオートマトンモデルに変換される。
【００３３】
上記のマップに加えて、本発明によれば、いわゆる環境モデルが、例えばユーザによって、定義される。環境モデルは、イベント駆動アプリケーションが実行される特定のオペレーティング環境に関してしなければならない仮定の最小セットをカプセル化する。具体的には、モデルチェッカ入力言語がモデルチェッカ（例えば、ＳＰＩＮ）に提供される（ブロック９５０）と、環境モデルが適用される（ブロック９７５）。その結果、本発明の好ましい実施例によれば、イベント駆動システムの性質の検証は、モデルチェッカによるイベント駆動ソフトウェアのテストおよびチェック（ブロック９６０）の間、環境モデルに従ってなされる。その後、イベント駆動システムがユーザの希望する実行の性質および動作に従っているかどうかを判断するために、モデルチェッカによって、テストおよびチェックの結果が周知の方法で出力される（ブロック９７０）。
【００３４】
本発明によるイベント駆動ソフトウェアの上記のテストおよびチェックにとって重要なことは、ソースプログラムで定義される制御状態を抽出するためにイベント駆動ソースコードプログラムを効率的に構文解析すること、および、ソースコードを中間状態マシンフォーマットに変換することである（例えば、図９、ブロック９２０を参照）。すなわち、モデルチェックを効率的に実行するためには、イベント駆動システムの制御状態、イベントおよびアクション（すなわち、応答）を識別することができなければならない。従って、本発明のもう１つの特徴は、以下で詳細に説明するように、モデルチェックの目的で、イベント駆動システムの記述を容易にする形式的仕様を実現することである。
【００３５】
本発明のこの特徴によれば、イベント駆動システムの仕様を容易にするフォーマットが定義される。本発明のさまざまな実施例（詳細は後述）によれば、仕様は、直接コンパイルおよび実行するために、ターゲットプログラミング言語（例えばＣ）に変換されることが可能である。本発明のさらに別の実施例によれば、仕様は、上記のマッピングを用いて、ＳＰＩＮモデルチェックツールの入力言語のような論理検証モデルに変換される。当業者には認識されるように、文法仕様ツールは周知である。例えば、ｙａｃｃ（ｙｅｔ−ａｎｏｔｈｅｒ−ｃｏｍｐｉｌｅｒ−ｃｏｍｐｉｌｅｒ）は、入力ストリームを解析し解釈するＣルーチンの開発においてプログラマを支援し、また、コンパイラおよびインタプリタの開発を容易にする、周知のＵＮＩＸソフトウェアユーティリティツールの１つである（例えば、Ａ．  Ｔ．  Ｓｃｈｒｅｉｎｅｒ，  ”Ｕｓｉｎｇ  Ｃ  ｗｉｔｈ  ｃｕｒｓｅｓ，  ｌｅｘ  ａｎｄ  ｙａｃｃ”，  Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ  Ｉｎｃ．，  Ｅｎｇｌｅｗｏｏｄ  Ｃｌｉｆｆｓ，  ＮＪ  ０７６３２，  １９９０、を参照）。ｙａｃｃと同様に、本発明の仕様フォーマットは、言語の文法を記述し、その言語に対するコンパイラの生成を自動化するフォーマリズムを提供する。ただし、本発明の仕様フォーマットは、本発明によれば、システムの動作の指定を目的とする。
【００３６】
具体的には、例示的な文法定義は、本発明の好ましい実施例によれば、以下のようになる。
【００３７】
0003631647.tif 000002
0003631647.tif 000003
【００３８】
上記の例示的な文法定義は、本発明の原理による特定のアプリケーション（例えば、イベント駆動システム）に対する仕様を定義するためのフレームワークを提供する。この例示的な文法定義において、二重引用符の間に現れるすべての項は終端記号（キーワード、リテラル、トークン）である。大文字の語ＳＴＲＩＮＧは、英数字ストリングを表し、ＮＵＭＢＥＲは１桁以上の数字列を表す。選択肢は縦棒”｜”（すなわち、パイプ記号）によって区切られ、各文法規則はセミコロンで終了する。
【００３９】
好ましい実施例によれば、仕様フォーマットは２つの部分、すなわち、宣言および仕様からなる。好ましい実施例の仕様の宣言部は、特に、仕様で用いられることになるすべてのイベントの記号名のリストを含む。例えば、以下のコード断片は、好ましい実施例による例示的な宣言である。
【００４０】
0003631647.tif 000004
【００４１】
上記の例示的な宣言において、パーセント”％”記号で始まるすべての語はキーワードである。例えば、”％ｃ＿ｔｅｍｐｌａｔｅ”は、Ｃ（すなわち、好ましい実施例のターゲット実装言語）のコードの最終実装のためのテンプレートを含むファイルの名前を定義する。さらに、”％ｐ＿ｍａｐ”ステートメントは、実装のＣコードと、モデルチェッカでの検証に用いられるコードの抽象表現（すなわち、マッピング）との間の関係を定義するために使用することが可能なファイルの名前を与える。さらに、上記の例示的な宣言は、仕様で用いられることになるすべてのイベントに対する記号名（例えば、”％ｅｖｅｎｔ  Ｃｒａｎｓｗｅｒ”）のリストと、仕様内のすべての制御状態に対する状態名（例えば、”％ｓｔａｔｅ  Ｓ＿ｉｄｌｅ”）のリストとを含む。
【００４２】
本発明によれば、仕様フォーマットのコアは、イベント駆動システムに対する遷移規則のセットの仕様である。この仕様において、状態仕様は、以下の記法で指定される遷移規則の列からなる。
0003631647.tif 000005
【００４３】
例えば、以下のコード断片は、好ましい実施例による例示的な制御状態仕様である。
0003631647.tif 000006
【００４４】
上記の例示的な制御状態仕様では、遷移規則は、状態の名前（例えば、”Ｓ＿ｉｄｌｅ”）と、それに続くコロンから始まる。コロンの後に、この状態からの一連の可能な遷移がリストされる。それぞれの遷移は、縦棒”｜”によって互いに区切られる。それぞれの完全な遷移は、３つの部分を有する。それらの３つの部分は、応答をトリガするイベントの名前と、応答が実行された後に到達する新しい状態（すなわち、「次状態」）の名前と、その応答自体である。仕様の次状態部分は、応答が完全に処理された後に制御がどこへ移動するかを定義し、あらかじめ定義された制御状態、または、いわゆる内部状態のいずれかの名前を含む。本発明の別の実施例によれば、２つのイベントが同じ次状態および応答を有する場合、次のような略記法を使用することができる。
0003631647.tif 000007
【００４５】
上記の略記法を用いると、イベントＣｒｆｌａｓｈ、Ｃｒｄｉｓ、およびＣｒｏｆｆｈｏｏｋはすべて同じ応答（すなわち、指定されたコード断片の実行と、状態”Ｓ＿ｉｄｌｅ”への遷移）を生成することになる。
【００４６】
認識されるように、イベント駆動システムは、各制御状態で実行を停止し、次のイベントの到着を待機する。これに対して、イベント駆動システムは、内部状態を待機せずに通過する。さらに、次のイベントの到着を待機せずに次状態の処理を継続すべきことを示すために、遷移規則の次状態セグメントにおける状態名に”＠”記号を前置することができる（なお、この記法は、関連米国特許出願の発明のさまざまな特徴に従って制御状態を識別することに関して前に説明したのと同じものではない）。このような場合、次状態におけるシステムの動作を決定するためにイベントが必要な場合、最後のイベントが利用可能である。
【００４７】
上記の内部状態に関して、このようなイベントは、イベント駆動システムの内部的な非イベント関連の判定をエンコードする。本発明の好ましい実施例によれば、仕様における内部イベントに対する構文は、イベント名の代わりに、ターゲット実装言語における一般的なブール条件を使用することを除いては、制御状態に対するものと同じである。例えば、例示的な内部状態は以下のように定義される。
0003631647.tif 000008
【００４８】
上記の例示的な内部状態は、特定のフィールドの値（この例では、”ｘ”という名前のＣデータ構造体内に２つのレベルを隠蔽している）が、状態”Ｓ＿ｏｔｒｕｎｋ”または状態”Ｓ＿ｉｄｌｅ＿Ｅ６”のいずれへ制御が移動するかを決定することになることを指定している。前の場合、その状態の後に定義されているアクションコードの部分が実行されることになる。後の場合、実行されるコードはない。
【００４９】
好ましい実施例によれば、イベントまたは条件の名前が”ｅｌｓｅ”である場合、明示的にリストされたイベント名またはブール条件のいずれも成立しないときにデフォルトの応答がなされることを示す。例えば、上記の例示的な内部状態コード断片は、次のように書くことも可能である。
0003631647.tif 000009
【００５０】
この内部状態コード断片によれば、この状態に到達したときに条件”｛ｘ−＞ｄｒｖ−＞ｔｒｕｎｋ｝”を評価して”ｆａｌｓｅ”（偽）の場合、実行されるコード断片はなく、状態”Ｓ＿ｉｄｌｅ＿Ｅ６”への遷移が起こるのみである。
【００５１】
さらに、イベント駆動システムの仕様に関して、制御状態においてイベントを受け取った直後に実行しなければならない共通のアクション断片を定義することが有用なことがある。定義により、このようなコード断片は、いずれかの遷移規則が適用される前に実行されるべきである。本発明の好ましい実施例によれば、このような共通のアクション断片を定義するためにキーワード”ｏｎｒｅｃｅｉｐｔ”が用いられる。このキーワードの使用法の例を次に示す。
0003631647.tif 000010
【００５２】
上記の例示的なコード断片では、状態は内部状態であるため、次状態セグメントにおいて常に”＠”プレフィクスで参照されることが可能である。”ｏｎｒｅｃｅｉｐｔ”コードは、遷移によりこの状態に到達すると直ちに実行され、条件”（ｙ  ＝＝  ｎｉｌ）”が評価される。この条件が”ｔｒｕｅ”（真）である場合、システムは”Ｓ＿ｏｒｉｇ＿Ｅ５４”という名前の別の内部状態に移動し、”ｆａｌｓｅ”（偽）の場合、システムは内部状態”Ｓ＿ｏｒｉｇ＿Ｅ５５”に移動して新しいイベントを待機せずに処理が継続する。
【００５３】
最後に、この仕様に関して、条件チェックをすべてバイパスして、無条件に次状態に進む中間遷移状態を指定することが有用なこともある。本発明の好ましい実施例によれば、常に真である条件は、次の例のコード断片に示すようにキーワード”ａｌｗａｙｓ”で表される。
0003631647.tif 000011
【００５４】
モデルチェックの目的でイベント駆動システムを記述する際の上記の形式的仕様の本発明による実現は、イベント駆動システムの動作を記述するための仕様フォーマットを提供する。
【００５５】
イベント駆動ソフトウェアをテストする際の本発明のさまざまな特徴および利点についてさらに説明するため、図１０に、上記の本発明の原理に従って図５および図６の例示的なＣソースコードプログラム５００のソースコードリストから導出された中間状態マシンコード１０００（プログラムコード行番号１〜１２４）を示す。上記のように、イベント駆動コードに対するモデルチェックを有効に実行するためには、制御状態、イベントおよびアクションの正確な評価および識別をしなければならない。本発明の原理によれば、中間状態マシンコード１０００は、制御状態と、イベントと、アクションとの間の明確な区別を提供する。具体的には、好ましい実施例によれば、トランスレータをＣソースコードプログラム５００に適用して、中間状態マシンコード１０００を直接に生成する。トランスレータの実際の構成は、コンピュータプログラミング技術の当業者には容易に理解されるため、ここで詳細に説明する必要はない。ただし、本発明に従ってＣソースコードプログラム５００を構造化することにより、関連する制御状態、イベント、およびアクションの自動識別が可能となる。すなわち、上記のような本発明の利点が実現される。
【００５６】
具体的には、中間状態マシンコード１０００を注意深く調べることにより、コード１０００の宣言部のイベント（例えばコードセクション１０１０を参照）と制御状態（例えば、コードセクション１０２０を参照）が明確にわかる。さらに、本発明によれば、中間状態マシンコード１０００内のさまざまな状態仕様（例えば、状態仕様１０３０〜１０５０を参照）によって、このようなイベント、制御状態および関連するアクションの間の明確な相互作用が示されている。図９のオペレーションに関して既に説明したように、本発明によれば、中間状態マシンノード１０００は、問題としているプログラムコードのテストを実行するためにモデルチェッカ入力言語に変換される。この変換は、検証プロセスの初期段階で定義される翻訳マップによって容易になる。特に、このマッピングは、特定のステートメントからモデルチェッカのターゲット言語への固定された翻訳を指定する。従って、このマップに現れる命令は、その命令がもとのソースコードに現れるどの場所でも、組織的にオートマトンモデルに変換される。
【００５７】
図１１に、例示的なＣソースコードプログラム５００によって定義されるイベント駆動システムに対する例示的なマップ１１００を示す。マップ１１００は、もとのソースコード内の個々のステートメントがどのようにしてモデルチェッカのターゲット言語へと固定的に翻訳されるかを定義するプログラムコード１１１０（プログラムコード行番号１〜４７）からなる。具体的には、プログラムコード１１１０は、イベント定義１１２０およびコード定義１１３０を含む。例えば、プログラムコード１１１０の第２０行は、左側のコラムのあらゆるステートメントを、右側のコラムに与えられた抽象へとマッピングする。本発明によれば、マップ１１００の適用により、図１２および図１３に示すモデルチェッカ入力言語１２００（プログラムコード行番号１〜３０３）が導出される。さらに、本発明によれば、図１２および図１３のモデルチェッカ入力言語に対して、図１４のライブラリ関数１４００に例示されるライブラリ関数のセットが生成される。認識されるように、ライブラリ関数１４００（プログラムコード行番号１〜１５３）は、モデルチェッカ入力言語１２００内の項を定義するのに必要な意味規則（セマンティクス）を提供する。好ましい実施例によれば、モデルチェッカ入力言語１２００は、ＳＰＩＮモデルチェッカツールで使用される。
【００５８】
重要な点であるが、本発明によれば、マップを使用することの１つの重要な利点は、ソースとは独立に、チェックプロセスを適用するのに適当なレベルの項目を正確に定義する能力がユーザに提供されることである。マップは、任意のステートメントの翻訳（すなわち、上記のプログラムコード１１１０の右側のコラム）として”ｔｒｕｅ”または”ｓｋｉｐ”を含むことができる。これは、この項目が抽象されていることを示す。従って、マップは、ターゲットプログラミング言語（例えば、Ｃ）から検証モデルへのコンバータとして作用するのに加えて、無関係な詳細をフィルタリングして除去する「フィルタ」として作用する。また、マップは、ソースコードと検証モデルの間の関連の完全な形式化を提供する。
【００５９】
上記のように、本発明の好ましい実施例によれば、イベント駆動システムの性質の検証は、検証システムによるイベント駆動ソフトウェアのテストおよびチェック（図９、ブロック９７５を参照）の間、環境モデルに従う。環境モデルは、イベント駆動プログラムコードが実行される環境に関してユーザによってなされる個々の仮定を形式化する。例えば、上記の例示的な通信呼処理アプリケーションの場合、環境モデルは、加入者の動作、ハードウェア応答、および通信ネットワークの性能に関する形式化を含む。具体的には、図１５は、図５および図６に記載した通信処理アプリケーションに対する例示的な環境モデル１５００（プログラムコード行番号１〜８０）である。例えば、環境モデル１５００のコード断片１５１０は、例示的な通信アプリケーションで使用される通信デバイスに対する形式化（すなわち、テンプレート）を記述する。好ましい実施例によれば、モデルチェッカ（すなわち、ＳＰＩＮ）は、モデルチェッカ入力言語１２００を環境モデル１５００とともに使用して、イベント駆動システムがユーザの所望の実行の性質および動作に従っているかどうかを判定する。
【００６０】
本発明によれば、マップと環境モデルとを別々に定義しているため、もとのソースコードにルーチンの変更がなされたときに、検証インフラストラクチャはほとんど更新する必要がない。すなわち、ステートメントの新たな基本型がソースコードに導入されなければ、検証プロセスはユーザの介在なしに繰り返すことが可能であり、ソースコードは、本質的な正当性の性質の大規模なライブラリに対して引き続き従っていることをチェックすることが可能である。さらに、本発明によれば、テスト対象のイベント駆動コードを表す正確なオートマトンモデルがソースコードから直接に自動生成され、論理モデルチェッカ（例えば、ＳＰＩＮ）で検証される。
【００６１】
例えば、図１６は、図５および図６に記載した通信処理アプリケーションによって定義される特定の制御状態に対する例示的なオートマトンモデル１６００である。具体的には、図１６に示す制御状態は、ソースコードプログラム５００において制御状態５４５として定義されるいわゆる”ｒｉｎｇ”制御状態である（図５および図６を参照）。ソースコードプログラム５００の第１８３行における”＠ｒｉｎｇ”プログラムステートメントは、ソースプログラムの観点から、この特定の制御状態の明確な記述を開始する。本発明のテストおよびチェックの特徴によれば、上記のように、この制御状態から、正確なオートマトン（例えば、オートマトンモデル１６００）が抽出される。オートマトンモデル１６００は、”ｒｉｎｇ”制御状態１６１０との間の遷移と、アプリケーションの他の制御状態（すなわち、”ｄｉｇｉｔｓ＿１”制御状態１６２０、”ｉｄｌｅ”制御状態１６３０、”ｃｏｎｎ”制御状態１６４０、および”ｅｒｒｏｒ”制御状態１６５０）の間の遷移を明確に示す。また、オートマトンモデル１６００は、例示的なアプリケーションにおいて発生するさまざまなイベント（すなわち、イベント１６６０〜イベント１６９５を明確に例示している。さらに、図１７に示す完全なオートマトンモデル１７００は、図５および図６に記載された、本発明により自動生成された完全な通信処理アプリケーションの例示的な完全なオートマトンモデルである。
【００６２】
本発明の上記の実施例は、関連米国特許出願により書かれ（例えば、図５および図６を参照）、上記の本発明の原理に従ってテストされたＣソースプログラムを使用している。本発明の発明者がさらに認識したところでは、ある種のユーザ（例えば、検証システムプログラマやソフトウェアテストエンジニア）は、上記の仕様フォーマットに従って駆動されるイベントを定義することによって自分のシステム設計プロセスを開始したいと考えることがある。例えば、このようなユーザは、問題となるイベント駆動システムを直接にコーディングするために上記の仕様フォーマットを使用することが考えられる。本発明のこのような実施例によれば、このような変換を容易にするためにテンプレートが用いられる。以下に、このような状態マシンコードをコンパイルおよび実行のために標準Ｃに変換する際に用いられる例示的なＣコードテンプレートを示す。
0003631647.tif 000012
0003631647.tif 000013
【００６３】
上記のＣコードテンプレートは、状態マシン仕様からＣへの完全な変換のためのフレームワークを提供する。認識されるように、この例示的なＣコードテンプレートは、モデルチェッカツール自体によって、または、別のマシン上で、実行されることが可能である。テンプレートは、変換実装のコアとして使用される”ｓｔａｔｅ”と呼ばれるルーチンに渡される引数の型定義を含む。このルーチンは、問題としているイベント駆動システムに関連するイベントが発生するときに必ず呼び出されなければならない。テンプレートコードはさらに、本発明に従って指定される遷移規則から生成される状態マシンに対するプレースホルダ”＠Ｃ”を含む。状態マシンの生成に必要な実際のプログラムコードは、当業者には直ちに理解されるはずであり、ここでこれ以上説明する必要はない。各呼出し時に、”ｓｔａｒｔ”ルーチンが実行され、現在のイベントに関する詳細な情報を記憶するために環境によって使用されるデータ構造体からイベント型およびパラメータ値を取得する。プロセスの現在の状態は、ルーチンへの第１引数のデータ構造体から取得され、いわゆるＣのｓｗｉｔｃｈ文がこの状態値に対して実行されて、遷移規則における正しい位置を確定する。テンプレートの略記号”＠＠”は、ツールによって、すべての制御状態の名前の完全なリストに展開され、生成後（すなわち、変換後）のＣコードにおいて、各状態の遷移規則に対するコード断片が置かれる場所へのジャンプが対応する。本発明の実施例によれば、仕様は、直接のコンパイルおよび実行のために、ターゲットプログラミング言語（例えば、Ｃ）に変換される。
【００６４】
例えば、図１８は、本発明に従ってイベント駆動ソフトウェアコードを実行しテストする際に用いられる例示的なコンピュータシステム１８００を示す。具体的には、コンピュータシステム１８００は、ディスプレイ１８２０およびキーボード１８３０に接続された通常のパーソナルコンピュータ１８１０を含む。認識されるように、例えば特定のイベント駆動ソフトウェアコードの実行中にパーソナルコンピュータ１８１０によって生成される情報は、コンピュータシステム１８００のユーザによるアクセスのために、ディスプレイ１８２０に表示されることが可能である。ユーザは、ディスプレイ１８２０を見た結果として、通常のように、キーボード１８３０を用いて、パーソナルコンピュータ１８１０と対話しパーソナルコンピュータ１８１０を制御する。さらに、マウス１８８０やその他の周知のポインティングデバイスにより、ユーザは、パーソナルコンピュータ１８１０にさらに入力を提供することが可能である。例示的なコンピュータシステム１８００は、さらに、例えば本発明に従ってイベント駆動アプリケーションソフトウェアコードを実行しテストするプロセッサ１８４０を有する。例えば、このようなイベント駆動アプリケーションソフトウェアコードは、通常のディスケット１８７０によりパーソナルコンピュータ１８１０にロードされた後、内部ディスクメモリ１８６０に記憶される。さらに、このコードの実行およびテストは、通常のようにして、ランダムアクセスメモリ１８５０（ＲＡＭ）のアクセスおよび使用を必要とする。こうして、コンピュータシステム１８００のユーザは、本発明に従って、ソフトウェアを実行しテストして、さまざまなアプリケーション（例えば、イベント駆動システム）を提供することができる。さらに、認識されるように、コンピュータシステム１８００は、通常のようにして、特定のアプリケーションプログラムの実行およびテストのために、他のコンピュータシステムやデバイスに接続されることも可能である。
【００６５】
例えば、コンピュータシステム１８００は、本発明に従って、ソフトウェアを実行しテストするために用いられ、図１９に示すようなエラートレース１９００を生成することが可能である。エラートレース１９００は、プログラムコード１９１０（プログラムコード行番号１〜４７）からなり、図５および図６に記載した通信処理アプリケーションに対して、本発明によって生成された例示的なエラートレースである。具体的には、例示的なエラートレース１９００は、イベント駆動システムのもとのソースコードにおけるエラーの存在を直接に識別するシナリオをどのようにしてチェックプロセスが生成しているかを示す。さらに、エラートレース１９００は、プログラムコード１９１０により、エラーを再現するために実行することが可能なプログラミングレベルのステートメント（例えば、Ｃレベルのステートメント）で、このようなエラーを識別する。例示的なエラートレース１９００では、このトレースは、Ｃプログラムコードステートメントの直接のシーケンス（図９、プログラムコード１９２０を参照）で、イベント駆動システムが、実行により、処理される最初のイベントを”Ｃｒｄｉｇｉｔ”として、例示的な状態”＠ｂｕｓｙ”になることを示す。Ｃソースプログラムコード５００（特に、第２２３行の制御状態５５５）とともに、エラートレース１９００から認識されるように、このイベントの発生の可能性を予期するものはプログラムコードにはない（すなわち、コーディングエラーはない）。本発明によれば、ユーザは、モデル自体の専門的な知識や、チェックプロセス自体で用いられる中間表現の大部分についての専門的な知識なしで、エラートレース１９００のみをＣレベルの実行ステートメントで解釈することができる。
【００６６】
以上、本発明の実施例について説明したが、当業者であればさまざまな変形が可能であり、そのような変形例も本発明の技術的範囲に入る。例えば、当業者には認識されるように、ブロック図は、本発明の原理を実現する回路例の概念図を表す。同様に、認識されるように、フローチャート、流れ図、状態遷移図、擬似コード、プログラムコードなどは、コンピュータ可読な媒体において実質的に表現され、コンピュータ、マシン、あるいはプロセッサによって（そのようなコンピュータ、マシン、あるいはプロセッサが明示的に図示されているか否かにかかわらず）実行されることが可能なさまざまなプロセスを表す。
【００６７】
さらに、特許請求の範囲において、指定された機能を実行する手段として表現された要素は、例えば、（ａ）その機能を実行する回路要素の組合せ、または、（ｂ）その機能を実行するソフトウェアを実行するために適当な回路と組み合わせられた任意の形式の（従って、ファームウェア、オブジェクトコード、マイクロコードなどを含む）ソフトウェア、などのような、その機能を実行する任意の手段を含む。
【００６８】
【発明の効果】
以上述べたごとく、本発明によれば、イベント駆動ソフトウェアを効率的にテストし、ソースコードの通常の保守、拡張および改定のプロセスの一部として、プログラムコードへの変更の妥当性を追跡することを可能にする技術が提供される。
【図面の簡単な説明】
【図１】例示的なイベント駆動システムのブロック図である。
【図２】図１の例示的なイベント駆動システムで用いられる例示的な通信呼処理アプリケーションに対する通常のＣソースコードプログラムの例を示す図である。
【図３】図１の例示的なイベント駆動システムで用いられる例示的な通信呼処理アプリケーションに対する通常のＣソースコードプログラムの例を示す図である。
【図４】本発明の原理によるソフトウェア開発の例示的なオペレーションの流れ図である。
【図５】図２および図３の例示的な通信呼処理アプリケーションに対する、図４のソフトウェア開発オペレーションに従って構造化され定義された、例示的なＣソースコードプログラムの図である。
【図６】図２および図３の例示的な通信呼処理アプリケーションに対する、図４のソフトウェア開発オペレーションに従って構造化され定義された、例示的なＣソースコードプログラムの図である。
【図７】図５および図６の例示的なＣソースコードプログラムから、本発明の原理に従って導出された、翻訳済みソースコードプログラムの図である。
【図８】図５および図６の例示的なＣソースコードプログラムから、本発明の原理に従って導出された、翻訳済みソースコードプログラムの図である。
【図９】本発明の原理に従ってイベント駆動ソフトウェアをテストする例示的なオペレーションの流れ図である。
【図１０】図５および図６の例示的なＣソースコードプログラムから導出される中間状態マシンコードの図である。
【図１１】図５および図６の例示的なＣソースコードプログラムによって定義されるイベント駆動システムの例示的なマップの図である。
【図１２】図１１の例示的なマップを適用することから導出されるモデルチェッカ入力言語の図である。
【図１３】図１１の例示的なマップを適用することから導出されるモデルチェッカ入力言語の図である。
【図１４】図１２および図１３のモデルチェッカ入力言語とともに使用される例示的なライブラリ関数のセットの図である。
【図１５】図５および図６に記述される通信処理アプリケーションに対する例示的な環境モデルの図である。
【図１６】図５および図６の通信処理アプリケーションによって定義される特定の制御状態に対する例示的なオートマトンモデルの図である。
【図１７】図５および図６に記述される完全な通信処理アプリケーションの例示的な完全なオートマトンモデルの図である。
【図１８】本発明に従って指定され書かれたイベント駆動ソフトウェアコードを実行する際に用いられる例示的なコンピュータシステム１８００の図である。
【図１９】図５および図６に記述される通信処理アプリケーションに対して、本発明の原理に従って生成される例示的なエラートレースの図である。
【符号の説明】
１００  通信ネットワーク
１０５  通信デバイス
１１０〜１１４  市内局
１１５  市外交換機
１２０  市外交換機
１２５  市外交換機
１３０  市外交換機
１３５  データリンク
１４０  ネットワーク制御ポイント（ＮＣＰ）
１５０  市外網
１６０  アジャンクト
２００  ソースコードプログラム
５００  ソースコードプログラム
５１０〜５５５  制御状態
７００  翻訳済みソースコードプログラム
１０００  中間状態マシンコード
１１００  マップ
１１２０  イベント定義
１１３０  コード定義
１２００  モデルチェッカ入力言語
１４００  ライブラリ関数
１５００  環境モデル
１６００  オートマトンモデル
１６１０  ”ｒｉｎｇ”制御状態
１６２０  ”ｄｉｇｉｔｓ＿１”制御状態
１６３０  ”ｉｄｌｅ”制御状態
１６４０  ”ｃｏｎｎ”制御状態
１６５０  ”ｅｒｒｏｒ”制御状態
１７００  完全なオートマトンモデル
１８００  コンピュータシステム
１８１０  パーソナルコンピュータ
１８２０  ディスプレイ
１８３０  キーボード
１８４０  プロセッサ
１８５０  ランダムアクセスメモリ
１８６０  内部ディスクメモリ
１８７０  ディスケット
１８８０  マウス
１９００  エラートレース
【図１】
0003631647.tif 000014
【図２】
0003631647.tif 000015
【図３】
0003631647.tif 000016
【図４】
0003631647.tif 000017
【図５】
0003631647.tif 000018
【図６】
0003631647.tif 000019
【図７】
0003631647.tif 000020
【図８】
0003631647.tif 000021
【図９】
0003631647.tif 000022
【図１０】
0003631647.tif 000023
【図１１】
0003631647.tif 000024
【図１２】
0003631647.tif 000025
【図１３】
0003631647.tif 000026
【図１４】
0003631647.tif 000027
【図１５】
0003631647.tif 000028
【図１６】
0003631647.tif 000029
【図１７】
0003631647.tif 000030
【図１８】
0003631647.tif 000031
【図１９】
0003631647.tif 000032