(57)【要約】【課題】情報処理システムの仕様設計書より、設計仕様の一貫性と整合性を検証する機能、及び、テストデータを生成する機能を有する、設計品質検査支援システムを提供する。【解決手段】情報処理システムの設計書の論理体系定義情報及び設計書を検証するための設計検証パラメータを記憶したデータベースと、設計書読込処理部と、設計情報抽出処理部と、設計検証処理部とを備えた設計品質検査の支援システム。【選択図】図１
2010072944.tif 000002
【特許請求の範囲】
【請求項１】
情報処理システムの設計書の論理体系定義情報及び設計書を検証するための設計検証パラメータを記憶したデータベースと、
情報処理システムの設計書データを読み込む設計書読込処理部と、
前記論理体系定義情報に基づき、前記読み込んだ設計書データから設計情報を抽出する設計情報抽出処理部と、
前記設計検証パラメータと前記抽出した設計情報とを照合することにより、前記読み込んだ設計書データの設計検証を行い、当該設計検証結果を出力する設計検証処理部とを備えた設計品質検査の支援システム。
【請求項２】
情報処理システムの設計書の論理体系定義情報、設計書を検証するための設計検証パラメータ及び情報処理システムのテストデータを生成するためのテストデータ生成パラメータを記憶したデータベースと、
情報処理システムの設計書データを読み込む設計書読込処理部と、
前記論理体系定義情報に基づき、前記読み込んだ設計書データから設計情報を抽出する設計情報抽出処理部と、
前記設計検証パラメータと前記抽出した設計情報とを照合することにより、前記読み込んだ設計書データの設計検証を行い、当該設計検証結果を出力する設計検証処理部と、
前記テストデータ生成パラメータと前記抽出した設計情報とを用いて、情報処理システムのテストデータを生成し、当該テストデータを出力するテストデータ生成処理部とを備えた設計品質検査の支援システム。
【請求項３】
前記設計書読込処理部は、前記設計書データから、入力インタフェースの条件、出力インタフェースの条件、及びデータ項目の定義域に関する情報を少なくとも抽出し、
前記設計検証処理部は、前記設計検証パラメータを参照して、前記抽出した情報における入力インタフェースと出力インタフェースとの一貫性、入力インタフェース及び出力インタフェースの編集条件に関する記述内容の整合性、並びにデータ項目の定義域の正当性を検査することを特徴とする請求項１又は２に記載の設計品質検査の支援システム。
【請求項４】
前記テストデータ生成処理部は、前記設計書読込処理部において抽出した設計情報に含まれるデータ項目の定義域並びに入力インタフェース及び出力インタフェースの編集条件に関する記述内容に適合するテストケースと当該テストケースに対して期待される出力データ値とを生成し出力することを特徴とする請求項３に記載の設計品質検査の支援システム。
【請求項５】
情報処理システムの設計書の論理体系定義情報及び設計書を検証するための設計検証パラメータを記憶したデータベースと、設計書読込処理部と、設計情報抽出処理部と、設計検証処理部とを備えた設計品質検査の支援システムにおける設計品質検査の支援プログラムであって、
前記設計書読込処理部が、情報処理システムの設計書データを読み込み、
前記設計情報抽出処理部が、前記論理体系定義情報に基づき、前記読み込んだ設計書データから設計情報を抽出し、
前記設計検証処理部が、前記設計検証パラメータと前記抽出した設計情報とを照合することにより、前記読み込んだ設計書データの設計検証を行い、当該設計検証結果を出力することを特徴とする設計品質検査の支援プログラム。
【請求項６】
情報処理システムの設計書の論理体系定義情報、設計書を検証するための設計検証パラメータ及び情報処理システムのテストデータを生成するためのテストデータ生成パラメータを記憶したデータベースと、設計書読込処理部と、設計情報抽出処理部と、設計検証処理部と、テストデータ生成処理部とを備えた設計品質検査の支援システムにおける設計品質検査の支援プログラムであって、
前記設計書読込処理部が、情報処理システムの設計書データを読み込み、
前記設計情報抽出処理部が、前記論理体系定義情報に基づき、前記読み込んだ設計書データから設計情報を抽出し、
前記設計検証処理部が、前記設計検証パラメータと前記抽出した設計情報とを照合することにより、前記読み込んだ設計書データの設計検証を行い、当該設計検証結果を出力し、
前記テストデータ生成処理部が、前記テストデータ生成パラメータと前記抽出した設計情報とを用いて、情報処理システムのテストデータを生成し、当該テストデータを出力することを特徴とする設計品質検査の支援プログラム。
【請求項７】
前記設計書読込処理部は、前記設計書データから、入力インタフェースの条件、出力インタフェースの条件、及びデータ項目の定義域に関する情報を少なくとも抽出し、
前記設計検証処理部は、前記設計検証パラメータを参照して、前記抽出した情報における入力インタフェースと出力インタフェースとの一貫性、入力インタフェース及び出力インタフェースの編集条件に関する記述内容の整合性、並びにデータ項目の定義域の正当性を検査することを特徴とする請求項５又は６に記載の設計品質検査の支援プログラム。
【請求項８】
前記テストデータ生成処理部は、前記設計書読込処理部において抽出した設計情報に含まれるデータ項目の定義域並びに入力インタフェース及び出力インタフェースの編集条件に関する記述内容に適合するテストケースと当該テストケースに対して期待される出力データ値とを生成し出力することを特徴とする請求項７に記載の設計品質検査の支援プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム開発の品質向上を支援し検査するシステムに係り、特に、情報システム設計書記述内容の一貫性や整合性を検査し、検査後に設計書記述内容からテスト項目を生成しテストデータを生成することができる、設計品質検証と動作検証を同一定義情報により行なえる好適な検査支援システムに関するものである。
【背景技術】
【０００２】
情報処理システムの開発においては、主に開発コストの低減を目的として、工程の一部を外注することがある。外注を効果的に行うには、外注にともなうオーバーヘッドを低減する必要がある。ここで言うオーバーヘッドには、発注仕様書（多くは機能設計書）の準備及び問い合わせ対応、及び検収作業がある。
【０００３】
設計書記述内容の一貫性や整合性については、機能設計書の品質を向上することで低減が可能である。特に近年増加しているオフショア開発（海外への事業者や子会社への委託開発）では、文化的な差異から、この種のオーバーヘッドが発生しやすくなっているため、これを低減することは重要である。
設計書記述情報よりテストデータを生成することについては、検収テストに使用するテストデータの入力値と、その入力値に対応して出力が期待される値を機能設計書から予め生成しておくことで、その作業効率を向上できる。
【特許文献１】特開平７−３６７３７号公報
【特許文献２】特開平１０−２１４２０５号公報
【特許文献３】特開２００６−２２１４４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上流工程における設計品質を向上する手段としては、Ｚ、ＶＤＭ（Vienna Development Method）等の形式言語により仕様を記述し、その内容を当該形式言語用の検証ツールにより検査する方法がある。
この方法では、システム仕様の正確な記述が可能になるが、システム開発プロジェクトの契約内容、設計基準等の制約により、採用できるとは限らない。多くのシステム開発プロジェクトでは、設計書、特に上流工程における設計書は、統合ソフトウェアにより作成する。
プロジェクトの基準に沿った設計書の作成と別に、検証のために形式言語による仕様記述を行うことは、作業量等の問題から現実的ではない。
同様の問題は、ＵＭＬ(Unified Modeling Language)等のモデリングツールによる仕様記述及び検証を行う場合にも当てはまる。
【０００５】
一方で、現実の事務処理システム開発では、複雑な計算や状態遷移が要求されることは少なく、比較的単純な出力編集、データ更新の処理を確実に行うことが要求の大半を占める。
ここで必要とされるには、複雑な処理手順を定義し、検査する方法ではなく、統合ソフトウェアで個別に作成された設計書のファイルから必要な設計情報を抽出し、開発対象の情報処理システムを構成する個別の機能の入力と出力の一貫性、整合性を効率的に検査する方法である。
【０００６】
テストデータを生成する手段としては、被テスト対象プログラムのソースコード情報から生成する方法がある。これは、単体テストを実施するうえでは有効であるが、設計書の記述との整合を検証する検収テストには適さない。
【０００７】
また別の方法として、ＤＢスキーマや、データ項目定義からテストデータを生成する方法がある。例えば、特許文献１に記載されたテストデータ作成方法がそれに該当する。これらは、各データ項目の一般的な入力データを生成するには役立つが、情報処理システムのデータ項目は一般に処理の段階に合わせて状態が遷移していくもので、その状態遷移をデータ項目定義などのみで表現することは難しいため、検収テスト対象とする個別の処理に適したテストデータを作成することは困難である。
【０００８】
また別の方法として、モジュール仕様書などからテストデータを生成する方法がある。例えば、特許文献２に記載されたモジュール検査装置では、モジュール仕様書からテストデータを生成する。しかし、これは単体テストを前提としており検収テストにはかならずしも適さない。
また、特許文献３に記載されたシステムテスト装置では、システムの仕様書からテストデータを生成する。この方法で生成対象となっているのは、いわゆる入力画面の入力データであり、それ以外の画面や帳票の出力編集処理には適用できない。
【０００９】
要約すると、従来の技術では、（１）上流設計の検証において、特定の言語仕様に基づいた大量の仕様記述や、特定のモデリングツール等が必要となり、開発プロジェクトの契約や基準であらかじめその適用が認められていない限り、それを導入しようとすれば作業負荷やコストが増加するという問題点、及び（２）テストデータの生成において、機能設計以上の上流工程の設計書に基づいた、詳細設計以下の下流工程の成果物を前提としない、適用範囲の広いテストデータの生成方法がないという問題点があった。
【００１０】
本発明は、上記従来の問題点に鑑みてなされたものであって、設計書は従来の自然言語による記述を主とし、特定の言語仕様に基づく仕様記述は最小限とした上で、その設計内容を検証でき、またその設計内容からテストデータを自動生成することで、早期の論理検証を可能とし、検収受入作業の効率を向上させることのできる、設計品質検査支援及システムを提供することである。
【課題を解決するための手段】
【００１１】
上記課題を解決するために、本発明においては、プロジェクトの本来の設計書に対する加工を最小限として、設計情報の収集を行えるようにする。このために、収集対象とする設計情報は、機能設計を提示して行う外注作業、およびその受入検収作業を支援するために必要な最低限の情報である、データ項目の定義、画面帳票等の編集方法などに限定する。
設計情報は統合アプリケーションで作成された設計書のファイルから抽出することを前提とし、プロジェクトごとに異なる設計書の様式に個別に対応できるよう、それらのファイルからの入力機能を本体より分離し、かつ、それらの動作を設定ファイル等で制御可能とする。
また、収集した設計情報の一貫性と整合性を検証し、設計品質の検査を行う。
また、収集した設計情報に含まれるデータ項目の定義域と、出力処理のデータ項目の編集条件により、テストケースとそれに対応する期待される出力データ値を生成する。
【００１２】
より具体的には、本発明は、情報処理システムの設計書の論理体系定義情報及び設計書を検証するための設計検証パラメータを記憶したデータベースと、情報処理システムの設計書データを読み込む設計書読込処理部と、前記論理体系定義情報に基づき、前記読み込んだ設計書データから設計情報を抽出する設計情報抽出処理部と、前記設計検証パラメータと前記抽出した設計情報とを照合することにより、前記読み込んだ設計書データの設計検証を行い、当該設計検証結果を出力する設計検証処理部とを備えた設計品質検査の支援システムを提供するものである。
本発明は、また、情報処理システムの設計書の論理体系定義情報、設計書を検証するための設計検証パラメータ及び情報処理システムのテストデータを生成するためのテストデータ生成パラメータを記憶したデータベースと、情報処理システムの設計書データを読み込む設計書読込処理部と、前記論理体系定義情報に基づき、前記読み込んだ設計書データから設計情報を抽出する設計情報抽出処理部と、前記設計検証パラメータと前記抽出した設計情報とを照合することにより、前記読み込んだ設計書データの設計検証を行い、当該設計検証結果を出力する設計検証処理部と、前記テストデータ生成パラメータと前記抽出した設計情報とを用いて、情報処理システムのテストデータを生成し、当該テストデータを出力するテストデータ生成処理部とを備えた設計品質検査の支援システムを提供するものである。
本発明の設計品質検査の支援システムにおいて、前記設計書読込処理部は、前記設計書データから、入力インタフェースの条件、出力インタフェースの条件、及びデータ項目の定義域に関する情報を少なくとも抽出し、前記設計検証処理部は、前記設計検証パラメータを参照して、前記抽出した情報における入力インタフェースと出力インタフェースとの一貫性、入力インタフェース及び出力インタフェースの編集条件に関する記述内容の整合性、並びにデータ項目の定義域の正当性を検査することを特徴とする。
本発明の設計品質検査の支援システムにおいて、前記テストデータ生成処理部は、前記設計書読込処理部において抽出した設計情報に含まれるデータ項目の定義域並びに入力インタフェース及び出力インタフェースの編集条件に関する記述内容に適合するテストケースと当該テストケースに対して期待される出力データ値とを生成し出力することを特徴とする。
【００１３】
本発明は、また、情報処理システムの設計書の論理体系定義情報及び設計書を検証するための設計検証パラメータを記憶したデータベースと、設計書読込処理部と、設計情報抽出処理部と、設計検証処理部とを備えた設計品質検査の支援システムにおける設計品質検査の支援プログラムであって、前記設計書読込処理部が、情報処理システムの設計書データを読み込み、前記設計情報抽出処理部が、前記論理体系定義情報に基づき、前記読み込んだ設計書データから設計情報を抽出し、前記設計検証処理部が、前記設計検証パラメータと前記抽出した設計情報とを照合することにより、前記読み込んだ設計書データの設計検証を行い、当該設計検証結果を出力することを特徴とする設計品質検査の支援プログラムを提供するものである。
本発明は、また、情報処理システムの設計書の論理体系定義情報、設計書を検証するための設計検証パラメータ及び情報処理システムのテストデータを生成するためのテストデータ生成パラメータを記憶したデータベースと、設計書読込処理部と、設計情報抽出処理部と、設計検証処理部と、テストデータ生成処理部とを備えた設計品質検査の支援システムにおける設計品質検査の支援プログラムであって、前記設計書読込処理部が、情報処理システムの設計書データを読み込み、前記設計情報抽出処理部が、前記論理体系定義情報に基づき、前記読み込んだ設計書データから設計情報を抽出し、前記設計検証処理部が、前記設計検証パラメータと前記抽出した設計情報とを照合することにより、前記読み込んだ設計書データの設計検証を行い、当該設計検証結果を出力し、前記テストデータ生成処理部が、前記テストデータ生成パラメータと前記抽出した設計情報とを用いて、情報処理システムのテストデータを生成し、当該テストデータを出力することを特徴とする設計品質検査の支援プログラムを提供するものである。
本発明の設計品質検査の支援プログラムにおいて、前記設計書読込処理部は、前記設計書データから、入力インタフェースの条件、出力インタフェースの条件、及びデータ項目の定義域に関する情報を少なくとも抽出し、前記設計検証処理部は、前記設計検証パラメータを参照して、前記抽出した情報における入力インタフェースと出力インタフェースとの一貫性、入力インタフェース及び出力インタフェースの編集条件に関する記述内容の整合性、並びにデータ項目の定義域の正当性を検査することを特徴とする。
本発明の設計品質検査の支援プログラムにおいて、前記テストデータ生成処理部は、前記設計書読込処理部において抽出した設計情報に含まれるデータ項目の定義域並びに入力インタフェース及び出力インタフェースの編集条件に関する記述内容に適合するテストケースと当該テストケースに対して期待される出力データ値とを生成し出力することを特徴とする。
【発明の効果】
【００１４】
本発明によれば、汎用的な事務処理システムにおける、画面入出力編集、帳票出力編集、ＤＢ更新仕様の設計内容の基本的な検査ができ、その設計内容の範囲内で、当該処理に掛かる情報処理システムの機能検証を行うテストケースと、そのデータセットを生成することができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の設計品質検査の支援システムの実施形態について、図面を参照して詳細に説明する。図１〜図６は、本発明の実施の形態を例示する図であり、これらの図において、同一の符号を付した部分は同一物を表わし、基本的な構成及び動作は同様であるものとする。
【００１６】
図１は、本発明の設計品質検査の支援システムの全体構成を示すブロック図である。
図１において、設計品質検査支援システム１００は、設計書論理体系構築処理部１１０と、設計書読込処理部１２１と、設計情報抽出処理部１２２と、設計検証処理部１３１とテストデータ生成処理部１３２のデータ処理部と、設計書論理体系定義ＤＢ２０１と、抽出済み設計情報ＤＢ２０３とテストデータＤＢ２０５のデータ化格納機能と、設計検証パラメータ２０６と、テストデータ生成パラメータ２０７のデータ処理補完情報とからなる、設計情報の検証支援及び設計情報に基づくテストデータ生成を行う装置である。
【００１７】
設計品質検査支援システム１００は、サーバーシステムないしはクライアント端末に装備される。但し、設計書論理体系構築処理部１１０と、設計書読込処理部１２１と、設計情報抽出処理部１２２と、設計検証処理部１３１とテストデータ生成処理部１３２のデータ処理部と、設計書論理体系定義ＤＢ２０１と、抽出済み設計情報ＤＢ２０３とテストデータＤＢ２０５のデータ格納機能は、別のハードウェアに装備することも可能である。
設計品質検査支援システム１００がサーバーシステムに装備された場合は、ネットワーク０２０を経由して、クライアント端末０１０より実行することも可能である。
【００１８】
設計書論理体系構築処理部１１０は、検査対象とするソフトウェア開発プロジェクトに関する設計書論理体系定義情報、すなわち設計検証及びデータ生成の各処理で使用する設計管理情報、開発基準等の情報を読込み、同情報を保持するクラスインスタンスを構築し、装置の他の処理で利用可能する機能部である。
【００１９】
設計書論理体系定義情報は、設計書論理体系定義ＤＢ２０１に設定される。設計書論理体系定義ＤＢ２０１は、リレーショナル型他のＤＢであるほか、ＸＭＬ等の構造化文書ファイルなどのテキストファイルであることもある。その詳細については後に図２を参照しながら説明する。
【００２０】
設計情報抽出処理部１２２は、設計書論理体系定義情報に基づき、設計書読込処理部１２１を経由して設計書を読み込み、抽出した設計情報を抽出済み設計情報ＤＢ２０３に所定の形式で登録する機能部である。抽出済み設計情報ＤＢ２０３は、リレーショナル型他のＤＢであるほか、ＸＭＬ等の構造化文書ファイルなどのテキストファイルであることもある。また、実装の形態によっては、オンメモリであることも可能とする。その詳細については後に図３を参照しながら説明する。
【００２１】
設計書読込処理部１２１は、統合ソフトウェア等で作成された、実際の設計書ファイルを読み込むための機能部である。設計書読込処理部１２１は、設計書論理体系定義ＤＢ２０１で定義される設計書を適切に読込めるように、ファイル作成に使用したソフトウェアの種類や、書式にあわせた一つ以上のモジュールで構成される。設計情報抽出処理部１２２により指示された設計書２０２のファイルを読み取り、所定の形式で設計情報抽出処理部１２２に引き渡す。設計情報抽出処理部１２２との通信は、共通のインタフェースを経由して行う。
【００２２】
設計検証処理部１３１は、抽出済み設計情報ＤＢ２０３に基づく設計検証を行う機能部である。設計書論理体系定義情報により定義された検証内容、検証対象に対し、一部は設計書論理体系定義情報に定義された規則に基づき検証を実施し、その結果を検証結果２０４に出力する。またこのとき、必要であれば設計検証パラメータ２０６を設定し、処理内容を補完、または、制御する。
【００２３】
検証結果２０４は、検証結果を出力するファイルである。出力形式は、設計書論理体系定義情報または、設計検証パラメータ２０６により指定された形式によるテキストファイルであるほか、画面表示、ＤＢ出力である場合もある。
【００２４】
設計検証パラメータ２０６は、設計書論理体系定義情報及び抽出済み設計情報の内容を一時的に上書き、または補完することで検証処理の内容を変更する情報およびその他の実行制御情報を含む。その詳細については後に図４を参照しながら説明する。設計検証パラメータ２０６は、画面等よりの入力パラメータであるほか、テキストファイル（設定ファイル）、ＤＢ等の場合もある。
【００２５】
テストデータ生成処理部１３２は、抽出済み設計情報ＤＢ２０３に基づくデータ生成を行う機能部である。設計書論理体系定義情報により定義された範囲で、テストデータ生成を行い、結果をテストデータＤＢ２０５に出力する。またこのとき、必要であればテストデータ生成パラメータ２０７を設定し、処理内容を制御する。
【００２６】
テストデータＤＢ２０５は、生成したテスト結果を出力するＤＢである。出力形式は、設計書論理体系定義情報または、テストデータ生成パラメータ２０７により指定された形式による。リレーショナルＤＢ、またはその他の形式のＤＢであるほか、テキストファイル、画面表示の場合もある。
【００２７】
テストデータ生成パラメータ２０７は、設計検証パラメータ２０６と同様の形式で、設計書論理体系定義情報及び抽出済み設計情報の内容を一時的に上書き、または補完することでデータ生成処理の内容を変更する情報およびその他の実行制御情報を含む。内容は図４にて説明する。テストデータ生成パラメータ２０７は、画面等よりの入力パラメータであるほか、テキストファイル（設定ファイル）、ＤＢ等であることもある。
【００２８】
図２は、図１に示す設計書論理体系定義ＤＢ２０１の主要なデータ項目及びデータ内容を示す図である。図２において、設計書論理体系定義情報には、装置の実行を制御するための情報と、検証ルールを定義する情報が含まれる。図２に示す項目のほか、付加的な情報を格納するための項目が追加されることもありうる。
【００２９】
図２におけるデータ例からは、設計書の論理体系に関して、以下のことが読み取れる。
検証対象となる設計書は、サーバ「SERVER1」の共有フォルダ「Docs\FD」に格納されており（No.1）、ＤＢ項目定義書は、その下位にあるフォルダ「03_ＤＢ項目定義」（No.2）内で、「[0-9][0-9]_.*_項目定義」（No.3）のパターンで命名されているファイルである。ＤＢ項目定義書は、「EXCEL2003」（No.4）により作成されているため、これに対応する設計書読込処理部モジュールが必要である（設計情報抽出処理部は「EXCEL2003」に対応する設計書読込処理部モジュールを知っており、これを起動できねばならない）。設計検証処理部において、「ＤＢ項目定義検証」は行うが（No.5）、そのうちの「ＤＢ項目定義属性検証」（No.6）は行わない。検証結果は、ファイル「C:\ValidateTool\ResultV.txt」（No.7）に所定の形式で出力する。ＤＢ項目記号名の命名規則の検証を行う場合、その検証パターンは、「[A-Z][A-Za-z0-9]*」（No.8）である。
【００３０】
図３Ａ〜図３Ｇは、図１に示す抽出済み設計情報ＤＢ２０３の主要なデータ項目及びデータ内容、並びにこれらのデータテーブル間の関連を示す図である。
【００３１】
データリソーステーブルは、システムを構成する各種データリソースの全体情報を保持する。主として、ＤＢ項目定義書内のテーブル自体に関する設計情報に対応する。
【００３２】
制約テーブルは、上記データリソーステーブルに登録された各データリソースに対して設定される制約条件を保持する。ここでいう制約条件とは、あるデータリソースに含まれるデータ項目が、特定の値をとるためには、同じまたは別のデータリソースの別の項目が、ある一定の条件を満たしている必要がある、といった条件のことをいう。
【００３３】
属性（項目）テーブルは、上記データリソースに登録された各データリソースを構成するデータ項目の定義情報を保持する。主として、ＤＢ項目定義内の項目定義部分や、コード仕様書の属性定義部分に対応する。
【００３４】
定義域テーブルは、上記属性（項目）テーブルに登録された各属性（項目）が取りうる値の範囲を示す情報を保持する。値の範囲が複数の区間に分割されている場合は、その区間毎に登録する。コード項目の場合は、コードを構成するコード値の毎に登録する。
【００３５】
インタフェーステーブルは、システムを構成する各機能のインタフェースの全体情報を保持する。主として、画面入出力編集条件表、帳票出力条件表、ＤＢ更新仕様書のインタフェース自体に関する設計情報に対応する。
【００３６】
適用条件テーブルは、上記インタフェースに登録された各インタフェースを使用する条件、または各インタフェース内の項目で参照されているデータの選択条件を示す情報を保持する。
【００３７】
項目テーブルは、上記インタフェーステーブルに登録された各インタフェースを構成するデータ項目の定義情報を保持する。
【００３８】
編集条件テーブルは、上記項目テーブルに登録された項目に対応する編集条件を示す情報を保持する。
【００３９】
その他の定義テーブル、及び、その他の定義適用条件テーブル、及び、その他の定義項目テーブル、及び、その他の定義編集条件テーブルは、上記データリソースやインタフェースに該当しない、その他の抽象度の高い設計概念について、上記インタフェーステーブル、項目テーブル、編集条件テーブルと同様の情報を保持する。例えば、「定期課税計算処理」のようなものがそれに該当する。こうした情報は、機能設計の段階では、その計算手順は定義されていても、その計算に必要なデータ項目や、計算結果のデータ項目は、上述したインタフェーステーブルの登録対象となる設計書に比して、その記述方法は定式化されていない場合が多い。そのため、これらの処理を設計検証及びテストデータ生成のために仮想的にブラックボックス化し、そのインタフェースを登録する。
【００４０】
図３の各テーブルにおけるデータ例からは、以下のことが読み取れる。
データリソーステーブルには、以下の情報が保持されている。
データリソースとして、リレーショナルＤＢテーブル「課税対象者」（No.1）、「課税明細」（No.2）が定義されている。また、コード「税目コード」（No.3）が定義されている。
【００４１】
制約テーブルには、以下の定義がなされている。
「課税明細テーブルの課税対象者番号（KAZEI_TAISHO_NO）項目には、課税対象者テーブルの課税対象者番号（KAZEI_TAISHO_NO）に設定済みのデータのみ設定できる」（No.1）という制約が存在する。なお、制約式の記法は、一例であり、実装に依存する。
【００４２】
属性（項目）テーブルには、以下の情報が保持されている。
テーブル「課税対象者」には、「課税対象者番号」（No.1）、「課税対象者名」（No.2）の項目が含まれる。テーブル「課税明細」には、「課税対象者番号」（No.3）、「税目コード」（No.4）、「課税年度」（No.5）、「当初課税額」（No.6）の項目が含まれる。コードテーブル「税目コード」には、「コード」（No.7）、「コード値」（No.8）の項目が含まれる。
【００４３】
定義域テーブルには、以下の情報が保持されている。
テーブル「課税対象者」の「対象者番号」が取りうる範囲は、一連番号「0000000001」から「9999999999」の間である（No.1）。テーブル「課税明細」の「税目コード」が取りうる範囲は、税目コードに含まれるいずれかのコードである（No.2）。「当初課税額」が取りうる範囲は、ゼロより大きい値である（No.3）。「税目コード」の「コード」は、「101」、「102」、「201」、「202」、「203」である（No.4〜No.8）。なお、範囲の記法は一例であり、実装に依存する。
【００４４】
インタフェーステーブルには、以下の情報が保持されている。
画面入力条件表として、「更正対象検索_検索実行」（No.1）、「課税情報詳細_修正入力」（No.3）、「課税情報詳細_修正確定」（No.5）が定義されている。画面出力編集表として、「課税情報詳細_表示」（No.2）、「課税情報詳細_修正確認」（No.4）が定義されている。また、ＤＢ更新仕様書として、「課税明細_更正登録」（No.6）が定義されている。
【００４５】
適用条件テーブルには、以下の情報が保持されている。
インタフェース「課税情報詳細_表示」で参照される、テーブル「課税明細」、「課税対象者」の行は、インタフェース「更正対象検索_検索実行」に入力された「課税対象者番号（検索条件）」、「税目コード（検索条件）」、「課税年度（検索条件）」の値を検索条件値として選択された行である。
【００４６】
項目テーブルには、以下の情報が保持されている。
インタフェース「更正対象検索_検索実行」には、項目「課税対象者番号（検索条件）」（No.1）、「税目コード（検索条件）」（No.2）、「課税年度（検索条件）」（No.3）が含まれている。
インタフェース「課税情報詳細_表示」には、項目「課税対象者番号（検索条件）」（No.4）、「税目コード（検索条件）」（No.5）、「課税年度（検索条件）」（No.6）、「課税対象者番号」（No.7）、「税目コード」（No.8）、「課税年度」（No.9）、「当初課税額」（No.10）、「課税対象額（更正後）」（No.11）が含まれている。
インタフェース「課税情報詳細_修正入力」には、項目「課税対象者番号（検索条件）」（No.12）、「税目コード（検索条件）」（No.13）、「課税年度（検索条件）」（No.14）、「課税対象者番号」（No.15）、「税目コード」（No.16）、「課税年度」（No.17）、「当初課税額」（No.18）、「課税対象額（更正後）」（No.19）が含まれている。
インタフェース「課税情報詳細_修正確認」には、項目「課税対象者番号（検索条件）」（No.20）、「税目コード（検索条件）」（No.21）、「課税年度（検索条件）」（No.22）、「課税対象者番号」（No.23）、「税目コード」（No.24）、「課税年度」（No.25）、「当初課税額」（No.26）、「課税対象額（更正後）」（No.27）、「課税額（更正後）」（No.28）が含まれている。
インタフェース「課税明細_更正登録」には、「課税対象者番号」（No.29）、「税目コード」（No.30）、「課税年度」（No.31）、「当初課税額」（No.32）、「課税対象額」（No.33）、「課税額」（No.34）、「減額更正フラグ」（No.35）が含まれている。
【００４７】
編集条件テーブルには、以下の情報が保持されている。
インタフェース「更正対象検索_検索実行」の項目「課税対象者番号（検索条件）」には、「入力されたデータの文字数が10文字未満の場合にエラーとする入力チェック」が設定されており、エラーとなる場合は、「エラーメッセージ「ZGKC0001E」（引数1：「10」）」（設計情報抽出元のファイルに記述されている内容をそのまま転記している）の処理が行われる（No.1）。また、「入力されたデータの型が数字でない場合にエラーとする入力チェック」が設定されており、エラーとなる場合は、「エラーメッセージ「ZGKC0002E」（引数1：「数字」）」の処理が行われる（No.2）。
インタフェース「課税情報詳細_表示」の項目「課税対象者番号（検索条件）」には無条件で、インタフェース「更正対象検索_検索実行」の項目「課税対象者番号（検索条件）」の内容が設定される（No.3）。項目「税目コード（検索条件）」には無条件で、インタフェース「更正対象検索_検索実行」の項目「税目コード（検索条件）」の内容が設定される（No.4）。項目「課税年度（検索条件）」には無条件で、インタフェース「更正対象検索_検索実行」の項目「課税年度（検索条件）」の内容が設定される（No.5）。項目「課税対象者番号」には無条件で、テーブル「課税明細」の項目「課税対象者番号」の内容が設定される（No.6）。項目「税目コード」には無条件で、テーブル「課税明細」の項目「税目コード」の内容が設定される（No.7）。項目「課税年度」には無条件で、テーブル「課税明細」の項目「課税年度」の内容が設定される（No.8）。項目「当初課税額」には無条件で、テーブル「課税明細」の項目「当初課税額」の内容が設定される（No.9）。項目「課税対象額（更正後）」には無条件で、空文字列が設定される（No.10）。
インタフェース「課税情報詳細_修正確認」の項目「課税対象者番号（検索条件）」には無条件で、インタフェース「課税情報詳細_修正入力」の項目「課税対象者番号（検索条件）」の内容が設定される（No11）。項目「税目コード（検索条件）」には無条件で、インタフェース「課税情報詳細_修正入力」の項目「税目コード（検索条件）」の内容が設定される（No.12）。項目「課税年度（検索条件）」には無条件で、インタフェース「課税情報詳細_修正入力」の項目「課税年度（検索条件）」の内容が設定される（No.13）。項目「課税対象者番号」には無条件で、インタフェース「課税情報詳細_修正入力」の項目「課税対象者番号」の内容が設定される（No.14）。項目「税目コード」には無条件で、インタフェース「課税情報詳細_修正入力」の項目「税目コード」の内容が設定される（No.15）。項目「課税年度」には無条件で、インタフェース「課税情報詳細_修正入力」の項目「課税年度」の内容が設定される（No.16）。項目「当初課税額」には無条件で、インタフェース「課税情報詳細_修正入力」の項目「当初課税額」の内容が設定される（No.17）。項目「課税対象額（更正後）」には無条件で、インタフェース「課税情報詳細_修正入力」の項目「課税対象額（更正後）」の内容が設定される（No.18）。項目「課税額（更正後）」には無条件で、その他の定義「課税計算結果」の項目「課税額」の内容が設定される（No.19）。
インタフェース「課税明細_更正登録」の項目「課税対象者番号」には無条件で、インタフェース「課税情報詳細_修正確定」の項目「課税対象者番号」の内容が設定される（No.20）。項目「税目コード」には無条件で、インタフェース「課税情報詳細_修正確定」の項目「税目コード」の内容が設定される（No.21）。項目「課税年度」には無条件で、インタフェース「課税情報詳細_修正確定」の項目「課税年度」の内容が設定される（No.22）。項目「当初課税額」には無条件で、インタフェース「課税情報詳細_修正確定」の項目「当初課税額」の内容が設定される（No.23）。項目「課税対象額」には無条件で、インタフェース「課税情報詳細_修正確定」の項目「課税対象額（更正後）」の内容が設定される（No.24）。項目「課税額」には無条件で、インタフェース「課税情報詳細_修正確定」の項目「課税額（更正後）」の内容が設定される（No.25）。項目「減額更正フラグ」には、インタフェース「課税情報詳細_修正確定」の項目「当初課税額」がインタフェース「課税情報詳細_修正確定」の項目「課税額（更正後）」より大きい場合は、「1」が設定される。これは減額更正の場合の編集方法である（No.26）。
インタフェース「課税情報詳細_修正確定」の項目「当初課税額」がインタフェース「課税情報詳細_修正確定」の項目「課税額（更正後）」以下の場合は、「0」が設定される。これは増額更正の場合の編集方法である（No.27）。
なお、編集条件および編集方法の記法は一例であり、実装に依存する。
【００４８】
その他の定義テーブルには、以下の情報が保持されている。
処理手順の入力情報に関する定義「課税計算入力情報」（No.1）、「課税計算入力情報」（No.2）が定義されている。処理手順の出力情報に関する定義「課税計算結果」（No.3）が定義されている。
【００４９】
その他の定義適用条件テーブルには、以下の定義がなされている。
定義「課税計算入力情報」は、税目コードが「101」の場合に使用する（No.1）。定義「課税計算入力情報２」は、税目コードが「101」以外の場合に使用する（No.2）。定義「課税計算結果」で参照される、テーブル「税率」の行は、インタフェース「課税計算入力情報」に入力された「税目コード」「課税年度」の値を検索条件値として選択された行である（No.3）。
なお、適用条件の記法は一例であり、実装に依存する。
【００５０】
その他の定義項目テーブルには、以下の情報が保持されている。
定義「課税計算入力情報」には、項目「税目コード」（No.1）「課税年度」（No.2）、「課税対象額」（No.3）が含まれている。定義「課税計算入力情報２」には、項目「税目コード」（No.4）、「課税年度」（No.5）、「課税対象額」（No.6）、「軽減事由コード」（No.7）が含まれている。定義「課税計算結果」には、項目「税率」（No.8）、「課税額」（No9）が含まれている。
【００５１】
その他の定義編集条件テーブルには、以下の情報が保持されている。
定義「課税計算結果」の項目「税率」には無条件で、テーブル「税率」の項目「税率」の内容が設定される（No.1）。項目「課税額」が取りうる範囲は、ゼロより大きい値である（No.2）。
なお、編集条件、編集方法の記法は一例であり、実装に依存する。
【００５２】
図４は、図１に示す設計検証パラメータ２０６及びテストデータ生成パラメータ２０７のデータ項目及びデータ内容を示す図である。処理対象とするデータ要素を指定するアクセスパスと、アクセスパスで指定されるデータ要素に対する設定値の組み合わせで構成される。
【００５３】
図４のデータ例からは、以下のことが読み取れる。
設計書論理体系定義ＤＢ（[DLSD]）のＤＢ項目定義属性検証可否（DBDeAttributefValidate）を、「true」に変更する（No.1）。設計書論理体系定義ＤＢ（[DLSD]）の検証結果出力先（ValidationResultOutput）を、「C:\ValidateTool\ResultV2.txt」に変更する（No.2）。抽出済み設計情報ＤＢ（[ADI]）のデータリソース「課税明細」（＜dataResouce
name="課税明細"＞）の属性（項目）「当初課税額」（＜attribute name="当初課税額"＞）の範囲（＜domain＞）を「int（12）{10000<<50000}」に変更する（No.3）。設計検証処理（[VDC]）の処理対象（target）に、インタフェース「課税情報詳細_表示」（＜interface
name="課税情報詳細_表示"＞）を加える（No.4）。テストデータ生成処理（[TDC]）の処理対象（target）に、インタフェース「課税情報詳細_表示」（＜interface
name="課税情報詳細_表示"＞）を加える（No.5）。
なお、アクセスパス及び設定値の記法は一例であり、実装に依存する。
【００５４】
図５Ａ及び図５Ｂは、図１に示すテストデータＤＢ２０５の主要なデータ項目及びデータ内容並びにこれらのデータテーブル間の関連を示す図である。図５Ａ及び図５Ｂに示す項目のほか、付加的な情報を格納するための項目が追加されることもありうる。
【００５５】
テストケーステーブルは、生成されたテストケースの全体情報を保持する。テストケースはテストデータ生成の対象となったインタフェースごとに一つ以上生成される。
【００５６】
入力条件テーブルは、各テストケースを構成するデータ項目単位の入力条件を保持する。
【００５７】
出力結果テーブルは、各テストケースのテスト結果として期待される出力値を、テスト対象のインタフェースを構成するデータ項目毎に保持する。ただし、テスト内容が入力チェックに該当する場合は、当該チェックの結果として期待される情報処理システムの動作を記述した文字列を保持する。
【００５８】
図５Ａ及び図５Ｂのデータ例からは、以下のことが読み取れる。
テストケーステーブルには、以下の情報が保持されている。
インタフェース「課税明細_更正登録」に対するテストケースが２件生成されており、それは「減額更正の場合」（No.1）と「増額更正の場合」（No.2）のものである。また、インタフェース「更正対象検索_検索実行」に対するテストケースも２件生成されており、それは、「桁数エラー」（No.3）と「属性エラー」（No.4）に関するものである。
【００５９】
入力条件テーブルには、以下の情報が保持されている。
インタフェース「課税明細_更正登録」の「減額更正の場合」のテストケースの入力条件は、すべてインタフェース「課税情報詳細_修正確定」のデータ項目で、「当初課税額に20000」（No.1）
、「課税額（更正後）に19000」（No.2）、「課税対象者番号に0000000001」（No.3）、「税目コードに101」（No.4）、「課税年度に2007」（No.5）、「課税対象額（更正後）に100000」（No.6）を入力するというものである。
インタフェース「課税明細_更正登録」の「増額更正の場合」のテストケースの入力条件は、すべてインタフェース「課税情報詳細_修正確定」のデータ項目で、「当初課税額に20000」（No.7）、「課税額（更正後）に20000」（No.8）、課税対象者番号に0000000001」（No.9）、「税目コードに101」（No.10）、「課税年度に2007」（No.11）、「課税対象額（更正後）に100000」（No.12）を入力するというものである。
インタフェース「更正対象検索_検索実行」の「桁数エラー」のテストケースの入力条件は、インタフェース「更正対象検索_検索実行」の項目「課税対象者番号（検索条件）」に「999999999」を入力するというものである（No.13）。
インタフェース「更正対象検索_検索実行」の「属性エラー」のテストケースの入力条件は、インタフェース「更正対象検索_検索実行」の項目「課税対象者番号（検索条件）」に「AAAAAAAAAA」を入力するというものである（No.14）。
【００６０】
出力結果テーブルには、以下の情報が保持されている。
インタフェース「課税明細_更正登録」の「減額更正の場合」のテストケースの出力結果は、各データ項目が、「課税対象者番号は0000000001」（No.1）、「税目コードは101」（No.2）、「課税年度は2007」（No.3）、「当初課税額は20000」（No.4）、「課税対象額は100000」（No.5）、「課税額は19000」（No.6）、「減額更正フラグは1」（No.7）となることである。
インタフェース「課税明細_更正登録」の「増額更正の場合」のテストケースの出力結果は、各データ項目が、「課税対象者番号は0000000001」（No.8）、「税目コードは101」（No.9）、「課税年度は2007」（No.10）、「当初課税額は20000」（No.11）、「課税対象額は100000」（No.12）、「課税額は20000」（No.13）、「減額更正フラグは0」（No.14）となることである。
インタフェース「更正対象検索_検索実行」の「桁数エラー」のテストケースの出力結果は、「エラーメッセージ「ZGKC0001E」（引数1：「10」）」である（No.15）。インタフェース「更正対象検索_検索実行」の「属性エラー」のテストケースの出力結果は、「エラーメッセージ「ZGKC0002E」（引数1：「数字」）」である（No.16）。
【００６１】
次に本実施形態の設計品質検査の支援システムの動作について説明する。
図６は、図１に示す設計書論理体系構築処理部１１０の動作を示すフローチャートである。
設計書論理体系構築処理部１１０は、情報システム設計書２０２の全ての設計書論理体系定義情報を読み込むまで（ステップＳＴ１）、設計書論理体系定義ＤＢ２０１を読み込み（ステップＳＴ２）、読み込んだ設計書論理体系定義情報のクラスインスタンスを構築する（ステップＳＴ３）。構築した論理設計書定義情報のクラスインスタンスは装置の他の処理部から参照される。以下の記述で「設計書論理体系定義情報」とある場合、特に断らない限り、当該設計書論理体系定義情報のクラスインスタンスを指すものとする。
【００６２】
図７は、図１に示す設計書読込処理部１２１の動作を示すフローチャートである。
まず、設計書読込処理部１２１は、情報システム設計書の設計書論理体系定義情報の設定内容により、設計情報抽出対象の設計情報種別を取得し、その全設計情報の抽出処理が終了するまで処理をおこなう（ステップＳＴ１１）。
【００６３】
ステップ１２（ＳＴ１２）では、まず設計書論理体系定義ＤＢ２０１の設定内容より、その設計情報に対応する設計書読込処理部の機能を提供するモジュールの識別情報を取得し、それにより設計書読込処理部モジュールを利用可能にする。（モジュールを活性化）。このとき当該モジュールの動作を制御するため付加的な情報が、設計書論理体系定義情報に設定されていれば、それを同時に引き渡す。
例えば、図２の例では、ＤＢ項目定義書を読み込むための設計書読込処理部モジュールは、「EXCEL2003」で識別されるモジュールである（No.4）。当該モジュールを実際にどのようにして利用するかは実装に依存するが、あらかじめ設計書読込処理部に、上記識別情報に対応するモジュールの呼び出しを事前に組み込んでおく方法や、プロセス間通信技術を使用し、当該プロセス間通信技術による通信を可能とするための制御文字列を上記識別情報として設定しておくことにより、実行時に任意のモジュールを呼び出す方法などがある。
ステップ１３（ＳＴ１３）では、ステップＳＴ１２で利用可能（活性化）とした設計書読込処理部モジュールに、処理対象の設計書ファイルを指定する文字列を、設計書論理体系定義情報より取得して引渡し、処理対象とする設計書ファイルのパスのリストを取得する。
この設計書ファイルパスリストにある全ての設計書ファイルを処理するまで、設計書ファイルの入力処理を繰り返す（ステップＳＴ１４）。
ステップ１５（ＳＴ１５）では、利用可能とした設計書読込処理部モジュールに処理対象の設計書ファイルパスを渡して、当該設計書ファイルの内容を読み込む。設計書読込処理部モジュールから設計書読込処理部に渡すデータの形式は実装に依存する。例えば、設計書読込処理部が解析可能な形式のＸＭＬテキストとする。図８は、その一例である。
ステップ１６（ＳＴ１６）では、設計書読込処理部モジュールから引き渡されたデータの内容を解析し、抽出済み設計情報ＤＢ２０３に登録する。
【００６４】
図９Ａは、図１に示す設計検証処理部１３１の動作を示すフローチャートである。
設計検証処理部１３１は、ステップ２１（ＳＴ２１）において、設計検証パラメータ２０６を読み込み、読み込んだパラメータのクラスインスタンスを構築する。
構築した設計検証パラメータ２０６のクラスインスタンスは設計検証処理部全体から参照される。以下の記述で「設計情報パラメータ」とある場合、特に断らない限り、設計検証パラメータ２０６のクラスインスタンスを指すものとする。
ステップ２２（ＳＴ２２）では、設計書論理体系定義ＤＢ２０１と設計検証パラメータ２０６の設定内容により、実行する検証処理の種類を決定する。次に、ステップ２３（ＳＴ２３）により、検証内容がデータリソース定義検証処理の処理対象となっているか否かを判定し、処理対象の場合はステップ２４（ＳＴ２４）のデータリソース定義検証処理部を実行する。
ステップ２４（ＳＴ２４）のデータリソース定義検証処理部については、後に図９Ｂを参照しながら詳細に説明する。
次に、ステップ２５（ＳＴ２５）において、検証内容がインタフェース定義検証処理の処理対象となっているか否かを判定し、処理対象の場合は、ステップ２６（ＳＴ２６）のインタフェース定義検証処理部の処理を実行する。
ステップ２６（ＳＴ２６）のインタフェース定義検証処理部については、後に図９Ｃを参照しながら詳細に説明する。
次に、ステップ２７（ＳＴ２７）において、検証内容がその他の定義検証処理の処理対象となっているか否かを判定し、処理対象の場合は、ステップ２８（ＳＴ２８）のその他の定義検証処理部の処理を実行する。
ステップ２８（ＳＴ２８）のインタフェース定義検証処理部については、後に図９Ｄを参照しながら詳細に説明する。
【００６５】
図９Ｂは、データリソース定義検証処理部の動作を示すフローチャートである。
データリソース定義検証処理部では、抽出済み設計情報ＤＢ２０３のデータリソーステーブルの全行を処理するまで、以下の処理を繰り返す（ステップＳＴ３１）。
まず、ステップ３２（ＳＴ３２）において、抽出済み設計情報ＤＢ２０３のデータリソーステーブルより、処理対象とする行を取得する。次に、ステップ３３（ＳＴ３３）において、データリソース定義検証処理の処理対象となるか否かを判定し、検証対象であれば、さらにステップ３４（ＳＴ３４）において、データリソース名称パターン整合検証の実行対象で否かを判定する。
ステップ３３（ＳＴ３３）の判定は、設計書論理体系定義ＤＢ２０１及び設計検証パラメータ２０６の設定内容により行う。
このとき、処理対象のデータリソースを明示的に指定する情報がない場合は、すべてのデータリソーステーブル行を処理対象とし、処理対象のデータリソースを明示的に指定する情報がある場合は、その指定に該当するデータリソーステーブル行のみを処理対象とする。ただし、データリソースを処理対象から明示的に除外する情報がある場合は、その指定に該当するデータリソーステーブル行を処理対象としない。処理対象とならなかった場合、次のデータリソーステーブル行の処理に移る。
ステップ３４（ＳＴ３４）で、データリソース名称パターン整合検証の実行対象と判定された場合は、ステップ３５（ＳＴ３５）のデータリソース名称パターン整合検証を実行する。
データリソース名称パターン整合検証は、処理中のデータリソーステーブル行の名前及び記号名が、設計書論理体系定義ＤＢ２０１または設計検証パラメータ２０６で指定されている、データリソースの名称ルールを満たしているか否かを判定し、満たしていない場合は、警告メッセージを検証結果に書き込む処理を行う。
次に、処理中のデータリソーステーブル行に対応する全ての属性（項目）テーブルの行について、以下に説明するステップ３７（ＳＴ３７）からステップ４２（ＳＴ42）までの処理を繰り返し、その終了判定を、ステップ３６（ＳＴ３６）において行う。
【００６６】
各属性（項目）テーブル行の処理は、まず、ステップ３７（ＳＴ３７）において、抽出済み設計情報ＤＢ２０３の属性（項目）テーブルより、処理対象とする行を取得する。次に、ステップ３８（ＳＴ３８）において、ステップ３７（ＳＴ３７）で取得した処理対象行がデータリソース定義検証処理の処理対象となるか否かを判定する。この判定は、設計書論理体系定義ＤＢ２０１及び設計検証パラメータ２０６の設定内容により行ない、設定内容において、処理対象の属性（項目）を明示的に指定する情報がない場合は、すべての属性（項目）テーブル行を処理対象とする。処理対象の属性（項目）を明示的に指定する情報がある場合は、その指定に該当する属性（項目）テーブル行のみを処理対象とする。ただし、属性（項目）を処理対象から明示的に除外する情報がある場合は、その指定に該当する属性（項目）テーブル行を処理対象としない。処理対象とならなかった場合は、ステップ３６（ＳＴ３６）戻る。処理対象となった場合は、以下のステップ３９（ＳＴ３９）からステップ４２（ＳＴ４２）までの処理を行う。
【００６７】
ステップ３８（ＳＴ３８）において処理対象と判定された場合、まず、ステップ３９（ＳＴ３９）において、名称パターン整合検証の実行対象であるか否かを判定し、対象である場合は、ステップ４０（ＳＴ４０）の名称パターン整合検証を実行する。
次に、ステップ４１（ＳＴ４１）において、属性整合検証の実行対象であるか否か判定する。対象である場合は、ステップ４２（ＳＴ４２）の属性整合検証を実行する。
ステップ４０（ＳＴ４０）の名称パターン整合検証では、処理中の属性（項目）テーブル行の名前及び記号名が、設計書論理体系定義ＤＢ２０１または設計検証パラメータ２０６で指定されている、属性（項目）の名称ルールを満たしているか否かを判定し、満たしていない場合は、警告メッセージを検証結果に書き込む処理を行う。
ステップ４２（ＳＴ４２）の属性整合検証では、処理中の属性（項目）行にその属性（項目）が属するドメインを指定する項目があり、かつ、当該項目にドメイン名の指定がある場合に、その属性（項目）のタイプが指定されているドメインの定義内容と整合性が取れているか否かを判定し、取れていない場合は、警告メッセージを検証結果に書き込む処理を行う。
ここでいうドメインとは、データ項目をその形式（データ型、桁数など）に着目して分類したものをいう。整合が取れていないとは、ドメイン定義の内容にもよるが、例えば、データ型が異なっている、桁数が異なっている、のような場合をいう。
ドメイン定義情報は設計書論理体系定義ＤＢ２０１及び設計検証パラメータ２０６に含まれているものとする。また、ドメインの指定の有無とはかかわり無く、定義域の整合性を確認する。処理中の属性（項目）行に対応する全ての定義域テーブルの行を参照し、その範囲項目の指定内容が属性（項目）テーブル行のタイプ項目と整合が取れていない場合は、警告メッセージを検証結果に書き込む。整合が取れていないとは、例えば、範囲の最大値としてタイプの桁数よりも大きな値が指定されている場合などである。
【００６８】
ステップ３６（ＳＴ３６）において、属性（項目）テーブルの終了を判定したあと、ステップ４３（ＳＴ４３）において、制約条件検証が実行対象であるか否か判定を行う。実行対象である場合、ステップ４５（ＳＴ４５）の処理対象制約行選択処理と、ステップ４６（ＳＴ４６）の制約条件検証処理を実行し、ステップ４４（ＳＴ４４）において、全制約行の実行終了判定によりこのループを抜ける。
ステップ４５（ＳＴ４５）では、抽出済み設計情報ＤＢ２０３の制約テーブルより処理対象とする行を取得し、ステップ４６（ＳＴ４６）の制約条件検証を実行する。制約条件検証では、処理対象の制約行の制約式に含まれる全てのデータリソース名がデータリソーステーブルに登録済みか、全ての属性（項目）名が、属性（項目）テーブルに登録済みかを（所属するデータリソースも考慮して）判定する。登録されていないデータリソース名または属性（項目）名が存在する場合は、警告メッセージを検証結果に書き込む。また、制約式の基本的な論理チェックを行い、エラーとなる場合は、警告メッセージを検証結果に書き込む。基本的な論理チェックとは、書式の誤りや、例えば、「Ａ＝Ｂ」と「Ａ≠Ｂ」のような、明らかに矛盾する式が同時に指定されている場合に、エラーとして検出する。
【００６９】
ステップ４４（ＳＴ４４）の制約テーブルの処理の終了後、ステップ４７（ＳＴ４７）の項目構成検証の実行対象であるか否かの判定を行う。実行対象と判定された場合は、ステップ４８（ＳＴ４８）の項目構成検証を行う。
項目構成検証では、タイプが「ステータス」であるデータリソーステーブル行のみが対象となる。情報処理システムに含まれるデータリソースは、処理の段階により、そのデータ内容が更新されていく。ここでいう「ステータス」とは、この処理の段階を指し、タイプが「ステータス」であるデータリソースとは、あるデータリソースが特定のステータスにあるとき、そのデータリソースを構成する属性（項目）が取りうる値の範囲を定義した情報である。この「ステータス」データリソーステーブル行に対応する属性（項目）テーブルの各行の名前、記号名、タイプが、元となるデータリソーステーブル行に対応する属性（項目）テーブルの各行の名前、記号名、タイプと一致していない場合、警告メッセージを検証結果に書き込む。
【００７０】
図９Ｃは、設計検証処理部から呼び出されるインタフェース定義検証処理部の動作を示すフローチャートである。
インタフェース定義検証処理部では、抽出済み設計情報ＤＢ２０３のインタフェーステーブルの全行を処理するまで、以下の処理を繰り返す。ステップ５１（ＳＴ51）
【００７１】
まず、ステップ５２（ＳＴ５２）において、抽出済み設計情報ＤＢ２０３のインタフェーステーブルより、処理対象とする行を取得する。ステップ５３（ＳＴ５３）において、取得した処理対象行がインタフェース定義検証処理の処理対象となるか否かを判定する。
ステップ５３（ＳＴ５３）の判定は、設計書論理体系定義ＤＢ２０１及び設計情報パラメータ（図示せず）の設定内容により行う。処理対象のインタフェースを明示的に指定する情報がない場合は、すべてのインタフェーステーブル行を処理対象とする。処理対象のインタフェースを明示的に指定する情報がある場合は、その指定に該当するインタフェーステーブル行のみを処理対象とする。ただし、インタフェースを処理対象から明示的に除外する情報がある場合は、その指定に該当するインタフェーステーブル行を処理対象としない。処理対象とならなかった場合、次のインタフェーステーブル行の処理ステップ５１（ＳＴ５１）に移る。
ステップ５３（ＳＴ５３）において処理対象と判定された場合は、ステップ５４（ＳＴ５４）において、インタフェース名称パターン整合検証の実行対象であるか否か判定を行う。実行対象と判定された場合は、ステップ５５（ＳＴ５５）のインタフェース名称パターン整合検証を実行する。インタフェース名称パターン整合検証では、処理中のインタフェーステーブル行の名前及び記号名が、設計書論理体系定義情報またはヒント情報で指定されている、インタフェースの名称ルールを満たしているか否かを判定し、満たしていない場合は、警告メッセージを検証結果に書き込む。
次に、処理中のインタフェーステーブル行に対応する全ての項目テーブルの行について、以下に説明するステップ５７（ＳＴ５７）からステップ６２（ＳＴ６２）までの処理を繰り返し、その終了判定をステップ５６（ＳＴ５６）において行う。
【００７２】
まず、ステップ５７（ＳＴ５７）において、抽出済み設計情報ＤＢ２０３の項目テーブルより、処理対象とする行を取得する。次に、ステップ５８（ＳＴ５８）において、取得した処理対象行がインタフェース定義検証処理の処理対象であるか否かを判定する。この判定は、設計書論理体系定義ＤＢ２０１及び設計検証パラメータ２０６の設定内容により行う。処理対象の項目を明示的に指定する情報がない場合は、すべての項目テーブル行を処理対象とする。処理対象の項目を明示的に指定する情報がある場合は、その指定に該当する項目テーブル行のみを処理対象とする。ただし、項目を処理対象から明示的に除外する情報がある場合は、その指定に該当する項目テーブル行を処理対象としない。処理対象とならなかった場合、ステップ５６（ＳＴ５６）に戻る。処理対象となった場合は、以下のステップ５９（ＳＴ59）からステップ６２（ＳＴ62）までの処理を行う。
【００７３】
ステップ５８（ＳＴ５８）において処理対象と判定された場合、まず、ステップ５９（ＳＴ５９）において、項目名称パターン整合検証の実行対象であるか否か判定し、対象である場合は、ステップ６０（ＳＴ６０）の項目名称パターン整合検証を実行する。
次に、ステップ６１（ＳＴ６１）において、編集条件検証の実行対象であるか否か判定する。対象である場合は、ステップ６２（ＳＴ６２）の編集条件検証を実行する。
ステップ６０（ＳＴ６０）の項目名称パターン整合検証では、処理中の項目テーブル行の名前及び記号名が、設計書論理体系定義ＤＢ２０１または設計検証パラメータ２０６で指定されている、項目の名称ルールを満たしているか否かを判定し、満たしていない場合は、警告メッセージを検証結果に書き込む。
【００７４】
ステップ６２（ＳＴ６２）の編集条件検証では、処理中の項目テーブル行に対応する全ての編集条件テーブルの行を参照し、その編集条件項目と編集方法項目の内容を検査する。まず、編集条件項目と編集方法項目に含まれる全てのデータリソース名、インタフェース名、その他の定義名が、それぞれデータリソーステーブル、インタフェーステーブル、その他の定義テーブルに登録済みか、全ての属性（項目）名、項目名、その他の定義項目名が、それぞれ属性（項目）テーブル、項目テーブル、その他定義項目テーブルに登録済みかを（所属するデータリソース、インタフェース、その他の定義も考慮して）判定する。登録されていないデータリソース名、インタフェース名、その他の定義名、属性（項目）名、項目名、その他の定義項目名が存在する場合は、警告メッセージを検証結果に書き込む。また、編集条件式の基本的な論理チェックを行い、エラーとなる場合は、警告メッセージを検証結果に書き込む。基本的な論理チェックとは、書式の誤りや、例えば、「Ａ＝Ｂ」と「Ａ≠Ｂ」のような、明らかに矛盾する式が同時に指定されている場合に、これをエラーとして検出するものである。また、編集方法に、属性（項目）名、項目名、その他の定義項目名が存在する場合、それらのタイプが、処理中の項目テーブル行のタイプと整合が取れていない、すなわちデータ型や桁数が一致しないなどの場合、警告メッセージを検証結果に書き込む。
【００７５】
ステップ５６（ＳＴ５６）において、項目テーブルの終了を判定したあと、ステップ６３（ＳＴ６３）において、適用条件検証の実行対象であるか判定を行う。実行対象である場合、ステップ６５（ＳＴ６５）の処理対象適用条件行選択処理と、ステップ６６（ＳＴ６６）の適用条件検証処理を実行し、ステップ６４（ＳＴ６４）において、全適用条件行の実行終了判定によりこのループを抜ける。
【００７６】
ステップ６５（ＳＴ６５）では、抽出済み設計情報ＤＢ２０３の適用条件テーブルより、処理対象とする行を取得し、ステップ６６（ＳＴ６６）の適用条件検証を実行する。適用条件検証では、処理対象の適用条件テーブル行の適用条件に含まれる、全ての属性（項目）名、項目名、その他の定義項目名が、それぞれ属性（項目）テーブル、項目テーブル、その他定義項目テーブルに登録済みかを（所属するデータリソース、インタフェース、その他の定義も考慮して）判定する。登録されていないデータリソース名、インタフェース名、その他の定義名、属性（項目）名、項目名、その他の定義項目名が存在する場合は、警告メッセージを検証結果に書き込む。また、適用条件式の基本的な論理チェックを行い、エラーとなる場合は、警告メッセージを検証結果に書き込む。基本的な論理チェックとは、書式の誤りや、例えば、「Ａ＝Ｂ」と「Ａ≠Ｂ」のような、明らかに矛盾する式が同時に指定されている場合に、これをエラーとして検出するものである。
【００７７】
図９Ｄは、設計検証処理部から呼び出されるその他の定義検証処理部の動作を示すフローチャートである。
その他の定義検証処理部では、抽出済み設計情報ＤＢのその他の定義テーブルの全行を処理するまで、以下の処理を繰り返す。ステップ７１（ＳＴ７１）
【００７８】
まず、ステップ７２（ＳＴ７２）において、抽出済み設計情報ＤＢ２０３の、その他の定義テーブルより処理対象とする行を取得する。ステップ７３（ＳＴ７３）において、取得した処理対象行がその他の定義検証処理の処理対象となるか否かを判定する。この判定は、設計書論理体系定義ＤＢ及び設計検証パラメータ２０６の設定内容により行う。処理対象のその他の定義を明示的に指定する情報がない場合は、すべてのその他の定義テーブル行を処理対象とする。処理対象のその他の定義を明示的に指定する情報がある場合は、その指定に該当するその他の定義テーブル行のみを処理対象とする。ただし、その他の定義を処理対象から明示的に除外する情報がある場合は、その指定に該当するその他の定義テーブル行を処理対象としない。処理対象とならなかった場合、次のその他の定義テーブル行の処理ステップ７１（ＳＴ７１）に移る。
ステップ７３（ＳＴ７３）において処理対象となった場合は、ステップ７４（ＳＴ７４）において、その他の定義名称パターン整合検証の実行対象であるか否か判定を行う。実行対象と判定された場合は、ステップ７５（ＳＴ７５）のその他定義名称パターン整合検証を実行する。その他の定義名称パターン整合検証では、処理中のその他の定義テーブル行の名前及び記号名が、設計書論理体系定義情報またはヒント情報で指定されている、その他の定義の名称ルールを満たしているか否かを判定し、満たしていない場合は、警告メッセージを検証結果に書き込む。
【００７９】
次に処理中のその他の定義行に対応する全ての項目テーブルの行について、以下に説明するステップ７７（ＳＴ７７）からステップ８２（ＳＴ８２）までの処理を繰り返し、その終了判定をステップ７６（ＳＴ７６）において行う。
【００８０】
まず、抽出済み設計情報ＤＢ２０３のその他の定義項目テーブルより、処理対象とする行を取得する。次に、ステップ７８（ＳＴ７８）において、取得した処理対象行がその他の定義検証処理の処理対象となるか否かを判定する。この判定は、設計書論理体系定義ＤＢ２０１及び設計検証パラメータ２０６の設定内容により行う。処理対象の項目を明示的に指定する情報がない場合は、すべてのその他の定義項目テーブル行を処理対象とする。処理対象のその他の定義項目を明示的に指定する情報がある場合は、その指定に該当するその他の定義項目テーブル行のみを処理対象とする。ただし、その他の定義項目を処理対象から明示的に除外する情報がある場合は、その指定に該当するその他の定義項目テーブル行を処理対象としない。処理対象とならなかった場合、ステップ７６（ＳＴ７６）に戻る。処理対象となった場合は、次のステップ７９（ＳＴ７９）からステップ８２（ＳＴ８２）までの処理を行う。
【００８１】
ステップ７８（ＳＴ７８）において処理対象と判定された場合、まず、ステップ７９（ＳＴ７９）において項目名称パターン整合検証の実行対象であるか否かを判定し、対象である場合は、ステップ８０（ＳＴ８０）のその他定義項目名称パターン整合検証を実行する。
次に、ステップ８１（ＳＴ８１）において、編集条件検証の実行対象であるか否か判定する。対象である場合は、ステップ８２（ＳＴ８２）のその他定義編集条件検証を実行する。
ステップ８０（ＳＴ８０）の、その他の定義項目名称パターン整合検証では、処理中のその他の定義項目テーブル行の名前及び記号名が、設計書論理体系定義ＤＢまたは設計検証パラメータ２０６で指定されている、その他の定義項目の名称ルールを満たしているか否かを判定し、満たしていない場合は、警告メッセージを検証結果に書き込む。
ステップ８２（ＳＴ８２）のその他定義編集条件検証では、処理中のその他の定義項目テーブル行に対応する全てのその他の定義編集条件テーブルの行を参照し、その編集条件項目と編集方法項目の内容を検査する。まず、編集条件項目と編集方法項目に含まれる全てのデータリソース名、インタフェース名、その他の定義名が、それぞれデータリソーステーブル、インタフェーステーブル、その他の定義テーブルに登録済みか、全ての属性（項目）名、項目名、その他の定義項目名が、それぞれ属性（項目）テーブル、項目テーブル、その他定義項目テーブルに登録済みかを（所属するデータリソース、インタフェース、その他の定義も考慮して）判定する。登録されていないデータリソース名、インタフェース名、その他の定義名、属性（項目）名、項目名、その他の定義項目名が存在する場合は、警告メッセージを検証結果に書き込む。また、編集条件式の基本的な論理チェックを行い、エラーとなる場合は、警告メッセージを検証結果に書き込む。基本的な論理チェックとは、書式の誤りや、例えば、「Ａ＝Ｂ」と「Ａ≠Ｂ」のような、明らかに矛盾する式が同時に指定されている場合に、これをエラーとして検出するものである。また、編集方法に、属性（項目）名、項目名、その他の定義項目名が存在する場合、それらのタイプが、処理中の項目テーブル行のタイプと整合が取れていない、すなわちデータ型や桁数が一致しないなどの場合、警告メッセージを検証結果に書き込む。
【００８２】
ステップ７６（ＳＴ７６）において、その他定義に属する項目行の処理の終了を判定したあと、ステップ８３（ＳＴ８３）において、適用条件検証の実行対象であるか否か判定を行う。実行対象と判定された場合は、ステップ８５（ＳＴ８５）の定義適用条件行の選択と、ステップ８６（ＳＴ８６）の適用条件検証を実行し、その終了判定をステップ８４（ＳＴ８４）で行う。
【００８３】
ステップ８５（ＳＴ８５）の処理は、抽出済み設計情報ＤＢ２０３のその他の定義適用条件テーブルより、処理対象とする行を取得するし、ステップ８６（ＳＴ８６）において、その他の定義適用条件検証を実行する。
ステップ８６（ＳＴ８６）では、処理対象のその他の定義適用条件テーブル行の適用条件に含まれる、全ての属性（項目）名、項目名、その他の定義項目名が、それぞれ属性（項目）テーブル、項目テーブル、その他定義項目テーブルに登録済みかを、所属するデータリソース・インタフェース・その他の定義も考慮して判定する。登録されていないデータリソース名、インタフェース名、その他の定義名、属性（項目）名、項目名、その他の定義項目名が存在する場合は、警告メッセージを検証結果２０４に書き込む。また、適用条件式の基本的な論理チェックを行い、エラーとなる場合は、警告メッセージを検証結果２０４に書き込む。基本的な論理チェックとは、書式の誤りや、例えば、「Ａ＝Ｂ」と「Ａ≠Ｂ」のような、明らかに矛盾する式が同時に指定されている場合に、これをエラーとして検出するものである。
【００８４】
図１０Ａは、図１に示すテストデータ生成処理部１３２の動作を示すフローチャートである。
まず、ステップ９１（ＳＴ９１）において、テストデータ生成パラメータ２０７を読み込み、読み込んだパラメータのクラスインスタンスを構築する。構築したパラメータのクラスインスタンスは以降テストデータ生成処理部全体から参照される。
次に、ステップ９２（ＳＴ９２）において、設計書論理体系定義ＤＢ２０１とテストデータ生成パラメータ２０７の設定内容により、テストデータの生成対象とするインタフェースを決定する。
ステップ９２（ＳＴ９２）において、インタフェースを決定した後、ステップ９４（ＳＴ９４）よりステップ１０１（ＳＴ１０１）の処理を実行し、その終了判定をステップ９３（ＳＴ９３）により行い。テストデータ生成処理を終える。
【００８５】
各インタフェーステーブル行の処理では、まず、ステップ９４（ＳＴ９４）において抽出済み設計情報ＤＢ２０３のインタフェーステーブルより、処理対象とする行を取得し、ステップ９５（ＳＴ９５）において、ステップ９２（ＳＴ９２）で取得したテストデータ生成処理の処理対象とされているか否かを判定する。
対象とされている場合、ステップＳＴ９７（ＳＴ９７）からステップ１０１（ＳＴ１０１）までの処理を行い、その終了判定をステップ９６（ＳＴ９６）により行う。対象とされていない場合、次のインタフェーステーブル行の処理に移る。
【００８６】
インタフェース各項目テーブル行の処理は、ステップ９７（ＳＴ９７）において抽出済み設計情報ＤＢ２０３の項目テーブルより処理対象とする行を取得し、ステップ９８（ＳＴ９８）の項目別テストケース生成処理部を実行する。ステップ９８（ＳＴ９８）では、インタフェース各項目の編集処理をテストするためのテストケースのリストを生成する。これを項目別テストケースリストと呼ぶ。
ステップ９７（ＳＴ９７）からステップ９８（ＳＴ９８）の処理が終了した後、ステップ９９（ＳＴ９９）において、全ての項目別テストケースリストを統合する。統合とは、全項目別テストケースリストに出現する全変数（データリソースの属性（項目）名、インタフェースの項目名、その他の定義のその他の定義項目名）を抽出し、抽出した変数毎の入力パターンをまとめ、まとめた全変数の全入力パターンを直積し、統合後テストケースリストを生成している。図１０Ｂは、当該処理の概念を示したものである。
【００８７】
次に、ステップ１００（ＳＴ１００）で、統合後テストケースリストを入力としてテストケースフィルタ処理部を実行し、フィルタ後テストケースリストを生成する。
次にステップ１０１（ＳＴ１０１）で、フィルタ後テストケースリストを入力として、制約チェック処理部を実行し、最終的なテストデータを生成し、テストデータＤＢに出力し、選択したインタフェースの処理を終える。
【００８８】
図１０Ｃは、ステップ９８（ＳＴ９８）の項目別テストケース生成処理部の動作を示すフローチャートである。項目別テストケース生成処理部では、テストデータ生成処理部で処理中の項目テーブル行に対応する、全ての編集条件テーブル行を処理する。
【００８９】
項目別テストケース生成処理は、まず、ステップ１１２（ＳＴ１１２）において、抽出済み設計情報ＤＢ２０３の編集条件テーブルより処理対象とする編集条件行を取得する。次に、ステップ１１３（ＳＴ１１３）において、ステップ１１２（ＳＴ１１２）で取得した編集条件テーブル行の編集条件より、そこに含まれる全変数（データリソースの属性（項目）名、インタフェースの項目名、その他の定義のその他の定義項目名）を抽出し、編集条件変数リストを生成する。
次に、ステップ１１５（ＳＴ１１５）において、各変数が取りうる入力データ値を比較し、全編集条件変数を処理するまでループさせて各変数が取りうる入力データ値の範囲を決定する。ステップ１１４（ＳＴ１１４）は、その終了判定である。
変数が、データリソースの属性（項目）名である場合、当該属性（項目）に対応する抽出済み設計情報ＤＢ２０３の定義域テーブル行で指定されている範囲を、当該変数の範囲とする。ただし、設計書論理体系定義ＤＢ２０１またはテストデータ生成パラメータ２０７に、当該変数に該当する範囲設定ルールが存在する場合、当該ルールにより範囲を決定する。
【００９０】
変数が、インタフェースの項目名またはその他の定義のその他の定義項目名である場合、以下のように決定する。当該項目名またはその他の定義項目名について、対応する編集条件テーブル行が1行のみで、編集条件の設定がなく、単純に別のデータリソースの属性（項目）、インタフェースの項目、またはその他の定義のその他の定義項目を参照している場合、その参照先の設定により、当該変数の範囲を決定する。参照先もまた同様の単純な参照をしている場合、さらにその参照元へ遡る。これを、繰り返す。例えば、インタフェースの項目Ａの範囲決定で、項目Ａがインタフェースの項目Ｂを単純に参照し、項目Ｂがインタフェースの項目Ｃを単純に参照し、項目Ｃがデータリソースの項目Ｄを単純に参照するならば、項目Ａの範囲は、項目Ｄの設定により決定される。また例えば、項目Ｂに複数の編集条件テーブル行が対応している場合は、項目Ｂの設定により決定される。また例えば、項目Ａが他を参照していない場合、項目Ａ自身の設定により決定される。
インタフェースの項目またはその他の定義のその他の定義項目の設定により、範囲を決定する場合、その範囲はまず、当該項目またはその他の定義項目のタイプにより決定される。次に、当該項目またはその他の定義項目が属するインタフェースまたはその他の定義の適用条件またはその他の定義適用条件のうち、当該項目またはその他の定義項目に関連する条件により範囲を限定する。例えば、インタフェースＸの項目Ａのタイプが符号付整数12桁で、インタフェースＸに「項目Ａ＜100000」という適用条件が設定されている場合、項目Ａの範囲はこの時点で「100000未満」となる。また、当該項目またはその他の定義項目に入力チェック条件を示す編集条件が設定されている場合、当該編集条件により、さらに範囲を限定する。上記の例で、項目Ａに「0未満または50000以上をエラーとする」入力チェック条件が設定されている場合、項目Ａの範囲は「0以上50000未満」となる。ただし、設計書論理体系定義情報またはヒント情報に、当該変数に該当する範囲設定ルールが存在する場合、当該ルールにより範囲を決定する。
【００９１】
通常は、上記の方法で範囲を決定するが、以下の条件が成立する場合は、当該変数をテストデータ生成処理上は擬似的な定数として扱い、範囲には単一の値を設定する。
１）当該変数が属する編集条件中の比較演算式の両辺に変数が含まれる。
２）当該変数が含まれる辺には、他の変数は存在しない。
３）両辺とも単一の変数しか存在しない場合、いずれか一方のみを当該措置の対象とする。どちらを対象とするかは、実装に依存する。
設定する単一の値は、設計書論理体系定義情報またはヒント情報に設定されているルール、または実装に依存して決定する。
【００９２】
ステップ１１５（ＳＴ１１５）の変数の範囲設定処理の終了後、編集条件の判定によるテストケース生成を行う。
まず、ステップ１１６（ＳＴ１１６）で編集条件に渡す入力データセットを初期化する。入力データセットの初期値は、各変数の範囲内の最小値とする。
入力データセットに含まれる全変数の全入力データのパターンの組み合わせを実行するまで、ステップ１１８（ＳＴ１１８）からステップ１２１（ＳＴ１２１）の処理を繰り返し、その終了判定をステップ１１７（ＳＴ１１７）で行う。
【００９３】
各入力データパターンの処理は以下のようになる。まず、ステップ１１８（ＳＴ１１８）において、現在の入力データセットの内容で、編集条件が成立するか否かを判定する。ステップ１１９（ＳＴ１１９）で、この判定結果が真、かつ前回判定結果が偽（または今回が初回の判定）である場合、ステップ１２０（ＳＴ１２０）において、現在の入力データセットの内容を項目別テストケースとして、項目別テストケースリストに追加する。
次に、ステップ１２１（ＳＴ１２１）において、入力データセットの内容を更新する。
入力データセットの更新は以下のように行う。入力データセット内の変数は、任意の優先順が設定されている。優先順の最も低い変数の設定値をその変数の範囲内の次の値に更新する。次の値の決定方法は、その変数のタイプと設計書論理体系定義ＤＢ２０１またはテストデータ生成パラメータ２０７に設定されているルール、または実装に依存して決定する。ただし、編集条件内で、当該変数が含まれる比較演算式の他辺が定数となっており、かつ当該定数及びその前後の値が、当該変数の範囲内であり、かつ更新後の値が、上記定数またはその前後の値より大きいならば、更新前の値に最も近い上記定数またはその前後の値が更新後の値となる。
変数の次の値が、当該変数の範囲内に存在しない場合、当該変数の上位の優先順を持つ変数の値を範囲内の次の値に更新する。次の値に正常に更新できるまで、優先順を上げながら、同様の処理を繰り返す。変数の更新が正常に出来た場合、その変数より優先度の低い全ての変数の値を、各変数の範囲の最小値に戻す。最上位の変数を更新できなかった場合、全入力パターンを処理し終えたものとして、テストケース生成処理を終了する。
【００９４】
図１０Ｄは、テストデータ生成処理部から呼び出されるテストケースフィルタ処理部の動作を示すフローチャートである。
テストケースフィルタ処理部では、テストデータ生成処理部で生成した統合後テストケースリストの全統合後テストケースを処理する。ステップ１３１（ＳＴ１３１）はその終了判定である。
各統合後テストケースの処理は、テストデータ生成処理部で処理中のインタフェーステーブル行に対応する、全ての項目テーブル行に対応する、全ての編集条件テーブル行について、ステップ１３３（ＳＴ１３３）からステップ１３４（ＳＴ１３４）の処理をループし、ステップ１３２（ＳＴ１３２）で終了を判定する。
【００９５】
各編集条件テーブル行の処理では、まず、ステップ１３３（ＳＴ１３３）で抽出済み設計情報ＤＢ２０３の編集条件テーブルより、処理対象とする行を取得する。
次に、ステップ１３４（ＳＴ１３４）で処理中の統合後テストケースを入力データセットとして、ステップ１３３（ＳＴ１３３）で取得した編集条件テーブル行の編集条件の真偽判定を行う。その結果と、入力した編集条件テーブル行の内容を記憶する。
ステップ１３２（ＳＴ１３２）の編集条件テーブル行の処理の終了判定後、ステップ１３５（ＳＴ１３５）において、編集条件の真偽判定の結果に関連する全ての編集条件テーブル行の編集条件が偽となる項目が含まれているか否か判定する。項目が含まれていない場合、ステップ１３６（ＳＴ１３６）において、フィルタ後テストケースリストに追加する。項目がある場合、次の統合後テストケースの処理に移る。
フィルタ後テストケースは、統合後テストケースの入力データセットの情報と、当該入力データセットによって真となる編集条件テーブル行の情報が含まれる。単一の項目で複数の編集条件テーブル行が真となる場合、それぞれを別のフィルタ後テストケースとして追加する。例えば、項目Ａと項目Ｂのみで構成されるインタフェースについて、項目Ａについては編集条件行１、項目Ｂについては編集条件行２及び編集条件行３が真となる場合、編集条件行１と編集条件行２を含むフィルタ後テストケースと編集条件行１と編集条件行３を含むフィルタ後テストケースを追加する。
【００９６】
図１０Ｅは、テストデータ生成処理部から呼び出される制約チェック処理部の動作を示すフローチャートである。
制約チェック処理部では、テストケースフィルタ生成処理部で生成したフィルタ後テストケースリストの全フィルタ後テストケースを処理する。
各フィルタ後テストケースの処理は、まず、フィルタ後テストケースに含まれる変数が属するデータリソースに対応する制約テーブル行（以下、これを関連制約行という）すべてについて、ステップ１４３（ＳＴ１４３）からステップ１４７（ＳＴ１４７）の処理を繰り返し、ステップ１４２（ＳＴ１４２）で終了判定を行う。
【００９７】
各関連制約行の処理では、ステップ１４３（ＳＴ１４３）において抽出済み設計情報ＤＢ２０３の制約テーブルより、処理対象とする行を取得する。次に、ステップ１４４（ＳＴ１４４）で取得した行が判定対象となるか否かを判定する。判定対象となるのは、制約式に変数が含まれ、かつその変数全てが、処理中のフィルタ後テストケースに含まれている行である。判定対象とならない場合は、次の関連制約行の処理に移る。
判定対象となる場合は、ステップ１４５（ＳＴ１４５）において、フィルタ後テストケースの入力データセットにより処理中の関連制約行の制約式が真となるか否かを判定する。ステップ１４６（ＳＴ１４６）は、ステップ１４５（ＳＴ１４５）の結果判定処理で、結果が真の場合は、次の関連制約行に処理を移る。結果が偽であれば、ステップ１４７（ＳＴ１４７）の制約警告文字列設定の処理により、テストデータＤＢ２０５のテストケーステーブルに追加するテストケース行のコメントに出力する文字列の編集領域に、制約違反の警告メッセージを追加する。警告メッセージの内容は、設計書論理体系定義ＤＢ２０１またはテストデータ生成パラメータ２０７に設定されているルールまたは、実装に依存して編集する。処理実行後、次の関連制約行の処理に移る。
【００９８】
ステップ１４２（ＳＴ１４２）で、関連制約行の処理の終了判定後、テストデータの編集出力を行う。
テストデータの編集出力では、まず、ステップ１４８（ＳＴ１４８）においてテストデータＤＢ２０５のテストケーステーブルに行を編集出力する。テストケーステーブル行のコメントは、ステップ１４７（ＳＴ１４７）で編集した編集領域の内容、及びフィルタ後テストケースに含まれる編集条件の付加情報に基づき、設計書論理体系定義ＤＢ２０１またはテストデータ生成パラメータ２０７に設定されているルールまたは、実装に依存して編集する。
次に、処理中のフィルタ後テストケースに含まれる全編集方法、すなわちインタフェースの全項目について、ステップ１５０（ＳＴ１５０）において項目別出力結果生成出力を行に、ステップ１４９（ＳＴ１４９）でその終了判定を行う。
ステップ１５０（ＳＴ１５０）の項目別出力結果生成出力では、テストデータＤＢ２０５の出力結果テーブルに行を追加する。追加する出力結果テーブル行のテスト結果は、以下のように編集する。
【００９９】
編集方法が、入力チェックの編集条件に対応付けられているものであるか、編集方法が定数のみであれば、編集方法の内容をそのまま転記する。
編集方法に、変数が含まれている場合、その変数に値を割り当てて、計算した結果を設定する。このとき、値を割り当てる変数が、フィルタ後テストケースの入力データセットに含まれている場合、入力データセット中の当該変数への設定値を割り当てる。値を割り当てる変数が、フィルタ後テストケースの入力データセットに含まれていない場合、当該変数のタイプ、及び設計書論理体系定義ＤＢ２０１またはテストデータ生成パラメータ２０７に設定されているルールまたは、実装に依存して値を割り当てる。
このとき、当該変数が属するデータリソース、インタフェース、またはその他の定義に、当該変数に関連する制約テーブル行、適用条件テーブル行、またはその他の定義適用条件テーブル行が存在する場合、それらの設定内容を考慮する。当該変数に関連するとは、制約式または適用条件に、当該変数が含まれ、かつ当該変数以外の全ての変数が、処理中のフィルタ後テストケースの入力データセットに含まれる変数であることをいう。このようにして、編集方法の内容から、新規に値を割り当てた変数は、追加入力データとして一時記憶領域に記憶する。
【０１００】
編集方法に関する処理の終了後、処理中のフィルタ後テストケースの入力データセットに含まれる全変数及び、ステップ１５０（ＳＴ１５０）で追加された全追加入力データについて、ステップ１５２（ＳＴ１５２）において項目別入力条件生成出力を行う。
項目別入力条件生成出力では、テストデータＤＢ２０５の入力条件テーブルにフィルタ後テストケースの入力データセットまたは追加入力データより編集した行を追加する。ステップ１５１（ＳＴ１５１）で追加された全追加入力データの生成出力の判定を行い。ステップ１４１（ＳＴ１４１）で全てのフィルタ後テストケースの処理判定を経て制約チェック処理部を終える。
【０１０１】
このように、実施の形態１によれば、統合ソフトウェアで作成した設計書ファイルから設計情報を抽出し、抽出した設計情報内容の基本的な整合性検証と、テストケースの生成を行うことができる。
【産業上の利用可能性】
【０１０２】
以上のように、本発明の情報処理システムの設計品質検査の支援システムは、一般的な事務処理システムの開発において、機能設計相当の設計書の内容に基づく、設計内容の整合性検証及びテストケースの生成を行うことができ、それらの結果により、早期の論理検証が可能となり、上流工程での設計品質向上を可能とする。また、機能設計相当の仕様を提示して行う外注及び、その検収作業の品質を向上し、外注作業の効率化を図ることができる。
【図面の簡単な説明】
【０１０３】
【図１】本発明の設計品質検査の支援システムの全体構成を示すブロック図である。
【図２】図１に示す設計書論理体系定義ＤＢの主要なデータ項目及びデータ内容を示す図である。
【図３Ａ】図１に示す抽出済み設計情報ＤＢの主要なデータ項目及びデータ内容を示す図である。
【図３Ｂ】図１に示す抽出済み設計情報ＤＢの主要なデータ項目及びデータ内容を示す図である。
【図３Ｃ】図１に示す抽出済み設計情報ＤＢの主要なデータ項目及びこれらのデータテーブル間の関連を示す図である。
【図３Ｄ】図１に示す抽出済み設計情報ＤＢの主要なデータ項目及びデータ内容を示す図である。
【図３Ｅ】図１に示す抽出済み設計情報ＤＢの主要なデータ項目及びデータ内容を示す図である。
【図３Ｆ】図１に示す抽出済み設計情報ＤＢの主要なデータ項目及びデータ内容を示す図である。
【図３Ｇ】図１に示す抽出済み設計情報ＤＢの主要なデータ項目及びデータ内容を示す図である。
【図４】図１に示す設計検証パラメータ及びテストデータ生成パラメータのデータ項目及びデータ内容を示す図である。
【図５Ａ】図１に示すテストデータＤＢの主要なデータ項目及びデータ内容並びにこれらのデータテーブル間の関連を示す図である。
【図５Ｂ】図１に示すテストデータＤＢの主要なデータ項目及びデータ内容を示す図である。
【図６】図１に示す設計書論理体系構築処理部の動作を示すフローチャートである。
【図７】図１に示す設計書読込処理部の動作を示すフローチャートである。
【図８】設計書読込処理部モジュールから設計書読込処理部に渡すデータの形式を例示する図である。
【図９Ａ】図１に示す設計検証処理部の動作を示すフローチャートである。
【図９Ｂ】データリソース定義検証処理部の動作を示すフローチャートである。
【図９Ｃ】設計検証処理部から呼び出されるインタフェース定義検証処理部の動作を示すフローチャートである。
【図９Ｄ】設計検証処理部から呼び出されるその他の定義検証処理部の動作を示すフローチャートである。
【図１０Ａ】図１に示すテストデータ生成処理部１３２の動作を示すフローチャートである。
【図１０Ｂ】図１に示すテストデータ生成処理部による統合後テストケースリストの生成処理の概念を示す図である。
【図１０Ｃ】項目別テストケース生成処理部の動作を示すフローチャートである。
【図１０Ｄ】テストデータ生成処理部から呼び出されるテストケースフィルタ処理部の動作を示すフローチャートである。
【図１０Ｅ】テストデータ生成処理部から呼び出される制約チェック処理部の動作を示すフローチャートである。
【符号の説明】
【０１０４】
０１０  クライアント端末
０２０  ネットワークシステム
１００  設計品質検査支援及びテストデータ生成システム
１１０  設計書論理体系構築処理部
１２１  設計書読込処理部
１２２  設計情報抽出処理部
１３１  設計検証処理部
１３２  テストデータ生成処理部
２０１  設計書論理体系定義ＤＢ
２０２  設計書データ
２０３  抽出済み設計情報ＤＢ
２０４  検証結果（ファイル）
２０５  テストデータＤＢ
２０６  設計検証パラメータ
２０７  テストデータ生成パラメータ
【図１】
2010072944.tif 000003
【図２】
2010072944.tif 000004
【図３Ａ】
2010072944.tif 000005
【図３Ｂ】
2010072944.tif 000006
【図３Ｃ】
2010072944.tif 000007
【図３Ｄ】
2010072944.tif 000008
【図３Ｅ】
2010072944.tif 000009
【図３Ｆ】
2010072944.tif 000010
【図３Ｇ】
2010072944.tif 000011
【図４】
2010072944.tif 000012
【図５Ａ】
2010072944.tif 000013
【図５Ｂ】
2010072944.tif 000014
【図６】
2010072944.tif 000015
【図７】
2010072944.tif 000016
【図８】
2010072944.tif 000017
【図９Ａ】
2010072944.tif 000018
【図９Ｂ】
2010072944.tif 000019
【図９Ｃ】
2010072944.tif 000020
【図９Ｄ】
2010072944.tif 000021
【図１０Ａ】
2010072944.tif 000022
【図１０Ｂ】
2010072944.tif 000023
【図１０Ｃ】
2010072944.tif 000024
【図１０Ｄ】
2010072944.tif 000025
【図１０Ｅ】
2010072944.tif 000026