"検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部として機能するコンピュータに、前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成し、前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、前記判定において前記日時遷移イベントデータであると判定した場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更し、前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する処理を実行させるプログラム検査プログラム。前記日時情報を変更する処理は、前記プログラムによる日時情報の取得要求の入力先プログラムが管理する第2の日時情報とは異なる、前記記憶部に記憶された前記日時情報を変更し、前記プログラムによる、前記入力先プログラムに対する日時情報の取得要求に応じ、前記記憶部に記憶された前記日時情報を前記プログラムに応答する処理を前記コンピュータに実行させる請求項1記載のプログラム検査プログラム。前記検査部が発行したイベントデータごとに、当該イベントデータの発行前後の前記検査対象のプログラムの状態をイベント履歴記憶部に記憶し、前記イベント履歴記憶部を参照して、前記日時遷移イベントデータが連続するかを判定して、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する処理を前記コンピュータに実行させ、前記所定のイベントデータ群を生成する処理は、前記判断する処理において前記日時遷移イベントデータの追加が必要であると判断された場合に、前記入力イベントデータに、前記日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成する請求項1又は2記載のプログラム検査プログラム。前記判断する処理は、更に、前記イベント履歴記憶部を参照して、最後に前記日時遷移イベントデータが発行された後に、前記プログラムの状態を有効条件とする全ての前記入力イベントデータが発行されているか否かに基づいて、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する請求項3記載のプログラム検査プログラム。検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部と、前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部と、前記記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成する生成部と、前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する入力部と、前記判定において前記日時遷移イベントデータであると判定された場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更する変更部とを有するプログラム検査装置。検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部として機能するコンピュータが、前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成し、前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、前記判定において前記日時遷移イベントデータであると判定した場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更し、前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する処理を実行するプログラム検査方法。しかしながら、シナリオ生成技術では、機能の実行順及び日時情報の変更のタイミングの組み合わせが単純に洗い出されるため、アプリケーションの機能数が多くなると、テストシナリオの数が膨大となるという問題がある。また、異なるテストシナリオであっても、実質的に意味は同じであるテストシナリオが生成され、無駄なテストが行われることも多い。本発明は、上記の点に鑑みてなされたものであって、日時情報の変更を要するプログラム検査を効率化することのできるプログラム検査プログラム、プログラム検査装置、及びプログラム検査方法の提供を目的とする。そこで上記課題を解決するため、プログラム検査プログラムは、検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部として機能するコンピュータに、前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成し、前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、前記判定において前記日時遷移イベントデータであると判定した場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更し、前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する処理を実行させる。日時情報の変更を要するプログラム検査を効率化することができる。以下、図面に基づいて本発明の実施の形態を説明する。図1は、第一の実施の形態におけるプログラム検査装置のハードウェア構成例を示す図である。図1のプログラム検査装置10は、それぞれバスBで相互に接続されているドライブ装置100、補助記憶装置102、メモリ装置103、CPU104、及びインタフェース装置105等を有する。プログラム検査装置10での処理を実現するプログラムは、記録媒体101によって提供される。プログラムを記録した記録媒体101がドライブ装置100にセットされると、プログラムが記録媒体101からドライブ装置100を介して補助記憶装置102にインストールされる。但し、プログラムのインストールは必ずしも記録媒体101より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置102は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。メモリ装置103は、プログラムの起動指示があった場合に、補助記憶装置102からプログラムを読み出して格納する。CPU104は、メモリ装置103に格納されたプログラムに従ってプログラム検査装置10に係る機能を実行する。インタフェース装置105は、ネットワークに接続するためのインタフェースとして用いられる。なお、記録媒体101の一例としては、CD-ROM、DVDディスク、又はUSBメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置102の一例としては、HDDHardDiskDrive又はフラッシュメモリ等が挙げられる。記録媒体101及び補助記憶装置102のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。図2は、第一の実施の形態におけるプログラム検査装置のソフトウェア構成例を示す図である。同図において、プログラム検査装置10は、プログラムモデル検査部11、検査対象プログラム12、プログラム実行環境部13、日時情報管理部14、検査対象統合部15、及び検査対象イベント記憶部16等を有する。プログラムモデル検査部11、プログラム実行環境部13、日時情報管理部14、検査対象統合部15は、プログラム検査装置10にインストールされたプログラムがCPU104に実行させる処理により実現される。検査対象イベント記憶部16は、例えば、補助記憶装置102を用いて実現可能である。プログラムモデル検査部11は、検査テストの対象とされたプログラムの各状態において当該プログラムに関して有効なイベントイベントデータを発行し又は発生させ、当該プログラムの状態の遷移を検証することにより、当該プログラムの検査を行う。プログラムの状態とは、プログラムのメモリの状態メモリイメージの内容をいう。イベントとは、検査対象のプログラムの状態に影響を与えうるイベント事象をいう。例えば、検査対象のプログラムに対する要求又はデータ等の入力がイベントの一例として挙げられる。より具体的には、検査対象プログラム12が有するインタフェース関数又はメソッド等の呼び出しがイベントの一例である。有効なイベントとは、検査対象のプログラムの或る状態において、検査として意味の有るイベントをいう。検査として意味の有るイベントは、検査対象のプログラムの或る状態において実行可能なイベントに限られない。実行可能でないイベントが実行可能でないことを確認することも検査として意味が有るからである。なお、有効なイベントは、プログラムの状態に応じて変化しうる。図3は、第一の形態におけるプログラムモデル検査部を説明するための図である。同図において、プログラムP1は、検査対象のプログラムである。プログラムモデル検査部11を示すブロック内の各楕円は、プログラムP1の状態を示す。各楕円から伸びる矢印a、b、又はcは、各状態において有効なイベントである。また、プログラムP1から各状態に伸びる太線の矢印は、プログラムモデル検査部11が、プログラムP1のメモリの内容を各状態として抽出又は監視していることを示す。なお、各状態において有効なイベント群は、プログラムP1よりプログラムモデル検査部11に通知される。まず、上段のプログラムモデル検査部11を参照すると、プログラムP1の初期状態は、状態st1である。状態st1において有効なイベントは、イベントa及びbである。プログラムモデル検査部11は、有効なイベントのうちのいずれかを発行する。同図では、イベントaが発行されている。イベントaに応じた機能又は処理の実行により、プログラムP1は、状態st2に遷移している。状態st2において有効なイベントは、イベントa及びbである。状態st2において、プログラムモデル検査部11は、イベントbを発行している。その結果、プログラムP1は、状態st3に遷移している。状態st3では、イベントcのみが有効である。そこで、プログラムモデル検査部11は、イベントcを実行している。状態st3において有効な全てのイベントの実行が完了すると、プログラムモデル検査部11は、プログラムP1のメモリの状態を一つ前の状態に戻す。したがって、同図では、状態st2に戻される。状態st2において有効なイベントのうち、発行されていないイベントは、イベントaである。したがって、同図下段に示されるように、プログラムモデル検査部11は、イベントaを発行する。その結果、プログラムP1は、状態st4に遷移する。以降、プログラムモデル検査部11は、上記において説明した処理を繰り返す。すなわち、プログラムモデル検査部11は、或る状態において有効なイベントを全て実行し終えたら、プログラムP1を一つ前の状態に戻す。最終的に、初期状態st1に戻ると、プログラムモデル検査部11による、プログラムP1の検査テストは終了する。なお、プログラムモデル検査部11は、プログラムP1の状態の遷移を検証することで、プログラムP1が正しい動作をしているか否かを確認する。状態の遷移の検証とは、イベントの発行に応じた遷移先の状態が、予め期待されている状態であるか否かを確認することをいう。以上のような検査方法は、プログラムモデル検査とも呼ばれる。プログラムモデル検査に関しては、例えば、特開2010-191508号公報、特開2010-191507号公報、及び特開2009-87352号公報等に開示されている。図2に戻る。検査対象プログラム12は、検査テストの対象とされるプログラムである。検査対象プログラム12の機能は所定のものに限定されない。但し、検査対象プログラム12の振る舞い処理内容は、日時情報によって影響を受ける。プログラム実行環境部13は、OSOperatingSystem等、プログラムの実行環境を実現するプログラムである。本実施の形態において、プログラム実行環境部13は、検査対象プログラム12による日時情報の取得先日時情報の取得要求の入力先として位置付けられる。日時情報管理部14は、プログラム実行環境部13が管理する日時情報とは別に、日時情報を管理する。同図において、日時情報管理部14は、日時遷移実行部141及び日時遷移モデル記憶部142等を含む。日時遷移モデル記憶部142は、日時情報遷移モデルを記憶する。日時情報遷移モデルとは、遷移前の日時情報と遷移後の日時情報との対応情報である。日時遷移実行部141は、検査対象統合部15からの日時遷移イベントの入力に応じ、日時情報遷移モデルにしたがって日時情報を遷移させる日時情報を更新する。すなわち、日時遷移イベントとは、プログラム実行環境部13が管理する日時情報とは別に日時情報管理部14が管理する日時情報に関して、日時情報遷移モデルを基づく遷移変更又は更新の実行を、日時遷移実行部141に実行させるためのイベントである。日時情報管理部14が、検査対象のプログラムが参照する日時情報を、プログラム実行環境部13が管理する日時情報とは別に管理することで、検査対象のプログラム以外のプログラムに、検査のための日時情報の変更の影響を及ぼすことを防ぐことが出来る。検査対象統合部15は、プログラムモデル検査部11に対し、検査対象統合部15、検査対象プログラム12、及び日時情報管理部14を一つの検査対象として見せるための処理を実行する。すなわち、本来であれば、検査対象プログラム12が検査対象である。但し、検査対象統合部15が実行する処理により、プログラムモデル検査部11から見た場合、検査対象統合部15、検査対象プログラム12、及び日時情報管理部14が、図3におけるプログラムP1の位置付けとして見える。より詳しくは、検査対象統合部15は、自らが検査対象であるかのようにプログラムモデル検査部11に対して振る舞うことにより、結果的に、検査対象統合部15、検査対象プログラム12、及び日時情報管理部14を一つの検査対象のプログラムとして見せる偽装する。または、検査対象統合部15は、検査対象プログラム12及び日時情報管理部14を、プログラムモデル検査部11に対してラッピングするともいえる。以下、検査対象統合部15が有する斯かる機能を、便宜上ラッピング機能という。ラッピング機能を実現するため、検査対象統合部15は、日時遷移イベント追加部151及びイベント分配部152等を有する。日時遷移イベント追加部151は、検査対象プログラム12の各状態において有効なイベント群をプログラムモデル検査部11に通知する。すなわち、図3では、プログラムP1が、自らの各状態に対して有効なイベント群をプログラムモデル検査部11に通知する旨を説明した。本実施の形態では、日時遷移イベント追加部151が、斯かる役割を担う。イベント群の通知に際し、日時遷移イベント追加部151は、日時遷移イベントを有効なイベント群に含める追加する。その結果、プログラムモデル検査部11は、日時遷移イベントを、検査対象に対して有効なイベントの一つとして認識する。イベント分配部152は、日時遷移イベント追加部151によって通知されたイベント群の中からプログラムモデル検査部11によって発行されるイベントを、日時情報管理部14又は検査対象プログラム12に分配する。すなわち、日時遷移イベントに関しては、日時情報管理部14に入力される。日時遷移イベント以外のイベントに関しては、検査対象プログラム12に入力される。検査対象イベント記憶部16は、検査対象プログラム12の状態に応じて有効なイベントを示す情報を記憶する。検査対象イベント記憶部16は、例えば、補助記憶装置102を用いて実現可能である。続いて、本実施の形態の検査対象プログラム12の機能について説明する。検査対象プログラム12は、説明の便宜上、所定の商品の注文の受け付け処理及び支払処理を実行するアプリケーションであり、機能A、機能B、及び機能Cを有することとする。機能Aは、電子メールによって注文を受け付け、注文の内容注文情報をデータベース以下、注文DBという。に登録する機能である。機能Bは、Webページを介して注文を受け付け、注文情報を注文DBに登録する機能である。機能Cは、Webページを介して支払いを受け付け、注文DBに登録されている注文情報を削除する機能である。なお、注文された月に支払いが行われた場合、10の割り引きが行われる。したがって、検査対象プログラム12は、注文に対する支払いが注文当月内に行われたか否かによって振る舞いが異なる。以上のような検査対象プログラム12に関して、機能Aを起動させるイベントは、電子メールによる注文である。以下、当該イベントをイベントAという。機能Bを起動させるイベントは、Webページを介した注文である。以下、当該イベントをイベントBという。機能Cを起動させるイベントは、Webを介した支払いである。以下、当該イベントをイベントCという。上記のような機能を有する検査対象プログラム12に関して、プログラム検査装置10が実行する検査処理の概要について説明する。図4は、第一の実施の形態のプログラム検査装置による検査処理の概要を説明するための図である。検査の開始に応じ、プログラムモデル検査部11により、検査対象統合部15がプロセスとして起動される。プログラムモデル検査部11に対しては、検査対象統合部15に係るプログラムが検査対象として指定されているからである。検査対象統合部15は、検査対象プログラム12及び日時情報管理部14を、自らのプロセス空間内において起動する。例えば、検査対象プログラム12及び日時情報管理部14は、それぞれスレッドとして起動される。その結果、プログラムモデル検査部11にとって、検査対象のメモリの状態は、検査対象統合部15に係るプロセスの状態となる。当該プロセスの範囲は、同図において破線によって示されている。以下、当該プロセスを検査対象プロセスという。プログラムモデル検査部11からは、検査対象プロセスが検査対象として見えるからである。同図には、検査対象プロセスの状態遷移モデルm1が示されている。すなわち、状態遷移モデルm1は、検査対象プログラム12の状態だけでなく、日時情報管理部14の状態をも含む状態遷移モデルである。検査対象プログラム12厳密には、検査対象プロセスが或る状態に遷移すると、検査対象統合部15は、当該状態において有効なイベント群イベントA、B、Cと、日時遷移イベントとをプログラムモデル検査部11に通知するS11。なお、同図において、Nextは、日時遷移イベントを示す。プログラムモデル検査部11は、通知されたイベント群の中から一つのイベントを選択し、当該イベントイベントA、B、C、又はNextを検査対象統合部15に入力するS12。検査対象統合部15は、イベントA、B、又はCについては、検査対象プログラム12に入力しS13、日時遷移イベントNextについては、日時情報管理部14に入力するS14。日時遷移イベントNextを入力された日時情報管理部14は、日時情報遷移モデルに基づいて自らが管理している日時情報を遷移させる。一方、イベントA、B、又はCを入力された検査対象プログラム12は、イベントに応じた機能A、B、又はCを実行する。この際、検査対象プログラム12は、プログラム実行環境部13に対して日時情報の取得要求を入力するS15。日時情報の取得要求は、日時情報管理部14によってフックされる。したがって、検査対象プログラム12には、日時情報管理部14が管理する日時情報が返却される。なお、通常、OSOperatingSystemは、OSが有するAPIApplicationProgramInterfaceに対する機能を拡張するための機構を備える。斯かる機構の一例として、各APIに対する呼び出しを、他のプログラムにフックさせる機構が挙げられる。日時情報管理部14を当該他のプログラムとして、プログラム実行環境としてのOSに登録しておくことにより、日時情報の取得要求に係るAPIの呼び出しを、日時情報管理部14にフックさせることができる。なお、状態遷移モデルm1では、状態ST1において、日時情報は5/15月1日、注文DBの内容は、空レコード無しとなっている。ここで、日時情報は、日時情報管理部14が管理する変数の内容である。注文DBは、検査対象プログラム12が管理する変数の内容である。但し、日時情報管理部14及び検査対象プログラム12は、同一のプロセスに含まれるため、日時情報と注文DBとは、当該プロセスのメモリの状態を構成する。同図では、初期状態ST1において、イベントAが発行され、その結果として状態ST2に遷移した例が示されている。イベントAは、検査対象プログラム12の機能Aを起動させる。その結果、注文DBにレコードが登録される。なお、状態ST2では、日時情報は更新されない。続いて、日時遷移イベントNextが発行され、状態ST3に遷移している。状態ST3では、日時情報が更新されている。このように、検査対象統合部15によって、検査対象プログラム12の状態注文DBの内容と、日時情報管理部14の状態現在の日時情報とを一単位のメモリの状態としてプログラムモデル検査部11に見せることができる。以下、プログラム検査装置10の処理手順について更に詳しく説明する。図5は、第一の実施の形態の検査処理の処理手順の一例を説明するためのフローチャートである。同図のフローチャートの開始時において、検査対象プロセスは初期状態ST1図4参照であるとする。ステップS101において、検査対象統合部15の日時遷移イベント追加部151は、現在の状態例えば、初期状態ST1において、検査対象プログラム12にとって有効なイベント群を検査対象イベント記憶部16より抽出する。図6は、検査対象イベント記憶部からの有効イベントの抽出例を示す図である。同図において、検査対象イベント記憶部16は、検査対象プログラム12に対して入力可能なイベントごとに、有効条件を記憶する。有効条件とは、イベントが有効となる条件である。検査対象プロセスの状態の構成情報に対する条件を有効条件として指定することができる。例えば、現在の日時情報が月末であることを有効条件とすることができる。または、注文DBが空ではないことを有効条件とすることもできる。すなわち、有効条件は、イベントが有効な状態を示す情報であるといえる。ステップS101では、現在の状態に照らして、有効条件が満たされているイベントが抽出される。同図の検査対象イベント記憶部16では、有効条件が指定されているイベントはない。したがって、ステップS101では、同図に示されるように、全てのイベントA、B、及びCが抽出される。なお、図7に示されるように、イベントCに関して注文DBが空ではないことが、有効条件として登録されている場合、注文DBにレコードが登録されていなければ、イベントCは抽出されない。続いて、日時遷移イベント追加部151は、日時遷移イベントNextを、ステップS101において抽出された有効なイベント群に追加するS102。図8は、有効なイベント群への日時遷移イベントの追加を説明するための図である。同図に示されるように、ステップS102では、日時遷移イベントNextが、有効なイベント群に含められる。続いて、日時遷移イベント追加部151は、有効なイベント群をプログラムモデル検査部11に通知するS103。なお、本実施の形態では、プログラムモデル検査部11は、検査対象プロセスのメモリの状態内容を参照可能であるとする。プログラムモデル検査部11が、検査対象プロセスのメモリ状態を参照可能であるか否かは、プログラムモデル検査部11等の実装形態に依存する。プログラムモデル検査部11が検査対象プロセスのメモリの状態を参照可能でない場合、日時遷移イベント追加部151は、有効なイベント群と共に、検査対象プロセスのメモリの状態を示すデータをプログラムモデル検査部11に通知してもよい。当該データは、当該メモリの内容における代表的な変数の値本実施の形態では、日時情報の値及び注文DBの値の集合であってもよいし、当該メモリのイメージのハッシュ値であってもよい。要するに、現在のメモリの状態を他の状態と識別可能なデータであればよい。続いて、プログラムモデル検査部11は、通知された有効なイベント群の中から、一つのイベントを選択するS104。選択方法は、所定のものに限定されない。いずれかのイベントがランダムに選択されてもよい。プログラムモデル検査部11は、現在の検査対象プロセスの状態と、当該状態に対して有効なイベント群と、当該イベント群の中で選択されたイベントとを関連付けて、例えばメモリ装置103に記録しておく。以下、現在の検査対象プロセスの状態と、当該状態に対して有効なイベント群と、当該イベント群の中で選択されたイベントとの組み合わせの履歴を、検査実行履歴という。続いて、プログラムモデル検査部11は、選択したイベントを検査対象統合部15に入力するS105。その結果、イベントに応じた機能が実行される。以下、イベントに応じた機能の実行を、イベントの実行という。イベントの実行が終了すると、プログラムモデル検査部11は、当該イベントの実行結果を検証するS106。イベントの実行結果の検証は、例えば、イベントの実行後の検査対象プログラム12の状態と、検証用に予め作成されているデータ以下、検証用データという。とを照合することにより行われる。検証用データは、検査対象プログラム12の状態とイベントとの組み合わせごとに、当該状態において当該イベントが実行された場合に期待される遷移先の状態を示す情報が記録されたデータである。したがって、プログラムモデル検査部11は、検査対象プログラム12に関して、イベントの実行前と一致する状態と実行されたイベントとの組み合わせに対して検証用データに記録されている遷移先の状態と、イベントの実行後の検査対象プログラム12の状態とが一致するか否かを判定する。プログラムモデル検査部11は、比較された双方の状態が一致する場合、検査結果は合格であると判定し、一致しない場合、検査結果は、不合格であると判定する。なお、本実施の形態において、検査対象プログラム12の状態を示す情報は、例えば、注文DBの内容を示す情報である。検査結果が不合格である場合S107でNo、プログラムモデル検査部11は、検査結果は不合格であることを示す情報を出力しS108、検査処理を終了させる。但し、検査結果が不合格である場合に、以降の検査処理が継続されてもよい。検査結果が合格である場合S107でYes、プログラムモデル検査部11は、検査対象プロセスの現在の状態を抽出又は取得するS109。ここで抽出される状態は、ステップS105におけるイベントの実行後の遷移先の状態である。続いて、プログラムモデル検査部11は、検査実行履歴に記録されている状態と、抽出された状態現在の状態とを照合して、現在の状態は、既に検査を実行済みの状態であるか否かを判定するS110。すなわち、現在の状態と一致する状態が検査実行履歴に含まれている場合、現在の状態は既に検査を実行済みであると判定される。現在の状態と一致する状態が検査実行履歴に含まれていない場合、現在の状態はまだ検査が実行されていないと判定される。現在の状態が検査を実行済みの状態でない場合S110でNo、プログラムモデル検査部11は、検査対象プロセスは、終了状態であるか否かを判定するS111。終了状態とは、例えば、プロセスが終了してしまった状態である。検査対象プロセスが終了状態でない場合S111でNo、プログラムモデル検査部11は、ステップS103における、有効なイベント群の通知に対する応答を検査対象統合部15に返却する。その結果、検査対象統合部15に制御が戻り、ステップS101以降が繰り返される。一方、検査対象プロセスが終了状態である場合S111でYes、又は現在の状態が検査を実行済みの状態である場合S110でYes、プログラムモデル検査部11は、検査対象とする状態検査対象プロセスの状態を、現在の状態の一つ前の状態に戻すS112。一つ前の状態とは、現在の状態に遷移する直前の状態をいう。なお、検査実行履歴は、例えば、スタック構造によって各状態とイベントとの組み合わせを記憶してもよい。スタック構造であれば、一つ前の状態を容易の特定することができる。以降、当該一つ前の状態が、現在の状態となる。続いて、プログラムモデル検査部11は、検査実行履歴を参照して、現在の状態に関して有効なイベントは、全て実行されたか否かを判定するS113。すなわち、検査実行履歴において、現在の状態に関して記録されている有効なイベント群の全てのイベントが選択済であるか否かが判定される。現在の状態に関して未実行のイベントが有る場合S113でNo、プログラムモデル検査部11は、ステップS104以降を繰り返す。この際、現在の状態に関して未実行のイベントのうちの一つが実行対象として選択される。一方、現在の状態に関して有効なイベントが全て実行されている場合S113でYes、プログラムモデル検査部11は、検査対象プロセスが初期状態であるか否かを判定するS114。例えば、スタック構造の検査実行履歴において、現在の状態が、最上位に記録されている状態であるか否かが判定される。現在の状態が初期状態でない場合、プログラムモデル検査部11は、ステップS112以降を繰り返す。現時の状態が初期状態である場合、プログラムモデル検査部11は、検査処理を終了させる。この場合は、検査対象プロセスの状態遷移モデルにおける全ての遷移パスが実行された場合だからである。続いて、ステップS105の詳細について説明する。図9は、イベントの実行処理の処理手順の一例を説明するためのフローチャートである。検査対象統合部15のイベント分配部152は、プログラムモデル検査部11からの入力イベントが日時遷移イベントNextであるか否かを判定するS201。入力イベントが日時遷移イベントNextである場合S201でYes、イベント分配部152は、日時情報管理部14に日時遷移イベントNextを入力するS202。日時情報管理部14の日時遷移実行部141は、日時遷移イベントNextの入力に応じ、日時遷移モデル記憶部142を参照して、現在の日時情報を更新する遷移させるS203。図10は、日時遷移モデル記憶部の構成例を示す図である。同図において、日時遷移モデル記憶部142は、遷移前日時及び遷移後日時の組み合わせの一覧を記憶する。或るレコードの遷移後日時は、他のレコード同図では、次のレコードの遷移前日時と一致する。したがって、日時遷移モデル記憶部142に記憶された日時遷移モデルは、日時の遷移を継続的に示すことができる。但し、同じ日時が繰り返される日時遷移モデルが日時遷移モデル記憶部142に登録されてもよい。同図の場合、遷移前日時が6/1であるレコードに関して、遷移後日時が5/1とされてもよい。そうすることにより、5/1と6/1が交互に遷移する日時遷移モデルを作成することができる。なお、日時遷移モデル記憶部142の最初のレコードの遷移前日時情報5/1は、日時情報管理部14の初期化時において日時情報に設定される日時情報である。ステップS203において、日時遷移実行部141は、遷移前日時が現在の日時情報と一致するレコードを日時遷移モデル記憶部142より検索し、検索されたレコードの遷移後日時によって現在の日時情報を更新する。一方、プログラムモデル検査部11からの入力イベントが日時遷移イベントでない場合すなわち、イベントA、B、又はCである場合S201でNo、イベント分配部152は、検査対象プログラム12に当該イベントを入力するS204。検査対象プログラム12は、当該イベントに応じた機能を実行するS205。その結果、本実施の形態においては、注文DBの内容が更新される。この際、検査対象プログラム12は、必要に応じて、プログラム実行環境部13に対して日時情報の取得要求を行う。例えば、機能A又は機能Bの実行時には、注文の日時を注文DBに記録するために、日時情報の取得要求が行われる。また、機能Cの実行時には、支払いの日時が、注文当月内であるか否かを判定するため、日時情報の取得要求が行われる。続いて、プログラム実行環境部13に対する日時情報の取得要求に応じて実行される処理について説明する。図11は、日時情報の取得要求に応じて実行される処理手順の一例を説明するためのフローチャートである。ステップS301において、プログラム実行環境部13は、日時情報管理部14に対して日時情報の取得要求を転送する。上記したように、日時情報の取得要求の転送は、日時情報管理部14による、日時情報の取得要求のフックという形態によって実現されてもよい。続いて、日時情報管理部14の日時遷移実行部141は、現在の日時情報の値をプログラム実行環境部13に返却するS302。続いて、プログラム実行環境部13は、当該日時情報の値を検査対象プログラム12に返却するS303。その結果、日時情報管理部14によって管理される日時情報が検査対象プログラム12に伝達される。なお、検査対象プログラム12が日時情報管理部14に対して日時情報の取得要求を行わないのは、検査対象プログラム12は、日時情報管理部14の存在を認識していないからである。すなわち、日時情報管理部14は、検査対象プログラム12の検査用に実装されている機能であり、検査対象プログラム12の本番運用時において、検査対象プログラム12が日時情報の取得先とするのは、プログラム実行環境部13であるからである。なお、日時情報の管理は、日時情報管理部14ではなく、プログラム実行環境部13に任せてもよい。すなわち、日時情報管理部14は、日時遷移イベントの入力に応じ、日時遷移モデル記憶部142に基づいて。プログラム実行環境部13が管理する日時情報を更新してもよい。この場合、プログラム実行環境部13に対する日時情報の取得要求は、日時情報管理部14によってフックされる必要はない。すなわち、プログラム実行環境部13が管理する日時情報が検査対象プログラム12に返却されればよい。但し、プログラム実行環境部13は、検査対象プログラム12以外の非図示の各種のプログラムからも共用されうる。したがって、検査対象プログラム12の検査の都合によってプログラム実行環境部13の日時情報が更新された場合、他のプログラムに予期しない影響を与える可能性がある。本実施の形態では、斯かる可能性を回避するため、日時情報管理部14が現在の日時情報を管理するようにしている。換言すれば、斯かる可能性を考慮する必要が無い場合、日時情報の管理は、日時情報管理部14ではなく、プログラム実行環境部13に任せてもよい。また、日時情報管理部14は、検査対象統合部15の一部として実装されてもよい。すなわち、検査対象統合部15が、日時情報管理部14の機能を有していてもよい。上述したように、第一の実施の形態によれば、検査対象プログラム12の状態遷移と日時情報の遷移とを含む状態遷移モデルに基づいて、プログラムモデル検査技術を利用して検査対象プログラム12の検査テストを実行することができる。したがって、検査対象プログラム12の機能と、日時情報の遷移のタイミングとの順列を洗い出し、当該順列に基づくテストシナリオによって検査を行う場合に比べて、検査の実行ステップ数を削減することができる。例えば、図12は、第一の実施の形態の実行ステップ数の一例を説明するための図である。同図において、Aは、本実施の形態の検査対象プログラム12と日時情報の変更のタイミングとの順列の一覧である。検査対象プログラム12の機能は3つである。日時情報の変更のタイミングが1回であるとすると、順列の要素は4つである。したがって、Aの一覧における順列数シナリオ数は、4の階乗=24である。また、各シナリオは、3つの機能のそれぞれを実行する3ステップと、日時情報を5/1に初期化するステップと、日時情報を変更するステップとの5つのステップを含む。したがって、Aにおける実行ステップ数は、24×5=120ステップとなる。一方、Bは、検査対象プロセスの状態遷移を洗い出した結果である。当該状態遷移に含まれる遷移数は31である。当該遷移数が、Bにおける実行ステップ数ということになる。したがって、Bにおける実行ステップ数は、31ステップとなる。このように、本実施の形態によれば、検査の実行ステップ数を削減することができる。すなわち、検査対象プログラム12の検査を効率化することができる。なお、プログラム検査装置10は、図13に示されるような構成を有していてもよい。図13は、本発明の実施の形態におけるプログラム検査装置の第二のソフトウェア構成例及び第二の処理概要を説明するための図である。同図において、図2と同一又は対応する部分には、図2と同一符号が付されている。同図のプログラム検査装置10aは、検査対象統合部15を有していない。したがって、プログラムモデル検査部11は、検査対象プログラム12を検査対象のプログラムとして認識する。すなわち、上記において検査対象プロセスとして説明したプロセスは、検査対象プログラムのプロセスとなる。その結果、同図の構成では、例えば、次のような処理手順が実行される。検査対象プログラム12が或る状態に遷移すると、検査対象プログラム12は、当該状態において有効なイベント群イベントA、B、Cをプログラムモデル検査部11に通知するS21。続いて、プログラムモデル検査部11は、日時情報の遷移要求を日時情報管理部14に入力するS22。プログラムモデル検査部11は、また、日時情報の遷移要求に同期させて、ステップS21において通知されたイベント群の中から一つのイベントを選択し、当該イベントイベントA、B、又はCを検査対象プログラム12に入力するS23。日時情報の遷移要求を入力された日時情報管理部14は、プログラム実行環部13の日時情報を更新するS24。但し、図4の構成の場合と同様に、日時情報管理部14が管理する日時情報が更新されてもよい。イベントA、B,又はCを入力された検査対象プログラム12は、イベントに応じた機能A、B、又はCを実行する。この際、検査対象プログラム12は、プログラム実行環境より日時情報の取得を要求するS25。当該取得要求に応じて、プログラム実行環境部13又は日時情報管理部14が管理する日時情報が検査対象プログラム12に返却される。このように、図13に示されるような構成を有するプログラム検査装置10aにおいても、検査対象プログラム12の状態を遷移させつつ、日時情報を更新することができる。但し、図13においては、プログラムモデル検査部11が、日時情報の遷移を意識する必要がある。また、ステップS22より明らかなように、プログラムモデル検査部11は、検査対象プログラム12以外に、日時情報管理部14の存在を意識し、日時情報管理部14とのインタフェースを有する必要がある。一方、図2におけるプログラムモデル検査部12は、日時情報の遷移や、日時情報管理部14の存在等を意識する必要性は低い。したがって、図2の構成によれば、プログラムモデル検査部12に関して、汎用的な製品を利用することができるという利点がある。このことは、換言すれば、検査対象統合部15及び日時情報管理部14の汎用性が確保されることを意味する。すなわち、検査対象統合部15及び日時情報管理部14が、特定の製品に係るプログラムモデル検査部12に依存する必要性を低減させることができる。ところで、第一の実施の形態において、日時遷移イベントNextは、有効なイベント群に対して無条件に又は常に追加される図5のステップS102、図8等参照。したがって、検査対象プロセスが日時遷移イベントNextの発行を受けても意味の無い場合においても、日時遷移イベントNextが発行されてしまう。すなわち、第一の実施の形態における検査の実行ステップ図12B参照には、冗長又は無駄な検査パスを構成する可能性がある。図14は、冗長な検査パスを発生させる日時遷移イベントの発行例を示す図である。同図において、各楕円は、検査対象プログラム12を含む検査対象プロセスの状態を示す。検査対象プログラム12は、機能A、B、Cを有し、各機能を起動させるイベントを、イベントA、B、Cという。イベントAの有効条件は無いこととする。イベントBの有効条件は、日時情報が示す日時が月末であることとする。イベントCの有効条件は、日時情報が示す日時が月初であることであるとする。同図において、状態ST10における日時情報が示す日時は、6/15である。すなわち、状態ST10における日時は、月末でも月初でもない。したがって、状態ST10において有効なイベントはイベントAである。また、日時遷移イベントNextも、有効なイベントに追加される。したがって、状態ST10では、イベントA及び日時遷移イベントNextが発行される。状態ST10に対して日時遷移イベントNextが発行された場合の遷移先の状態は、状態ST12である。状態ST12における日時情報が示す日時は、6/30である。したがって、状態ST12において有効なイベントは、イベントA及びBである。また、日時遷移イベントNextも有効なイベントに追加される。したがって、状態ST12では、イベントA、B、及び日時遷移イベントNextが発行される。状態ST12において、日時遷移イベントNextが発行された場合、検査対象プロセスの状態は、日時情報が7/1すなわち、月初である状態ST15へ遷移する。ここで、状態ST10→状態ST12→状態ST15への状態遷移パス検査パスにおいては、日時遷移イベントNextが連続して発行されることになる。その結果、状態ST15では、6/30すなわち、月末において実行されているべき機能Bは実行されない状態において、機能Cが実行されてしまう。このような、検査パスは、異常系の検査として意味を有する場合も有るが、正常系の検査としては必要な検査パスではない。すなわち、冗長な検査パスである。そこで、上記のような冗長性を除去した例を、第二の実施の形態として説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及されない点については、第一の実施の形態と同様でよい。図15は、第二の実施の形態におけるプログラム検査装置のソフトウェア構成例を示す図である。図15中、図2と同一部分には同一符号を付し、その説明は省略する。図15において、検査対象統合部15は、日時遷移要否判断部153を更に有する。日時遷移要否判断部153は、日時遷移イベントNextの追加の要否を判断する。すなわち、第二の実施の形態において、日時遷移イベント追加部151は、日時遷移イベントNextを有効なイベント群に無条件に追加するのではなく、日時遷移イベントNextの追加の要否を日時遷移要否判断部153に問い合わせる。日時遷移イベント追加部151は、日時遷移要否判断部153によって日時遷移イベントNextの追加が必要であると判断された場合に、日時遷移イベントNextを有効なイベント群に追加する。図16は、日時遷移要否判断部の機能構成例を示す図である。同図において、日時遷移要否判断部153は、受付部171、判断部172、イベント履歴管理部173、及びイベント履歴記憶部174等を有する。受付部171は、日時遷移イベント追加部151より、日時遷移イベントNextの追加の要否の問い合わせを受け付ける。受付部171は、また、当該問い合わせに対する応答を、日時遷移イベント追加部151に出力する。イベント履歴管理部173は、検査対象プロセスの状態遷移が発生するたびに、遷移元の状態の識別情報、遷移先の状態の識別情報、及び状態遷移のきっかけ原因となったイベントの識別情報とを関連付けてイベント履歴記憶部174に記録する。判断部172は、受付部171によって受け付けられた問い合わせに応じ、イベント履歴記憶部174が記憶する情報に基づいて、日時遷移イベントNextの追加の要否を判断する。以下、第二の実施の形態のプログラム検査装置10の処理手順について説明する。図17は、第二の実施の形態の検査処理の処理手順の一例を説明するためのフローチャートである。図17中、図5と同一ステップには同一ステップ番号を付し、その説明は省略する。図17では、ステップS101及びステップS102の間に、ステップS101a及びS101bが追加されている。また、ステップS105及びS106の間に、ステップS105aが追加されている。ステップS101aにおいて、日時遷移要否判断部153は、日時遷移イベント追加部151からの問い合わせに応じて、日時遷移イベントNextの追加の要否の判断処理を実行する。当該判断処理において、日時遷移イベントNextの追加は必要であると判断された場合S101bでYes、日時遷移イベント追加部151は、日時遷移イベントNextを、ステップS101において抽出された有効なイベント群に追加するS102。一方、当該判断処理において、日時遷移イベントNextの追加は不要であると判断された場合S101bでNo、日時遷移イベント追加部151は、ステップS102を実行しない。また、ステップS105aにおいて、イベント履歴管理部173は、プログラムモデル検査部11からの通知に応じ、実行されたイベントと、当該イベントの実行前の状態の識別情報、及び当該イベントの実行後の状態の識別情報をイベント履歴記憶部174に記録する。続いて、図17のステップS105aの詳細について説明する。図18は、イベント履歴記録処理の処理手順の一例を説明するためのシーケンス図である。イベントの実行後、プログラムモデル検査部は、実行したイベントの識別情報以下、イベント名という。と、当該イベント実行前後のそれぞれの検査対象プロセスの状態を示す情報とを含むイベント履歴情報を、イベント履歴管理部173に通知するS501。続いて、イベント履歴管理部173は、通知されたイベント履歴情報を、イベント履歴記憶部174の新たなレコードとして記録するS502。図19は、イベント履歴記憶部の構成例を示す図である。同図において、イベント履歴記憶部174の各レコードは、一つのイベントの実行に関して、検査対象プロセスの状態遷移前の状態を示す情報、状態遷移後の状態を示す情報、及び当該イベントのイベント名等を記憶する。同図では、各状態を示す情報は、数値0~3等によって示されているが、これは便宜的なものである。また、最初のレコードは、検査対象プロセスの初期状態を記憶するためのレコードであるため、最初のレコードの遷移後状態及びイベント名の値は空となっている。すなわち、最初のレコードの遷移前状態は、検査対象プロセスの初期状態を示す。図19の記憶内容は、図20に示される状態遷移イベントの履歴に対応する。図20は、一例としてのイベント履歴記憶部に記憶された状態遷移を示す図である。図20における、状態ST10、ST11、ST12、ST13、ST14は、図19において、順番に、0、1、2、3、4によって示されている状態に相当する。続いて、図17のステップS101aについて説明する。図21は、日時遷移イベントの追加の要否の判断処理の概要を説明するためのシーケンス図である。ステップS601において、日時遷移イベント追加部151は、日時遷移イベントNextの追加の要否を受付部171に問い合わせるS601。この際、日時遷移イベント追加部151は、図22のステップS101において抽出された有効なイベント群のイベント名の一覧を問い合わせ内容に含める。受付部171は、日時遷移イベント追加部151からの問い合わせ内容を判断部172に通知するS602。判断部172は、当該通知に応じ、イベント履歴記憶部174の記憶内容イベント履歴情報を、イベント履歴管理部173を介して取得するS603~S606。続いて、判断部172は、問い合わせ内容と、イベント履歴情報とに基づいて、日時遷移イベントNextの追加の要否を判断するS607。続いて、判断部172は、判断結果を受付部171に応答するS608。受付部171は、当該判断結果を日時遷移イベント追加部151に応答するS609。続いて、図21のステップS602~S608において、判断部172又はイベント履歴管理部173によって実行される処理の詳細について説明する。図22は、日時遷移イベントの追加の要否の判断処理の処理手順の一例を説明するためのフローチャートである。ステップS701において、判断部172は、受付部171より、問い合わせ内容を受け付ける。続いて、判断部172は、検査対象プロセスの現在の状態以下、現状態という。への遷移のきっかけ原因となったイベント名を、イベント履歴管理部173に問い合わせるS702。続いて、イベント履歴管理部173は、現状態への遷移のきっかけとなったイベント名を、イベント履歴記憶部174より取得するS703。検査対象プロセスの現状態は、イベント履歴記憶部174の最後のレコードの遷移後状態に記録されている情報に基づいて特定される。したがって、現状態への遷移のきっかけとなったイベント名は、当該最後のレコードに記録されているイベント名である。続いて、イベント履歴管理部173は、当該イベント名を判断部172に返却するS703。続いて、判断部172は、返却されたイベント名がNextであるか、すなわち、日時遷移イベントNextを示すイベント名であるか否かを判定するS704。返却されたイベント名がNextである場合S704でYes、判断部172は、日時遷移イベントNextの追加は不要である旨を、受付部171に対して応答するS705。すなわち、この場合、日時遷移イベントNextが連続して発生する検査パスが形成されてしまうことになる。したがって、現状態への遷移のきっかけとなったイベントが日時遷移イベントNextである場合は、日時遷移イベントNextの追加は不要であると判断される。一方、現状態への遷移のきっかけとなったイベント名がNextでない場合S704でNo、判断部172は、最後最新の日時遷移イベントNextから、現状態に至るまでの全てのイベントのイベント名の一覧を、イベント履歴管理部173に問い合わせるS706。最後の日時遷移イベントNextから、現状態に至るまでの全てのイベントとは、最後の日時遷移イベントNextから、現状態に至るまでの状態遷移のパスにおいて、直系の又は直列ののパスに含まれる全てのイベントをいう。当該問い合わせに応じ、イベント履歴管理部173は、まず、イベント履歴記憶部174における最後のレコードを注目レコードとするS707。続いて、イベント履歴管理部173は、注目レコードのイベント名をイベント履歴記憶部174より取得するS708。続いて、イベント履歴管理部173は、取得されたイベント名はNextであるか否かを判定するS709。当該イベント名がNextでない場合S709でNo、イベント履歴管理部173は、イベント履歴記憶部174において、注目レコードの遷移前状態と一致する状態が遷移後状態であるレコードを、新たに注目レコードとするS710。すなわち、状態遷移のパスが遡られる。イベント履歴管理部173は、注目レコードのイベント名がNextとなるまで、ステップS708~S710を繰り返す。注目レコードのイベント名がNextである場合S709でYes、イベント履歴管理部173は、ステップS708において取得された全てのイベント名の一覧から、最後に取得されたイベント名すなわち、Nextを除いた一覧を、判断部172に返却するS711。すなわち、当該一覧が、最後最新の日時遷移イベントNextから、現状態に至るまでの全てのイベントのイベント名の一覧である。なお、当該イベント名の一覧は、現状態の日時において、実行された全てのイベントのイベント名の一覧に相当する。続いて、判断部172は、返却されたイベント名の一覧を、問い合わせ内容に含まれている、有効なイベント群のイベント名の一覧と比較するS712。続いて、判断部172は、返却されたイベント名の一覧に関して、有効なイベント群のイベント名の一覧に対する不足分の有無を判定するS713。すなわち、返却されたイベント名の一覧に含まれておらず、有効なイベント群のイベント名の一覧に含まれているイベント名の有無が判定される。当該判定は、現状態において有効なイベント群に係るすべての機能が、現状態の日時において実行されたか否かの判定に相当する。不足分が有る場合S713でYes、判断部172は、日時遷移イベントNextの追加は不要である旨を、受付部171に対して応答するS714。不足分が無い場合S713でNo、判断部172は、日時遷移イベントNextの追加は必要である旨を、受付部171に対して応答するS715。すなわち、日時遷移イベントNextは、各日時において、有効な全てのイベントが実行された後に実行される。そうすることで、或る日時において実行されるべき一部又は全部の機能が実行されないまま、日時が遷移してしまうといったケース検査パスの発生が回避される。図17、図18、及び図22において説明したような処理が実行されることにより、例えば、図14における、状態ST12から状態ST15への遷移の発生は抑制される。すなわち、状態ST12への遷移のきっかけとなったイベントは日時遷移イベントNextである。したがって、図22のステップS704及びS705の判断により、有効なイベント群に対する日時遷移イベントの追加は回避される。また、状態ST13及び状態ST14における、日時遷移イベントNextの追加も抑制される。すなわち、状態ST13及び状態ST14のそれぞれにおいて有効なイベントは、イベントA及びBである。しかしながら、状態ST13及び状態ST14では、最後の日時遷移イベントNextの実行後からイベントB又はイベントAが実行されていない。したがって、図22のステップ706以降の判断により、有効なイベント群に対する日時遷移イベントの追加は抑制される。なお、図14の状態ST13においてイベントBが発生した場合の遷移先の非図示の状態においては、日時遷移イベントNextが有効なイベント群に追加される。また、状態ST14においてイベントAが発生した場合の遷移先の非図示の状態においても、日時遷移イベントNextが有効なイベント群に追加される。図14に関して説明した有効条件によれば、6/30すなわち、月末において、有効なイベント群は、イベントA及びBである。そして、上記した各非図示の遷移先の状態は、6/30において、イベントA及びBの双方が発生した状態すなわち、機能A及びBの双方が実行された状態である。また、当該各非図示の状態への遷移へのきっかけとなったイベントは、日時遷移イベントNextではない。したがって、当該各非図示の状態では、日時遷移イベントの追加が許容される。上述したように、第二の実施の形態によれば、日時遷移イベントが無条件に追加されることによる、冗長な検査パスの発生を抑制することができる。したがって、検査の実行ステップを、更に削減することができる。また、日時の遷移前に或る機能が実行されていることを前提とした他の機能の実行に関して、例えば、注文DBのデータ内容の矛盾等に基づく異常の発生を防止することができる。換言すれば、正しいテストシナリオの実行が可能になり、テスト精度を向上させることができる。なお、本実施の形態において、プログラムモデル検査部11は、検査部の一例である。日時遷移イベント追加部151は、生成部の一例である。イベント分配部152は、入力部の一例である。日時遷移実行部141は、変更部の一例である。以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形変更が可能である。以上の説明に関し、更に以下の項を開示する。付記1検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部として機能するコンピュータに、前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成し、前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、前記判定において前記日時遷移イベントデータであると判定した場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更し、前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する処理を実行させるプログラム検査プログラム。付記2前記日時情報を変更する処理は、前記プログラムによる日時情報の取得要求の入力先プログラムが管理する第2の日時情報とは異なる、前記記憶部に記憶された前記日時情報を変更し、前記プログラムによる、前記入力先プログラムに対する日時情報の取得要求に応じ、前記記憶部に記憶された前記日時情報を前記プログラムに応答する処理を前記コンピュータに実行させる付記1記載のプログラム検査プログラム。付記3前記検査部が発行したイベントデータごとに、当該イベントデータの発行前後の前記検査対象のプログラムの状態をイベント履歴記憶部に記憶し、前記イベント履歴記憶部を参照して、前記日時遷移イベントデータが連続するかを判定して、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する処理を前記コンピュータに実行させ、前記所定のイベントデータ群を生成する処理は、前記判断する処理において前記日時遷移イベントデータの追加が必要であると判断された場合に、前記入力イベントデータに、前記日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成する付記1又は2記載のプログラム検査プログラム。付記4前記判断する処理は、更に、前記イベント履歴記憶部を参照して、最後に前記日時遷移イベントデータが発行された後に、前記プログラムの状態を有効条件とする全ての前記入力イベントデータが発行されているか否かに基づいて、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する付記3記載のプログラム検査プログラム。付記5検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部と、前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部と、前記記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成する生成部と、前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する入力部と、前記判定において前記日時遷移イベントデータであると判定された場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更する変更部とを有するプログラム検査装置。付記6前記変更部は、前記プログラムによる日時情報の取得要求の入力先プログラムが管理する第2の日時情報とは異なる、前記記憶部に記憶された前記日時情報を変更し、前記プログラムによる、前記入力先プログラムに対する日時情報の取得要求に応じ、前記記憶部に記憶された前記日時情報を前記プログラムに応答する付記5記載のプログラム検査装置。付記7前記検査部が発行したイベントデータごとに、当該イベントデータの発行前後の前記検査対象のプログラムの状態を記憶するイベント履歴記憶部と、前記イベント履歴記憶部を参照して、前記日時遷移イベントデータが連続するかを判定して、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する判断部とを有し、前記生成部は、前記判断部によって前記日時遷移イベントデータの追加が必要であると判断された場合に、前記入力イベントデータに、前記日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成する付記5又は6記載のプログラム検査装置。付記8前記判断部は、更に、前記イベント履歴記憶部を参照して、最後に前記日時遷移イベントデータが発行された後に、前記プログラムの状態を有効条件とする全ての前記入力イベントデータが発行されているか否かに基づいて、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する付記7記載のプログラム検査装置付記9検査対象のプログラムを実行し、前記プログラムの状態に応じて、所定のイベントデータ群に含まれるイベントデータを発行して、該状態の遷移を検証する検査部として機能するコンピュータが、前記プログラムの状態を基に、前記プログラムの状態を有効条件とする前記プログラムへの入力イベントを示す入力イベントデータが記憶された記憶部を参照して、前記プログラムの状態を有効条件とする入力イベントデータを抽出し、抽出した前記入力イベントデータに、前記プログラムが参照する日時情報の変更を示す所定の日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成し、前記生成した所定のイベントデータ群を前記検査部に通知し、前記検査部が発行したイベントデータを取得し、前記取得したイベントデータが前記日時遷移イベントデータであるか否かを判定し、前記判定において前記日時遷移イベントデータであると判定した場合に、前記記憶部に記憶された遷移前の日時情報と遷移後の日時情報との対応情報を参照して、前記日時情報を、該日時情報と一致する遷移前の日時情報に対応付けて前記記憶部に記憶された遷移後の日時情報に変更し、前記判定において前記日時遷移イベントデータでないと判定した場合に、当該イベントデータを前記プログラムに入力する処理を実行するプログラム検査方法。付記10前記日時情報を変更する処理は、前記プログラムによる日時情報の取得要求の入力先プログラムが管理する第2の日時情報とは異なる、前記記憶部に記憶された前記日時情報を変更し、前記プログラムによる、前記入力先プログラムに対する日時情報の取得要求に応じ、前記記憶部に記憶された前記日時情報を前記プログラムに応答する処理を前記コンピュータに実行させる付記9記載のプログラム検査方法。付記11前記検査部が発行したイベントデータごとに、当該イベントデータの発行前後の前記検査対象のプログラムの状態をイベント履歴記憶部に記憶し、前記イベント履歴記憶部を参照して、前記日時遷移イベントデータが連続するかを判定して、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する処理を前記コンピュータが実行し、前記所定のイベントデータ群を生成する処理は、前記判断する処理において前記日時遷移イベントデータの追加が必要であると判断された場合に、前記入力イベントデータに、前記日時遷移イベントデータを追加して、前記所定のイベントデータ群を生成する付記9又は10記載のプログラム検査方法。付記12前記判断する処理は、更に、前記イベント履歴記憶部を参照して、最後に前記日時遷移イベントデータが発行された後に、前記プログラムの状態を有効条件とする全ての前記入力イベントデータが発行されているか否かに基づいて、前記入力イベントデータへの前記日時遷移イベントデータの追加の要否を判断する付記11記載のプログラム検査方法。"