JP6205512B2 - ルール管理支援装置、およびルール管理支援方法 - Google Patents

Description

本発明は、ルール管理支援装置、およびルール管理支援方法に関する。

ソフトウェアは、処理対象となる製品、サービス等の業務に関する法的な規制、種々の業務上の規則、基準等に従って仕様が決定され設計される。ソフトウェアの仕様を、ＩＦ−ＴＨＥＮ形式で整理する場合がある。ＩＦ−ＴＨＥＮ形式の仕様（以下、ＩＦ節を「条件部」、ＴＨＥＮ節を「結果部」という。）は、ビジネスルール、システムルール、チェックルールなど利用するフェーズに応じて様々な呼び名がある（以下、これらをすべて「ルール」という。また、複数のルールの集まりを「ルールセット」という。）。ルールは、「もし〜ならば〜である」というように自然文で記述したり、「ＩＦ Ａ＝１ ＡＮＤ Ｂ＝２ ＴＨＥＮ Ｒ＝１」というように機械解釈可能な一定の規則に従って記述したり、条件と結果の対応関係を表形式で定義した決定表で記述したり、などさまざまな形態で表現される。例えば、命題形式の記述と決定表とを連携させてルールを定義する方法が、特許文献１で開示されている。

ソフトウェアに組み込まれるルールは、ルールの入力となる入力項目とルールの出力となる出力項目をもつ。ルールの条件部は、入力項目を活用した論理式として表現され、ルールの結果部は、出力項目を活用した論理式として表現できる。

複数のルールが混在した場合、ルール間に不整合や、入力のパターン考慮漏れなどが発生する場合がある。特許文献１では、命題形式のルール間の不整合や考慮もれを検出する方法が開示されている。

また、法改正や業務規則の変更に伴い、ソフトウェアに組み込まれているルールセットも変更する必要がある。この場合、一部の入力と出力の関係が変わり、残りは変更前と同様な場合がほとんどである。また、ルールセットの理解容易性の向上などを目的に、入力と出力の関係を保持したまま、ルールセットを変更する場合がある。変更を行った場合、入力と出力の関係が変更前と変更後で維持されるべき部分が維持されていること（以下、「等価性」という。）を確認する必要がある。等価性を確認する方法としては、変更前のテストケースを保存しておき、変更後のルールセットに対して、同じテストケースを適用することで確認する方法が、特許文献２で開示されている。

特開２０１２−１９０２０３号公報 ＵＳ２００９／０１１２６５４

特許文献１を活用することで、ルール間の不整合や考慮漏れを検出できるが、変更前と変更後のルールセット間の等価性を検証する方法を開示していない。

また、特許文献２で開示されている技術により、変更後のルールセットに対して、変更前のテストケースを適用して、テストを実行することで、不要な変更が加えられていないかテストした範囲において確認できる。しかし、ソフトウェア仕様の変更により、テストが失敗する場合と、誤ってルールを変更したことにより、テストが失敗する場合が混在してしまうため、失敗したテストケースを１つ１つ人が確認する必要がある。また、特許文献２で開示されている技術は、サンプリングテストに基づくものであるため、変更が加えられてはいけない部分が影響を受けていないことを保証できない。

上記の課題に鑑み、本発明では、変更前と変更後のルールセットの等価性の確認を容易に実行できるようにするルール管理支援装置、およびルール管理支援方法を提供することを目的とする。

ソフトウェア仕様の開発におけるルールの管理を支援するための装置であって、前記ルールが成立するための条件を格納する条件部と前記条件が成立した場合の結果を格納する結果部とを含む１以上の入力ルールを含む入力ルールセットを受け付けるための入力ルール編集部と、前記入力ルールセットと変更前のルールセットである変更前ルールセットとを比較検証するルール等価性検証部とを備え、前記入力ルール編集部は、入力と出力の関係を変更後においても維持する変更前の入力ルールである等価性維持ルールを指定する等価性維持ルールオプション指定部を備え、前記ルール等価性検証部は、前記等価性維持ルールオプション指定部を参照して、前記等価性維持ルールの条件部を満たす入力に対して、前記入力ルールセットが前記等価性維持ルールと同一の出力を返すか否かを判定した結果を出力することを特徴とするルール管理支援装置。

本発明の実施形態によれば、変更前と変更後のルールセットにおいて、入力と出力の関係が維持されるべき部分が維持されていることの確認を容易に実行できるようにするルール管理支援装置、およびルール管理支援方法を提供することができる。

本発明に係るルール管理支援装置１００の構成図の例である。 入力ルール保持部１２１のデータ構造の例である。 比較結果保持部１２２のデータ構造の例である。 テストケース保持部１２３のデータ構造の例である。 ルール編集画面５００の例である。 対応関係判定部１０３の処理例を示すフローチャートである。 ルール等価性検証部１０４の処理例を示すフローチャートである。 ルール補正部１０５の処理例を示すフローチャートである。 ルール補正部１０５の変更ルール優先補正処理例を示すフローチャートである。 ルール補正部１０５の等価性維持ルール優先補正処理例を示すフローチャートである。 テストケース編集画面１１００の例である。 ルールテスト実行部１１２の処理例を示すフローチャートである。 テストケース補正部１１３の処理例を示すフローチャートである。

以下、本発明について、その実施形態に則して、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている諸要素およびその組み合わせの全てが発明の解決手段に必須であるとは限らない。

本実施形態では、ユーザが定義したルールの変更を支援する装置の例を説明する。

図１は、本実施形態に係るルール管理支援装置１００の構成図の例である。ルール管理支援装置１００は、少なくともＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等のプロセッサ１３１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等のメモリ１３２、補助記憶装置１３３、およびキーボード、表示モニタ等の入出力装置１３４を備えたコンピュータである。ルール管理支援装置１００は、入力ルール編集部１０１、ルール整合性検証部１０２、対応関係判定部１０３、ルール等価性検証部１０４、ルール補正部１０５、検証結果出力部１０６、テストケース編集部１１１、ルールテスト実行部１１２、テストケース補正部１１３、およびテスト実行結果出力部１１４などの機能ロジックを備える。これらの機能ロジックはコンピュータプログラムとして実現されており、メモリ１３２上でプロセッサ１３１により実行される。また、ルール管理支援装置１００は、入力ルール保持部１２１、比較結果保持部１２２、およびテストケース保持部１２３などのデータを、補助記憶装置１３３に保管している。これらのデータは、プロセッサ１３１が前記機能ロジックを実行する際に補助記憶装置１３３から読みだして使用する。

入力ルール編集部１０１は、ユーザが追加、変更、または削除したルール、ユーザが選択したルール編集モード、および前記ルール編集モードを適用する変更前のルールに関する情報を受け付け、入力ルール保持部１２１に登録する。ルール編集モードとは、ユーザが選択する変更前のルールに関する種類であり、本実施形態では、「変更対象指定」「等価性維持対象指定」「変更内容優先」のいずれかの値である。

次に、ルール整合性検証部１０２は、入力ルール保持部１２１に登録されているルール間に不整合があるか否かを検証する。ルール間の不整合とは、ある入力が複数のルールの条件部を満たす場合、結果部を満たす出力値が存在しない場合である。例えば、「ＩＦ Ａ＝１ ＴＨＥＮ Ｒ＝１」と「ＩＦ Ｂ＝１ ＴＨＥＮ Ｒ＝２」という２つのルールがあったとする。２つのルールの条件部は、「Ａ＝１、Ｂ＝１」という入力を満たすが、結果部が一方は「Ｒ＝１」で、もう一方は「Ｒ＝２」であり、これら２つを満たすＲの値が存在しないため、これら２つのルールは不整合となる。ルール間の不整合の判定方法については、例えば、特許文献１において充足可能性判定を用いた方法が開示されている。

次に、対応関係判定部１０３は、変更前のルール（以下、「変更前ルール」という。）と変更後のルール（以下、「変更後ルール」という。）の対応関係を判定し、判定結果を比較結果保持部１２２に登録する。

次に、ルール等価性検証部１０４は、変更前のルールセット（以下、「変更前ルールセット」という。）の入力と出力の関係が、変更後のルールセット（以下、「変更後ルールセット」という。）において維持されているか否かを、変更前ルール毎に検証し、その結果を比較結果保持部１２２に登録する。また、変更前ルールのうち、変更後ルールセットにおいて入力と出力の関係が維持されるべきルール（以下、「等価性維持ルール」という。）を、入力ルール編集部１０１が受け付けた情報に基づき判定した結果を比較結果保持部１２２に登録する。

