(57)【要約】【課題】ソフトウェアが実行されたときのプロセスによるメモリ、子プロセス又はスレッドの状態を対象として、ソフトウェアを検査することを目的とする。【解決手段】ソフトウェアが実行されたときのプロセスにおける所定の状態及び対応する動作を記述したシナリオを用いてソフトウェアを検査する検査装置におけるソフトウェア検査方法は、前記検査装置の動的追跡器が、検査対象のプロセスによるメモリ、子プロセス又はスレッドを監視する監視ステップと、前記検査装置の検査器が、前記動的追跡器により監視されたメモリ、子プロセス又はスレッドの情報とシナリオとに基づき、前記動的追跡器に対して動作を指示する指示ステップと、前記動的追跡器が、前記検査器からの指示に基づいて、検査対象のプロセスを制御する制御ステップとを有する。【選択図】図１
2014206807.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアが実行されたときのプロセスにおける所定の状態及び対応する動作を記述したシナリオを用いてソフトウェアを検査する検査装置におけるソフトウェア検査方法であって、
前記検査装置の動的追跡器が、検査対象のプロセスによるメモリ、子プロセス又はスレッドを監視する監視ステップと、
前記検査装置の検査器が、前記動的追跡器により監視されたメモリ、子プロセス又はスレッドの情報とシナリオとに基づき、前記動的追跡器に対して動作を指示する指示ステップと、
前記動的追跡器が、前記検査器からの指示に基づいて、検査対象のプロセスを制御する制御ステップと、
を有するソフトウェア検査方法。
【請求項２】
前記監視ステップは、前記動的追跡器が、検査対象のプロセスのグローバル変数が割り当てられているメモリ上のページと、実行時に確保されるメモリ上のページの書き込み権限を削除することにより、メモリ上の状態の変化を監視する、請求項１に記載のソフトウェア検査方法。
【請求項３】
前記監視ステップは、前記動的追跡器が、検査対象のプロセスによるメモリの確保と開放とを監視する、請求項１又は２に記載のソフトウェア検査方法。
【請求項４】
前記監視ステップは、前記動的追跡器が、検査対象のプロセスによる子プロセス又はスレッドの生成と終了とを監視する、請求項１乃至３のうちいずれか１項に記載のソフトウェア検査方法。
【請求項５】
前記指示ステップは、前記動的追跡器により監視されたメモリ、子プロセス又はスレッドの情報がシナリオに記述された所定の状態を満たす場合、前記動的追跡器に対してフォールトインジェクション又はアサーションの確認を指示する、請求項１乃至４のうちいずれか１項に記載のソフトウェア検査方法。
【請求項６】
ソフトウェアが実行されたときのプロセスにおける所定の状態及び対応する動作を記述したシナリオを用いてソフトウェアを検査する検査装置として、コンピュータを機能させるためのプログラムであって、当該コンピュータを
検査対象のプロセスによるメモリ、子プロセス又はスレッドを監視する動的追跡手段、及び
前記動的追跡手段により監視されたメモリ、子プロセス又はスレッドの情報とシナリオとに基づき、前記動的追跡手段に対して動作を指示する検査手段、
として機能させ、
前記動的追跡手段は、前記検査手段からの指示に基づいて、検査対象のプロセスを制御するプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア検査方法及びプログラムに関する。特に、本発明は、複数のプロセスが複数のマシンで実行される分散システム環境においても、複数のプロセスの内部の状態に基づくテストやデバッグの実行を可能とするソフトウェア検査技術に関する。
【背景技術】
【０００２】
複雑なプロトコルを実装した分散システムをデバッグする場合、その分散システムの形式的なモデルをモデル記述言語を用いて作成し、モデル検査器を利用してプロトコルが要求される性質を満たすか検査するという方法が広く採用されている（非特許文献１参照）。
【０００３】
この方法では、分散システムの各ノードの状態遷移を形式的に記述した状態遷移機械のモデルを作成し、それらの分散システム全体を状態遷移機械の直積として定義する。このように定義された状態遷移機械について、起こり得るすべての遷移を辿り、それぞれの状態について与えられた性質が満たされているかどうか検査することで、プロトコルにバグが含まれていないことを検査する。
【０００４】
上記の方法は網羅的な検査を行うために必要とされる時間的コストが比較的小さいという点では優れているが、作成したモデルと実装との乖離が無いことを機械的に確認する術がないという欠点を持つ。そのため、検査対象を実装そのものとするモデル検査技術も存在する（非特許文献２参照）。
【０００５】
非特許文献２で紹介されている技術はWindows（登録商標）上で動作するアプリケーションを対象としており、Win32 APIの呼び出しを契機として検査器に状態の更新を通知する。検査器は状態の更新の通知を受け取ると、Win32 APIの呼び出しを失敗させるかどうかを判断し、検査対象のプロセスに指示を送る。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Gerard J. Holzmann. The Model Checker SPIN. Journal: IEEE Transactions on Software Engineering, vol. 23, no. 5, pp. 279-295, 1997.
【非特許文献２】Junfeng Yang, Tisheng Chen, Ming Wu, Zhilei Xu, Xuezheng Liu, Haoxiang Lin, Mao Yang, Fan Long, Lintao Zhang, Lidong Zhou. MODIST: Transparent Model Checking of Unmodified Distributed Systems. In proceedings of the Networked Systems Design and Implementation - NSDI , pp. 213-228, 2009.
【発明の概要】
【発明が解決しようとする課題】
【０００７】
非特許文献２で紹介されている技術は、実装を検査対象として網羅的な検査を行うことを可能にしているが、検査器に状態の更新を通知するタイミングがOS（Operating System）のシステムコール呼び出しに限定されている。そのため、プロセスのメモリ内の状態の変化を契機としてフォールトインジェクションを行うことが出来ないという課題を持っている。
【０００８】
本発明は、ソフトウェアが実行されたときのプロセスによるメモリ、子プロセス又はスレッドの状態を対象として、ソフトウェアを検査することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一形態に係るソフトウェア検査方法は、
ソフトウェアが実行されたときのプロセスにおける所定の状態及び対応する動作を記述したシナリオを用いてソフトウェアを検査する検査装置におけるソフトウェア検査方法であって、
前記検査装置の動的追跡器が、検査対象のプロセスによるメモリ、子プロセス又はスレッドを監視する監視ステップと、
前記検査装置の検査器が、前記動的追跡器により監視されたメモリ、子プロセス又はスレッドの情報とシナリオとに基づき、前記動的追跡器に対して動作を指示する指示ステップと、
前記動的追跡器が、前記検査器からの指示に基づいて、検査対象のプロセスを制御する制御ステップと、
を有することを特徴とする。
【００１０】
また、本発明の一形態に係るプログラムは、
ソフトウェアが実行されたときのプロセスにおける所定の状態及び対応する動作を記述したシナリオを用いてソフトウェアを検査する検査装置として、コンピュータを機能させるためのプログラムであって、当該コンピュータを
検査対象のプロセスによるメモリ、子プロセス又はスレッドを監視する動的追跡手段、及び
前記動的追跡手段により監視されたメモリ、子プロセス又はスレッドの情報とシナリオとに基づき、前記動的追跡手段に対して動作を指示する検査手段、
として機能させ、
前記動的追跡手段は、前記検査手段からの指示に基づいて、検査対象のプロセスを制御することを特徴とする。
【発明の効果】
【００１１】
本発明の実施例によれば、ソフトウェアが実行されたときのプロセスによるメモリ、子プロセス又はスレッドの状態を対象として、ソフトウェアを検査することが可能になる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施例に係るソフトウェア検査装置のブロック図
【図２】本発明の実施例に係るソフトウェア検査装置内の動的追跡器のフローチャート
【図３】本発明の実施例に係るソフトウェア検査装置内の検査器のフローチャート
【図４】本発明の実施例に係るソフトウェア検査装置において複数のプロセスを検査するときの例
【発明を実施するための形態】
【００１３】
以下、本発明の実施例について詳細に説明する。
【００１４】
本発明の実施例では、ソフトウェアが実行されたときのプロセスにおける所定の状態及び対応する動作を記述したシナリオを用いてソフトウェアを検査するソフトウェア検査装置について説明する。典型的には、ソフトウェア検査装置は、記憶装置にロードされたプログラムに従ってデータを処理するコンピュータである。
【００１５】
図１に、本発明の実施例に係るソフトウェア検査装置のブロック図を示す。ソフトウェア検査装置は、シナリオ記憶部１０１と、動的追跡器１０３と、検査器１０５とを有する。
【００１６】
シナリオ記憶部１０１は、メモリ上における変数のアドレス情報を格納するシンボルテーブルと、ソフトウェアが実行されたときのプロセスにおける所定の状態及び対応する動作を記述したシナリオとを記憶する記憶装置である。シンボルテーブルは、検査対象のプロセスのグローバル変数が割り当てられているメモリ上のアドレス情報と、実行時に確保されるメモリ上のアドレス情報とを定義したテーブルである。これらのアドレス情報は、例えばDWARFと呼ばれるデバッグ用フォーマットから取得される。シナリオは、ユーザにより記述された検査器１０５に与える動作の組み合わせである。例えば、シナリオにより記述される動作には、プロセスが特定の状態になった場合、フォールトインジェクション又はアサーションの確認のような動作を行わせることが含まれる。
【００１７】
動的追跡器１０３は、検査対象のプロセスによるメモリ、子プロセス又はスレッドを監視する。例えば、動的追跡器１０３は、（１）メモリ上の状態の変化、（２）メモリの確保と開放、（３）子プロセス又はスレッドの作成と終了のうちいずれかに該当する変化が発生した場合に、検査器１０５に通知する。
【００１８】
検査器１０５は、動的追跡器１０３により監視されたメモリ、子プロセス又はスレッドの情報とシナリオとに基づき、動的追跡器１０３に対して動作を指示する。例えば、検査器１０５は、動的追跡器１０３から通知されたメモリ、子プロセス又はスレッドの情報がシナリオに記述された所定の状態を満たす場合、動的追跡器１０３に対してフォールトインジェクション又はアサーションの確認のような動作を指示する。動的追跡器１０３は、検査器１０５からの指示に基づいて、検査対象のプロセスを制御する。
【００１９】
以下に、ソフトウェア検査装置の動作の詳細について説明する。
【００２０】
＜動的追跡器の動作＞
図２に、本発明の実施例に係るソフトウェア検査装置内の動的追跡器１０３のフローチャートを示す。
【００２１】
動的追跡器１０３は、検査対象のプロセスについて、以下のいずれかの事象が発生するまで、プログラムカウンタが指す命令を実行する（ステップＳ１０１）。そして、以下のいずれかの事象が発生した場合にその情報を検査器１０５に通知する。なお、以下の事象は、これらの事象が発生した場合にプログラムが中断されるため、トラップとも呼ばれる。事象の発生は、プログラムの動的追跡ツール（例：DynamoRIO）などを利用して捕捉される。
【００２２】
動的追跡器１０３が捕捉する事象には、（１）メモリ上の状態の変化、（２）メモリの確保と開放、（３）子プロセス又はスレッドの作成と終了が存在する。
【００２３】
（１）メモリ上の状態の変化
本発明の実施例では、ソフトウェアの実装が取りうる状態を、そのソフトウェアが実行されたプロセスのグローバル変数として使用されるメモリ領域、及び実行時に確保されるメモリ領域の状態と定義する。動的追跡器１０３は、検査対象のプロセスのグローバル変数が割り当てられているページと、実行時に確保されるメモリを含むページの書き込みの権限を実行時に削除し、そのページへの書き込みが発生した場合にセグメンテーション違反を通知するシグナルハンドラが呼ばれるように設定する。なお、グローバル変数が割り当てられているページと、実行時に確保されるメモリを含むページとは、シナリオ記憶部１０１のシンボルテーブルに定義されたアドレス情報から取得される。
【００２４】
動的追跡器１０３は、セグメンテーション違反が発生したか否かを判断し（ステップＳ１０３）、セグメンテーション違反が発生した場合（ステップＳ１０３：Ｙｅｓ）、メモリ上の状態の変化が生じたと判断する。検査対象のプロセスが書き込みを禁止したページにアクセスしていない場合（ステップＳ１０５：Ｎｏ）、動的追跡器１０３は、ソフトウェアのバグであると判断し、処理を終了する（ステップＳ１０７）。監視対象のプロセスが書き込みを禁止したページにアクセスしている場合（ステップＳ１０５：Ｙｅｓ）、動的追跡器１０３は、シグナルハンドラの内部で書き込みが試みられたメモリ上のアドレスと、書き込まれた値と、書き込まれた値のサイズとを、セグメンテーション違反を発生させたプログラムカウンタが指す命令をデコードすることで求める（ステップＳ１０９）。
【００２５】
動的追跡器１０３は、求められたメモリ上のアドレスと、書き込まれた値と、書き込まれた値のサイズとを後述のメッセージとして構成し、別のプロセスとして動作している検査器１０５に送信する（ステップＳ１１１）。検査器１０５は、送られてきた情報に基づいて、保持してあるシステム全体のプロセスの状態を更新する。検査器１０５は、後述するように、システム全体のプロセスの状態を基に、指示を表現する値を動的追跡器１０３に送り返すため、動的追跡器１０３は、検査器１０５から返信されるデータを待つ。
【００２６】
ここで、検査器１０５に通知される具体的なメッセージの構成は以下の３つ組になる：
（ポインタ型：更新が行われたメモリ上のアドレス、整数型：書き込まれた値、整数型：書き込まれた値のバイト数）
（２）メモリの確保と開放
動的追跡器１０３は、ヒープ上に確保されたメモリの状態を追跡するため、ライブラリの提供するメモリの確保又は開放を行う関数と、それらが内部的に呼び出すシステムコールの呼び出しも検査器１０５に通知する必要がある。
【００２７】
ステップＳ１０３においてセグメンテーション違反が発生していない場合（ステップＳ１０３：Ｎｏ）、動的追跡器１０３は、メモリの確保又は開放、子プロセス若しくはスレッドの生成又は終了が発生したと判断する。このうち、メモリの確保又は開放について以下に説明する。
【００２８】
メモリの確保又は開放が発生した場合、動的追跡器１０３は、メモリの確保又は開放を検査器１０５に通知する（ステップＳ１１３）。検査器１０５に通知される具体的なメッセージの構成は以下のようになる：
メモリの確保の場合：（ポインタ型：割り当てられた先頭のアドレス、整数型：割り当てられた領域のバイト数）
メモリの開放の場合：（ポインタ型：開放される先頭のアドレス）
検査器１０５は、後述するように、システム全体のプロセスの状態を基に、指示を表現する値を動的追跡器１０３に送り返すため、動的追跡器１０３は、検査器１０５から返信されるデータを待つ（ステップＳ１１５）。
【００２９】
（３）子プロセス又はスレッドの作成と終了
動的追跡器１０３は、検査対象のプロセスが新しい子プロセス又はスレッドの作成又は終了を行う場合、その事象を検査器１０５に通知する（ステップＳ１１３）。子プロセスやスレッドにより行われる処理や、スレッド毎に確保されるメモリ領域の追跡のために、この事象は追跡される必要がある。検査器に通知される具体的なメッセージの構成は以下のようになる
子プロセスの生成の場合：（整数型：新しいプロセスのプロセスID）
子プロセスの終了の場合：（整数型：終了したプロセスのプロセスID）
スレッドの生成の場合：（整数型：新しいスレッドのスレッドID）
スレッドの終了の場合：（整数型：終了したスレッドのスレッドID）
検査器１０５は、動的追跡器１０３が捕捉した上記の３つの事象に応じて内部で保存されている検査対象のプロセスの状態を更新する。そして、検査対象のプロセスの状態に基づき、後述するユーザから与えられたシナリオを実行する。
【００３０】
検査対象のプロセスは検査器１０５から動的追跡器１０３を介して返された値を基に動作を行う。指示が返されるまでは処理を進行させない。指示と指示に対応して実行する動作の組み合わせは以下の３種類である。
（１）[指示]何も行わない：[動作]処理を進行させる
（２）[指示]ネットワークエラーを発生させる：[動作]プロセスが作成したTCP（Transmission Control Protocol）のコネクションを全て破棄する
（３）[指示]ディスクエラーを発生させる：[動作]プロセスが開いているファイルを全て閉じ、そのプロセスが作成したファイル全てを削除する
いずれの場合も、動的追跡器１０３は、動作の実行後、退避されたプログラムカウンタの値をセグメンテーション違反を発生させた命令のサイズだけ加算し、次の命令の実行を再開する。
【００３１】
上記の３種類の指示と動作の組み合わせの中から、検査器１０５から何もせずに次の命令を実行するように指示された場合（ステップＳ１１７：Ｙｅｓ）、すなわち、上記の指示のうち（１）が指示された場合、動的追跡器１０３は、次のプログラムカウンタが指す命令を実行する（ステップＳ１０１）。
【００３２】
一方、検査器１０５からフォールトインジェクション又はアサーションの確認が指示された場合（ステップＳ１１７：Ｎｏ）、動的追跡器１０３は、フォールトインジェクション又はアサーションの確認を行う（ステップＳ１１９）。フォールトインジェクションとは、意図的にエラーを発生させてエラー処理の異常を検査することを意味する。例えば、フォールトインジェクションは、上記の指示のうち（２）及び（３）が対応する。アサーションとは、システムの前提として記述された充足すべき要件が、実行時に充足されない場合にエラーや例外、メッセージ表示、処理中断等を発生させる機能を意味する。フォールトインジェクション又はアサーションによる検査を行うため、動的追跡器１０３は、次のプログラムカウンタが指す命令を実行する（ステップＳ１０１）。
【００３３】
＜検査器の動作＞
図３に、本発明の実施例に係るソフトウェア検査装置内の検査器１０５のフローチャートを示す。
【００３４】
検査器１０５は、検査対象のプロセスから通知された事象を基に動作を行う。このため、検査器１０５は、新たな検査対象のプロセスの開始又は検査中のプロセスの状態の更新を動的追跡器１０３から受信するまで待つ（ステップＳ２０１）。新たな検査対象のプロセスの開始である場合（ステップＳ２０３：Ｙｅｓ）、新しいプロセスを表現するためのデータを確保して初期化する（ステップＳ２０５）。新たな検査対象のプロセスの開始ではない場合（ステップＳ２０３：Ｎｏ）、検査器１０５は、対応するプロセスの状態を更新する。
【００３５】
なお、検査器１０５に与えるシナリオは以下のような状態とそれに対応する検査器１０５の動作の組み合わせの繰り返しとして記述され、シナリオ記憶部１０１に格納されている：
（プロセス1の状態，プロセス2の状態，...，プロセスnの状態）->検査器の動作
プロセス１つにつき保存される状態は、最初に作成された親プロセスと全ての子プロセスの、全てのグローバル変数、動的に確保されたメモリの使用状況、スレッド数、スレッド毎に確保されたメモリ領域となる。便宜的にこのプロセスの状態を目的の状態と呼ぶ。
【００３６】
目的の状態は、保存されているプロセスの状態の上に定義される条件として記述される。例えば、目的の状態は、所定の条件を満たすプロセスの状態として記述される。
【００３７】
上記のように、各プロセスから通知されてきた事象を基に検査器１０５は各プロセスの状態を更新する。各プロセスの状態が上記の目的の状態と一致した場合（ステップＳ２０９：Ｙｅｓ）、検査器１０５は、上記シナリオの記述例における矢印の右側に記述された動作を行う（ステップＳ２１１）。検査器１０５の動作の例としては、フォールトインジェクションや分散システム全体の状態に対するアサーションの確認、またはそれらの組み合わせなどがあげられる。各プロセスの状態が目的の状態と一致しない場合（ステップＳ２０９：Ｎｏ）、検査器１０５は、新たな検査対象のプロセスの開始又は検査中のプロセスの状態の更新を動的追跡器１０３から受信するまで待つ（ステップＳ２０１）。
【００３８】
なお、ユーザによるシナリオの記述を容易にするために、各プロセスの状態として、特殊な２つの記法を用意する。
ワイルドカード：任意の状態であることを許可する。状態の更新の通知が発生してもそのプロセスの停止は行わない。
無条件停止：n-1番目の検査器の動作が終了した後、n番目のプロセスkの状態が無条件停止だった場合、プロセスｋには状態の更新を許可しない。
【００３９】
これらの記法を用い、ユーザは検査したい状態遷移の系列を個別のシナリオとして記述することが可能になる。ユーザは各プロセスの初期状態と終了状態に加えてその間の遷移を記述し、その合成を作成することで、検査を行いたい全てのシナリオを生成することが出来る。
【００４０】
検査器１０５が全ての目的の状態を達成していない場合、すなわち、シナリオの全てが終了していない場合（ステップＳ２１３：Ｎｏ）、検査器１０５は、新たな検査対象のプロセスの開始又は検査中のプロセスの状態の更新を動的追跡器１０３から受信するまで待つ（ステップＳ２０１）。全ての目的の状態を達成した場合、すなわち、シナリオの全てが終了した場合（ステップＳ２１３：Ｙｅｓ）、検査器１０５は処理を終了する。
【００４１】
＜複数のプロセスを検査するときの例＞
図４に、本発明の実施例に係るソフトウェア検査装置において複数のプロセスを検査するときの例を示す。図４は、動的追跡器１０３が、それぞれ検査対象のプロセス1〜nの状態s1〜snを追跡し、検査器１０５に通知している様子を示す。
【００４２】
一例として、分散ストレージシステムにおいてディスクエラーを正しく処理できているかどうかを検査するシナリオについて説明する。この分散ストレージシステムはオブジェクトの単位でデータを保存し、保存の際に冗長度を設定出来るものとする。この分散ストレージシステムを４つの計算機で動作させ、冗長度を３に設定しているものとする（図４においてn=4）。つまり、１つのオブジェクトを保存した際、４つの計算機のうち３つにそのオブジェクトは保存されることになる。そして、動作中のシステムが利用している計算機が故障して動作の続行が不可能になった場合、その計算機が保存していたオブジェクトを、別の計算機から復元して冗長度を回復するための修復作業を行うものとする。そして、設定された冗長度を満たせない数の計算機しか利用出来ない状態になった場合、ユーザからの書き込みの要求を全て拒否する、という挙動を行うものとする。
【００４３】
このシステムのプロセスは初期化が完了した後、runningという真偽値型のグローバル変数がtrueに設定されるものとする。また、修復作業中はrecovery_workというポインタ型の変数が非NULLに設定され、完了後にNULLになるものとする。
【００４４】
検査するシナリオは、このシステムが４つの計算機を利用している状況で、最初に１つの計算機が故障し、それを検出した他の計算機が修復作業を開始した段階で、さらにもう１つの計算機が故障した場合、書き込みの要求が受け付けられないかということを検査する、という内容である。この場合、シナリオは以下のように記述される：
(proc0: running == true, proc1: running == true, proc2: running == true, proc3: running == true) -> kill proc3
(proc0: recovery_work != NULL, proc1: recovery_work != NULL, proc3, recover_work != NULL) -> kill proc3, assert(DENIED == write object proc0)
網羅的な検査を行いたい場合は、最初に強制終了させるプロセス、次に強制終了させるプロセス、書き込みを試されるプロセスの４＊３＊２＝２４通りの全てを網羅すれば、このシナリオを網羅的に検査することが出来る。
【００４５】
このシナリオを用いて、図１を参照して説明した通り、動的追跡器１０３は、監視対象のプロセス1〜n（上記のシナリオにおけるproc0〜proc3）によるメモリ、子プロセス又はスレッドの状態s1〜sn（上記のシナリオにおけるrunningというグローバル変数の値）を監視し、状態の遷移を検査器１０５に同期的に通知する。また、動的追跡器１０３は、検査器１０５に通知した状態に対する返信に応じた動作を行う。
【００４６】
検査器１０５は、動的追跡器１０３から通知された状態の組（s1,...sn）を更新し、初期化時に与えられた上記のシナリオを記述したファイルに基づき、検査対象のプロセス1〜n（上記のシナリオではproc0〜proc3）の進行を制御する。
【００４７】
＜本発明の実施例の効果＞
非特許文献２で紹介されている技術では、システムコールの呼び出しのみを事象として検査器に通知している。この手法では、プログラム内部のメモリの状態を得るためにはシステムコールの呼び出しの履歴からメモリの状態を推定する必要がある。また、推定によって得られた状態であるため、実際の状態との乖離の可能性は常に残ってしまう。
【００４８】
本発明の実施例では、メモリ上の状態のコピーを確実に作ることが可能となる。そのため、目的の状態に対する条件としてシナリオを記述する際、検査対象のプロセスの変数を項として記述することが可能になる。このため、本発明の実施例では、単一システムのデバッグを行う際に利用出来るアサーションと同じ利便性を、分散システムのデバッグに提供することが可能になる。
【００４９】
本発明の実施例によれば、実装したソフトウェアに対し、プロセスのメモリ状態の変化に応じた網羅的な検査を可能とすることで、精度の高い検査を効果的に実行することが可能になる。また、検査器での動作実行にあたり、利用者は検査を行いたい全シナリオを効率的に生成可能であり、検査対象の状態遷移の系列について各プロセスの初期状態と終了状態だけではなく、その間の遷移を含めて個別のシナリオとして記述可能となり、シナリオ生成効率の向上が図られる。
【００５０】
また、本発明の実施例よれば、非分散システムのデバッグ時に利用するアサーションと同様の利便性を、分散システムのデバッグに提供することが可能になる。
【符号の説明】
【００５１】
１０１  シナリオ記憶部
１０３  動的追跡器
１０５  検査器
【図１】
2014206807.tif 000003
【図２】
2014206807.tif 000004
【図３】
2014206807.tif 000005
【図４】
2014206807.tif 000006