(57)【要約】  ルール管理支援装置は、変更前と変更後のバージョンのルールセットにおいて入力と出力の関係が維持されるべき等価範囲に関する情報を受け付ける入力ルール編集部、並びに、変更前のバージョンのルールセットの論理式を含む変更前バージョン論理式、変更後のバージョンのルールセットの論理式を含む変更後バージョン論理式、等価範囲を表す等価範囲論理式、および変更前のバージョンのルールセットと変更後のバージョンのルールセットとの出力項目が等しくないことを表す論理式を論理積で結合した等価性判定式を生成し、等価性判定式の充足可能性の判定に基づき、変更前のバージョンのルールセットと変更後のバージョンのルールセットとの等価性を検証する等価性検証部を有する。
2017085824.tif 000002
【特許請求の範囲】
【請求項１】
変更前のバージョンと変更後のバージョンのルールセットにおいて入力と出力の関係が維持されるべき等価範囲に関する情報を受け付ける入力ルール編集部、並びに、
前記変更前のバージョンの前記ルールセット、前記変更後のバージョンの前記ルールセット、および前記等価範囲に関する情報に基づき、前記変更前のバージョンの前記ルールセットと前記変更後のバージョンの前記ルールセットとの等価性を検証する等価性検証部を有することを特徴とするルール管理支援装置。
【請求項２】
前記等価性検証部は、
前記変更前のバージョンの前記ルールセットの論理式を含む変更前バージョン論理式、前記変更後のバージョンの前記ルールセットの論理式を含む変更後バージョン論理式、前記等価範囲を表す等価範囲論理式、および前記変更前のバージョンの前記ルールセットと前記変更後のバージョンの前記ルールセットとの出力項目が等しくないことを表す論理式を論理積で結合した等価性判定式を生成し、前記等価性判定式の充足可能性の判定に基づき、前記変更前のバージョンの前記ルールセットと前記変更後のバージョンの前記ルールセットとの等価性を検証することを特徴とする請求項１に記載のルール管理支援装置。
【請求項３】
前記等価性検証部は、前記等価性判定式の前記充足可能性の判定の結果、充足不能のとき、前記変更前のバージョンの前記ルールセットと前記変更後のバージョンの前記ルールセットとが等価とし、充足可能のとき、前記変更前のバージョンの前記ルールセットと前記変更後のバージョンの前記ルールセットとが非等価とすることを特徴とする請求項２に記載のルール管理支援装置。
【請求項４】
前記変更前のバージョンの前記ルールセットと前記変更後のバージョンの前記ルールセットとが非等価の場合の、前記ルールセットの入力値、前記変更後のバージョンの前記ルールセットの出力値、前記変更前のバージョンの前記ルールセットの出力値、並びに、前記入力値を入力とする、前記変更前のバージョンの前記ルールセットおよび前記変更後のバージョンの前記ルールセットに含まれるルールを出力する検証結果出力部をさらに有することを特徴とする請求項３に記載のルール管理支援装置。
【請求項５】
前記変更前のバージョンの前記ルールセットの論理式および前記変更後のバージョンの前記ルールセットの論理式の各々は、前記ルールセットの入力項目として他のルールセットの出力項目を用いる依存関係にある前記他のルールセットの論理式を含むことを特徴とする請求項２に記載のルール管理支援装置。
【請求項６】
前記入力ルール編集部は、前記変更前と前記変更後のバージョンの前記ルールセットにおいて前記入力と前記出力の関係が維持されない非等価の範囲に関する情報を受け付け、
前記等価性検証部は、前記非等価の範囲を表す論理式の否定を前記等価範囲論理式とすることを特徴とする請求項２に記載のルール管理支援装置。
【請求項７】
ルール管理支援装置によるルール管理支援方法であって、前記ルール管理支援装置は、
変更前のバージョンと変更後のバージョンのルールセットにおいて入力と出力の関係が維持されるべき等価範囲に関する情報を受け付け、
前記変更前のバージョンの前記ルールセット、前記変更後のバージョンの前記ルールセット、および前記等価範囲に関する情報に基づき、前記変更前のバージョンの前記ルールセットと前記変更後のバージョンの前記ルールセットとの等価性を検証することを特徴とするルール管理支援方法。
【請求項８】
前記変更前のバージョンの前記ルールセットと前記変更後のバージョンの前記ルールセットとの等価性は、
前記変更前のバージョンの前記ルールセットの論理式を含む変更前バージョン論理式、前記変更後のバージョンの前記ルールセットの論理式を含む変更後バージョン論理式、前記等価範囲を表す等価範囲論理式、および前記変更前のバージョンの前記ルールセットと前記変更後のバージョンの前記ルールセットとの出力項目が等しくないことを表す論理式を論理積で結合した等価性判定式を生成し、生成された前記等価性判定式の充足可能性の判定に基づき、検証されることを特徴とするルール管理支援方法。
【請求項９】
前記ルール管理支援装置は、前記等価性判定式の前記充足可能性の判定の結果、充足不能のとき、前記変更前のバージョンの前記ルールセットと前記変更後のバージョンの前記ルールセットとが等価とし、充足可能のとき、前記変更前のバージョンの前記ルールセットと前記変更後のバージョンの前記ルールセットとが非等価とすることを特徴とする請求項８に記載のルール管理支援方法。
【請求項１０】
前記ルール管理支援装置は、前記変更前のバージョンの前記ルールセットと前記変更後のバージョンの前記ルールセットとが非等価の場合の、前記ルールセットの入力値、前記変更後のバージョンの前記ルールセットの出力値、前記変更前のバージョンの前記ルールセットの出力値、並びに、前記入力値を入力とする、前記変更前のバージョンの前記ルールセットおよび前記変更後のバージョンの前記ルールセットに含まれるルールを出力することを特徴とする請求項９に記載のルール管理支援方法。
【請求項１１】
前記変更前のバージョンの前記ルールセットの論理式および前記変更後のバージョンの前記ルールセットの論理式の各々は、前記ルールセットの入力項目として他のルールセットの出力項目を用いる依存関係にある前記他のルールセットの論理式を含むことを特徴とする請求項８に記載のルール管理支援方法。
【請求項１２】
前記ルール管理支援装置は、前記変更前と前記変更後のバージョンの前記ルールセットにおいて前記入力と前記出力の関係が維持されない非等価の範囲に関する情報を受け付け、
前記非等価の範囲を表す論理式の否定を前記等価範囲論理式とすることを特徴とする請求項８に記載のルール管理支援方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ルール管理支援装置およびルール管理支援方法に関する。
【背景技術】
【０００２】
流通や金融などの業務を支援するソフトウェアは、商品、サービス等の業務に関する法的な規制、業務上の規則、基準等に従って仕様が決定され設計される。【０００３】
そのようなソフトウェアでは、ＩＦ−ＴＨＥＮ形式でその仕様を整理する場合がある。ＩＦ−ＴＨＥＮ形式の仕様（以下、ＩＦ節を「条件部」、ＴＨＥＮ節を「結果部」という。）は、ビジネスルール、システムルール、チェックルールなどのように、適用するフェーズに応じて様々な呼び名がある（以下、これらを「ルール」という）。ルールは、「もし〜ならば〜である」というような自然文による記述、「ＩＦ  Ａ＝１  ＡＮＤ  Ｂ＝２  ＴＨＥＮ  Ｒ＝１」というようにコンピュータにより解釈可能な所定の規則に従った記述、条件と結果の対応関係を表形式で定義した決定表による記述などさまざまな形態で表現される。【０００４】
法改正や業務規則の変更に伴い、ソフトウェアに組み込まれているルールを変更する必要がある。このような場合、一部のルールの入力と出力の関係が変更され、他のルールは変更前と同様なことがほとんどである。ルールを分かり易くするために、ルールの入力と出力の関係を維持したまま、ルールを変更する場合もある。【０００５】
いずれの場合のルールの変更においても、ルールの入力と出力の関係が変更前と変更後とで維持されるべき部分が維持されていること（以下、「等価性」という。）を確認する必要がある。等価性を確認する方法としては、ソフトウェアに組み込まれた、変更前のルールをテストするためのテストケースを、変更後のルールに適用して確認する方法が、特許文献１で開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】ＵＳ２００９／０１１２６５４Ａ1
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１に開示されている技術により、変更後のルールに変更前のテストケースを適用して、テストを実行することで、不要な変更が加えられていないかをテストしたケースにおいて確認できる。しかし、ソフトウェア仕様の変更に伴う設計、製作不良により、テストが失敗する場合と、誤ってルールを変更したことにより、テストが失敗する場合が混在するため、失敗したテストケースを１つ１つユーザが確認する必要がある。また、特許文献１で開示されている技術は、サンプリングテストであるため、テストしたケースについては等価性を確認できるが、テストしていない範囲については等価性を確認できない。【０００８】
そこで、ユーザが指定した論理的範囲について、変更前と変更後のルールの等価性の確認を網羅的に実行できることが望まれる。
【課題を解決するための手段】
【０００９】
開示するルール管理支援装置は、変更前と変更後のバージョンのルールセットにおいて入力と出力の関係が維持されるべき等価範囲に関する情報を受け付ける入力ルール編集部、並びに、変更前のバージョンのルールセットの論理式を含む変更前バージョン論理式、変更後のバージョンのルールセットの論理式を含む変更後バージョン論理式、等価範囲を表す等価範囲論理式、および変更前のバージョンのルールセットと変更後のバージョンのルールセットとの出力項目が等しくないことを表す論理式を論理積で結合した等価性判定式を生成し、等価性判定式の充足可能性の判定に基づき、変更前のバージョンのルールセットと変更後のバージョンのルールセットとの等価性を検証する等価性検証部を有する。
【発明の効果】
【００１０】
開示するルール管理支援装置によれば、ユーザが指定した論理的範囲（等価範囲）について、変更前と変更後のルールの等価性の確認を網羅的に実行できる。
【図面の簡単な説明】
【００１１】
【図１】ルール管理支援装置の構成例である。
【図２】バージョン管理されているルールセットの例である。
【図３】入力ルール保持部のデータ構造の例である。
【図４】等価範囲保持部のデータ構造の例である。
【図５】検証結果保持部のデータ構造の例である。
【図６】ルールセットの編集画面の例である。
【図７】等価性検証部の処理フローチャートである。
【図８】検証結果の表示画面の例である。
【発明を実施するための形態】
【００１２】
図１は、ルール管理支援装置１００の構成例である。ルール管理支援装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）等のプロセッサ１３１、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）等のメモリ１３２、補助記憶装置１２０、およびキーボード、表示モニタ等の入出力装置１３３を備えたコンピュータである。
【００１３】
ルール管理支援装置１００は、入力ルール編集部１０１、整合性検証部１０２、完全性検証部１０３、等価性検証部１０４、および検証結果出力部１０５の処理部を備える。これらの処理部はコンピュータプログラムとして実現され、メモリ１３２上でプロセッサ１３１により実行される。また、ルール管理支援装置１００は、入力ルール保持部１２１、等価条件保持部１２２、および検証結果保持部１２３の保持部のデータを、補助記憶装置１２０に保持している。これらのデータは、プロセッサ１３１による処理部の実行に伴い、補助記憶装置１２０からメモリ１３２に読み出され、使用される。
【００１４】
各処理部および各保持部の説明に先立って、ルール管理支援装置が支援するルールの変更について説明する。業務を支援するソフトウェア（以下、業務を支援するソフトウェアを単に「ソフトウェア」と呼ぶ。）において、業務規則（法改正、業務規則などの種々の規則・基準を含む）を反映した仕様をＩＦ−ＴＨＥＮ形式で整理する。ＩＦ−ＴＨＥＮ形式の仕様（以下、ＩＦ節を「条件部」、ＴＨＥＮ節を「結果部」という。）には、ビジネスルール、システムルール、チェックルールなどのように、業務規則を適用するフェーズに応じて様々な呼び名がある（以下、これらを「ルール」という。）。
【００１５】
図２は、バージョン管理されているルールセットの例である。バージョン管理およびルールセットについては後述する。条件部と結果部を有するルールは、ＩＤ（識別子）が付されている。たとえば、条件部が「Ａｍｏｕｎｔ＜２００００」であり、結果部が「Ｒａｎｋ＝Ｒｅｇｕｌａｒ」のルールは、そのＩＤとしてＲ１が付され、「ＩＦ  Ａｍｏｕｎｔ＜２００００  ＴＨＥＮ  Ｒａｎｋ＝Ｒｅｇｕｌａｒ」を意味する。
【００１６】
条件部の変数を入力項目と呼び、結果部の変数を出力項目と呼ぶ。ＩＤがＲ１（ランク判定のＲ１）のルールでは、「Ａｍｏｕｎｔ」が入力項目であり、「Ｒａｎｋ」が出力項目である。入力項目の値を入力値、出力項目の値を出力値と呼ぶ。Ｒ１のルールでは、「Ａｍｏｕｎｔ」として入力される値が入力値であり、「Ｒａｎｋ」として出力される「Ｒｅｇｕｌａｒ」が出力値である。この例から明らかなように、入力値および出力値は必ずしも数値ではなく、文字列などの場合もある。
【００１７】
このようなルールの集まりを「ルールセット」と呼ぶ。図２の例では、ランク判定（ＲＳ１）と割引率判定（ＲＳ２）の２つのルールセットを表している。ルールセットは複数のルールの集まりであるが、各ルールの出力項目は同一であり、入力値は、ルールセットに含まれるルールのいずれか一つのルールの条件部を真とする（成立させる）。ランク判定（ＲＳ１）のルールセットにおいては、各ルールの出力項目は同一の「Ｒａｎｋ」である。入力項目「Ａｍｏｕｎｔ」の入力値は、Ｒ１〜Ｒ３のルールのいずれか一つの条件部を真とする。図２の例では、ランク判定（ＲＳ１）のルールセットの出力項目は、割引率判定（ＲＳ２）のルールセットの入力項目の一つとして用いられる。割引率判定（ＲＳ２）のルールセットの入力項目から明らかなように、ルールセットおよびルールの入力項目は一つとは限らず、複数の場合、個々の入力項目の条件式は、演算子で結合される。割引率判定（ＲＳ２）のルールセットは、ＡＮＤの論理演算子を用いている。
【００１８】
なお、ルールセットの各ルールの出力項目は同一であるとしたが、複数種の出力項目に共通する（共用できる）ルールがある場合、一つのルールセットに複数種の出力項目を持たせることも可能である。しかし、ルールセットに複数種の出力項目があると、業務規則の変更に応じて、そのルールセットのルールの変更が複雑になる。そこで、ルールセットの意味の分かり易さ、ルールの変更の容易さの観点から、複数種の出力項目に対しては、それぞれ一つの出力項目を有する複数のルールセットを設けることが望ましい。
【００１９】
これらのルールセット（一つの場合もある）は、業務規則の変更に応じて、ソフトウェア仕様として、バージョン番号を付してバージョン管理される。図２は、バージョン番号Ｖ１のルールセットを、業務規則の変更に伴いバージョン番号Ｖ２のルールセットに変更する例を表している。図２に示すルールセットの変更点は、バージョン番号Ｖ２内の下線で示している箇所であり、ランク判定（ＲＳ１）のルールＲ３の入力項目「Ａｍｏｕｎｔ」に上限が設けられ、ランク判定（ＲＳ１）の出力値に「Ｐｌａｔｉｎｕｍ」を出力するルールＲ４が追加され、割引率判定（ＲＳ２）のルールセットの入力項目として、「Ｐｌａｔｉｎｕｍ」を用いるルールが追加または変更され、割引率判定（ＲＳ２）のルールＲ１の条件部が変更されている。
【００２０】
業務規則の変更に伴う新しいバージョンのルールセットを持つソフトウェア仕様に基づくソフトウェアは、変更された業務規則の適用日より前に検証されている必要がある。したがって、業務規則の変更内容が明確になる日から適用日までの日数が少ない場合もあり、このような場合でも新しいバージョンのルールセットの確実な検証が求められる。
【００２１】
ルールセットの検証は、図1の処理部の名称から明らかなように、整合性、完全性、および等価性の検証である。図１に示すルール管理支援装置の各処理部の説明として、これらの検証の概要を含めて説明する。
【００２２】
入力ルール編集部１０１は、ユーザが入出力装置１３３を用いて入力する、追加、変更、または削除する入力項目、出力項目、および条件部や結果部などのルールに関する情報を入力ルール保持部１２１に登録する。また、入力ルール編集部１０１は、変更前と変更後のルールセットにおいて、入力と出力の関係（入力項目の値である入力値と出力項目の値である出力値との関係）が維持されるべき範囲（以下、「等価範囲」）に関する情報を受け付け、等価範囲保持部１２２に登録する。等価範囲は等価性が検証されるべき範囲である。詳細は後述する。
【００２３】
整合性検証部１０２は、入力ルール保持部１２１に登録されているルール間に不整合があるか否か（整合性）を検証し、検証結果を検証結果保持部１２３に登録する。ルール間の不整合とは、ある入力値（入力項目の値）が複数のルールの条件部を満たす（条件部が真）が、その複数のルールの結果部を同時に満たす出力値（出力項目の値）が存在しない場合である。例えば、「ＩＦ  Ａ＝１  ＴＨＥＮ  Ｒ＝１」と「ＩＦ  Ｂ＝１  ＴＨＥＮ  Ｒ＝２」という２つのルールがあったとする。２つのルールの条件部は、「Ａ＝１」および「Ｂ＝１」という入力値（入力値の組）を満たすが、結果部が一方は「Ｒ＝１」であり、他方は「Ｒ＝２」であるので、これら２つルールを満たすＲの値が存在しないため、これら２つのルールは不整合となる。ルール間の不整合の判定方法については、例えば、特開２０１２−１９０２０３号公報に充足可能性判定を用いた方法が開示されている。
【００２４】
完全性検証部１０３は、入力ルール保持部１２２に登録されているルールセットが完全であるか否か（完全性）を検証し、検証結果を検証結果保持部１２３に登録する。ルールセットが完全とは、ルールセットの入力項目が取り得るすべての入力値に対して、ルールセット内のいずれか一つのルールの条件部が真になることである。例えば、ルールセット内に「ＩＦ  Ａ＜１  ＴＨＥＮ  Ｒ＝１」と「ＩＦ  Ａ＞１  ＴＨＥＮ  Ｒ＝２」という２つのルールがあるとする。入力がＡ＝１の場合、いずれのルールの条件部も真とならないため、当該ルールセットは完全ではない。
【００２５】
ルールセットが完全であるか否かの判定（完全性の判定）は、例えば、ルールセット内の条件部の論理和の否定の充足可能性を判定する。充足可能な場合は、当該ルールセットは完全ではなく、充足不能な場合は、当該ルールセットは完全である。上記の例の「¬（Ａ＜１  ∨  Ａ＞１）」の充足可能性を判定すると、充足可能（Ａ＝１のとき、真）となるため、当該ルールセットは完全ではないことがわかる。なお、¬はＮＯＴ(否定)を表し、¬ＸはＸのＮＯＴ(否定)を表す。
【００２６】
等価性検証部１０４は、等価範囲において、変更前と変更後のルールセットの入力と出力の関係が維持されているか否か（等価性）を検証し、検証結果を検証結果保持部１２３に登録する。等価性検証部１０４の処理は後述する。
【００２７】
検証結果出力部１０５は、検証結果保持部１２３に登録されている情報を入出力装置１３３の画面や、補助記憶装置１２０にファイルとして出力する。
【００２８】
図３は、入力ルール保持部１２１のデータ構造の例である。入力ルール保持部１２１は、バージョン情報２０１、ルールセット情報２１０、ルール情報２１１、入力情報２１２、出力情報２１３、エンティティ情報２２０、および属性情報２２１の各テーブルを有する。図３の各テーブルの表記は、２つの四角形により構成されており、上の四角形内にテーブル名を表し、下の四角形内に当該テーブルのカラム名を表している。また、テーブル間の関連は、ひし形と実線を結んで表し、ひし形側のテーブルと実線側のテーブルは、１対多の関係にあることを表す。以下に示す他のデータ構造の図についても同様の表記を用いている。
【００２９】
図３において、バージョン情報２０１は、ルール管理支援装置１００が管理するルールセットの集まりのバージョンに関する情報として、バージョン番号および更新日時（又は適用日）を有する。バージョン番号は、入力ルール保持部１２１においてユニークな識別子である。更新日時は、バージョン番号が表すバージョンに最後に更新された日時である。なお、更新日時に替えて、新たなルールの適用日（適用開始日）としてもよいし、両方のカラムを設けてもよい。
【００３０】
ルールセット情報２１０は、ルールセットに関する情報として、ルールセットＩＤ、ルールセット名、および更新日時（又は適用日）を有する。ルールセットＩＤは、バージョン情報２０１で表されるバージョンのルールセット情報２１０においてユニークな識別子である。図２の例では、バージョンのＶ１のルールセットＩＤとして、ランク判定のＲＳ１と割引率判定のＲＳ２がある。ルールセット名は、ルールセットＩＤが示すルールセットの名称である。図２の例では、ルールセットの名称は「ランク判定」と「割引率判定」である。更新日時は、当該ルールセットが最後に更新された日時である。なお、更新日時に替えて、新たなルールの適用日（適用開始日）としてもよいし、両方のカラムを設けてもよい。
【００３１】
ルール情報２１１は、ルールセットに含まれるルールに関する情報として、ルールＩＤ、条件部論理式、および結果部論理式を有する。ルールＩＤは、ルールセットにおいて、各ルールに付したユニークな識別子である。図２の例では、バージョンＶ１のルールセット「ランク判定」に含まれるＲ１〜Ｒ３がルールＩＤである。条件部論理式は、ルールの条件部を表す論理式であり、入力項目、入力項目が取り得る値、比較演算子（等式演算子を含む）、四則演算子、論理演算子などの組合せで表現される。結果部論理式は、ルールの結果部を表す論理式であり、出力項目、出力項目が取り得る値、等式演算子、四則演算子、論理演算子などの組合せで表現される。
【００３２】
入力情報２１２は、当該ルールセットの入力項目に関する情報として、入力項目名、参照種別、および参照式を有する。入力項目名は、入力項目の名称である。参照種別は、当該入力項目に代入する値の参照先の種別であり、本実施形態では、「Ｅｎｔｉｔｙ」および「ＲｕｌｅＳｅｔ」のいずれかである。参照種別が「Ｅｎｔｉｔｙ」の場合、参照先はエンティティ情報２２０であり、「ＲｕｌｅＳｅｔ」の場合、参照先はルールセット情報２１０である。参照式は、当該入力項目に代入する値の参照先である。参照種別が「Ｅｎｔｉｔｙ」の場合、参照式は「エンティティ名．属性名」の形式となり、参照種別が「ＲｕｌｅＳｅｔ」の場合、参照式は「ルールセット名．出力項目名」となる。入力情報２１２の参照種別が「ＲｕｌｅＳｅｔ」であるとき、他のルールセットの出力項目に依存している（入力項目として、他のルールセットの出力項目を用いている）ことを表すので、ルールセット間の依存関係を表現していることになる。
【００３３】
入力情報２１２の例を、図２のルールセット割引率判定ＲＳ２を用いて説明する。ルールセット割引率判定ＲＳ２の入力項目名は、「Ａｇｅ」と「Ｒａｎｋ」である。「Ａｇｅ」の参照種別は「Ｅｎｔｉｔｙ」であり、「エンティティ名．属性名」の参照式を用いて、後述するエンティティ情報２２０を参照し、エンティティ情報２２０の定義に従った値を、割引率判定ＲＳ２の「Ａｇｅ」の入力値とする。「Ｒａｎｋ」の参照種別は「ＲｕｌｅＳｅｔ」であり、「ルールセット名．出力項目名」の参照式として「ランク判定、Ｒａｎｋ」を用いて、ルールセットランク判定ＲＳ１の出力項目「Ｒａｎｋ」の出力値を、割引率判定ＲＳ２の「Ｒａｎｋ」の入力値とする。後者の例は、ルールセット割引率判定ＲＳ２の入力項目の入力値は、ルールセットランク判定ＲＳ１の出力項目「Ｒａｎｋ」の出力値に依存している。
【００３４】
出力情報２１３は、当該ルールセットの出力項目に関する情報として、出力項目名、および出力項目型を有する。出力項目名は、出力項目の名称である。出力項目型は、Ｉｎｔｅｇｅｒ型（整数型）、Ｂｏｏｌ型、およびユーザ定義の列挙型のような出力項目のデータ型である。
【００３５】
エンティティ情報２２０は、当該バージョンのルールセットの入力値のエンティティの情報として、エンティティ名を有する。エンティティ名は、当該エンティティの名称である。
【００３６】
属性情報２２１は、エンティティ情報２２０が有する属性に関する情報として、属性名、および属性型有する。属性名は、当該属性の名称である。属性型は、Ｉｎｔｅｇｅｒ型（整数型）、Ｂｏｏｌ型、およびユーザ定義の列挙型のような当該属性のデータ型である。
【００３７】
図４は、等価範囲保持部１２２のデータ構造の例である。等価範囲保持部１２２は、等価性検証対象情報３０１、および等価範囲情報３０２のテーブルを有する。
【００３８】
等価性検証対象情報３０１は、等価性検証の対象となるルールセットに関する情報として、変更後ルールセットＩＤ、変更後バージョン番号、変更前ルールセットＩＤ、変更前バージョン番号、範囲指定条件、および条件式を有する。変更後ルールセットＩＤは、変更後のルールセットＩＤであり、変更後バージョン番号にリンクするルールセット情報２１０のルールセットＩＤのいずれかである。変更後バージョン番号は、変更後のルールセットのバージョン番号であり、バージョン情報２０１のバージョン番号のいずれかである。変更前ルールセットＩＤは、変更前のルールセットＩＤであり、変更前のバージョン番号にリンクするルールセット情報２１０のルールセットＩＤのいずれかである。変更前バージョン番号は、変更前のルールセットのバージョン番号であり、バージョン情報２０１のバージョン番号のいずれかである。
【００３９】
範囲指定条件は、等価範囲情報３０２間の論理的な関係を表す情報であり、本実施形態では、「Ａｎｄ」、「Ｏｒ」、および「手動指定」のいずれかである。条件式は、等価範囲情報３０２間の論理的な関係を表す式であり、範囲指定条件が「手動指定」の場合に必須のカラムである。条件式は、後述する等価範囲情報３０２の等価範囲ＩＤ、論理演算子、括弧などを含む式である。
【００４０】
等価範囲情報３０２は、変更前と変更後のルールセット間において入力と出力の関係が維持されるべき範囲、または、維持されるべきでない範囲に関する情報として、等価範囲ＩＤ、範囲指定対象、バージョン種別、範囲種類、および範囲式を有する。等価範囲ＩＤは、等価性検証対象情報３０１にリンクする等価範囲情報３０２においてユニークな識別子である。範囲指定対象は、範囲式で指定する対象であり、本実施形態では、「ルール」、「Ｅｎｔｉｔｙ入力値」、「ＲｕｌｅＳｅｔ入力値」、および「出力値」のいずれかである。バージョン種別は、範囲指定対象のバージョンに関する情報であり、本実施形態では、「変更前」、「変更後」、および「両方」のいずれかである。範囲種類は、「等価」および「非等価」のいずれかの値であり、「等価」の場合、指定した範囲が変更前と変更後で等価であるべき範囲であることを表し、「非等価」の場合、指定した範囲以外の部分が等価であるべき範囲であることを表す。範囲式は、等価もしくは非等価となる範囲を表す式またはルールＩＤのリストである。ルールＩＤのリストの場合も、依存関係にあるルールセットのルールを含めてもよい。どのルールセットのルールであるかは、例えば、「ルールセットＩＤ．ルールＩＤ」の形式で記述することで、一意に特定できる。
【００４１】
図５は、検証結果保持部１２３のデータ構造の例である。検証結果保持部１２３は、検証結果情報４０１、非等価ケース情報４１０、入力値情報４１１、出力値情報４１２、および適用ルール情報４１３のテーブルを有する。
【００４２】
検証結果情報４０１は、ルールセットＩＤ、バージョン番号、整合性検証結果、整合性検証日時、完全性検証結果、完全性検証日時、等価性検証結果、および等価性検証日時を有する。ルールセットＩＤは、検証対象のルールセットを識別する情報であり、ルールセット情報２１０のいずれかである。バージョン番号は、当該ルールセットのバージョンを識別する情報であり、バージョン情報２０１のバージョン番号のいずれかである。
【００４３】
整合性検証結果および整合性検証日時は、整合性検証部１０２により当該ルールセットの整合性を検証した結果および検証した日時である。完全性検証結果および完全性検証日時は、完全性検証部１０３により当該ルールセットの完全性を検証した結果および検証した日時である。等価性検証結果および等価性検証日時は、等価性検証部１０４により当該ルールセットの等価性を検証した結果および検証した日時である。整合性、完全性、および等価性の各検証結果は、本実施形態では、「ＯＫ」、「ＮＧ」、および「ＮＵＬＬ」のいずれかである。「ＮＵＬＬ」は初期値であり、検証処理が未実行であることを表す。
【００４４】
非等価ケース情報４１０は、等価性検証結果が「ＮＧ」のケースの情報として、非等価ケースＩＤのカラムを有する。非等価ケースＩＤは、当該検証結果情報４０１にリンクする非等価ケース情報４１０においてユニークな識別子である。
【００４５】
入力値情報４１１は、非等価となるケースの入力値に関する情報として、入力項目名、および入力値を有する。入力項目名は、当該ルールセットの入力項目の名称である。入力値は、非等価となるときの当該入力項目の値である。
【００４６】
出力値情報４１２は、非等価となるケースの出力値に関する情報として、バージョン種別、出力項目名、および出力値を有する。バージョン種別は、当該出力値情報が、変更前のバージョンのルールセットに関するものであるか、変更後のバージョンのルールセットに関するものであるかを識別する情報であり、本実施形態では、「変更前」および「変更後」のいずれかである。出力項目名は、当該ルールセットの出力項目の名称である。出力値は、非等価となるケースの当該出力項目の値である。
【００４７】
適用ルール情報４１３は、非等価となる場合に適用されるルールに関する情報として、バージョン種別、ルールセットＩＤ、およびルールＩＤを有する。バージョン種別は、当該関連ルール情報が、変更前のバージョンにリンクするルールセットに関するものであるか、変更後のバージョンにリンクするルールセットに関するものであるかを識別する情報であり、本実施形態では、「変更前」および「変更後」のいずれかである。ルールセットＩＤは、非等価となる場合に適用されるルールが属するルールセットの識別子である。ルールＩＤは、非等価となる場合に適用されるルールの識別子である。
【００４８】
なお、本実施形態では等価性検証結果が「ＮＧ」の場合の関連情報を管理しているが、整合性と完全性の検証結果が「ＮＧ」の場合の関連情報も管理するようにしてもよい。例えば、整合性の検証結果が「ＮＧ」の場合であれば、不整合となるルールの組み合わせに関する情報、不整合を引き起こす入力値に関する情報を管理する。また、完全性の検証結果が「ＮＧ」の場合であれば、いずれの条件部も真にできない入力値に関する情報を管理する。
【００４９】
図６は、入出力装置１３３に表示されるルールセットの編集画面の例である。ルール編集画面５００は、入力ルール編集部１０１がユーザからの、業務規則の変更に応じたルールの編集入力を受け付けるための画面である。
【００５０】
ルール編集画面５００は、ルールセット基本情報表示エリア５１０、入力項目編集エリア５２０、出力項目編集エリア５３０、ルール編集エリア５４０、等価範囲指定エリア５５０、および検証ボタン５６０を含む。
【００５１】
ルールセット基本情報表示エリア５１０は、編集対象のルールセットに関する基本情報を表示する領域であり、ルールセットＩＤ、ルールセット名、およびバージョン番号を表示する。入力ルール編集部１０１が「ルールセットＩＤ」、「ルールセット名」および「バージョン番号」のタイトル（項目名）を表示し、ユーザによるルールセットＩＤ、ルールセット名およびバージョン番号を入力する。図６は、ルールセットＩＤとして「ＲＳ２」、ルールセット名として「割引率判定」、バージョン番号として「Ｖ２」が入力された例である。
【００５２】
入力項目編集エリア５２０は、ルールセットの入力項目を編集（追加、変更、および削除）する領域であり、入力項目名、種別、および参照式の項目を表示する。
【００５３】
入力ルール編集部１０１が入力項目編集エリア５２０の各項目にその内容を表示する場合、入力ルール編集部１０１の動作に３通りある。第１は、ルールセット基本情報表示エリア５１０に入力されたルールセットＩＤ「ＲＳ２」とそのバージョン番号「Ｖ２」に係るデータが事前に入力ルール保持部１２１に保持されている場合である。第２は、事前に入力ルール保持部１２１に保持されていないが、業務規則の変更に対応する変更前のルールセットＩＤ「ＲＳ２」とそのバージョン番号「Ｖ１」に係るデータが事前に入力ルール保持部１２１に保持されている場合である。第３は、ソフトウェアの新規開発時などのように、入力ルール保持部１２１に、第１又は第２の場合のようなデータが保持されていない場合である。
【００５４】
第１の場合は、たとえば、それらのデータを入力ルール保持部１２１に保持し、ルールセットＩＤ「ＲＳ２」の整合性、完全性、および等価性のいずれかの検証結果の「ＮＧ」に伴い、再検証する場合などであり、入力ルール編集部１０１は、入力ルール保持部１２１の入力情報２１２の入力項目名、参照種別、および参照式を表示する。
【００５５】
第２の場合は、業務規則の変更に応じて、ユーザが初めて入力項目を編集する場合であり、入力ルール保持部１２１にバージョン番号「Ｖ２」に係るデータが事前に入力ルール保持部１２１に保持されてないので、入力ルール編集部１０１は、バージョン番号「Ｖ２」に対応する変更前のージョン番号「Ｖ１」に係るデータを入力項目編集エリア５２０に表示する。
【００５６】
第３の場合は、入力項目編集エリア５２０の各項目のタイトル（項目名）を表示する。
【００５７】
第１〜第３のいずれの場合においても、入力ルール編集部１０１は、入力項目の数に応じて入力項目編集エリア５２０の行数を追加、または削除する。また、入力ルール編集部１０１は、ユーザによる入力項目の編集（追加、変更、および削除）の結果を、バージョン番号「Ｖ２」に対応付けて入力ルール保持部１２１に反映する。したがって、編集後の各項目の内容は、それぞれ入力ルール保持部１２１の入力情報２１２の入力項目名、参照種別、参照式に対応する。
【００５８】
入力項目編集エリア５２０に関する第１〜第３の場合の入力ルール編集部１０１の動作は、出力項目編集エリア５３０およびルール編集エリア５４０に関しても同様である。
【００５９】
出力項目編集エリア５３０は、ルールセットの出力項目を編集（追加、変更、および削除）する領域であり、出力項目名および型の項目を持つ。ユーザによる編集後の各項目の内容は、入力項目編集エリア５２０と同様に、入力ルール編集部１０１によって入力ルール保持部１２１に反映され、それぞれ入力ルール保持部１２１の出力情報２１３の出力項目名、および出力項目型に対応する。
【００６０】
ルール編集エリア５４０は、ルールセットに含まれるルールを編集（追加、変更、および削除）する領域であり、ＩＤ、条件部、および、結果部の項目を持つ。編集後の各項目の内容は、入力項目編集エリア５２０と同様に、入力ルール編集部１０１によって入力ルール保持部１２１に反映され、それぞれ入力ルール保持部１２１のルール情報２１１のルールＩＤ、条件部論理式、および結果部論理式に対応する。
【００６１】
図６の入力項目編集エリア５２０、出力項目編集エリア５３０、およびルール編集エリア５４０の表示内容は、入力ルール保持部１２１に保持されている、図２のルールセットＩＤ「ＲＳ２」、ルールセット名「割引率判定」、バージョン番号「Ｖ２」に係るデータである。
【００６２】
等価範囲指定エリア５５０は、等価性検証の条件を設定、編集する領域であるので、ソフトウェアの新規開発時などの業務規則の変更に無関係の場合は、入力ルール編集部１０１は等価範囲指定エリア５５０を用いない。等価範囲指定エリア５５０は、変更前と変更後のルールセットにおいて入力と出力の関係が維持されるべき範囲、または、維持されるべきでない範囲の追加、変更、および削除などの等価範囲を編集する領域であり、変更前ルールセットＩＤ、変更前バージョン番号、範囲指定条件、Ｎｏ、範囲指定対象、Ｖｅｒ、範囲種類、および範囲式の項目を持つ。
【００６３】
編集後の各項目の内容は、入力ルール編集部１０１によって等価範囲保持部１２２に反映される。変更前ルールセットＩＤ、変更前バージョン番号、範囲指定条件、および条件式は、それぞれ等価範囲保持部１２２の等価性検証対象情報３０１の変更前ルールセットＩＤ、変更前バージョン番号、範囲指定条件、および条件式に対応する。なお、等価性検証対象情報３０１の変更後ルールセットＩＤおよび変更後バージョン番号は、ルールセット基本情報表示エリア５１０のルールセットＩＤおよびバージョン番号に対応する。
【００６４】
Ｎｏ、範囲指定対象、Ｖｅｒ、範囲種類、および範囲式の各項目は、それぞれ等価範囲保持部１２２の等価範囲情報３０２の等価範囲ＩＤ、範囲指定対象、バージョン種別、範囲種類、および範囲式に対応する。範囲指定対象、Ｖｅｒ、および範囲種類は、プルダウンリストからユーザが選択入力する。
【００６５】
図６の等価範囲指定エリア５５０の例では、変更前のルールセットＩＤがＲＳ２で、バージョン番号がＶ１であることがユーザにより指定されている。また、範囲として、Ｎｏ．１とＮｏ．２の２つの範囲が指定され、これら２つの範囲の関係は、範囲指定条件によりＯＲ条件となっている。Ｎｏ．１の範囲は、等価な範囲（範囲種類）として、変更前（Ｖｅｒ）のルールセット（ルールセットＩＤがＲＳ２で、バージョン番号がＶ１）のＲ１とＲ２のルール（範囲指定対象）が指定されている。これは、当該変更前のルールセットのＲ１とＲ２の条件部の論理和が等価範囲として指定されたことを意味する。この例では、具体的には、「（Ａｇｅ＜＝３５∧Ｒａｎｋ＜＞Ｇｏｌｄ）∨（３５＜Ａｇｅ＜６０∧Ｒａｎｋ＝Ｒｅｇｕｌａｒ）」がＮｏ．１の等価範囲となる。
【００６６】
一方、Ｎｏ．２の範囲は、非等価な範囲として、Ｅｎｔｉｔｙ入力値（範囲指定対象）の範囲が指定されている。図６の例では、「顧客」というＥｎｔｉｔｙの属性「Ａｍｏｕｎｔ」が１０００００より大きい場合（範囲式）、非等価（範囲種類）であることを意味する。範囲種類として「非等価」が指定された場合、範囲として指定した条件（範囲式）の否定が「等価」であるとみなす。そのため、Ｎｏ．２は、その否定「¬（顧客．Ａｍｏｕｎｔ＞１０００００）」を等価範囲とみなす。図６の例では、Ｎｏ．１とＮｏ．２の関係は、ＯＲ条件であるため、Ｎｏ．１とＮｏ．２による等価範囲は、「（（Ａｇｅ＜＝３５∧Ｒａｎｋ＜＞Ｇｏｌｄ）∨（３５＜Ａｇｅ＜６０∧Ｒａｎｋ＝Ｒｅｇｕｌａｒ））∨¬（顧客．Ａｍｏｕｎｔ＞１０００００）」である。
【００６７】
ユーザによる検証ボタン５６０の押下に応答して、整合性検証部１０２および完全性検証部１０３が実行され、整合性と完全性の検証結果が「ＯＫ」の場合であり、且つ等価範囲指定エリア５５０に等価範囲が指定されたとき、等価性検証部１０４が実行される。
【００６８】
検証結果出力部１０５は、検証結果保持部１２３を参照し、整合性検証部１０２、完全性検証部１０３、および等価性検証部１０４による検証結果を出力する。本実施形態では、検証ボタン５６０を１つとしているが、整合性、完全性、等価性のそれぞれの検証用のボタンを用意しても良い。
【００６９】
前述した等価範囲指定エリア５５０の範囲指定対象、Ｖｅｒ、範囲種類、および範囲式の指定について補足説明する。
【００７０】
範囲指定対象は、「ルール」、「Ｅｎｔｉｔｙ入力値」、「ＲｕｌｅＳｅｔ入力値」、および「出力値」のいずれかである。
【００７１】
Ｖｅｒの指定は、範囲指定対象に指定した内容により異なる。範囲指定対象が「ルール」の場合は、Ｖｅｒの指定は「変更前」および「変更後」のいずれかである。ユーザは、Ｖｅｒで指定したバージョンのルールセットの中からルールを選択する。範囲指定対象が「Ｅｎｔｉｔｙ入力値」の場合は、Ｖｅｒの指定は「両方」である。ユーザは、エンティティ情報２２０の属性情報２２１の属性名を使って範囲式を記述する。範囲指定対象が「ＲｕｌｅＳｅｔ入力値」の場合は、Ｖｅｒの指定は「変更前」、「変更後」、および「両方」のいずれかである。ユーザは、入力情報２１２の参照種別が「ＲｕｌｅＳｅｔ」である入力項目名を使って範囲式を記述する。ただし、Ｖｅｒの指定が「両方」の場合は、変更前と変更後のルールセットに参照種別が「ＲｕｌｅＳｅｔ」である同一名の入力項目がある必要がある。範囲指定対象が「出力値」の場合は、Ｖｅｒの指定は「変更前」および「変更後」のいずれかである。
【００７２】
範囲種類は、「等価」および「非等価」のいずれかである。範囲種類が「等価」の場合、範囲式を表す論理式が等価範囲となる。一方、「非等価」の場合は、範囲式を表す論理式の否定が等価範囲となる。
【００７３】
図７は、等価性検証部１０４の処理フローチャートである。等価性検証部１０４は、整合性検証部１０２および完全性検証部１０３の検証結果が「ＯＫ」の場合に、処理を実行する（Ｓ７００）。また、ユーザによる入出力装置１３３の操作、バッチ処理などにより処理を実行してもよい。
【００７４】
等価性検証部１０４は、等価範囲保持部１２２を参照し、等価性検証対象の等価性検証対象情報３０１と、当該等価性検証対象情報３０１にリンクする等価範囲情報３０２を取得する（Ｓ７０１）。等価性検証部１０４は、ルール編集画面５００のルールセット基本情報表示エリア５１０からルールセットＩＤとバージョン番号を取得し、変更後ルールセットＩＤと変更後バージョン番号がこれらと一致する等価性検証対象情報３０１を特定し、当該等価性検証対象情報３０１と、当該等価性検証対象情報３０１に紐づく等価範囲情報３０２を取得する。
【００７５】
等価性検証部１０４は、取得した等価性検証対象情報３０１の変更後ルールセットＩＤ、変更後バージョン番号、変更前ルールセットＩＤ、および変更前バージョン番号から、対応する変更前と変更後のルールセット、および、依存関係にある変更前と変更後のルールセットを入力ルール保持部１２１から取得する（Ｓ７０２）。図２の例では、「ランク判定ＲＳ１（以下、ＲＳ１）」と「割引率判定ＲＳ２（以下、ＲＳ２）」は依存関係にあるので、等価性検証部１０４は、バージョン番号Ｖ１およびＶ２のルールセット「ＲＳ１」と「ＲＳ２」を取得する。
【００７６】
等価性検証部１０４は、変更前と変更後のルールセットに含まれる各ルールを表すルール論理式を生成する（Ｓ７０３）。ルール論理式は、ルールセットの各ルールについて「ルール有効フラグ∧条件部論理式∧結果部論理式」という形式の論理式である。ここで、ルール有効フラグとは、当該ルールが有効であるか否かを示す命題変数であり、ルール毎に異なる命題変数を割り当てる。例えば、ルールセットＩＤ、バージョン番号、およびルールＩＤを組み合わせることでルール毎に異なる命題変数を割り当てることができる。ルール有効フラグは、後述するＳ７１３の制約の追加において、利用する。また、結果部論理式に含まれる出力項目名は、バージョン毎に異なる名称で置き換える。例えば、図２のバージョン番号Ｖ１のランク判定のＲ１のルール論理式は、「（ＲＳ１Ｖ１Ｒ１）∧（Ａｍｏｕｎｔ＜２００００）∧（ＲａｎｋＶ１＝Ｒｅｇｕｌａｒ）」となる。ここで、ＲＳ１Ｖ１Ｒ１はルール有効フラグを表す。ＲａｎｋＶ１は結果部論理式に含まれる出力項目名Ｒａｎｋをバージョン番号Ｖ１用に名称を置き換えた出力項目名を表す。なお、等価性検証部１０４は、検証対象のルールセットと依存関係にあるルールセットに含まれるルールに対してもルール論理式を生成する。
【００７７】
等価性検証部１０４は、変更前と変更後のルールセットを表すルールセット論理式を生成する（Ｓ７０４）。ルールセット論理式は、各ルールセットについて、ルール論理式を論理和で結合した論理式である。例えば、図２のバージョン番号Ｖ１のランク判定のルールセット論理式は、「（Ｒ１を表すルール論理式）∨（Ｒ２を表すルール論理式）∨（Ｒ３を表すルール論理式）」、すなわち、「{（ＲＳ１Ｖ１Ｒ１）∧（Ａｍｏｕｎｔ＜２００００）∧（ＲａｎｋＶ１＝Ｒｅｇｕｌａｒ）}∨{（ＲＳ１Ｖ１Ｒ２）∧（２００００≦Ａｍｏｕｎｔ＜５００００）∧（ＲａｎｋＶ１＝Ｓｉｌｖｅｒ）}∨{（ＲＳ１Ｖ１Ｒ３）∧（５００００≦Ａｍｏｕｎｔ）∧（ＲａｎｋＶ１＝Ｇｏｌｄ）}」となる。このように、ルールセット論理式は、ルールセットに含まれるいずれか一つのルールを満足すれば、真となる。なお、等価性検証部１０４は、検証対象のルールセットと依存関係にあるルールセットに対してもルールセット論理式を生成する。
【００７８】
等価性検証部１０４は、変更前および変更後のバージョンの各々を表すバージョン論理式を生成する（Ｓ７０５）。バージョン論理式は、変更前の検証対象のルールセット論理式と、検証対象のルールセットと依存関係にあるルールセットに対応するルールセット論理式とを、論理積で結合した論理式である。例えば、図２のバージョン番号Ｖ１（変更前）のバージョン論理式は、「（ＲＳ１を表すルールセット論理式）∧（ＲＳ２を表すルールセット論理式）」となる。このように、バージョン論理式は、バージョンにリンクするすべてのルールセットを満足すれば、真となる。換言すると、バージョン論理式は、バージョンにリンクするルールセット毎にいずれか一つのルールを満足すれば、真となる。等価性検証部１０４は、変更後の検証対象のルールセットについても、同様に、バージョン論理式を生成する。
【００７９】
等価性検証部１０４は、等価範囲を表す等価範囲論理式を生成する（Ｓ７０６）。等価性検証部１０４は、等価性検証対象情報３０１の範囲指定条件および条件式、並びに等価範囲情報３０２に基づき、等価範囲を表す等価範囲論理式を生成する。等価性検証部１０４は、各等価範囲情報３０２から等価範囲を表す論理式を生成し、これらの論理式を範囲指定条件に基づき論理結合し、等価範囲論理式を生成する。等価範囲情報３０２の範囲種類が非等価である場合、その否定が等価範囲となる。例えば、図６の等価範囲指定エリア５５０の内容を表す等価範囲論理式は、「（変更前のＲＳ２．Ｒ１の条件部）∨（変更前のＲＳ２．Ｒ２の条件部）∨¬（顧客．Ａｍｏｕｎｔ＞１０００００）」となる。
【００８０】
等価性検証部１０４は、等価性判定用の論理式（等価性判定式）を生成する（Ｓ７０７）。等価性検証部１０４は、変更前と変更後のルールセットの等価性を判定するための等価性判定式として、変更前のバージョン論理式、変更後のバージョン論理式、等価範囲論理式、および変更前と変更後のルールセットの出力項目が等しくないことを表す論理式を論理積で結合した論理式（等価性判定式）を生成する。例えば、図２の割引率判定の等価性判定式は、「（バージョン番号Ｖ１のバージョン論理式）∧（バージョン番号Ｖ２のバージョン論理式）∧（等価範囲論理式）∧¬（ＤｉｓｃｏｕｎｔＶ１＝ＤｉｓｃｏｕｎｔＶ２）」となる。ここで、ＤｉｓｃｏｕｎｔＶ１はバージョン番号Ｖ１の検証対象である割引率判定の出力項目を表し、ＤｉｓｃｏｕｎｔＶ２はバージョン番号Ｖ２の検証対象である割引率判定の出力項目を表す。
【００８１】
等価性検証部１０４は、ループカウント変数ｉに０を代入する（Ｓ７０８）。
【００８２】
等価性検証部１０４は、等価性判定式の充足可能性を判定する（Ｓ７０９）。充足可能性とは、与えられた論理式を真（ＴＲＵＥ）にする変数の値の組合せが存在するか否かを表す性質である。等価性判定式が充足可能とは、等価性判定式が真になることであり、すなわち、等価性判定式を構成する、変更前のバージョン論理式、変更後のバージョン論理式、等価範囲論理式、および変更前と変更後のルールセットの出力項目が等しくないことを表す論理式がすべて真になることを意味する。このうち、変更前と変更後のルールセットの出力項目が等しくないことを表す論理式が、真になるとは、変更前と変更後のルールセットの出力項目の値が等しくないことを表す。等価性判定式が真のとき、等価範囲論理式も真となる必要がある。すなわち、等価範囲において出力項目の値が異なるので、非等価であることを意味する。そのため、等価性判定式が充足可能な場合には、非等価であり、充足不能な場合には等価となる。
【００８３】
充足可能性は、単純には、すべての変数の値の組合せをチェックすることで判定可能である。また、ＤＰＬＬ（Ｄａｖｉｓ−Ｐｕｔｎａｍ−Ｌｏｇｅｍａｎｎ−Ｌｏｖｅｌａｎｄ）アルゴリズムなど、変数の値の組合せではなく、論理式の構造に着目して、効率的に充足可能性を判定するツールがある。例えば、ＳＭＴ（Ｓａｔｉｓｆｉａｂｉｌｉｔｙ  Ｍｏｄｕｌｏ  Ｔｈｅｏｒｉｅｓ）ソルバは、充足可能性を判定するツールの一種であり、等価性判定式の充足可能性を判定できる。
【００８４】
充足可能である場合、等価性検証部１０４は、検証結果情報４０１の等価性検証結果が「ＮＧ」でない場合に「ＮＧ」を設定（「ＮＧ」に変更）し、「ＮＧ」の場合にはそのままにして、Ｓ７１０に進む。充足不能である場合、等価性検証部１０４は、検証結果情報４０１の等価性検証結果を確認し「ＮＵＬＬ」の場合に「ＯＫ」を設定し、「ＮＵＬＬ」以外の場合にはそのままにして、処理を終了する（Ｓ７１４）。
【００８５】
等価性検証部１０４は、モデルを取得する（Ｓ７１０）。ここで、モデルとは、等価性判定式を真（充足可能）にする入力項目、出力項目、およびルール有効フラグの値の組合せの一例である。例えば、ＳＭＴソルバの機能を利用することで、モデルを取得できる。等価性検証部１０４は、取得した入力項目の値を入力値情報４１１に、出力項目の値を出力値情報４１２に登録する。また、等価性検証部１０４は、ルール有効フラグがＴｒｕｅ（真）のルールの情報を適用ルール情報４１３に登録する。ルール有効フラグがＴｒｕｅである場合、対応するルールが適用されたことを意味する。
【００８６】
等価性検証部１０４は、ループカウント変数ｉに１を加える（Ｓ７１１）。等価性検証部１０４は、ループカウント変数ｉが予め定めた値Ｎよりも小さいか否か確認する（Ｓ７１２）。ｉがＮよりも小さい場合、Ｓ７１３に進み、そうでない場合、処理を終了する（Ｓ７１４）。Ｎの値は、設定ファイルなどで設定できるようにしてもよい。Ｎの値により、検証失敗時に出力する非等価ケースの数の最大値を調整できる。ここで、非等価ケースとは、非等価のときに条件部が真となるルールの組合せである。
【００８７】
等価性検証部１０４は、同一のルール有効フラグの組が同時にＴｒｕｅにならないようにするための制約を追加する（Ｓ７１３）。同一のルール有効フラグの組とは、前述の非等価のときに条件部が真となるルールの組合せを意味する。Ｓ７１０において、モデルを取得した際に、値がＴｒｕｅであるルール有効フラグの集合が、同一のルール有効フラグの組である。この制約は、値がＴｒｕｅである各ルール有効フラグの否定を論理和で結合した論理式（以下、「ルール有効フラグ組無効化論理式」という。）である。等価性検証部１４０は、等価性判定式とルール有効フラグ組無効化論理式を論理積で結合した論理式を新しい等価性判定式として、Ｓ７０９の処理を実行する。非等価ケースが他にも存在する場合、ルール有効フラグ組無効化論理式を論理積で結合した等価性判定式は真となる。このとき、ルール有効フラグ組無効化論理式があるため、既出の非等価ケースが出力されることはない。
【００８８】
なお、本実施形態では、Ｓ７０９およびＳ７１０で、検証結果保持部１２３に検証結果を登録しているが、Ｓ７１４の実行の直前にまとめて登録してもよい。また、本実施形態では、ループカウント変数を利用しているが、ループカウント変数を利用せずに、Ｓ７０９で充足不能になるまで処理を継続するようにしてもよい。
【００８９】
図８は、検証結果の表示画面の例である。検証結果表示画面８００は、検証結果出力部１０５が、検証結果保持部１２３の情報を参照して表示する。検証結果表示画面８００は、検証結果概要表示エリア８０１、および検証結果詳細表示エリア８０２を含む。
【００９０】
検証結果概要表示エリア８０１は、整合性検証部１０２、完全性検証部１０３、および等価性検証部１０４の処理の結果を表示する領域である。
【００９１】
検証結果詳細表示エリア８０２は、検証の結果が「ＮＧ」の場合に、「ＮＧ」となるケースを表示する領域である。図８の例では、等価性の検証結果が「ＮＧ」の場合の「ＮＧ」となるケースとして、非等価ケース一覧８２０を表示している。非等価ケース一覧８２０には、非等価となるケースの情報として非等価ケース８３０を含む。非等価ケース８３０には、非等価となる場合の入力値８４０、出力値８５０、および適用ルール８６０を含む。出力値８５０、および適用ルール８６０は、それぞれ変更前と変更後の情報を含む。
【００９２】
図８の非等価ケース一覧８０２では、図２で示すルールセットの例について、図５に示す等価範囲指定エリア５５０で指定した等価範囲について等価性を検証した結果を表示している。非等価ケース一覧８０２に示す通り、非等価ケースは２つある。そのうちの１つの非等価ケースは、顧客．Ａｇｅ＝６０、顧客．Ａｍｏｕｎｔ＝１０００００のとき、変更前ルールセットのＤｉｓｃｏｕｎｔの値が２０、変更後のルールセットのＤｉｓｃｏｕｎｔの値が２５となり、非等価となる。また、このとき、ルールの条件部がＴｒｕｅとなるルールは、変更前のルールセットは、ＲＳ１．Ｒ３とＲＳ２．Ｒ４であり、変更後のルールセットは、ＲＳ１．Ｒ４とＲＳ２．Ｒ６が真となる。なお、もう１つの非等価ケースは、変更前のルールセットのＲＳ１．Ｒ３とＲＳ２．Ｒ５、変更後のルールセットのＲＳ１．Ｒ４とＲＳ２．Ｒ６の条件部が真のときである。
【００９３】
図８の検証結果を参照することで、変更後のルールセットのＲＳ１．Ｒ３、ＲＳ１．Ｒ４、ＲＳ２．Ｒ４、ＲＳ２．Ｒ５のいずれかに誤りがある可能性があることがわかる。図２の例では、実際には、ＲＳ１．Ｒ３とＲＳ１．Ｒ４の不等号に誤りがある。ＲＳ１．Ｒ３の条件部を「５００００  ＜＝  Ａｍｏｕｎｔ  “＜＝”  １０００００」に、ＲＳ１．Ｒ４の条件部を「Ａｍｏｕｎｔ  “＞”  １０００００」に変更することで、指定された等価範囲において等価となる。等価である場合、図８の検証結果概要表示エリア８０１の等価性検証結果はＯＫとなり、検証結果詳細表示エリア８０２には何も表示されない。
【００９４】
以上説明した実施形態によれば、ルール管理支援装置は、ユーザが指定した論理的範囲について、変更前と変更後のルールの等価性の確認を網羅的に実行できる。
【符号の説明】
【００９５】
１００：ルール管理支援装置、１０１：入力ルール編集部、１０２：整合性検証部、１０３：完全性検証部、１０４：等価性検証部、１０５：検証結果出力部、１２０：補助記憶装置、１２１：入力ルール保持部、１２２：等価範囲保持部、１２３：検証結果保持部、１３１：プロセッサ、１３２：メモリ、１３３：入出力装置、５００：ルール編集画面、８００：検証結果表示画面。
【図１】
2017085824.tif 000003
【図２】
2017085824.tif 000004
【図３】
2017085824.tif 000005
【図４】
2017085824.tif 000006
【図５】
2017085824.tif 000007
【図６】
2017085824.tif 000008
【図７】
2017085824.tif 000009
【図８】
2017085824.tif 000010
【国際調査報告】
2017085824.tif 000011
2017085824.tif 000012