次に、ルール補正部１０５は、ルール等価性検証部１０４の検証の結果、等価性維持ルールと入力と出力の関係が維持されていない変更後ルールについて、等価性維持ルールと入力と出力の関係が維持されるように変更後ルールの補正案を生成する。また、ルール編集モードが「変更内容優先」の場合、ルール整合性検証部１０２の検証の結果、変更後ルール間に不整合がある変更後ルールについて、その不整合を解消する補正案を生成する。

次に、検証結果出力部１０６は、ルール整合性検証部１０２およびルール等価性検証部１０４による検証結果を画面やファイルなどに出力する。

次に、テストケース編集部１１１は、ユーザが追加、変更、または削除したテストケースを受け付け、テストケース保持部１２３に登録する。

次に、ルールテスト実行部１１２は、テストケース保持部１２３に登録されているテストケース情報に基づき、テストを実行する。

次に、テストケース補正部１１３は、ルールテスト実行部１１２によるテストの実行の結果、失敗したテストケースについて、その補正案を画面やファイルなどに出力する。

次に、テスト実行結果出力部１１４は、テストケース保持部１２３に登録されているテスト結果を画面やファイルなどに出力する。

続いて、図２を参照して、本実施形態に係る入力ルール保持部１２１のデータ構造の例について説明する。図２に示すように、入力ルール保持部１２１は、ルールセット情報２０１、ルール情報２０２、編集モード適用ルール情報２０３、および不整合ルール情報２０４といったエンティティを有する。図２の各エンティティは、２つの四角形から構成されており、上の四角形内に示す名前はエンティティ名を表し、下の四角形内に示す名前は当該エンティティの属性名を表している。また、エンティティ間の関連は、ひし形と実線を結んで表し、ひし形側のエンティティと実線側のエンティティは、１対多の関係にあることを表す。以下、他のデータ構造の図についても同様に記載している。

図２において、ルールセット情報２０１は、ルールセットに関する情報として、ルールセットＩＤ、変更前ルールセットＩＤ、ルール編集モード、および整合性判定結果といった属性を有するエンティティである。ルールセットＩＤは、入力ルール保持部１２１においてユニークな識別子である。例えば、ルールセットＩＤとして、数値を利用し、ルールセットを編集する度に、１を加えた値を変更後のルールセットのルールセットＩＤとする。これにより、ルールセットＩＤを比較することで、どちらが新しいルールセットかを特定できる。変更前ルールセットＩＤは、当該ルールセットの変更前のルールセット情報２０１のルールセットＩＤである。変更前のルールセット情報２０１が存在しない場合は、「ＮＵＬＬ」を指定する。ルール編集モードは、入力ルール編集部１０１が受け付けたルール編集モードであり、本実施形態では、「変更対象指定」「等価性維持対象指定」「変更内容優先」のいずれかの値である。整合性判定結果は、変更後ルールセットの整合性の判定結果であり、本実施形態では、「整合」「不整合」「未判定」のいずれかの値である。なお、どちらのルールセットが新しいかどうかの判定は、ルールセットＩＤを用いる以外に、作成日など他の情報をルールセット情報２０１に含めて判定してもよい。ルールセット情報２０１は、ルールセットの変更履歴の管理に利用でき、１つのルールセット情報２０１が１つの履歴に対応する。

次に、ルール情報２０２は、ルールセットに含まれるルールに関する情報として、ルールＩＤ、条件部論理式、結果部論理式、および編集ラベルといった属性を有するエンティティである。ルールＩＤは、当該ルールセットの中でユニークな識別子である。条件部論理式は、ルールの条件部を表す論理式であり、入力項目、入力項目が取り得る値、比較演算子（等式演算子を含む）、四則演算子、論理演算子などの組合せで表現される。結果部論理式は、ルールの結果部を表す論理式であり、入力項目、出力項目、出力項目が取り得る値、等式演算子、四則演算子、論理積演算子などの組合せで表現される。なお、本実施形態では、条件部論理式および結果部論理式を構成する最小単位である「左辺式 比較演算子 右辺式」を「項」と呼称する。ここで、左辺式および右辺式は、入力項目、入力項目が取り得る値、出力項目、出力項目が取り得る値、および四則演算子などを利用して構成される式である。例えば、「Ａ」「Ａ＋１」「１」などが左辺式または右辺式であり、「Ａ＝１」「Ａ＝Ｂ＋1」などが項である。なお、結果部論理式に含まれる項の左辺式は必ず出力項目である。編集ラベルは、ルールが変更前ルールから変更されたか否かなどを示す情報であり、本実施形態では、「追加」「変更」「変更なし」のいずれかの値であり、入力ルール編集部１０１により設定される。「変更」または「変更なし」は、条件部論理式と結果部論理式を文字列として表現した場合に、変更前ルールと完全一致している場合が「変更なし」であり、それ以外は、「変更」である。

次に、編集モード適用ルール情報２０３は、入力ルール編集部１０１が受け付けた、ユーザが選択したルールに関する情報として、変更前ルールＩＤといった属性を有するエンティティである。変更前ルールＩＤは、変更前ルールうち、ユーザが選択した変更前ルールのルールＩＤである。

次に、不整合ルール情報２０４は、ルール情報２０２の変更後ルールが他の変更後ルールと不整合となる場合に存在するエンティティであり、前記他のルールに関する情報として、ルールＩＤといった属性を有する。ルールＩＤは、前記他のルールに対応するルール情報２０２のルールＩＤである。本実施形態では、２つのルールの条件部論理式の論理積が充足可能であり、かつ、結果部論理式の論理積が充足不能な場合、前記２つのルールは不整合であるとみなす。２つのルールが不整合であるか否かの判定は、ルール整合性検証部１０２が行い、不整合となるルール情報を、入力ルール保持部１２１の不整合ルール情報２０４に記憶する。

続いて、図３を参照して、本実施形態に係る比較結果保持部１２２のデータ構造の例について説明する。図３に示すように、比較結果保持部１２２は、ルールセット比較結果情報３０１、ルール比較結果情報３０２、および関連変更後ルール情報３０３といったエンティティを有する。

図３において、ルールセット比較結果情報３０１は、変更前ルールセットと変更後ルールセットの比較結果に関する情報として、ルールセットＩＤ、および等価性判定結果といった属性を有するエンティティである。ルールセットＩＤは、変更後ルールセットの識別子であり、変更後ルールセットに対応するルールセット情報２０１のルールセットＩＤである。等価性判定結果は、変更前ルールセットと変更後ルールセットの比較結果であり、本実施形態では、「等価」「非等価」「未判定」のいずれかの値である。変更前ルールセットは、変更後ルールセットに対応するルールセット情報２０１の変更前ルールセットＩＤを参照することで特定できる。

次に、ルール比較結果情報３０２は、変更前ルールと変更後ルールの比較結果に関する情報として、変更前ルールＩＤ、等価性維持フラグ、等価性判定結果、および完全性判定結果といった属性を有するエンティティである。変更前ルールＩＤは、変更前ルールの識別子である。等価性維持フラグは、変更前ルールが等価性維持ルールであるか否かを示す情報であり、本実施形態では、「ＴＲＵＥ」「ＦＡＬＳＥ」「ＵＮＫＮＷＯＮ」のいずれかの値である。等価性判定結果は、変更前ルールと変更後ルールの等価性の判定結果であり、本実施形態では、「完全等価」「等価」「部分等価」「非等価」「未判定」のいずれかの値である。完全性判定結果は、変更前ルールの条件部を満たす全ての入力値の組合せに対して、関連変更後ルール情報３０３に関連するいずれかの変更後ルールの条件部を満たすか否かに関する情報であり、本実施形態では、「漏れあり」「漏れなし」「未判定」のいずれかの値である。「漏れあり」の場合、変更前ルールの条件を満たすが、いずれの変更後ルールの条件部も満たさない入力値の組合せが存在することを表す。「漏れなし」の場合、変更前ルールの条件部を満たす全ての入力値の組合せに対して、いずれかの変更後ルールの条件部を満たす。

