プログラムモデル検査におけるデータベース制御装置、データベース制御方法、データベース制御プログラム
【課題】プログラムモデル検査において実行環境で使用されるＤＢのデータを復元状態へ戻す効率的なバックトラックを行う。
【解決手段】 データベースに変化があることを検出したとき、ノードＩＤを有する状態変更通知を前記プログラムモデル検査装置から受信し、ノードＩＤに関連付けてパス情報とログ情報を状態ツリー管理テーブルに記録する状態ツリー管理部と、バックトラックを実行するとき、プログラムモデル検査装置からバックトラックを開始情報と復元先ノードＩＤを有するバックトラック開始通知を受信し、復元先ノードＩＤに基づいて状態ツリー管理テーブルからパス情報とログ情報を取得し、取得した前記パス情報と前記ログ情報に基づいてデータベースを復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理部と、を備えるプログラムモデル検査におけるデータベース制御装置である。
【解決手段】 データベースに変化があることを検出したとき、ノードＩＤを有する状態変更通知を前記プログラムモデル検査装置から受信し、ノードＩＤに関連付けてパス情報とログ情報を状態ツリー管理テーブルに記録する状態ツリー管理部と、バックトラックを実行するとき、プログラムモデル検査装置からバックトラックを開始情報と復元先ノードＩＤを有するバックトラック開始通知を受信し、復元先ノードＩＤに基づいて状態ツリー管理テーブルからパス情報とログ情報を取得し、取得した前記パス情報と前記ログ情報に基づいてデータベースを復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理部と、を備えるプログラムモデル検査におけるデータベース制御装置である。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラムモデル検査において実行環境で使用されるデータベース（以降、ＤＢ）を制御する際に用いるバックトラック技術に関する。
【背景技術】
【０００２】
プログラムモデル検査を行う場合、検査対象プログラムのプログラムパスにおける各状態を構成する要素のひとつとしてＤＢに記録されたデータがある。プログラムモデル検査では、ＤＢのレコードに対し検索、参照のみを行うときはＤＢのデータの状態は変わらないが、作成、更新、削除などを行うとＤＢの状態に変化がおきる。図１０のＡに示す例では、状態Ａから状態Ｂに至るパスでＤＢデータに対して挿入（Insert）を実行し、状態Ｂから状態Ｃに至るパスで削除（Delete）を実行する。次に、プログラムモデル検査で状態Ｂから状態Ｄに至るパスを実行するために、状態Ｃから状態ＢにＤＢデータを含む実行環境を戻してから、状態Ｄに至るパスを実行する。この状態Ｃから状態Ｂに実行環境を戻すときにバックトラックが必要になる。すなわち、バックトラックはプログラムパスにおける各状態を構成する全ての要素に対して行うが、ＤＢデータに対しても行う必要がある。
【０００３】
このＤＢデータのバックトラックを実現する方法には、ＤＢスタブを用いる方法と実際のＤＢに接続して中身を書き換える方法がある。
ＤＢスタブを使用した場合、予めＤＢデータのファイルを用意しておき、各状態フェーズにおけるＤＢデータイメージを保持する。バックトラック時には、スタブプログラムの内部変数として保持し、プログラムモデル検査ツールがもつプログラムの内部変数を戻す仕組みを活用することにより状態を元に戻す。そのためには、ＤＢＭＳ（Data Base Management System）の振る舞いを模倣するスタブを準備しなければならないが、ＤＢＭＳの機能を持つスタブを作成するには多くの作業時間が発生するという問題がある。また、プログラムモデル検査対象のシステムごとに使うＤＢＭＳごとに作成するスタブが変わるため、スタブを使えるようにするにはシステム対象を変更しなければならないという問題もある。さらに、ＤＢＭＳごとに異なる部分（例えば、データ型の違い、ＤＢＭＳごとの文法の違い）が存在するため、スタブの仕組みを１つ作成すれば他のシステムでも利用できるとは限らない。
【０００４】
そこで、ＤＢスタブを使わないで実際のＤＢに接続してＤＢの内容を書き換える提案がされている。
例えば、データベーススナップショットという別の読み取り専用ポイントインタイム(point in time)コピー用のデータベースを用意し、元のデータベースの修正分のみストレージにコピーし、そのポイントインタイムビューを保持する。そして、ユーザエラーが起きてデータ復元が必要になった時に直近のスナップショットをコピーすることで以前の状態に復帰する技術が知られている。ところが、ＤＢに対してバックトラックを実行すると、管理しなければならないスナップショットの数は直近のものだけではなく、状態ツリーのルートに遡って各状態にそれぞれバックトラックを実行しなければならない。そのため、スナップショットの数がプログラムによって非常に大きなものになることがある。
【０００５】
そこで、次のような技術が提案されている。例えば、ＳＱＬ（Structured Query Language）ログを用いてＤＢデータを元に戻す方法が知られている。しかし、プログラムモデル検査のように、特定の状態のＤＢに戻すためにどのようなＳＱＬ文を発行すべきかを簡単に解くことはできない。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特表２００７−５２４１７３号公報
【特許文献２】特開２００６−２４４３９４号公報
【特許文献３】特開２００４−３４８７０１号公報
【特許文献４】特開平７−１６０５６３号公報
【特許文献５】特開２０００−１０８３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記のような実情に鑑みてなされたものであり、プログラムモデル検査において実行環境で使用されるＤＢのデータを復元したい状態へ戻す効率的なバックトラックを行うデータベース制御装置、データベース制御方法、データベース制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
態様のひとつであるプログラムモデル検査装置がプログラムモデル検査を実施する際に実行環境で使用するデータベースを制御するデータベース制御装置データベース制御装置は、記録部、バックトラック管理部を備えている。
【０００９】
記録部は、上記プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する。
【００１０】
バックトラック管理部は、上記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて上記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、上記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成する。
【発明の効果】
【００１１】
プログラムモデル検査において実行環境で使用されるＤＢのデータを復元したい状態へ戻す効率的なバックトラックを行うことができる。
【図面の簡単な説明】
【００１２】
【図１】プログラムモデル検査を行うシステムの装置の構成を示すブロック図である。
【図２】プログラムモデル検査装置の構成を示すブロック図である。
【図３】Ａはプログラムモデル検査装置から発行されたＳＱＬ文を示す図である。ＢはＳＱＬ文とノードを関連付けたコードを示す図である。
【図４】データベースの状態の例を示す図である。
【図５Ａ】プログラムモデル検査のやり取りを示すフロー図である。
【図５Ｂ】プログラムモデル検査のやり取りを示すフロー図である。
【図６】ＤＢデータ管理部の動作を示すフロー図である。
【図７】Ａ〜Ｅは状態ツリー管理テーブルを示す図である。
【図８】バックトラック管理部の動作を示すフロー図である。
【図９】本実施例がコンピュータプログラムとして実現される場合の構成を示す図である。
【図１０】Ａ〜Ｃはデータベースの状態の例を示す図である。
【発明を実施するための形態】
【００１３】
以下図面に基づいて、本発明の実施形態について詳細に説明する。
本実施例は、ＤＢのレコードに対して作成、更新、削除などを行った後にバックトラックが発生した場合、復元したい状態にＤＢのデータを戻すための効率的な方法を示すものである。
【００１４】
（構成）
図１はプログラムモデル検査における実行環境で使用されるＤＢのデータを任意の状態へ戻すバックトラックを実行するデータベース制御装置２を備えるプログラムモデル検査を行うシステムの構成を示す図である。このプログラムモデル検査を行うシステムは、プログラムモデル検査装置１、データベース制御装置２を備えている。
【００１５】
プログラムモデル検査装置１は、例えば図２に示すように、検査対象プログラム２２に対するモデル検査環境であるドライバ２１および、実際に検査対象プログラム２２が実行の際に使用するＤＢＭＳ１１（データベース管理システム）などを備えている。プログラムモデル検査装置１は、プログラム中の分岐条件（検査対象プログラム２２が保持するデータの変化に加えＤＢのレコードに対して作成、更新、削除など）が現れるたびにその時の状態を記録する。なお、プログラムモデル検査装置１は、図示しないＤＢスタブ、ネットワークスタブなども備えていてもよい。
【００１６】
ドライバ２１は、クライアント（例えば、検証実行者）の代わりに検査対象プログラム２２に対してユーザ操作を模倣した入力データ２３を入力する。そして、プログラムモデル検査装置１が、検査対象プログラム２２をさまざまなバリエーションで複数回、連続的に呼び出し、プロパティ２４に格納されている機能仕様などが満たされているかをチェックする。
【００１７】
このように、プログラムモデル検査装置１は、検査対象プログラム２２とデータをやり取りするＤＢＭＳ１１、ＤＢ用スタブ２３などに対して網羅的な検査を行う。
データベース制御装置２は、ＤＢデータ管理部３、コード保存部５（ＤＢドライバ追加モジュール４）などを備えている。
【００１８】
ＤＢドライバ追加モジュール４はコード保存部５を備え、通常ＤＢデータベースに含まれるＤＢ用ドライバ（例えばＪＤＢＣ（Java Data Base Connectivity）など)から発行されるコード（例えば、ＳＱＬ文）をログファイル６に保存する（図３のＡ）。なお、本例ではＳＱＬを用いているが、リレーショナルデータベースの操作を行なうための言語であればＳＱＬに限定するものではない。検査対象プログラム２２が使用するＤＢＭＳ１１によってログファイルを保存できる機能を有しているため、その場合にはコード保存部５の代わりに該機能を用いてもよい。
【００１９】
状態ツリー管理部７は、各状態に戻るためのパスを把握するために、プログラムモデル検査装置１の状態ツリーと同等の情報を管理する。また、状態ツリー管理部７は、プログラムモデル検査装置１からプログラムパスの分岐と、プログラムの新しい状態を示すノードＩＤ（識別番号）を有する状態変更通知を受信する。そして、新しい状態に対応するノードＩＤに、直前の状態と新しい状態間のパスを関連付けて、後述する状態ツリー管理テーブルに記録する。
【００２０】
ログファイル管理部８は、プログラムモデル検査装置１から状態変更通知を受信すると、ＳＱＬログファイル６を読み込み、パス状態が変化するたびに状態遷移間で発行されたＳＱＬ文を取得して管理する。ログファイル管理部８は、ログファイル６を読み込み、前回発行された状態変更通知から今回発行された状態変更通知を受信するに至るまでのコード（例えば、ＳＱＬ文）を抽出し、ノードＩＤと結びつけて管理する（図３のＢ）。例えば、図４に示す状態１から状態２に遷移するパスであれば、状態２に対応するノードＩＤに状態１から状態２に至る間に発行されたＳＱＬ文を全て関連付けて記録する。また、状態２から状態３に遷移するパスであれば、状態３に対応するノードＩＤに状態２から状態３に至る間に発行されたＳＱＬ文全てを関連付けて記録する。なお、図４の各状態に割り振った番号はプログラムモデル検査装置１がプログラムモデル検査を行う順番と対応付けられている。
【００２１】
バックトラック管理部９は、プログラムモデル検査装置１からバックトラックを実行する通知を受信すると、ＤＢＭＳ１１を初期状態に戻して目的の状態にするためのＤＢ制御コード（例えば、ＳＱＬ文）を作成する（詳細は後述する）。
ＤＢ制御コード発行部１０は、バックトラック管理部９で作成したＤＢ制御コードをＤＢＭＳ１１に発行する。
【００２２】
（動作説明）
図５はプログラムモデル検査装置１、ＤＢデータ管理部３、コード保存部５、検査対象プログラム２２、ＤＢＭＳ１１の動作を説明するフロー図である。
【００２３】
ステップＳ１では、ＤＢデータ管理部３がＤＢを初期状態にするためのコードを有する検査開始通知をＤＢＭＳ１１に送信する。例えば、ＤＢを初期状態にするＳＱＬ文を、ＤＢドライバ追加モジュール４を介して出力する。
【００２４】
ステップＳ２では、ＤＢＭＳ１１が初期状態にするためのコードを受信する。ステップＳ３では、ＤＢＭＳ１１がＤＢを初期状態にする。
ステップＳ４では、プログラムモデル検査装置１がプログラムモデル検査を開始する。
【００２５】
ステップＳ５では、プログラムモデル検査装置１がコードをコード保存部５とＤＢＭＳ１１へ出力を開始する（図３のＡ参照）。
ステップＳ６では、コード保存部５がコードをログファイル６に記録する。また、ステップＳ７ではＤＢＭＳ１１がコードを受信する。
【００２６】
ステップＳ８では、ログファイル管理部８がログファイル６の読み込みを開始する。
ステップＳ９では、プログラムモデル検査装置１がＤＢの状態変化を判定する。例えば、プログラムモデル検査装置１がＳＱＬ文に記述されている分岐条件となる挿入（ｉｎｓｅｒｔ）、更新（ｕｐｄａｔｅ）、削除（ｄｅｌｅｔｅ）などを検出する。
【００２７】
ステップＳ１０では、プログラムモデル検査装置１がステップＳ９で検出した状態変化を後述する状態変更通知をＤＢデータ管理部３へ送信する。
ステップＳ１１では、ＤＢデータ管理部３が状態変更通知を受信する。ＤＢデータ管理部３は、状態変更通知に基づいてＤＢの状態に変化があったことを検知する。
【００２８】
ステップＳ１２では、ＤＢデータ管理部３がコード保存部５からコードを読み込む。
ステップＳ１３では、ＤＢデータ管理部３がコード保存部５から取得したコードと状態を関連付ける（詳細については後述する）。
【００２９】
通常時、ステップＳ４〜ステップＳ１３に示した処理を繰り返し実行し、バックトラックを行う場合にはステップＳ１５に移行する。
ステップＳ１４では、プログラムモデル検査装置１がバックトラックを行うか否かを判定し、バックトラックを行う場合はステップＳ１５に移行する。例えば、プログラムモデル検査装置１が既存の機能によりこれ以上状態が変化しないことを検出する。なお、バックトラックを実行するとき、プログラムモデル検査装置１はプログラムモデル検査を中断する。そして、バックトラック処理が完了したことを検出すると、プログラムモデル検査を再開する。例えば、ＪＰＦ（Ｊａｖａ Ｐａｔｈｆｉｎｄｅｒ）などを用いることにより、プログラムモデル検査装置１とデータベース制御装置２の切り替え同期を取る。
【００３０】
ステップＳ１５では、プログラムモデル検査装置１が後述するバックトラック開始通知をＤＢデータ管理部３に送信する。
ステップＳ１６では、バックトラック開始通知をＤＢデータ管理部３が受信する。
【００３１】
ステップＳ１７では、ＤＢデータ管理部３がバックトラック処理を実行する（詳細については後述する）。
ステップＳ１８では、ＤＢデータ管理部３がＤＢＭＳ１１のＤＢを初期状態にするコードを、ＤＢドライバ追加モジュール４を介してＤＢＭＳ１１に送信する。
【００３２】
ステップＳ１９では、ＤＢＭＳ１１が初期状態にするコードを受信し、ステップＳ２０でＤＢＭＳ１１がＤＢを初期状態にする。
ステップＳ２１では、ＤＢデータ管理部３がバックトラック開始通知に示されているＤＢＭＳ１１をロールバックする情報（復元先ノードＩＤ）に基づいて生成されたコードを、ＤＢドライバ追加モジュール４を介してＤＢＭＳ１１に送信する。
【００３３】
ステップＳ２２では、ＤＢＭＳ１１がＤＢをロールバックするコードを受信し、ステップＳ２３でＤＢＭＳ１１がＤＢに対して指定された状態にロールバックする指示を出力する。
【００３４】
ステップＳ２４では、ステップＳ２２の処理が完了すると、ＤＢデータ管理部３がプログラムモデル検査装置１に対して状態復元終了通知を送信する。状態復元終了通知は、プログラムモデル検査装置１にプログラムモデル検査を再開させるとともに、データベース制御装置２からプログラムモデル検査装置１に動作を切り替える通知である。
【００３５】
（ＤＢデータ管理部の動作説明）
図４に示す状態ツリーを持つプログラム状態を想定して、図６に示すフロー図を用い、ＤＢデータ管理部３の動作を説明する。なお、本例ではＳＱＬ文をコードとして用いるものとする。
【００３６】
ステップＳ３１では、ＤＢデータ管理部３が、ＤＢＭＳ１１のＤＢを初期状態（図４の状態１）にするためにＳＱＬ文をプログラムモデル検査装置１に発行する。例えば、図７のＡに示す「delete * from TB1」「delete * from TB5」などを発行する。初期状態にするＳＱＬ文は、予めユーザ（検証実行者）が状態ツリー管理テーブルに記録する。また、「ＴＢ１」「ＴＢ５」はＤＢＭＳ１１にも受けられているテーブルなどである。
【００３７】
なお、図７のＡ〜Ｅに示す状態ツリー管理テーブルは、「ノードＩＤ」「パス」「ＳＱＬ」を記録するセルを有し、「ノードＩＤ」にはプログラムモデル検査装置１から通知される状態を示す識別番号を記録する。「パス」には「ノードＩＤ」に関連付けられ、分岐点の状態と遷移した状態を示す内容（パス情報）を記録する。例えば、状態２から状態３への分岐であれば「２→３」のように記録する。「ＳＱＬ」には、「ノードＩＤ」に関連付けられ、分岐（状態遷移）が検出されるまでに発行されたＳＱＬ文が記録される。
【００３８】
ステップＳ３２では、ＤＢデータ管理部３が、プログラムモデル検査装置１からＤＢドライバ追加モジュール４を介して検査開始通知（再開時にも通知される）を受信する。検査開始通知は、プログラムモデル検査装置１が検査を開始もしくは再開するときに発行される情報である（図６のＡ参照）。
【００３９】
ステップＳ３３では、コード保存部５がＤＢＭＳ１１から発行されるＳＱＬ文をログファイル６へ記録する。図３のＡにＤＢＭＳ１１から発行されるＳＱＬ文の例を示す。
ステップＳ３４（状態ツリー管理処理）では、状態ツリー管理部７がプログラムモデル検査装置１からＤＢドライバ追加モジュール４を介して状態変更通知を受信する。状態変更通知は、検査中のプログラムのパスに状態変更があるとき通知され、この通知が状態変更を示す通知であることを示す状態変更コードと、新たな状態を示すノードＩＤを有している（図６のＢ参照）。例えば、図４の状態１から状態２（分岐点）への遷移であれば、状態２を示すノードＩＤとして「２」が通知される。
なお、プログラムモデル検査装置１は、プログラム中の分岐条件が現れるたびにその時の状態を記憶している。
【００４０】
ステップＳ３５（ログファイル管理処理）では、ログファイル管理部８がＳＱＬ文に状態変更のマークを記録する。図３のＢにＤＢＭＳ１１から発行されるＳＱＬ文の例を示す。図３のＢの例ではマークとして［初期状態]、［ノードＩＤ２]〜［ノードＩＤ６]を記述している。なお、本例ではコメント記号「／＊」「＊／」を用いマークをコメント文として扱っている。
【００４１】
ステップＳ３６（状態ツリー管理処理）では、状態ツリー管理部７では、新たな状態を示す「ノードＩＤ」を状態ツリー管理テーブルに追加記録する。例えば、図４の状態１から状態２（分岐点）への遷移であれば、図７のＢに示すように状態ツリー管理テーブルの「ノードＩＤ」に「２」を追加する。そして、「パス」に「ノードＩＤ」の「１」（状態１）から進んでプログラム分岐点である状態２が検出されたことを示す「１→２」を記録する。また、ログファイル管理部８で記録された状態１から状態２に至る間で発行されたＳＱＬ文を順番に「ＳＱＬ」に記録する。
【００４２】
同様に、状態２から状態３、状態３から状態４への遷移についてもステップＳ３３〜Ｓ３６と同じように処理をする。その結果、図７のＢ、Ｃに示す状態ツリー管理テーブルが生成される。
【００４３】
ステップＳ３７〜Ｓ３９、Ｓ４１（バックトラック管理処理）、ステップＳ４０（ＤＢ制御コード発行処理）によりバックトラック処理を行う。
ステップＳ３７では、バックトラック管理部９がプログラムモデル検査装置１からバックトラック開始通知を受信し、バックトラック開始通知を受信したときステップＳ３８に移行し、受信しないときステップＳ３３に移行する。バックトラック開始通知は、バックトラック開始を示すコードと、復元先の状態を示す識別番号である復元先ノードＩＤを有している。例えば、図４において状態４までプログラムが進むと直近のプログラム分岐状態３に戻るバックトラック開始通知を、バックトラック管理部９がプログラムモデル検査装置１から受信する。
【００４４】
ステップＳ３８では、バックトラック管理部９が復元先ノードＩＤを取得する。
ステップＳ３９では、バックトラック管理部９が状態ツリー管理テーブルから復元先ノードＩＤに示されたノードＩＤを検索し、初期状態から復元先ノードＩＤに示された状態に至るまでのパスとＳＱＬ文を全て抽出する。そして、抽出したＳＱＬ文をパスの順序と逆に並べ替えてＳＱＬ文（ＤＢ制御コード）を生成してＤＢ制御コード発行部１０に送信する。
【００４５】
ステップＳ４０（ＤＢ制御コード発行処理）では、ＤＢ制御コード発行部１０がステップＳ３９で生成したＳＱＬ文を順番にＤＢＭＳ１１に発行する。
ステップＳ４１では、バックトラック管理部９がプログラムモデル検査装置１に状態復元終了通知を送信する。
【００４６】
図４の場合であれば、ＤＢデータバックトラック部２は、状態４までプログラムが進むと、「ノードＩＤ」の「３」が示す状態３からプログラムモデル検査装置１が実行され、状態５とその間に発行されたＳＱＬ文を状態ツリー管理テーブルに記録する。
【００４７】
状態５までプログラムが進むと直近のプログラム分岐状態２に戻るようにプログラムモデル検査装置１から通知を受け取る。そのため状態２に戻るためのバックトラックの処理に移る。
【００４８】
次に、ＤＢ制御コード発行部１０がＳＱＬ文を発行して、ＤＢＭＳ１１を状態２に戻す。
次に、図４の状態２からプログラムモデル検査装置１が実行され、状態２から状態６の間に発行されたＳＱＬ文が状態ツリー管理テーブルの「ＳＱＬ」に記録される。
【００４９】
なお、プログラムモデル検査装置１からコード（ＳＱＬ文）が出力されるのは、プログラムモデル検査装置１の検査対象プログラム２２が動作した時のみであるため、バックトラック時はプログラムが動作しない。そのため、検査対象プログラム２２からのコード（ＳＱＬ文など）は無視される。よって、バックトラック時の動作はログファイル６に記録されない。
【００５０】
（バックトラック管理部の動作説明：バックトラック管理処理）
図８はバックトラック管理部９の動作を示すフロー図である。
【００５１】
ステップＳ５１では、バックトラック管理部９がプログラムモデル検査装置１からバックトラック開始通知を受信するまで待機する。例えば、図４に示した状態４から状態３に戻る場合であれば、状態ツリー管理テーブルには図７のＣに示すように「ノードＩＤ」の「１」〜「４」に対応する「パス」「ＳＱＬ」が生成され記録されている。
【００５２】
ステップＳ５２では、バックトラック管理部９がプログラムモデル検査装置１からバックトラック開始通知を受信する。例えば、バックトラック開始通知は、図８のＡに示すように、バックトラック開始を示すコード（「ｓｔａｒｔコード」）、復元先ノードＩＤ（復元先の状態を示す識別番号）を有している。図４に示す状態３にプログラムモデル検査が戻る場合であれば、復元先ノードＩＤとして「３」がプログラムモデル検査装置１から送信され、バックトラック管理部９が復元先ノードＩＤに基づいて状態３へバックトラックすることを認識する。
【００５３】
ステップＳ５３では、バックトラック管理部９が状態ツリー管理テーブルから復元先ノードＩＤに対応する「ノードＩＤ」を検索する。例えば、復元先ノードＩＤが「３」であれば、図７のＣの状態ツリー管理テーブルの中から「ノードＩＤ」が「３」である行を探索する。そして、探索結果である「３」を記録部に記録する（図８のＢ）。
【００５４】
ステップＳ５４〜Ｓ５６では、バックトラック管理部９が初期状態を示す「ノードＩＤ」から復元先ノードに対応する状態に至るまでのパスを抽出する。
ステップＳ５４では、バックトラック管理部９が、復元先ノードに対応する「ノードＩＤ」に関連付けられている「パス」を抽出する。また、ステップＳ５６で検出された「ノードＩＤ」に対応する「パス」を抽出する。
【００５５】
ステップＳ５５では、バックトラック管理部９が、抽出した「パス」に前のノードＩＤ（前状態）に初期状態が示されているかを判定し、初期状態を示していればステップＳ５７に移行し、初期状態を示していない場合にはステップＳ５６に移行する。例えば、図７の場合であれば「ノードＩＤ」の「１」が図４の状態１である初期状態を示しているので、「パス」に記録されている「１→２」を検出したときステップＳ５７に移行する。
【００５６】
ステップＳ５６では、バックトラック管理部９が、記録した「パス」の前のノードＩＤに対応する「ノードＩＤ」を、状態ツリー管理テーブルから抽出する。
【００５７】
図４の状態４から状態３へバックトラックする場合について説明する。
ステップＳ５４では図８のＣに示すように、「ノードＩＤ」の「３」に関連付けられている「パス」である「２→３」を抽出する。各「ノードＩＤ」に関連付けられた各「パス」は「Ａ→Ｂ」のように示されており、Ｂは同じレコードに関連付けられている「ノードＩＤ」を示し、ＡはＢに示される「ノードＩＤ」に辿り着く前のノードＩＤを示している。
【００５８】
例えば、ステップＳ５５において「２→３」の前のノードＩＤが「２」であるので、前の状態が初期状態ではないためステップ５６に移行する（ステップＳ５：１回目）。
ステップ５６では、ステップＳ５５で記録した図８のＣに示すノードＩＤ（１回目）のパス「２→３」から前のノードＩＤである「２」を抽出する（図８のＥ）。
【００５９】
ステップＳ５４では、図８のＣに示すように、「ノードＩＤ」の「２」に関連付けられている「パス」である「１→２」を抽出する。
次に、ステップＳ５５では、「１→２」の前のノードＩＤが「１」であるので、初期状態と判定してステップ５７に移行する（ステップＳ５５：図８のＤの２回目）。
【００６０】
上記のようにして、バックトラック管理部９が初期状態を示す「ノードＩＤ」から復元先ノードに対応する状態に至るまでのパス（状態１→状態２→状態３）を抽出する。
ステップＳ５７では、バックトラック管理部９が、記録した「パス」に関連付けられた「ノードＩＤ」に対応する「ＳＱＬ」にあるＳＱＬ文を状態ツリー管理テーブルから抽出する。例えば、図８のＦに示すように「ノードＩＤ」の「３」に対応するＳＱＬ文、「ノードＩＤ」の「２」に対応するＳＱＬ文、「ノードＩＤ」の「１」（初期状態）のＳＱＬ文を状態ツリー管理テーブルから抽出する。
【００６１】
ステップＳ５８では、バックトラック管理部９が、ステップＳ５９で抽出したＳＱＬ文をパスの順序と逆に並べ替え、その順序でＤＢ制御コード発行部１０に送信する。例えば、図８のＧに示すように「ノードＩＤ」の「１」（初期状態）に対応するＳＱＬ文、「ノードＩＤ」の「２」のに対応するＳＱＬ文、「ノードＩＤ」の「３」のに対応するＳＱＬ文を並べ替えてＤＢ制御コード発行部１０に送信する。
【００６２】
なお、ＤＢ制御コード発行部１０は受信したＳＱＬ文を順番にプログラムモデル検査装置１のＤＢＭＳ１１に発行する。そして、プログラムモデル検査装置１は、ＳＱＬ文に基づいてＤＢの状態を復元する。
【００６３】
ステップＳ５９では、バックトラック管理部９が、復元先ノードＩＤが示す状態にするための全てのＳＱＬ文を、ＤＢＭＳ１１に復元終了したことを通知（状態復元終了通知）する。
【００６４】
上記のようにバックトラック処理を行うことにより、プログラムモデル検査において実行環境で使用されるＤＢＭＳ１１のデータを復元状態へ戻す効率的なバックトラックを行うことにより、メモリ消費を削減することができる。また、それぞれの状態に至るログを状態ツリー構造として管理し、そこに戻るパスを動的に作成することができる。
【００６５】
また、実際のＤＢを用いてプログラムモデル検査を実行する場合でも、従来のようなＤＢデータの各状態をスナップショットで残しておき、それらをプログラムモデル検査パスの持つ状態とリンクして管理する仕組みを必要としない。
【００６６】
また。従来はプログラムモデル検査にＤＢデータがないとしても、膨大なメモリとＣＰＵの性能が必要である。加えてスナップショットによるメモリ消費が追加されるとプログラムモデル検査の実行そのものに多大な影響を与える。また、コピー用データベースおよびストレージが別途必要になる。また、スナップショットを取るタイミングがデータ変更のタイミングで管理されており、プログラムモデル検査で管理する単位とは異なるため、両者を結びつけて管理する機構が別途必要になる。また、従来はプログラムモデル検査装置内部において動的に作成される状態ツリー情報を管理し、図１０のＢに示すように全く別の部分木に属する状態に戻る時、その状態が属する部分木を特定し、その状態に至るパスを求めている。
【００６７】
しかし、本例では、図１０のＢに示すように状態Ｓから状態Ｉに戻るためには状態を遡るだけでなく、状態Ｉが属する部分木を特定してその状態に至るパスを計算する必要がなくなる。また、データスナップショットを取っておくための追加ストレージも不要になる。また、メモリの消費を削減することができる。
【００６８】
また、従来は図１０のＣに示されるように１次元の時間列で表現される状態に戻ることを想定しており、プログラムモデル検査の状態木のように複数の時間列が存在する状態を管理する方法ではない。そのため、プログラムモデル検査ツール内部において動的に作成される複数の時間列が存在する状態ツリー情報を管理するためには、動的に作成されるプログラムモデル検査状態木に連動したＤＢ状態の管理を効率的に行う必要がある。しかし、対象の状態がルートからどのノードを通って達するパスであるか、それら複数のパスの全てを記録可能なデータ構造を持っていなければ、任意の状態へのバックトラックを効率的にＳＱＬログから作成することは難しい。また、ツリー構造を無視して管理をすると、プログラムモデル検査のように状態数が数百から数千など非常に多くなる場合、メモリの消費が多くなるとともに、どのパスを辿れば目的の状態を探し出すことができるかを検索するため、ＣＰＵの負荷が大きくなる。
【００６９】
それに対して本例では、バックトラック開始点へのパスを状態ツリーとして管理するため、ノード探索およびそこに至るパス計算が速くなりＣＰＵの負荷を減らすことができる。
【００７０】
また、プログラムモデル検査装置１で発行したコード（ＳＱＬ文など）を用いるため、ＤＢＭＳ１１ごとにプログラムモデル検査装置に変更を加えなくてよい。
なお、本実施例では、プログラムモデル検査装置とデータベース制御装置とが別々の装置である例を示したが、両装置の機能を備えた１台の装置として本発明を構成することも可能である。
【００７１】
（本実施例がコンピュータプログラムとして実現される場合の構成）
図９は、上記本発明の実施形態の装置を実現できるコンピュータのハードウェア構成の一例を示す図である。
【００７２】
コンピュータのハードウェア９０は、ＣＰＵ９１、記録部９２（ＲＯＭ、ＲＡＭ、ハードディスクドライブなど）、記録媒体読取装置９３、入出力インタフェース９４（入出力Ｉ／Ｆ）、通信インタフェース９５（通信Ｉ／Ｆ）などを備えている。また、上記各構成部はバス９６によってそれぞれ接続されている。
【００７３】
ＣＰＵ９１は、記録部９２に格納されている上記説明した状態ツリー管理処理、ログファイル管理処理、バックトラック管理処理、ＤＢ復元通知発行処理（図５、６、８に示した処理）を実行する。
【００７４】
記録部９２は、ＣＰＵ９１が実行するプログラムやデータが記録されている。また、ワークエリアなどとして使用される。
記録媒体読取装置９３は、ＣＰＵ９１の制御にしたがって記録媒体９３ａに対するデータのリード／ライトを制御する。そして、記録媒体９３ａ、記録媒体読取装置９３の制御で書き込まれたデータを記憶したり、記録媒体９３ａに記憶されたデータを読み取らせたりする。また、着脱可能な記録媒体９３ａは、コンピュータで読み取り可能な記録媒体として、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）などがある。光ディスクには、ＤＶＤ(Digital Versatile Disc)、ＤＶＤ−ＲＡＭ(Random Access Memory)、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)、ＣＤ−Ｒ(Recordable)／ＲＷ(ReWritable)などがある。光磁気記録媒体には、ＭＯ(Magneto-Optical disk)などがある。
【００７５】
入出力インタフェース９４には、入出力装置９４ａ（マウス、キーボード、ディスプレイなど）が接続され、ユーザが入力した情報を受信し、バス９６を介してＣＰＵ９１に送信する。また、ＣＰＵ９１からの命令に従ってディスプレイの画面上に操作情報などを表示する。
【００７６】
通信インタフェース９５は、必要に応じ、他のコンピュータとの間のＬＡＮ接続やインターネット接続や無線接続のためのインタフェースである。また、他の装置に接続され、外部装置からのデータの入出力を制御する。
【００７７】
このようなハードウェア構成を有するコンピュータを１台または２台以上用いることによって、上記説明した各種処理機能（実施例で説明した処理（フローチャートなど））が実現される。その場合システムが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体９３ａに記録しておくことができる。
【００７８】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【００７９】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
また、本発明は、上記実施の形態に限定されるものでなく、本発明の要旨を逸脱しない範囲内で種々の改良、変更が可能である。
【００８０】
以上実施例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
プログラムモデル検査装置がプログラムモデル検査を実施する際に実行環境で使用するデータベースを制御するデータベース制御装置であって、
前記プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する記録部と、
前記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理部と、
を備えることを特徴とするデータベース制御装置。
（付記２）
前記バックトラック管理部は、
初期状態から前記復元先ノードＩＤに対応する状態に到るまでの遷移経路を示す複数のパス情報に対応する複数のログ情報を、前記状態ツリー管理テーブルから取得し、該ログ情報を並べてバックトラック用コードを生成することを特徴とする付記１に記載のデータベース制御装置。
（付記３）
プログラムモデル検査を行うプログラムモデル検査手段から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から変化後の状態へ遷移する間に該プログラムモデル検査手段から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する記録手段と、
前記プログラムモデル検査手段から、戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報に基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理手段と、
を備えることを特徴とするコンピュータ。
（付記４）
プログラムモデル検査装置がプログラムモデル検査を実施する際に実行環境で使用するデータベースのデータベース制御方法であって、
前記プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録し、
前記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成する、
ことを特徴とするプログラムモデル検査におけるデータベース制御方法。
（付記５）
コンピュータに、
プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する処理と、
前記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理処理と、
を実行させることを特徴とするプログラムモデル検査におけるデータベース制御プログラム。
（付記６）
初期状態から前記復元先ノードＩＤに対応する状態に到るまでの遷移経路を示す複数のパス情報に対応する複数のログ情報を、前記状態ツリー管理テーブルから取得し、該ログ情報を並べてバックトラック用コードを生成させることを特徴とする付記４に記載のプログラムモデル検査におけるデータベース制御方法。
（付記７）
コンピュータに、
初期状態から前記復元先ノードＩＤに対応する状態に到るまでの遷移経路を示す複数のパス情報に対応する複数のログ情報を、前記状態ツリー管理テーブルから取得し、該ログ情報を並べてバックトラック用コードを生成させることを特徴とするプログラムモデル検査におけるデータベース制御プログラム。
【符号の説明】
【００８１】
１ プログラムモデル検査装置
２ データベース制御装置
３ ＤＢデータ管理部
４ モジュール
５ コード保存部
６ ログファイル
７ 状態ツリー管理部
８ ログファイル管理部
９ バックトラック管理部
１０ ＤＢ制御コード発行部
２１ ドライバ
２２ プログラム
２３ 入力データ
２４ プロパティ
３１ ドライバ
９０ ハードウェア
９２ 記録部
９３ 記録媒体読取装置
９３ａ 記録媒体
９４ 入出力インタフェース
９４ａ 入出力装置
９５ 通信インタフェース
９６ バス
【技術分野】
【０００１】
本発明は、プログラムモデル検査において実行環境で使用されるデータベース（以降、ＤＢ）を制御する際に用いるバックトラック技術に関する。
【背景技術】
【０００２】
プログラムモデル検査を行う場合、検査対象プログラムのプログラムパスにおける各状態を構成する要素のひとつとしてＤＢに記録されたデータがある。プログラムモデル検査では、ＤＢのレコードに対し検索、参照のみを行うときはＤＢのデータの状態は変わらないが、作成、更新、削除などを行うとＤＢの状態に変化がおきる。図１０のＡに示す例では、状態Ａから状態Ｂに至るパスでＤＢデータに対して挿入（Insert）を実行し、状態Ｂから状態Ｃに至るパスで削除（Delete）を実行する。次に、プログラムモデル検査で状態Ｂから状態Ｄに至るパスを実行するために、状態Ｃから状態ＢにＤＢデータを含む実行環境を戻してから、状態Ｄに至るパスを実行する。この状態Ｃから状態Ｂに実行環境を戻すときにバックトラックが必要になる。すなわち、バックトラックはプログラムパスにおける各状態を構成する全ての要素に対して行うが、ＤＢデータに対しても行う必要がある。
【０００３】
このＤＢデータのバックトラックを実現する方法には、ＤＢスタブを用いる方法と実際のＤＢに接続して中身を書き換える方法がある。
ＤＢスタブを使用した場合、予めＤＢデータのファイルを用意しておき、各状態フェーズにおけるＤＢデータイメージを保持する。バックトラック時には、スタブプログラムの内部変数として保持し、プログラムモデル検査ツールがもつプログラムの内部変数を戻す仕組みを活用することにより状態を元に戻す。そのためには、ＤＢＭＳ（Data Base Management System）の振る舞いを模倣するスタブを準備しなければならないが、ＤＢＭＳの機能を持つスタブを作成するには多くの作業時間が発生するという問題がある。また、プログラムモデル検査対象のシステムごとに使うＤＢＭＳごとに作成するスタブが変わるため、スタブを使えるようにするにはシステム対象を変更しなければならないという問題もある。さらに、ＤＢＭＳごとに異なる部分（例えば、データ型の違い、ＤＢＭＳごとの文法の違い）が存在するため、スタブの仕組みを１つ作成すれば他のシステムでも利用できるとは限らない。
【０００４】
そこで、ＤＢスタブを使わないで実際のＤＢに接続してＤＢの内容を書き換える提案がされている。
例えば、データベーススナップショットという別の読み取り専用ポイントインタイム(point in time)コピー用のデータベースを用意し、元のデータベースの修正分のみストレージにコピーし、そのポイントインタイムビューを保持する。そして、ユーザエラーが起きてデータ復元が必要になった時に直近のスナップショットをコピーすることで以前の状態に復帰する技術が知られている。ところが、ＤＢに対してバックトラックを実行すると、管理しなければならないスナップショットの数は直近のものだけではなく、状態ツリーのルートに遡って各状態にそれぞれバックトラックを実行しなければならない。そのため、スナップショットの数がプログラムによって非常に大きなものになることがある。
【０００５】
そこで、次のような技術が提案されている。例えば、ＳＱＬ（Structured Query Language）ログを用いてＤＢデータを元に戻す方法が知られている。しかし、プログラムモデル検査のように、特定の状態のＤＢに戻すためにどのようなＳＱＬ文を発行すべきかを簡単に解くことはできない。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特表２００７−５２４１７３号公報
【特許文献２】特開２００６−２４４３９４号公報
【特許文献３】特開２００４−３４８７０１号公報
【特許文献４】特開平７−１６０５６３号公報
【特許文献５】特開２０００−１０８３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記のような実情に鑑みてなされたものであり、プログラムモデル検査において実行環境で使用されるＤＢのデータを復元したい状態へ戻す効率的なバックトラックを行うデータベース制御装置、データベース制御方法、データベース制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
態様のひとつであるプログラムモデル検査装置がプログラムモデル検査を実施する際に実行環境で使用するデータベースを制御するデータベース制御装置データベース制御装置は、記録部、バックトラック管理部を備えている。
【０００９】
記録部は、上記プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する。
【００１０】
バックトラック管理部は、上記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて上記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、上記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成する。
【発明の効果】
【００１１】
プログラムモデル検査において実行環境で使用されるＤＢのデータを復元したい状態へ戻す効率的なバックトラックを行うことができる。
【図面の簡単な説明】
【００１２】
【図１】プログラムモデル検査を行うシステムの装置の構成を示すブロック図である。
【図２】プログラムモデル検査装置の構成を示すブロック図である。
【図３】Ａはプログラムモデル検査装置から発行されたＳＱＬ文を示す図である。ＢはＳＱＬ文とノードを関連付けたコードを示す図である。
【図４】データベースの状態の例を示す図である。
【図５Ａ】プログラムモデル検査のやり取りを示すフロー図である。
【図５Ｂ】プログラムモデル検査のやり取りを示すフロー図である。
【図６】ＤＢデータ管理部の動作を示すフロー図である。
【図７】Ａ〜Ｅは状態ツリー管理テーブルを示す図である。
【図８】バックトラック管理部の動作を示すフロー図である。
【図９】本実施例がコンピュータプログラムとして実現される場合の構成を示す図である。
【図１０】Ａ〜Ｃはデータベースの状態の例を示す図である。
【発明を実施するための形態】
【００１３】
以下図面に基づいて、本発明の実施形態について詳細に説明する。
本実施例は、ＤＢのレコードに対して作成、更新、削除などを行った後にバックトラックが発生した場合、復元したい状態にＤＢのデータを戻すための効率的な方法を示すものである。
【００１４】
（構成）
図１はプログラムモデル検査における実行環境で使用されるＤＢのデータを任意の状態へ戻すバックトラックを実行するデータベース制御装置２を備えるプログラムモデル検査を行うシステムの構成を示す図である。このプログラムモデル検査を行うシステムは、プログラムモデル検査装置１、データベース制御装置２を備えている。
【００１５】
プログラムモデル検査装置１は、例えば図２に示すように、検査対象プログラム２２に対するモデル検査環境であるドライバ２１および、実際に検査対象プログラム２２が実行の際に使用するＤＢＭＳ１１（データベース管理システム）などを備えている。プログラムモデル検査装置１は、プログラム中の分岐条件（検査対象プログラム２２が保持するデータの変化に加えＤＢのレコードに対して作成、更新、削除など）が現れるたびにその時の状態を記録する。なお、プログラムモデル検査装置１は、図示しないＤＢスタブ、ネットワークスタブなども備えていてもよい。
【００１６】
ドライバ２１は、クライアント（例えば、検証実行者）の代わりに検査対象プログラム２２に対してユーザ操作を模倣した入力データ２３を入力する。そして、プログラムモデル検査装置１が、検査対象プログラム２２をさまざまなバリエーションで複数回、連続的に呼び出し、プロパティ２４に格納されている機能仕様などが満たされているかをチェックする。
【００１７】
このように、プログラムモデル検査装置１は、検査対象プログラム２２とデータをやり取りするＤＢＭＳ１１、ＤＢ用スタブ２３などに対して網羅的な検査を行う。
データベース制御装置２は、ＤＢデータ管理部３、コード保存部５（ＤＢドライバ追加モジュール４）などを備えている。
【００１８】
ＤＢドライバ追加モジュール４はコード保存部５を備え、通常ＤＢデータベースに含まれるＤＢ用ドライバ（例えばＪＤＢＣ（Java Data Base Connectivity）など)から発行されるコード（例えば、ＳＱＬ文）をログファイル６に保存する（図３のＡ）。なお、本例ではＳＱＬを用いているが、リレーショナルデータベースの操作を行なうための言語であればＳＱＬに限定するものではない。検査対象プログラム２２が使用するＤＢＭＳ１１によってログファイルを保存できる機能を有しているため、その場合にはコード保存部５の代わりに該機能を用いてもよい。
【００１９】
状態ツリー管理部７は、各状態に戻るためのパスを把握するために、プログラムモデル検査装置１の状態ツリーと同等の情報を管理する。また、状態ツリー管理部７は、プログラムモデル検査装置１からプログラムパスの分岐と、プログラムの新しい状態を示すノードＩＤ（識別番号）を有する状態変更通知を受信する。そして、新しい状態に対応するノードＩＤに、直前の状態と新しい状態間のパスを関連付けて、後述する状態ツリー管理テーブルに記録する。
【００２０】
ログファイル管理部８は、プログラムモデル検査装置１から状態変更通知を受信すると、ＳＱＬログファイル６を読み込み、パス状態が変化するたびに状態遷移間で発行されたＳＱＬ文を取得して管理する。ログファイル管理部８は、ログファイル６を読み込み、前回発行された状態変更通知から今回発行された状態変更通知を受信するに至るまでのコード（例えば、ＳＱＬ文）を抽出し、ノードＩＤと結びつけて管理する（図３のＢ）。例えば、図４に示す状態１から状態２に遷移するパスであれば、状態２に対応するノードＩＤに状態１から状態２に至る間に発行されたＳＱＬ文を全て関連付けて記録する。また、状態２から状態３に遷移するパスであれば、状態３に対応するノードＩＤに状態２から状態３に至る間に発行されたＳＱＬ文全てを関連付けて記録する。なお、図４の各状態に割り振った番号はプログラムモデル検査装置１がプログラムモデル検査を行う順番と対応付けられている。
【００２１】
バックトラック管理部９は、プログラムモデル検査装置１からバックトラックを実行する通知を受信すると、ＤＢＭＳ１１を初期状態に戻して目的の状態にするためのＤＢ制御コード（例えば、ＳＱＬ文）を作成する（詳細は後述する）。
ＤＢ制御コード発行部１０は、バックトラック管理部９で作成したＤＢ制御コードをＤＢＭＳ１１に発行する。
【００２２】
（動作説明）
図５はプログラムモデル検査装置１、ＤＢデータ管理部３、コード保存部５、検査対象プログラム２２、ＤＢＭＳ１１の動作を説明するフロー図である。
【００２３】
ステップＳ１では、ＤＢデータ管理部３がＤＢを初期状態にするためのコードを有する検査開始通知をＤＢＭＳ１１に送信する。例えば、ＤＢを初期状態にするＳＱＬ文を、ＤＢドライバ追加モジュール４を介して出力する。
【００２４】
ステップＳ２では、ＤＢＭＳ１１が初期状態にするためのコードを受信する。ステップＳ３では、ＤＢＭＳ１１がＤＢを初期状態にする。
ステップＳ４では、プログラムモデル検査装置１がプログラムモデル検査を開始する。
【００２５】
ステップＳ５では、プログラムモデル検査装置１がコードをコード保存部５とＤＢＭＳ１１へ出力を開始する（図３のＡ参照）。
ステップＳ６では、コード保存部５がコードをログファイル６に記録する。また、ステップＳ７ではＤＢＭＳ１１がコードを受信する。
【００２６】
ステップＳ８では、ログファイル管理部８がログファイル６の読み込みを開始する。
ステップＳ９では、プログラムモデル検査装置１がＤＢの状態変化を判定する。例えば、プログラムモデル検査装置１がＳＱＬ文に記述されている分岐条件となる挿入（ｉｎｓｅｒｔ）、更新（ｕｐｄａｔｅ）、削除（ｄｅｌｅｔｅ）などを検出する。
【００２７】
ステップＳ１０では、プログラムモデル検査装置１がステップＳ９で検出した状態変化を後述する状態変更通知をＤＢデータ管理部３へ送信する。
ステップＳ１１では、ＤＢデータ管理部３が状態変更通知を受信する。ＤＢデータ管理部３は、状態変更通知に基づいてＤＢの状態に変化があったことを検知する。
【００２８】
ステップＳ１２では、ＤＢデータ管理部３がコード保存部５からコードを読み込む。
ステップＳ１３では、ＤＢデータ管理部３がコード保存部５から取得したコードと状態を関連付ける（詳細については後述する）。
【００２９】
通常時、ステップＳ４〜ステップＳ１３に示した処理を繰り返し実行し、バックトラックを行う場合にはステップＳ１５に移行する。
ステップＳ１４では、プログラムモデル検査装置１がバックトラックを行うか否かを判定し、バックトラックを行う場合はステップＳ１５に移行する。例えば、プログラムモデル検査装置１が既存の機能によりこれ以上状態が変化しないことを検出する。なお、バックトラックを実行するとき、プログラムモデル検査装置１はプログラムモデル検査を中断する。そして、バックトラック処理が完了したことを検出すると、プログラムモデル検査を再開する。例えば、ＪＰＦ（Ｊａｖａ Ｐａｔｈｆｉｎｄｅｒ）などを用いることにより、プログラムモデル検査装置１とデータベース制御装置２の切り替え同期を取る。
【００３０】
ステップＳ１５では、プログラムモデル検査装置１が後述するバックトラック開始通知をＤＢデータ管理部３に送信する。
ステップＳ１６では、バックトラック開始通知をＤＢデータ管理部３が受信する。
【００３１】
ステップＳ１７では、ＤＢデータ管理部３がバックトラック処理を実行する（詳細については後述する）。
ステップＳ１８では、ＤＢデータ管理部３がＤＢＭＳ１１のＤＢを初期状態にするコードを、ＤＢドライバ追加モジュール４を介してＤＢＭＳ１１に送信する。
【００３２】
ステップＳ１９では、ＤＢＭＳ１１が初期状態にするコードを受信し、ステップＳ２０でＤＢＭＳ１１がＤＢを初期状態にする。
ステップＳ２１では、ＤＢデータ管理部３がバックトラック開始通知に示されているＤＢＭＳ１１をロールバックする情報（復元先ノードＩＤ）に基づいて生成されたコードを、ＤＢドライバ追加モジュール４を介してＤＢＭＳ１１に送信する。
【００３３】
ステップＳ２２では、ＤＢＭＳ１１がＤＢをロールバックするコードを受信し、ステップＳ２３でＤＢＭＳ１１がＤＢに対して指定された状態にロールバックする指示を出力する。
【００３４】
ステップＳ２４では、ステップＳ２２の処理が完了すると、ＤＢデータ管理部３がプログラムモデル検査装置１に対して状態復元終了通知を送信する。状態復元終了通知は、プログラムモデル検査装置１にプログラムモデル検査を再開させるとともに、データベース制御装置２からプログラムモデル検査装置１に動作を切り替える通知である。
【００３５】
（ＤＢデータ管理部の動作説明）
図４に示す状態ツリーを持つプログラム状態を想定して、図６に示すフロー図を用い、ＤＢデータ管理部３の動作を説明する。なお、本例ではＳＱＬ文をコードとして用いるものとする。
【００３６】
ステップＳ３１では、ＤＢデータ管理部３が、ＤＢＭＳ１１のＤＢを初期状態（図４の状態１）にするためにＳＱＬ文をプログラムモデル検査装置１に発行する。例えば、図７のＡに示す「delete * from TB1」「delete * from TB5」などを発行する。初期状態にするＳＱＬ文は、予めユーザ（検証実行者）が状態ツリー管理テーブルに記録する。また、「ＴＢ１」「ＴＢ５」はＤＢＭＳ１１にも受けられているテーブルなどである。
【００３７】
なお、図７のＡ〜Ｅに示す状態ツリー管理テーブルは、「ノードＩＤ」「パス」「ＳＱＬ」を記録するセルを有し、「ノードＩＤ」にはプログラムモデル検査装置１から通知される状態を示す識別番号を記録する。「パス」には「ノードＩＤ」に関連付けられ、分岐点の状態と遷移した状態を示す内容（パス情報）を記録する。例えば、状態２から状態３への分岐であれば「２→３」のように記録する。「ＳＱＬ」には、「ノードＩＤ」に関連付けられ、分岐（状態遷移）が検出されるまでに発行されたＳＱＬ文が記録される。
【００３８】
ステップＳ３２では、ＤＢデータ管理部３が、プログラムモデル検査装置１からＤＢドライバ追加モジュール４を介して検査開始通知（再開時にも通知される）を受信する。検査開始通知は、プログラムモデル検査装置１が検査を開始もしくは再開するときに発行される情報である（図６のＡ参照）。
【００３９】
ステップＳ３３では、コード保存部５がＤＢＭＳ１１から発行されるＳＱＬ文をログファイル６へ記録する。図３のＡにＤＢＭＳ１１から発行されるＳＱＬ文の例を示す。
ステップＳ３４（状態ツリー管理処理）では、状態ツリー管理部７がプログラムモデル検査装置１からＤＢドライバ追加モジュール４を介して状態変更通知を受信する。状態変更通知は、検査中のプログラムのパスに状態変更があるとき通知され、この通知が状態変更を示す通知であることを示す状態変更コードと、新たな状態を示すノードＩＤを有している（図６のＢ参照）。例えば、図４の状態１から状態２（分岐点）への遷移であれば、状態２を示すノードＩＤとして「２」が通知される。
なお、プログラムモデル検査装置１は、プログラム中の分岐条件が現れるたびにその時の状態を記憶している。
【００４０】
ステップＳ３５（ログファイル管理処理）では、ログファイル管理部８がＳＱＬ文に状態変更のマークを記録する。図３のＢにＤＢＭＳ１１から発行されるＳＱＬ文の例を示す。図３のＢの例ではマークとして［初期状態]、［ノードＩＤ２]〜［ノードＩＤ６]を記述している。なお、本例ではコメント記号「／＊」「＊／」を用いマークをコメント文として扱っている。
【００４１】
ステップＳ３６（状態ツリー管理処理）では、状態ツリー管理部７では、新たな状態を示す「ノードＩＤ」を状態ツリー管理テーブルに追加記録する。例えば、図４の状態１から状態２（分岐点）への遷移であれば、図７のＢに示すように状態ツリー管理テーブルの「ノードＩＤ」に「２」を追加する。そして、「パス」に「ノードＩＤ」の「１」（状態１）から進んでプログラム分岐点である状態２が検出されたことを示す「１→２」を記録する。また、ログファイル管理部８で記録された状態１から状態２に至る間で発行されたＳＱＬ文を順番に「ＳＱＬ」に記録する。
【００４２】
同様に、状態２から状態３、状態３から状態４への遷移についてもステップＳ３３〜Ｓ３６と同じように処理をする。その結果、図７のＢ、Ｃに示す状態ツリー管理テーブルが生成される。
【００４３】
ステップＳ３７〜Ｓ３９、Ｓ４１（バックトラック管理処理）、ステップＳ４０（ＤＢ制御コード発行処理）によりバックトラック処理を行う。
ステップＳ３７では、バックトラック管理部９がプログラムモデル検査装置１からバックトラック開始通知を受信し、バックトラック開始通知を受信したときステップＳ３８に移行し、受信しないときステップＳ３３に移行する。バックトラック開始通知は、バックトラック開始を示すコードと、復元先の状態を示す識別番号である復元先ノードＩＤを有している。例えば、図４において状態４までプログラムが進むと直近のプログラム分岐状態３に戻るバックトラック開始通知を、バックトラック管理部９がプログラムモデル検査装置１から受信する。
【００４４】
ステップＳ３８では、バックトラック管理部９が復元先ノードＩＤを取得する。
ステップＳ３９では、バックトラック管理部９が状態ツリー管理テーブルから復元先ノードＩＤに示されたノードＩＤを検索し、初期状態から復元先ノードＩＤに示された状態に至るまでのパスとＳＱＬ文を全て抽出する。そして、抽出したＳＱＬ文をパスの順序と逆に並べ替えてＳＱＬ文（ＤＢ制御コード）を生成してＤＢ制御コード発行部１０に送信する。
【００４５】
ステップＳ４０（ＤＢ制御コード発行処理）では、ＤＢ制御コード発行部１０がステップＳ３９で生成したＳＱＬ文を順番にＤＢＭＳ１１に発行する。
ステップＳ４１では、バックトラック管理部９がプログラムモデル検査装置１に状態復元終了通知を送信する。
【００４６】
図４の場合であれば、ＤＢデータバックトラック部２は、状態４までプログラムが進むと、「ノードＩＤ」の「３」が示す状態３からプログラムモデル検査装置１が実行され、状態５とその間に発行されたＳＱＬ文を状態ツリー管理テーブルに記録する。
【００４７】
状態５までプログラムが進むと直近のプログラム分岐状態２に戻るようにプログラムモデル検査装置１から通知を受け取る。そのため状態２に戻るためのバックトラックの処理に移る。
【００４８】
次に、ＤＢ制御コード発行部１０がＳＱＬ文を発行して、ＤＢＭＳ１１を状態２に戻す。
次に、図４の状態２からプログラムモデル検査装置１が実行され、状態２から状態６の間に発行されたＳＱＬ文が状態ツリー管理テーブルの「ＳＱＬ」に記録される。
【００４９】
なお、プログラムモデル検査装置１からコード（ＳＱＬ文）が出力されるのは、プログラムモデル検査装置１の検査対象プログラム２２が動作した時のみであるため、バックトラック時はプログラムが動作しない。そのため、検査対象プログラム２２からのコード（ＳＱＬ文など）は無視される。よって、バックトラック時の動作はログファイル６に記録されない。
【００５０】
（バックトラック管理部の動作説明：バックトラック管理処理）
図８はバックトラック管理部９の動作を示すフロー図である。
【００５１】
ステップＳ５１では、バックトラック管理部９がプログラムモデル検査装置１からバックトラック開始通知を受信するまで待機する。例えば、図４に示した状態４から状態３に戻る場合であれば、状態ツリー管理テーブルには図７のＣに示すように「ノードＩＤ」の「１」〜「４」に対応する「パス」「ＳＱＬ」が生成され記録されている。
【００５２】
ステップＳ５２では、バックトラック管理部９がプログラムモデル検査装置１からバックトラック開始通知を受信する。例えば、バックトラック開始通知は、図８のＡに示すように、バックトラック開始を示すコード（「ｓｔａｒｔコード」）、復元先ノードＩＤ（復元先の状態を示す識別番号）を有している。図４に示す状態３にプログラムモデル検査が戻る場合であれば、復元先ノードＩＤとして「３」がプログラムモデル検査装置１から送信され、バックトラック管理部９が復元先ノードＩＤに基づいて状態３へバックトラックすることを認識する。
【００５３】
ステップＳ５３では、バックトラック管理部９が状態ツリー管理テーブルから復元先ノードＩＤに対応する「ノードＩＤ」を検索する。例えば、復元先ノードＩＤが「３」であれば、図７のＣの状態ツリー管理テーブルの中から「ノードＩＤ」が「３」である行を探索する。そして、探索結果である「３」を記録部に記録する（図８のＢ）。
【００５４】
ステップＳ５４〜Ｓ５６では、バックトラック管理部９が初期状態を示す「ノードＩＤ」から復元先ノードに対応する状態に至るまでのパスを抽出する。
ステップＳ５４では、バックトラック管理部９が、復元先ノードに対応する「ノードＩＤ」に関連付けられている「パス」を抽出する。また、ステップＳ５６で検出された「ノードＩＤ」に対応する「パス」を抽出する。
【００５５】
ステップＳ５５では、バックトラック管理部９が、抽出した「パス」に前のノードＩＤ（前状態）に初期状態が示されているかを判定し、初期状態を示していればステップＳ５７に移行し、初期状態を示していない場合にはステップＳ５６に移行する。例えば、図７の場合であれば「ノードＩＤ」の「１」が図４の状態１である初期状態を示しているので、「パス」に記録されている「１→２」を検出したときステップＳ５７に移行する。
【００５６】
ステップＳ５６では、バックトラック管理部９が、記録した「パス」の前のノードＩＤに対応する「ノードＩＤ」を、状態ツリー管理テーブルから抽出する。
【００５７】
図４の状態４から状態３へバックトラックする場合について説明する。
ステップＳ５４では図８のＣに示すように、「ノードＩＤ」の「３」に関連付けられている「パス」である「２→３」を抽出する。各「ノードＩＤ」に関連付けられた各「パス」は「Ａ→Ｂ」のように示されており、Ｂは同じレコードに関連付けられている「ノードＩＤ」を示し、ＡはＢに示される「ノードＩＤ」に辿り着く前のノードＩＤを示している。
【００５８】
例えば、ステップＳ５５において「２→３」の前のノードＩＤが「２」であるので、前の状態が初期状態ではないためステップ５６に移行する（ステップＳ５：１回目）。
ステップ５６では、ステップＳ５５で記録した図８のＣに示すノードＩＤ（１回目）のパス「２→３」から前のノードＩＤである「２」を抽出する（図８のＥ）。
【００５９】
ステップＳ５４では、図８のＣに示すように、「ノードＩＤ」の「２」に関連付けられている「パス」である「１→２」を抽出する。
次に、ステップＳ５５では、「１→２」の前のノードＩＤが「１」であるので、初期状態と判定してステップ５７に移行する（ステップＳ５５：図８のＤの２回目）。
【００６０】
上記のようにして、バックトラック管理部９が初期状態を示す「ノードＩＤ」から復元先ノードに対応する状態に至るまでのパス（状態１→状態２→状態３）を抽出する。
ステップＳ５７では、バックトラック管理部９が、記録した「パス」に関連付けられた「ノードＩＤ」に対応する「ＳＱＬ」にあるＳＱＬ文を状態ツリー管理テーブルから抽出する。例えば、図８のＦに示すように「ノードＩＤ」の「３」に対応するＳＱＬ文、「ノードＩＤ」の「２」に対応するＳＱＬ文、「ノードＩＤ」の「１」（初期状態）のＳＱＬ文を状態ツリー管理テーブルから抽出する。
【００６１】
ステップＳ５８では、バックトラック管理部９が、ステップＳ５９で抽出したＳＱＬ文をパスの順序と逆に並べ替え、その順序でＤＢ制御コード発行部１０に送信する。例えば、図８のＧに示すように「ノードＩＤ」の「１」（初期状態）に対応するＳＱＬ文、「ノードＩＤ」の「２」のに対応するＳＱＬ文、「ノードＩＤ」の「３」のに対応するＳＱＬ文を並べ替えてＤＢ制御コード発行部１０に送信する。
【００６２】
なお、ＤＢ制御コード発行部１０は受信したＳＱＬ文を順番にプログラムモデル検査装置１のＤＢＭＳ１１に発行する。そして、プログラムモデル検査装置１は、ＳＱＬ文に基づいてＤＢの状態を復元する。
【００６３】
ステップＳ５９では、バックトラック管理部９が、復元先ノードＩＤが示す状態にするための全てのＳＱＬ文を、ＤＢＭＳ１１に復元終了したことを通知（状態復元終了通知）する。
【００６４】
上記のようにバックトラック処理を行うことにより、プログラムモデル検査において実行環境で使用されるＤＢＭＳ１１のデータを復元状態へ戻す効率的なバックトラックを行うことにより、メモリ消費を削減することができる。また、それぞれの状態に至るログを状態ツリー構造として管理し、そこに戻るパスを動的に作成することができる。
【００６５】
また、実際のＤＢを用いてプログラムモデル検査を実行する場合でも、従来のようなＤＢデータの各状態をスナップショットで残しておき、それらをプログラムモデル検査パスの持つ状態とリンクして管理する仕組みを必要としない。
【００６６】
また。従来はプログラムモデル検査にＤＢデータがないとしても、膨大なメモリとＣＰＵの性能が必要である。加えてスナップショットによるメモリ消費が追加されるとプログラムモデル検査の実行そのものに多大な影響を与える。また、コピー用データベースおよびストレージが別途必要になる。また、スナップショットを取るタイミングがデータ変更のタイミングで管理されており、プログラムモデル検査で管理する単位とは異なるため、両者を結びつけて管理する機構が別途必要になる。また、従来はプログラムモデル検査装置内部において動的に作成される状態ツリー情報を管理し、図１０のＢに示すように全く別の部分木に属する状態に戻る時、その状態が属する部分木を特定し、その状態に至るパスを求めている。
【００６７】
しかし、本例では、図１０のＢに示すように状態Ｓから状態Ｉに戻るためには状態を遡るだけでなく、状態Ｉが属する部分木を特定してその状態に至るパスを計算する必要がなくなる。また、データスナップショットを取っておくための追加ストレージも不要になる。また、メモリの消費を削減することができる。
【００６８】
また、従来は図１０のＣに示されるように１次元の時間列で表現される状態に戻ることを想定しており、プログラムモデル検査の状態木のように複数の時間列が存在する状態を管理する方法ではない。そのため、プログラムモデル検査ツール内部において動的に作成される複数の時間列が存在する状態ツリー情報を管理するためには、動的に作成されるプログラムモデル検査状態木に連動したＤＢ状態の管理を効率的に行う必要がある。しかし、対象の状態がルートからどのノードを通って達するパスであるか、それら複数のパスの全てを記録可能なデータ構造を持っていなければ、任意の状態へのバックトラックを効率的にＳＱＬログから作成することは難しい。また、ツリー構造を無視して管理をすると、プログラムモデル検査のように状態数が数百から数千など非常に多くなる場合、メモリの消費が多くなるとともに、どのパスを辿れば目的の状態を探し出すことができるかを検索するため、ＣＰＵの負荷が大きくなる。
【００６９】
それに対して本例では、バックトラック開始点へのパスを状態ツリーとして管理するため、ノード探索およびそこに至るパス計算が速くなりＣＰＵの負荷を減らすことができる。
【００７０】
また、プログラムモデル検査装置１で発行したコード（ＳＱＬ文など）を用いるため、ＤＢＭＳ１１ごとにプログラムモデル検査装置に変更を加えなくてよい。
なお、本実施例では、プログラムモデル検査装置とデータベース制御装置とが別々の装置である例を示したが、両装置の機能を備えた１台の装置として本発明を構成することも可能である。
【００７１】
（本実施例がコンピュータプログラムとして実現される場合の構成）
図９は、上記本発明の実施形態の装置を実現できるコンピュータのハードウェア構成の一例を示す図である。
【００７２】
コンピュータのハードウェア９０は、ＣＰＵ９１、記録部９２（ＲＯＭ、ＲＡＭ、ハードディスクドライブなど）、記録媒体読取装置９３、入出力インタフェース９４（入出力Ｉ／Ｆ）、通信インタフェース９５（通信Ｉ／Ｆ）などを備えている。また、上記各構成部はバス９６によってそれぞれ接続されている。
【００７３】
ＣＰＵ９１は、記録部９２に格納されている上記説明した状態ツリー管理処理、ログファイル管理処理、バックトラック管理処理、ＤＢ復元通知発行処理（図５、６、８に示した処理）を実行する。
【００７４】
記録部９２は、ＣＰＵ９１が実行するプログラムやデータが記録されている。また、ワークエリアなどとして使用される。
記録媒体読取装置９３は、ＣＰＵ９１の制御にしたがって記録媒体９３ａに対するデータのリード／ライトを制御する。そして、記録媒体９３ａ、記録媒体読取装置９３の制御で書き込まれたデータを記憶したり、記録媒体９３ａに記憶されたデータを読み取らせたりする。また、着脱可能な記録媒体９３ａは、コンピュータで読み取り可能な記録媒体として、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）などがある。光ディスクには、ＤＶＤ(Digital Versatile Disc)、ＤＶＤ−ＲＡＭ(Random Access Memory)、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)、ＣＤ−Ｒ(Recordable)／ＲＷ(ReWritable)などがある。光磁気記録媒体には、ＭＯ(Magneto-Optical disk)などがある。
【００７５】
入出力インタフェース９４には、入出力装置９４ａ（マウス、キーボード、ディスプレイなど）が接続され、ユーザが入力した情報を受信し、バス９６を介してＣＰＵ９１に送信する。また、ＣＰＵ９１からの命令に従ってディスプレイの画面上に操作情報などを表示する。
【００７６】
通信インタフェース９５は、必要に応じ、他のコンピュータとの間のＬＡＮ接続やインターネット接続や無線接続のためのインタフェースである。また、他の装置に接続され、外部装置からのデータの入出力を制御する。
【００７７】
このようなハードウェア構成を有するコンピュータを１台または２台以上用いることによって、上記説明した各種処理機能（実施例で説明した処理（フローチャートなど））が実現される。その場合システムが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体９３ａに記録しておくことができる。
【００７８】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【００７９】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
また、本発明は、上記実施の形態に限定されるものでなく、本発明の要旨を逸脱しない範囲内で種々の改良、変更が可能である。
【００８０】
以上実施例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
プログラムモデル検査装置がプログラムモデル検査を実施する際に実行環境で使用するデータベースを制御するデータベース制御装置であって、
前記プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する記録部と、
前記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理部と、
を備えることを特徴とするデータベース制御装置。
（付記２）
前記バックトラック管理部は、
初期状態から前記復元先ノードＩＤに対応する状態に到るまでの遷移経路を示す複数のパス情報に対応する複数のログ情報を、前記状態ツリー管理テーブルから取得し、該ログ情報を並べてバックトラック用コードを生成することを特徴とする付記１に記載のデータベース制御装置。
（付記３）
プログラムモデル検査を行うプログラムモデル検査手段から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から変化後の状態へ遷移する間に該プログラムモデル検査手段から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する記録手段と、
前記プログラムモデル検査手段から、戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報に基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理手段と、
を備えることを特徴とするコンピュータ。
（付記４）
プログラムモデル検査装置がプログラムモデル検査を実施する際に実行環境で使用するデータベースのデータベース制御方法であって、
前記プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録し、
前記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成する、
ことを特徴とするプログラムモデル検査におけるデータベース制御方法。
（付記５）
コンピュータに、
プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する処理と、
前記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理処理と、
を実行させることを特徴とするプログラムモデル検査におけるデータベース制御プログラム。
（付記６）
初期状態から前記復元先ノードＩＤに対応する状態に到るまでの遷移経路を示す複数のパス情報に対応する複数のログ情報を、前記状態ツリー管理テーブルから取得し、該ログ情報を並べてバックトラック用コードを生成させることを特徴とする付記４に記載のプログラムモデル検査におけるデータベース制御方法。
（付記７）
コンピュータに、
初期状態から前記復元先ノードＩＤに対応する状態に到るまでの遷移経路を示す複数のパス情報に対応する複数のログ情報を、前記状態ツリー管理テーブルから取得し、該ログ情報を並べてバックトラック用コードを生成させることを特徴とするプログラムモデル検査におけるデータベース制御プログラム。
【符号の説明】
【００８１】
１ プログラムモデル検査装置
２ データベース制御装置
３ ＤＢデータ管理部
４ モジュール
５ コード保存部
６ ログファイル
７ 状態ツリー管理部
８ ログファイル管理部
９ バックトラック管理部
１０ ＤＢ制御コード発行部
２１ ドライバ
２２ プログラム
２３ 入力データ
２４ プロパティ
３１ ドライバ
９０ ハードウェア
９２ 記録部
９３ 記録媒体読取装置
９３ａ 記録媒体
９４ 入出力インタフェース
９４ａ 入出力装置
９５ 通信インタフェース
９６ バス
【特許請求の範囲】
【請求項１】
プログラムモデル検査装置がプログラムモデル検査を実施する際に実行環境で使用するデータベースを制御するデータベース制御装置であって、
前記プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する記録部と、
前記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理部と、
を備えることを特徴とするデータベース制御装置。
【請求項２】
前記バックトラック管理部は、
初期状態から前記復元先ノードＩＤに対応する状態に到るまでの遷移経路を示す複数のパス情報に対応する複数のログ情報を、前記状態ツリー管理テーブルから取得し、該ログ情報を並べてバックトラック用コードを生成することを特徴とする請求項１に記載のデータベース制御装置。
【請求項３】
プログラムモデル検査を行うプログラムモデル検査手段から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から変化後の状態へ遷移する間に該プログラムモデル検査手段から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する記録手段と、
前記プログラムモデル検査手段から、戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報に基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理手段と、
を備えることを特徴とするコンピュータ。
【請求項４】
プログラムモデル検査装置がプログラムモデル検査を実施する際に実行環境で使用するデータベースのデータベース制御方法であって、
前記プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録し、
前記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成する、
ことを特徴とするプログラムモデル検査におけるデータベース制御方法。
【請求項５】
コンピュータに、
プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する処理と、
前記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理処理と、
を実行させることを特徴とするプログラムモデル検査におけるデータベース制御プログラム。
【請求項１】
プログラムモデル検査装置がプログラムモデル検査を実施する際に実行環境で使用するデータベースを制御するデータベース制御装置であって、
前記プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する記録部と、
前記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理部と、
を備えることを特徴とするデータベース制御装置。
【請求項２】
前記バックトラック管理部は、
初期状態から前記復元先ノードＩＤに対応する状態に到るまでの遷移経路を示す複数のパス情報に対応する複数のログ情報を、前記状態ツリー管理テーブルから取得し、該ログ情報を並べてバックトラック用コードを生成することを特徴とする請求項１に記載のデータベース制御装置。
【請求項３】
プログラムモデル検査を行うプログラムモデル検査手段から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から変化後の状態へ遷移する間に該プログラムモデル検査手段から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する記録手段と、
前記プログラムモデル検査手段から、戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報に基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理手段と、
を備えることを特徴とするコンピュータ。
【請求項４】
プログラムモデル検査装置がプログラムモデル検査を実施する際に実行環境で使用するデータベースのデータベース制御方法であって、
前記プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録し、
前記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成する、
ことを特徴とするプログラムモデル検査におけるデータベース制御方法。
【請求項５】
コンピュータに、
プログラムモデル検査装置から、データベースの変化後の状態を識別する識別番号であるノードＩＤを有する状態変更通知を受信したときに、該ノードＩＤに関連付けて、該変化後の状態への遷移経路を示すパス情報と、変化前の状態から該変化後の状態へ遷移する間に該プログラムモデル検査装置から出力された該データベースを制御するコードであるログ情報を状態ツリー管理テーブルに記録する処理と、
前記プログラムモデル検査装置から戻り先の状態を示す識別番号である復元先ノードＩＤを有するバックトラック開始通知を受信したときに、該復元先ノードＩＤに関連付けて前記状態ツリー管理テーブルに記録されたパス情報とログ情報とに基づいて、前記データベースを該復元先ノードＩＤが示す状態に戻すバックトラック用コードを生成するバックトラック管理処理と、
を実行させることを特徴とするプログラムモデル検査におけるデータベース制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１１−１３７９２（Ｐ２０１１−１３７９２Ａ）
【公開日】平成２３年１月２０日（２０１１．１．２０）
【国際特許分類】
【出願番号】特願２００９−１５５５０９（Ｐ２００９−１５５５０９）
【出願日】平成２１年６月３０日（２００９．６．３０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２３年１月２０日（２０１１．１．２０）
【国際特許分類】
【出願日】平成２１年６月３０日（２００９．６．３０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]