次に、関連変更後ルール情報３０３は、ルール比較結果情報３０２の変更前ルールＩＤに対応する変更前ルールと対応関係がある変更後ルールに関する情報として、変更後ルールＩＤ、および整合性判定結果といった属性を有するエンティティである。変更後ルールＩＤは、ルール比較結果情報３０２の変更前ルールＩＤに対応する変更前ルールと対応関係がある変更後ルールの識別子である。整合性判定結果は、ルール比較結果情報３０２の変更前ルールＩＤに対応する変更前ルールと、変更後ルールＩＤに対応する変更後ルールとの整合性の判定結果であり、「整合」「不整合」「未判定」のいずれかの値である。

続いて、図４を参照して、本実施形態に係るテストケース保持部１２３のデータ構造の例について説明する。図４に示すように、テストケース保持部１２３は、テストケースバージョン情報４０１、テストケース情報４０２、テスト結果情報４０３、および実行ルール情報４０４といったエンティティを有する。

図４において、テストケースバージョン情報４０１は、テストケースのバージョンを管理する情報として、テストケースバージョンＩＤといった属性を有するエンティティである。例えば、テストケースバージョンＩＤとして、数値を利用し、テストケースのバージョンを上げる度に、１を加えた値を新しいバージョンのテストケースバージョンＩＤとする。これにより、テストケースバージョンＩＤを比較することで、どちらが新しいテストケースかを特定できる。なお、どちらのテストケースが新しいかどうかの判定は、テストケースバージョンＩＤを用いる以外に、作成日など他の情報をテストケースバージョン情報４０１に含めて判定してもよい。

次に、テストケース情報４０２は、個々のテストケースを管理する情報として、テストケースＩＤ、テストケースラベル、入力値条件、および期待値条件といった属性を有するエンティティである。テストケースＩＤは、テストケース保持部１２３においてユニークな識別子である。テストケースラベルは、テストケースの種類を示す情報であり、本実施形態では、「必須」「推奨」「一般」のいずれかの値である。テストケースラベルは、テストケース編集部１１１により設定される。入力値条件は、テストケースの入力値の条件を表す論理式である。入力値条件としては、例えば、「Ａｇｅ＝３０ ＡＮＤ Ｒａｎｋ＝Ｇｏｌｄ」「Ａｇｅ＞＝３５」など任意の論理式を指定できる。期待値条件は、テストケースの期待値の条件を表す論理式である。期待値条件としては、例えば、「Ｄｉｓｃｏｕｎｔ＝５」「Ｄｉｓｃｏｕｎｔ＜２０」などの任意の論理式を指定できる。

次に、テスト結果情報４０３は、テストを実行した結果に関する情報として、対象ルールセットＩＤ、テスト結果、およびテスト日時といった属性を有するエンティティである。対象ルールセットＩＤは、テスト対象のルールセットの識別子である。テスト結果は、テストを実行した結果であり、本実施形態では、「ＯＫ」「ＮＧ」「ＷＡＲＮ」のいずれかの値である。テスト日時は、テストを実行した日付と時間に関する情報である。

次に、実行ルール情報４０４は、当該テストケースをテストする際に実行したルールに関する情報として、ルールＩＤといった属性を有するエンティティである。ルールＩＤは、当該テストケースをテストする際に実行したルールの識別子である。

続いて、図５を参照して、本実施形態に係るルールの編集画面の例について説明する。ルール編集画面５００は、入力ルール編集部１０１におけるユーザからの入力を受け付けると共に、検証結果出力部１０６において検証結果を表示する。

図５に示すように、ルール編集画面５００は、ルール編集エリア５１０、変更前ルール表示エリア５５０などの領域、および検証ボタン５７０を含む。

ルール編集エリア５１０は、ルールの追加、変更、および削除などのルールを編集する領域であり、ＩＤ５１２、条件部５１３、結果部５１４、等価性５１５、および整合性５１６といった項目を持つ変更後ルール一覧５１１と、追加ボタン５２１、削除ボタン５２２、および補正案表示ボタン５２３といったボタンを有する。

ＩＤ５１２は、変更後ルールの識別子である。条件部５１３は、変更後ルールの条件部を表す論理式である。結果部５１４は、変更後ルールの結果部を表す論理式である。

等価性５１５は、変更後ルールと等価性維持ルールとの等価性の検証結果であり、ユーザが検証ボタン５７０を押下することで、検証結果出力部１０６が値を設定する。検証結果出力部１０６は、関連変更後ルール情報３０３の変更後ルールＩＤがＩＤ５１２と一致する関連変更後ルール情報３０３と、前記関連変更後ルール情報３０３を持つルール比較結果情報３０２のペアについて、すべてのペアの前記関連変更後ルール情報３０３の整合性判定結果が「整合」であり、かつ、前記ルール比較結果情報３０２の等価性維持フラグが「ＴＵＲＥ」の場合、等価性５１５に「等価」を設定し、前記関連変更後ルール情報３０３の整合性判定結果が「不整合」であり、かつ、前記ルール比較結果情報３０２の等価性維持フラグが「ＴＵＲＥ」であるペアを含む場合、等価性５１５に「非等価」を設定し、その他の場合には等価性判定の対象外を示す「−」を設定する。

整合性５１６は、変更後ルール間での整合性の検証結果であり、ユーザが検証ボタン５７０を押下することで、検証結果出力部１０６が不整合となるルールのＩＤを設定する。検証結果出力部１０６は、ルール情報２０２のルールＩＤがＩＤ５１２と一致するルール情報２０２について、不整合ルール情報２０４がない場合、不整合となるルールがないことを示す「−」を設定し、不整合ルール情報２０４が１以上ある場合は、不整合ルール情報２０４のルールＩＤを整合性５１６に設定する。不整合ルール情報２０４が複数ある場合は、カンマ（，）で区切るなどして、全ての不整合ルール情報２０４のルールＩＤを設定する。

追加ボタン５２１は、新規にルールを追加するためボタンであり、ユーザが追加ボタン５２１を押下することで、入力ルール編集部１０６が変更後ルール一覧５１１に空のルールを追加する。ユーザは、追加された空のルールもしくは既存のルールを選択することで、ルールの条件部および結果部を編集できる。削除ボタン５２２は、変更後ルール一覧５１１のルールを削除するためのボタンであり、ユーザが変更後ルール一覧５１１のルールを選択し、削除ボタン５２２を押下することで、入力ルール編集部１０６が、ユーザが選択したルールを削除する。補正案表示ボタン５２３は、等価性や整合性の検証で不備が見つかった場合に、その不備を解消するための補正案を表示するためのボタンであり、ユーザが補正案表示ボタン５２３を押下することで、ルール補正部１０５が補正案を表示する。

変更前ルール表示エリア５５０は、変更前ルールを表示する領域であり、ルール編集モード５５１を選択する領域と、ＩＤ５６２、対象５６３、条件部５６４、結果部５６５、等価性５６６、および完全性５６７といった項目を持つ変更前ルール一覧５６１を有する。ルール編集モード５５１は、変更前ルール一覧５６１から、ユーザが選択するルールの種類であり、本実施形態では、「変更対象指定」「等価性維持対象指定」「変更内容優先」のいずれかを選択できる。ＩＤ５６２は、変更前ルールの識別子である。対象５６３は、ユーザが選択したルールであるか否かを示すフラグである。条件部５６４は、変更前ルールの条件部を表す論理式である。結果部５６５は、変更前ルールの結果部を表す論理式である。

等価性５６６は、変更前ルールと変更後ルールの等価性の検証結果であり、ユーザが検証ボタン５７０を押下することで、検証結果出力部１０６が値を設定する。検証結果出力部１０６は、ルール比較結果情報３０２の変更前ルールＩＤがＩＤ５６２と一致するルール比較結果情報３０２について、ルール比較結果情報３０２の等価性維持フラグが「ＴＲＵＥ」である場合、ルール比較結果情報３０２の等価性判定結果の値を等価性５６６に設定する。ルール比較結果情報３０２の等価性維持フラグが「ＦＡＬＳＥ」または「ＵＮＫＮＯＷＮ」である場合、等価性判定の対象外であることを示す「−」を設定する。

完全性５６７は、変更前ルールの条件部を満たす全ての入力値の組合せに対して、いずれかの変更後ルールの条件部を満たすか否かを検証した結果であり、ユーザが検証ボタン５７０を押下することで、検証結果出力部１０６が値を設定する。検証結果出力部１０６は、ルール比較結果情報３０２の変更前ルールＩＤがＩＤ５６２と一致するルール比較結果情報３０２の完全性判定結果が「漏れあり」の場合、完全性５６７に「ＮＧ」を設定し、「漏れなし」の場合、完全性５６７に「ＯＫ」を設定する。

検証ボタン５７０は、ユーザが押下することで、ルール整合性検証部１０２、対応関係判定部１０３、およびルール等価性検証部１０４が順次実行され、検証結果出力部１０６が、入力ルール保持部１２１および比較結果保持部１２２を参照し、等価性５１５、整合性５１６、等価性５６６、および完全性５６７に検証結果を出力する。なお、検証の結果、非等価、不整合、および漏れありといった不具合を検出した場合、検証結果出力１０６は、不具合が発生する入力値の組合せを出力するようにしてもよい。例えば、ＳＭＴ（Ｓａｔｉｓｆｉａｂｉｌｉｔｙ Ｍｏｄｕｌｏ Ｔｈｅｏｒｉｅｓ）ソルバを活用することで、前記入力値の組合せを取得できる。

次に、ルール編集モード５５１の各選択子が選択された場合の検証結果出力部１０６の振る舞いを説明する。

「変更対象指定」が選択された場合、検証結果出力部１０６は、ユーザが選択していない変更前ルールを等価性維持ルールとみなし、等価性維持ルールと等価か否かの情報を変更後ルール一覧５１１の等価性５１５に設定する。等価性維持ルールと対応関係がない変更後ルールの等価性５１５は等価性検証の対象外を示す「−」を設定する。また、検証結果出力部１０６は、変更前ルール一覧５６１の等価性５６６にも変更後ルールが等価性維持ルールと等価であるか否かの情報を設定する。等価性維持ルールでない等価性５６６には、等価性検証の対象外を示す「−」を設定する。また、検証結果出力部１０６は、変更後ルール一覧５１１の整合性５１６、および変更前ルール一覧５６１の完全性５６７に各検証結果を設定する。

「等価性維持対象指定」が選択された場合、検証結果出力部１０６は、ユーザが選択した変更前ルールを等価性維持ルールとみなし、「変更対象指定」が設定された場合と同様の処理を行う。

「変更内容優先」が選択された場合、検証結果出力部１０６は、等価性の検証結果は出力せず、変更後ルール一覧５１１の整合性５１６、および変更前ルール一覧５６１の完全性５６７に各検証結果を設定する。

続いて、図６を参照して、本発明の実施形態に係る対応関係判定部１０３の処理について説明する。図６は、本実施形態に係る対応関係判定部１０３の処理例を示すフローチャートである。なお、図中の符号Ｓはステップを表す（以下本明細書中で同様）。

まず、対応関係判定部１０３は、ユーザによる入出力装置１３４の操作、バッチ処理などにより処理の実行を開始する（Ｓ６００）。対応関係判定部１０３は、変更前ルールセットと変更後ルールセットを読み込む（Ｓ６０１）。対応関係判定部１０３は、ルールセット情報２０１を参照し、最新のルールセット情報２０１を特定し、前記ルールセット情報２０１、前記ルールセット情報２０１に関連するルール情報２０２、および編集モード適用ルール情報２０３を読み込む。また、対応関係判定部１０３は、前記ルールセット情報２０１の変更前ルールセットＩＤを参照し、変更前ルールセットを特定し、対応するルールセット情報２０１およびルール情報２０２を読み込む。

次に、対応関係判定部１０３は、変更前ルールセットから変更前ルールを１つ取得する（Ｓ６０２）。

次に、対応関係判定部１０３は、変更後ルールのうち、変更後ルールの条件部と前記変更前ルールの条件部との論理積が、充足可能な全ての変更後ルールを特定する（Ｓ６０３）。図５に示す変更前ルールと変更後ルールの例では、ＩＤ５６２がＢ１の変更前ルールをＳ６０２で選択したとすると、｛Ｂ１，Ａ１｝｛Ｂ１，Ａ２｝｛Ｂ１，Ａ３｝｛Ｂ１，Ａ４｝の各変更前ルールと変更後ルールのペアについて、それぞれの条件部の論理積の充足可能性を判定する。充足可能性の判定には、例えば、ＳＭＴ（Ｓａｔｉｓｆｉａｂｉｌｉｔｙ Ｍｏｄｕｌｏ Ｔｈｅｏｒｉｅｓ）ソルバを利用できる。

次に、対応関係判定部１０３は、Ｓ６０３において、充足可能と判定された前記変更後ルールについて、前記変更前ルールの結果部の出力項目を含む前記変更後ルールを特定し、変更前ルールと変更後ルールの対応関係を比較結果保持部１２２に記憶する（Ｓ６０４）。対応関係判定部１０３は、ルール比較結果情報３０２を作成し、ルール比較結果情報３０２の変更前ルールＩＤに前記変更前ルールの識別子を設定し、ルール比較結果情報３０２の等価性維持フラグに、前記変更前フラグが等価性維持ルールであるか否かの情報を設定する。前記変更前ルールが等価性維持ルールであるか否かは、入力ルール保持部１２１のルールセット情報２０１のルール編集モード、および編集モード適用ルール情報２０３の変更前ルールＩＤを参照することで判定できる。具体的には、前記ルール編集モードが「変更対象指定」の場合、ルール比較結果情報３０２の変更前ルールＩＤが、編集モード適用ルール情報２０３の変更前ルールＩＤのいずれとも一致しない場合、対応関係判定部１０３は、等価性維持フラグに「ＴＲＵＥ」を設定し、そうでない場合、「ＦＡＬＳＥ」を設定する。前記ルール編集モードが「等価性維持対象指定」の場合、ルール比較結果情報３０２の変更前ルールＩＤが、編集モード適用ルール情報２０３の変更前ルールＩＤのいずれかと一致する場合、対応関係判定部１０３は、等価性維持フラグに「ＴＲＵＥ」を設定し、そうでない場合、「ＦＡＬＳＥ」を設定する。前記ルール編集モードが「変更内容優先」の場合、対応関係判定部１０３は、等価性維持フラグに「ＵＮＫＮＯＷＮ」を設定する。また、対応関係判定部１０３は、ルール比較結果情報３０２の等価性判定結果および完全性判定結果に「未判定」を設定する。また、対応関係判定部１０３は、前記変更前ルールの結果部の出力項目を含む前記変更後ルールの識別子を、関連変更後ルール情報３０３の変更後ルールＩＤに設定し、関連変更後ルール情報３０３の整合性判定結果に「未判定」を設定する。

次に、対応関係判定部１０３は、変更前ルールセットに、未処理の変更前ルールがあるかを判定する（Ｓ６０５）。未処理の変更前ルールがある場合、対応関係判定部１０３は、Ｓ６０２に進み、そうでない場合、処理を終了する（Ｓ６０６）。

続いて、図７を参照して、本発明の実施形態に係るルール等価性検証部１０４の処理について説明する。図７は、本実施形態に係るルール等価性検証部１０４の処理例を示すフローチャートである。

まず、ルール等価性検証部１０４は、ユーザによる入出力装置１３４の操作、バッチ処理などにより処理の実行を開始する（Ｓ７００）。ルール等価性検証部１０４は、ルール比較結果情報３０１の等価性判定結果が「未判定」である変更前ルールに関する情報を取得する（Ｓ７０１）。ルール等価性検証部１０４は、ルールセット比較結果情報３０１のルールセットＩＤとルール比較結果情報３０２の変更前ルールＩＤをキーとして、前記変更前ルールに関する情報を、入力ルール保持部１２１から取得する。

次に、ルール等価性検証部１０４は、関連変更後ルール情報３０３の変更後ルールＩＤに対応する変更後ルールに関する情報（以下、「関連変更後ルールセット」という。）を取得する（Ｓ７０２）。取得する変更後ルールは、Ｓ７０１で取得した変更前ルールに関するもの全ての変更後ルールであり、関連変更後ルールセットには、１以上の変更後ルールが含まれ、上記関連変更後ルールが複数存在する場合には、そのすべてが含まれる。

次に、ルール等価性検証部１０４は、前記関連変更後ルールセットの各々の変更後ルールについて、前記変更前ルールの結果部と前記変更後ルールの結果部との論理積の充足可能性を判定する（Ｓ７０３）。

次に、ルール等価性検証部１０４は、Ｓ７０３の充足可能性判定結果に基づき、前記変更前ルールと前記変更後ルールの整合性の判定結果を関連変更後ルール情報３０３に記憶する（Ｓ７０４）。比較結果保持部１２２は、Ｓ７０３の充足可能性判定の結果、充足可能な場合、関連変更後ルール情報３０３の整合性判定結果に「整合」を設定し、充足不能な場合、「不整合」を設定する。

次に、ルール等価性検証部１０４は、前記変更前ルールの条件部と、前記関連変更後ルールセットの各々の変更後ルールの条件部の論理和（以下、「変更後ルールセット条件部」という。）との包含関係を判定する（Ｓ７０５）。例えば、変更前ルールの条件部をＣ１、変更後ルールセットの各々の変更後ルールの条件部をＤ１、Ｄ２、Ｄ３とすると、「¬（Ｃ１→（Ｄ１∨Ｄ２∨Ｄ３））」（式７０５ａ）と「¬（（Ｄ１∨Ｄ２∨Ｄ３）→Ｃ１）」（式７０５ｂ）のそれぞれの充足可能性を判定することで、包含関係を判定する。式７０５ａが充足不能な場合、変更前ルールの条件部は、変更後ルールセット条件部の部分集合である。また、式７０５ｂが充足不能な場合、変更後ルールセット条件部は変更前ルールの条件部の部分集合である。

次に、ルール等価性検証部１０４は、Ｓ７０３およびＳ７０５の判定結果に基づき、前記変更前ルールと前記関連変更後ルールセットの等価性と完全性を判定し、その結果をルール比較結果情報３０２に記憶する（Ｓ７０６）。変更前ルールの条件部が変更後ルールセット条件部の部分集合である場合、ルール等価性検証部１０４は、ルール比較結果情報３０２の完全性判定結果に「漏れなし」を設定し、それ以外の場合、「漏れあり」を設定する。Ｓ７０３において、変更前ルールの結果部と変更後ルールの結果部の論理積の全てが充足可能であり、かつ、変更前ルールの条件部が変更後ルールセット条件部の部分集合であり、かつ、変更後ルールセット条件部が変更前ルールの条件部の部分集合である場合、ルール等価性検証部１０４は、ルール比較結果情報３０２の等価性判定結果に「完全等価」を設定する。Ｓ７０３において、変更前ルールの結果部と変更後ルールの結果部の論理積の全てが充足可能であり、かつ、変更前ルールの条件部が変更後ルールセット条件部の部分集合である場合、ルール等価性検証部１０４は、ルール比較結果情報３０２の等価性判定結果に「等価」を設定する。Ｓ７０３において、変更前ルールの結果部と変更後ルールの結果部の論理積の全てが充足可能であり、かつ、変更後ルールセット条件部が変更前ルールの条件部の部分集合である場合、ルール等価性検証部１０４は、ルール比較結果情報３０２の等価性判定結果に「部分等価」を設定する。Ｓ７０３において、変更前ルールの結果部と変更後ルールの結果部の論理積の一部（全ての場合を除く）が充足可能である場合、ルール等価性検証部１０４は、ルール比較結果情報３０２の等価性判定結果に「部分等価」を設定する。Ｓ７０３において、変更前ルールの結果部と変更後ルールの結果部の論理積の全てが充足不能である場合、ルール等価性検証部１０４は、ルール比較結果情報３０２の等価性判定結果に「非等価」を設定する。

次に、ルール等価性検証部１０４は、ルール比較結果情報３０２の等価性判定結果が「未判定」である未処理の変更前ルールがあるか否かを判定する（Ｓ７０７）。未処理の変更前ルールがある場合、ルール等価性検証部１０４は、Ｓ７０２に進み、ない場合、Ｓ７０４に進む。

次に、ルール等価性検証部１０４は、全てのルール比較結果情報３０２の等価性判定結果に基づき、変更後ルールセットと変更前ルールセットの等価性を判定し、その結果をルールセット比較結果情報３０１に記憶する（Ｓ７０８）。ルール比較結果情報３０２の等価性判定結果の全てが「完全等価」または「等価」のいずれかの場合、ルール等価性検証部１０４は、ルールセット比較結果情報３０１の等価性判定結果に「等価」を設定し、それ以外の場合、「非等価」を設定する。以上の処理の後、ルール等価性検証部１０４は、処理を終了する（Ｓ７０９）。

続いて、図８を参照して、本発明の実施形態に係るルール補正部１０５の処理について説明する。図８は、本実施形態に係るルール補正部１０５の処理例を示すフローチャートである。

まず、ルール補正部１０５は、本実施形態では、ユーザがルール編集画面５００の変更後ルール一覧５１１のルールを選択後、補正案表示ボタン５２３を押下することにより処理の実行を開始する（Ｓ８００）。その他、補正対象のルールを指定するなどして、バッチ処理などにより処理を開始してもよい。

次に、ルール補正部１０５は、変更後ルールセットが検証済みであるか否かを判定する（Ｓ８０１）。検証済みの場合、Ｓ８０２に進み、そうでない場合、Ｓ８１０に進む。検証済みであるか否かは、ルールセット情報２０１の整合性判定結果、ルールセット比較結果情報３０１の等価性判定結果を参照することで判定できる。

次に、ルール補正部１０５は、ルール編集モードが「変更内容優先」であるか否かを判定する（Ｓ８０２）。変更内容優先である場合、Ｓ８０３に進み、そうでない場合、Ｓ８０６に進む。

次に、Ｓ８０２において、ルール編集モードが「変更内容優先」である場合の処理について説明する。ルール補正部１０５は、ユーザがルール編集画面５００の変更後ルール一覧５１１から選択したルール（以下、「ユーザ選択ルール」という。）が、変更前ルールから変更が加えられているか否かを判定する（Ｓ８０３）。変更が加えられていない場合、Ｓ８０４に進み、そうでない場合、Ｓ８１０に進む。ユーザ選択ルールに変更が加えられているか否かは、ルール情報２０２の編集ラベルを参照することで判定する。

次に、ルール補正部１０５は、前記ユーザ選択ルールが、追加または変更されたルールと不整合であるか否かを判定する（Ｓ８０４）。不整合である場合、Ｓ８０５に進み、そうでない場合、Ｓ８１０に進む。ルール補正部１０５は、不整合ルール情報２０４のルールＩＤに対応するルール情報２０２の編集ラベルが「追加」または「変更」であるか否かを参照することで、前記ユーザ選択ルールが、追加または変更されたルールと不整合であるか否かを判定する。

次に、ルール補正部１０５は、変更ルール優先補正処理を実行する（Ｓ８０５）。変更ルール優先補正処理については、図９を参照して、その詳細を後述する。

次に、Ｓ８０２において、ルール編集モードが「変更内容優先」でない場合の処理について説明する。ルール補正部１０５は、前記ユーザ選択ルールが変更前ルールと不整合であるか否かを判定する（Ｓ８０６）。不整合である場合、Ｓ８０７に進み、そうでない場合、Ｓ８１０に進む。ルール補正部１０５は、関連変更後ルール情報３０３について、変更後ルールＩＤがユーザ選択ルールのルールＩＤと一致し、かつ、整合性判定結果が「不整合」である関連変更後ルール情報３０３が存在する場合、前記ユーザ選択ルールが変更前ルールと不整合であると判定する。

次に、ルール補正部１０５は、前記ユーザ選択ルールと対応する変更前ルールが等価性維持ルールであるか否かを判定する（Ｓ８０７）。等価性維持ルールである場合、Ｓ８０８に進み、そうでない場合、Ｓ８１０に進む。ルール補正部１０５は、関連変更後ルール情報３０３について、変更後ルールＩＤがユーザ選択ルールのルールＩＤと一致し、かつ、整合性判定結果が「不整合」である関連変更後ルール情報３０３を持つルール比較結果情報３０２の等価性維持フラグが「ＴＲＵＥ」である場合、前記ユーザ選択ルールと対応する変更前ルールが等価性維持ルールであると判定する。

次に、ルール補正部１０５は、等価性維持ルール優先補正処理を実行する（Ｓ８０８）。等価性維持ルール優先補正処理については、図１０を参照して、その詳細を後述する。

次に、ルール補正部１０５は、補正したルール（以下、「補正ルール」という。）を出力し（Ｓ８０９）、処理を終了する（Ｓ８１０）。ルール補正部は、画面やファイルに補正ルールを出力する。出力する情報には、補正対象である変更後ルールのルールＩＤ、補正前の条件部論理式および結果部論理式、補正後の条件部論理式および結果部論理式などを含む。

なお、本実施形態では、ユーザが選択した１つのルールの補正ルールを出力するようにしているが、Ｓ８０３およびＳ８０４、または、Ｓ８０６およびＳ８０７を満たす全てのルールについて、一括して補正ルールを出力するようにしてもよい。

続いて、図９を参照して、本発明の実施形態に係るルール補正部１０５の変更ルール優先補正処理について説明する。図９は、本発明の実施形態に係るルール補正部１０５の変更ルール優先補正処理例を示すフローチャートである。

まず、ルール補正部１０５は、Ｓ８０５において変更ルール優先補正処理をサブルーチンとして呼び出すなどして、処理を開始する（Ｓ９００）。ルール補正部１０５は、ユーザ選択ルールと不整合となる変更後ルールのうち、編集ラベルが「追加」または「変更」である変更後ルール（以下、「変更ルール」という。）を取得する（Ｓ９０１）。

次に、ルール補正部１０５は、前記ユーザ選択ルールの条件部と、前記変更ルールの条件部の否定と、を論理積で結合した論理式（以下、「補正ルール条件部」という。）を生成する（Ｓ９０２）。例えば、ユーザ選択ルールの条件部をＣ１、変更ルールの条件部をＣ２とＣ３とする（変更ルールが２つある場合である）。この場合、補正ルール条件部は、「Ｃ１∧¬Ｃ２∧¬Ｃ３」となる。

次に、ルール補正部１０５は、前記補正ルール条件部の充足可能性を判定する（Ｓ９０３）。

次に、ルール補正部１０５は、補正ルールを生成し（Ｓ９０４）、処理を終了する（Ｓ９０５）。ルール補正部１０５は、前記補正ルール条件部が充足可能である場合、ユーザ選択ルールの条件部を補正ルール条件部に置き換えたものを補正ルールとする。この場合、補正ルール条件部については、命題論理におけるド・モルガンの法則、分配律などを適用し、論理式を展開し、簡略化してもよい。また、ルール補正部１０５は、前記補正ルール条件部が充足不能である場合、ユーザ選択ルールは不要と判断し、補正ルールを生成しない。

なお、補正ルールを生成するのではなく、不整合が発生する入力値の組合せを生成するようにしてもよい。例えば、ＳＭＴソルバを活用して、ユーザ選択ルールの条件部と変更ルールの論理積の充足可能性を判定し、充足可能となるモデルを取得する。前記モデルが、不整合が発生する入力値の組合せとなる。

続いて、図１０を参照して、本発明の実施形態に係るルール補正部１０５の等価性維持ルール優先補正処理について説明する。図１０は、本発明の実施形態に係るルール補正部１０５の等価性維持ルール優先補正処理例を示すフローチャートである。

まず、ルール補正部１０５は、Ｓ８０８において等価性維持ルール優先補正処理をサブルーチンとして呼び出すなどして、処理を開始する（Ｓ１０００）。ルール補正部１０５は、ユーザ選択ルールと不整合となる等価性維持ルール（以下、「不整合等価性維持ルール」という。）を取得する（Ｓ１００１）。

次に、ルール補正部１０５は、不整合等価性維持ルールの結果部論理式の項のうち、左辺式にユーザ選択ルールの結果部論理式の左辺式の出力項目（以下、「ユーザ選択ルール出力項目」という。）を含む項（以下、「不整合候補結果項」という。）を取得する（Ｓ１００２）。

次に、ルール補正部１０５は、同一の不整合候補結果項を持つ不整合等価性維持ルールの条件部を、論理和で結合した論理式（以下、「同一項条件部論理式」という。）を生成する（Ｓ１００３）。ルール補正部１０５は、生成した同一項条件部論理式と不整合候補結果項とのペアをメモリ１３２上で管理する。不整合候補結果項の数と同じ数の同一項条件部論理式が生成される。

次に、ルール補正部１０５は、不整合候補結果項の組合せ（以下、「補正ルール結果項組合せ」という。）を１つ生成する（Ｓ１００４）。ルール補正部１０５は、同じユーザ選択ルール出力項目を持つ不整合候補結果項が含まれないように、補正ルール結果項組合せを生成する。例えば、ユーザ選択ルール出力項目がＯＵＴ１とＯＵＴ２、不整合候補結果項が「ＯＵＴ１＝１」「ＯＵＴ１＝２」「ＯＵＴ２＝１」である場合、ルール補正部１０５は、補正ルール結果項組合せとして、｛（空の組合せ）｝｛ＯＵＴ１＝１｝｛ＯＵＴ１＝２｝｛ＯＵＴ２＝１｝｛ＯＵＴ１＝１、ＯＵＴ２＝１｝｛ＯＵＴ１＝２、ＯＵＴ２＝１｝のいずれかを生成する。｛ＯＵＴ１＝１、ＯＵＴ１＝２｝は、同じユーザ選択ルール出力項目を持つので、生成されない。

次に、ルール補正部１０５は、補正ルール結果項組合せに基づき、補正ルールの条件部となる論理式（以下、「補正ルール条件部」という。）を生成する（Ｓ１００５）。補正ルール条件部は、補正ルール結果項組合せに含まれる不整合候補結果項とペアになる同一項条件部論理式と、補正ルール結果項組合せに含まれない不整合候補結果項とペアになる同一項条件部論理式の否定と、ユーザ選択ルールの条件部とを論理積で結合した論理式である。例えば、不整合候補結果項が｛Ｒ１、Ｒ２、Ｒ３、Ｒ４｝であり、それぞれに対応する同一項条件部論理式が｛Ｃ１、Ｃ２、Ｃ３、Ｃ４｝であり、補正ルール結果項組合せが｛Ｒ１、Ｒ２｝であり、ユーザ選択ルールの条件部がＣＵである場合を考える。この場合、補正ルール条件部は、「Ｃ１∧Ｃ２∧¬Ｃ３∧¬Ｃ４∧ＣＵ」となる。

次に、ルール補正部１０５は、前記補正ルール条件部の充足可能性を判定する（Ｓ１００６）。充足可能な場合、Ｓ１００７に進み、そうでない場合、Ｓ１００８に進む。

次に、ルール補正部１０５は、補正ルールを生成する（Ｓ１００７）。補正ルールの条件部は、前記補正ルール条件部である。この場合、補正ルール条件部については、命題論理におけるド・モルガンの法則、分配律などを適用し、論理式を展開し、簡略化してもよい。また、補正ルールの結果部は、前記補正ルール結果項組合せに含まれる項を、ユーザ選択ルールの結果部論理式と同じ出力項目を持つ項と置き換えた論理式である。なお、ユーザ選択ルールの結果部論理式の項のうち、前記補正ルール結果項組合せに含まれない出力項目を持つ項については、置き換えない。

次に、ルール補正部１０５は、未処理の補正ルール結果項組合せがあるか否かを判定する（Ｓ１００８）。未処理の補正ルール結果項組合せがある場合、Ｓ１００４に進み、ない場合、Ｓ１００９に進み、処理を終了する（Ｓ１００９）。

なお、補正ルールを生成するのではなく、不整合が発生する入力値の組合せを生成するようにしてもよい。例えば、ＳＭＴソルバを活用して、ユーザ選択ルールの条件部と不整合等価性維持ルールの論理積の充足可能性を判定し、充足可能となるモデルを取得する。前記モデルが、不整合が発生する入力値の組合せとなる。

例えば、ルール編集画面５００におけるＩＤ５１２がＡ４の変更後ルールの補正案としては、「Ａｇｅ＝６０ ＡＮＤ Ｒａｎｋ＝Ｇｏｌｄ ＴＨＥＮ Ｄｉｓｃｏｕｎｔ＝２０」「Ａｇｅ＜６０ ＡＮＤ Ｒａｎｋ＝Ｇｏｌｄ ＴＨＥＮ Ｄｉｓｃｏｕｎｔ＝１０」の２つの補正ルールが出力される。

続いて、図１１を参照して、本実施形態に係るテストケース編集画面の例について説明する。テストケース編集画面１１００は、ＩＤ１１１１、入力値条件１１１２、期待値条件１１１３、ラベル１１１４、およびテスト結果１１１５といった項目を持つテストケース一覧１１１０と、追加ボタン１１２１、削除ボタン１１２２、およびテスト実行ボタン１１２３といったボタンを有する。ＩＤ１１１１は、テストケースの識別子である。入力値条件１１１２は、テストケースの入力値の条件であり、入力項目の値（例、Ａｇｅ＝３５）、入力項目の値の条件（例、Ａｇｅ＜３５）などを指定する。期待値条件１１１３は、テストケースの期待値の条件であり、出力項目の値（Ｄｉｓｃｏｕｎｔ＝１０）、出力項目の値の条件（例、Ｄｉｓｃｏｕｎｔ＜２０）などを指定する。ラベル１１１４は、テストケースの種類を示す情報であり、本実施形態では、「必須」「推奨」「一般」のいずれかの値である。テスト結果１１１５は、テストの実行結果であり、ユーザがテスト実行ボタン１１２３を押下することで、テスト実行結果出力部１１４が値を設定する。追加ボタン１１２１は、新規にテストケースを追加するためボタンであり、ユーザが追加ボタン１１２１を押下することで、テストケース編集部１１１がテストケース一覧１１１０に空のテストケースを追加する。ユーザは、追加された空のテストケースもしくは既存のテストケースを選択することで、テストケースの入力値条件１１１２、期待値条件１１１３、およびラベル１１１４を編集できる。削除ボタン１１２２は、テストケース一覧１１１０のテストケースを削除するためのボタンであり、ユーザがテストケース一覧１１１０のテストケースを選択し、削除ボタン１１２２を押下することで、テストケース編集部１１１が、ユーザが選択したテストケースを削除する。テスト実行ボタン１１２３は、テストケース一覧のテストケースのテストを実行するためのボタンであり、ユーザがテスト実行ボタン１１２３を押下することで、ルールテスト実行部１１２がテストケース一覧のすべてのテストケースのテストを実行する。なお、ユーザが選択したテストケースのみを実行するようにしてもよい。

次に、ラベル１１１４の各選択子が選択された場合のルールテスト実行部１１２の振る舞いを説明する。テストに成功した場合は、ラベル１１１４に設定された値に係らず、ルールテスト実行部１１２は、テスト結果情報４０３のテスト結果に「ＯＫ」を設定する。次に、テストに失敗した場合のルールテスト実行部１１２の振る舞いについて説明する。

ラベル１１１４として「必須」が選択された場合、ルールテスト実行部１１２は、テストに失敗した場合、テスト結果情報４０３のテスト結果に「ＮＧ」を設定する。

ラベル１１１４として「推奨」が選択された場合、ルールテスト実行部１１２は、テストに失敗した場合、テスト結果情報４０３のテスト結果に「ＷＡＲＮ」を設定する。

ラベル１１１４として「一般」が選択された場合、ルールテスト実行部１１２は、テストに失敗した場合、実行ルール情報４０４のルールＩＤに対応するルールの変更前ルールが等価性維持ルールである場合、「ＮＧ」を設定し、そうでない場合、「ＷＡＲＮ」を設定する。前記変更前ルールが等価性維持ルールでない場合は、テストケースが無効である可能性があるため「ＷＡＲＮ」を設定する。

ユーザは、ルールの変更に伴い、見直す必要があるテストケースがどれであるかを、テスト結果が「ＷＡＮＲ」であるテストケースに着目して検討でき、テストケースの見直し作業を効率化できる。

続いて、図１２を参照して、本発明の実施形態に係るルールテスト実行部１１２の処理について説明する。図１２は、本発明の実施形態に係るルールテスト実行部１１２の処理例を示すフローチャートである。

まず、ルールテスト実行部１１２は、ユーザによる入出力装置１３４の操作、バッチ処理などにより処理の実行を開始する（Ｓ１２００）。ルールテスト実行部１１２は、最新のルールセットを取得する（Ｓ１２０１）。ルールテスト実行部１１２は、入力ルール保持部１２１のルールセット情報２０１を参照することで、最新のルールセットを取得できる。

次に、ルールテスト実行部１１２は、等価性維持ルールを特定する（Ｓ１２０２）。ルールテスト実行部１１２は、入力ルール保持部１２１のルールセット情報２０１のルール編集モード、および、編集モード適用ルール情報２０３を参照することで、等価性維持ルールを特定する。ルールテスト実行部１１２は、等価性維持ルールのルールＩＤをメモリ１３２上で保持する。

次に、ルールテスト実行部１１２は、テストケースを１つ取得する（Ｓ１２０３）。ルールテスト実行部１１２は、テストケース保持部１２３のテストケース情報４０２を参照し、テストケースを取得する。

次に、ルールテスト実行部１１２は、テストケースの入力値条件を満たすルール（以下、「テスト対象ルール」という。）を取得する（Ｓ１２０４）。ルールテスト実行部１１２は、テストケースの入力値条件と各ルールの条件部論理式の論理積の充足可能性を判定し、充足可能なものをテスト対象ルールとして取得する。

次に、ルールテスト実行部１１２は、テスト対象ルールの数が０より大きいか否かを判定する（Ｓ１２０５）。０より大きい場合、Ｓ１２０６に進み、そうでない場合、テスト結果情報４０３のテスト結果に「ＮＧ」を設定し（Ｓ１２１１）、Ｓ１２１４に進む。

次に、ルールテスト実行部１１２は、テスト対象ルールの結果部とテストケースの期待値条件の論理積が充足可能であるか否かを判定する（Ｓ１２０６）。充足不能である場合、Ｓ１２０７に進み、充足可能な場合、テスト結果情報４０３のテスト結果に「ＯＫ」を設定し（Ｓ１２１３）、Ｓ１２１４に進む。なお、テスト対象ルールが複数ある場合は、すべてのテスト対象ルールの結果部の論理積と、テストケースの期待値条件の論理積の充足可能性を判定する。

次に、ルールテスト実行部１１２は、テストケースラベルが「推奨」であるか否かを判定する（Ｓ１２０７）。「推奨」である場合、テスト結果情報４０３のテスト結果に「ＷＡＲＮ」を設定し（Ｓ１２１２）、Ｓ１２１４に進み、そうでない場合、Ｓ１２０８に進む。

次に、ルールテスト実行部１１２は、テストケースラベルが「一般」であるか否かを判定する（Ｓ１２０８）。「一般」である場合、Ｓ１２０９に進み、そうえない場合、テスト結果情報４０３のテスト結果に「ＮＧ」を設定し（Ｓ１２１０）、Ｓ１２１４に進む。

次に、ルールテスト実行部１１２は、等価性維持ルールに対するテスト結果があるか否かを判定する（Ｓ１２０９）。等価性維持ルールに対するテスト結果がある場合、Ｓ１２１０に進み、ない場合、テスト結果情報４０３のテスト結果に「ＮＧ」を設定し（Ｓ１２１１）、Ｓ１２１４に進む。ルールテスト実行部１１２は、前記テストケースに係るテスト結果情報４０３の対象ルールセットＩＤと、前記ルールセットに係るルールセット情報２０１の変更前ルールセットＩＤが一致するか否かを判定し、一致する場合、実行ルール情報４０４のルールＩＤのうち、等価性維持ルールのルールＩＤと一致するものがあるか否かを判定する。一致する実行ルール情報４０４がある場合、等価性維持ルールに対するテスト結果があると判定する。

次に、ルールテスト実行部１１２は、等価性維持ルールに対するテスト結果が「ＯＫ」であるか否かを判定する（Ｓ１２１０）。「ＯＫ」である場合、テスト結果情報４０３のテスト結果に「ＮＧ」を設定し（Ｓ１２１１）、そうでない場合、テスト結果に「ＷＡＲＮ」を設定し（Ｓ１２１２）、Ｓ１２１４に進む。

次に、ルールテスト実行部１１２は、未処理のテストケースがあるか否かを判定し、ある場合は、Ｓ１２０３に進み、ない場合は、処理を終了する（Ｓ１２１５）。

なお、本実施形態では、テスト対象ルールが２以上ある場合でも、テスト結果を１つのみを出力するようにしているが、テスト対象ルール毎にテストを実行し、テスト結果を出力してもよい。この場合、Ｓ１２０６からＳ１２１３までの処理が、テスト対象ルールの数だけ繰り返し処理を実行すればよい。また、この場合、テストケース保持部１２３の実行ルール情報４０４にテスト結果の属性を追加することで、テスト対象ルール毎のテスト結果を管理できる。

続いて、図１３を参照して、本発明の実施形態に係るテストケース補正部１１３の処理について説明する。図１３は、本発明の実施形態に係るテストケース補正部１１３の処理例を示すフローチャートである。

まず、テストケース補正部１１３は、ユーザによる入出力装置１３４の操作、バッチ処理などにより処理の実行を開始する（Ｓ１３００）。テストケース補正部１１３は、テスト実行済みであるか否かを判定する（Ｓ１３０１）。実行済みである場合、Ｓ１３０２に進み、そうでない場合、エラー情報を出力し、処理を終了する（Ｓ１３０８）。

次に、テストケース補正部１１３は、テスト結果が「ＷＡＲＮ」であるか否かを判定する（Ｓ１３０２）。「ＷＡＲＮ」である場合、Ｓ１３０３に進み、そうでない場合、エラー情報を出力し、処理を終了する（Ｓ１３０８）。

次に、テストケース補正部１１３は、テストケースラベルが「一般」であるか否かを判定する（Ｓ１３０３）。「一般」である場合、Ｓ１３０４に進み、そうでない場合、エラー情報を出力し、処理を終了する（Ｓ１３０８）。

次に、テストケース補正部１１３は、テスト時に実行したルール（以下、「実行ルール」という。）を取得する（Ｓ１３０４）。テストケース補正部１１３は、実行ルール情報４０４のルールＩＤを参照することで、実行ルールを特定する。

次に、テストケース補正部１１３は、実行ルールの結果部を論理積で結合した論理式（以下、「補正期待値条件」という。）を生成する（Ｓ１３０５）。テストケース補正部１１３は、実行ルールの結果部を論理積で結合する際に、同一の項がある場合、１つのみを残し、他の同一である項を削除する。

次に、テストケース補正部１１３は、補正期待値条件が充足可能であるか否かを判定する（Ｓ１３０６）。充足可能である場合、Ｓ１３０７に進み、そうでない場合、エラー情報を出力し、処理を終了する（Ｓ１３０８）。

次に、テストケース補正部１１３は、テストケースの補正案である補正テストケースを生成し（Ｓ１３０７）、処理を終了する（Ｓ１３０８）。補正テストケースは、入力値条件には変更を加えずに、期待値条件を補正期待値条件に置き換えたものである。

以上説明した本発明の実施形態によれば、変更前と変更後のルールセットにおいて、入力と出力の関係が維持されるべき部分が維持されていることの確認を容易に実行できるようにするルール管理支援装置等を提供することができる。

１００ ルール管理支援装置
１０１ 入力ルール編集部
１０２ ルール整合性検証部
１０３ 対応関係判定部
１０４ ルール等価性検証部
１０５ ルール補正部
１０６ 検証結果出力部
１１１ テストケース編集部
１１２ ルールテスト実行部
１１３ テストケース補正部
１１４ テスト実行結果出力部
１２１ 入力ルール保持部
１２２ 比較結果保持部
１２３ テストケース保持部
１３１ プロセッサ
１３２ メモリ
１３３ 補助記憶装置
１３４ 入出力装置
５００ ルール編集画面
１１００ テストケース編集画面

Claims (7)

1. ソフトウェア仕様の開発におけるルールの管理を支援するための装置であって、
   前記ルールが成立するための条件を格納する条件部と前記条件が成立した場合の結果を格納する結果部とを含む１以上の入力ルールを含む入力ルールセットを受け付けるための入力ルール編集部と、前記入力ルールセットと変更前のルールセットである変更前ルールセットとを比較検証するルール等価性検証部と
   を備え、
   前記入力ルール編集部は、入力と出力の関係を変更後においても維持する変更前の入力ルールである等価性維持ルールを指定する等価性維持ルールオプション指定部を備え、
   前記ルール等価性検証部は、前記等価性維持ルールオプション指定部を参照して、前記等価性維持ルールの条件部を満たす入力に対して、前記入力ルールセットが前記等価性維持ルールと同一の出力を返すか否かを判定した結果を出力する、
   ことを特徴とするルール管理支援装置。
2. 請求項１に記載のルール管理支援装置であって、
   前記ルール等価性検証部は、前記入力ルールの条件部と前記変更前ルールセットに含まれる変更前ルールの条件部との論理積の充足可能性を判定し、充足可能と判定された前記入力ルールについて、前記変更前ルールの結果部の出力項目を含む前記入力ルールを特定し、特定した前記入力ルールの結果部と前記変更前ルールの結果部との論理積の充足可能性を判定し、前記変更前ルールが等価性維持ルールであるか否かを判定する、
   ことを特徴とするルール管理支援装置。
3. 請求項１に記載のルール管理支援装置であって、
   前記ルール等価性検証部により前記等価性維持ルールの条件部を満たす入力に対して、前記入力ルールセットが前記等価性維持ルールと同一の出力を返すか否かを判定した結果が非等価となる前記入力ルールの補正案を出力するルール補正部、
   を備えることを特徴とするルール管理支援装置。
4. 請求項１に記載のルール管理支援装置であって、
   前記入力ルールセットをテストするためのテストケースを受け付けるテストケース編集部と、前記テストケースに基づき前記入力ルールセットのテストを実行するルールテスト実行部と、前記テストケースの変更履歴とテストの実行結果を記憶するテストケース保持部と
   を備え、
   前記テストケースは、前記入力ルールセットへの入力の条件である入力値条件と、前記入力値条件を満たす場合の出力が満たすべき条件である期待値条件とを含み、
   前記テストの実行結果は、テスト対象の前記ルールセットを識別する実行ルールセットＩＤとテスト実行時に実行した前記入力ルールを識別する実行ルールＩＤとを含み、
   前記ルールテスト実行部は、前記入力値条件を満たす前記入力ルールを特定し、前記入力ルールが前記期待値条件を満たさない場合であって、前記テストケースの過去の前記テストの実行結果を参照し、前記実行ルールＩＤが前記等価性維持ルールに関するものであり、かつ、前記過去のテストの実行結果が成功していない場合、または前記実行ルールＩＤが前記等価性維持ルールに関するものでない場合、警告を出力する、
   ことを特徴とするルール管理支援装置。
5. 請求項４に記載のルール管理支援装置であって、
   前記テストケースは、常に満たす必要があることを示す必須オプション、満たすことが推奨されることを示す推奨オプション、およびルールの変更によりテストが失敗してもよいことを示す一般オプションのうち１以上のオプションについて、適用する前記オプションを指定するためのテストケースオプション指定部を備え、
   前記ルールテスト実行部は、前記一般オプションが指定されたテストケースに対して、請求項４に記載の処理を実行する、
   ことを特徴とするルール管理支援装置。
6. 請求項４に記載のルール管理支援装置であって、
   前記ルールテスト実行部により警告が出力されたテストケースの補正案を出力するテストケース補正部を備える、
   ことを特徴とするルール管理支援装置。
7. ソフトウェア仕様の開発におけるルールの管理を支援するための方法であって、
   
   前記ルールが成立するための条件を格納する条件部と前記条件が成立した場合の結果を格納する結果部とを含む１以上の入力ルールを含む入力ルールセットを受け付けるための入力ルール編集部が、入力と出力の関係を変更後においても維持する変更前の入力ルールである等価性維持ルールを指定する等価性維持ルールオプション指定部による指定を受け付け、
   前記入力ルールセットと変更前のルールセットである変更前ルールセットとの比較検証を行うルール等価性検証部は、前記等価性維持ルールオプション指定部を参照して、前記等価性維持ルールの条件部を満たす入力に対して、前記入力ルールセットが前記等価性維持ルールと同一の出力を返すか否かを判定した結果を出力する、
   ことを特徴とするルール管理支援方法。

Images