JP6216757B2 - ビジネスルールの編集およびコンパイルの、方法、コンピュータプログラム、およびシステム - Google Patents

Description

本発明は、ビジネスルールの編集およびコンパイルに関する。

複雑な計算は、有向グラフによるデータフローとして表せることが多く、計算成分はそのグラフの頂点と関係付けられ、成分間のデータフローはグラフのリンク（弧、辺）に対応する。このようなグラフ型計算を実装するシステムは、米国特許第５，９６６，０７２号、発明の名称「グラフとして表される計算の実行」に記載されている。場合によっては、頂点と関係付けられる計算は、人が読み取れる「ビジネスルール」と呼ぶ形式で記述される。

総じて、一態様では、データフローを表すリンク要素により接続されるデータ処理成分を有するグラフ型計算における成分は、ルール仕様を受け取るステップ、そのルール仕様に基づいてデータを変換するための変換式を生成するステップ、その変換式をグラフ型計算内の成分と関係付けるステップ、および新規ルール仕様を受け取ったのか、または既存ルール仕様を編集したのかという決定に応じて、新規ルール仕様または編集したルール仕様に従ってグラフ型計算の成分と関係付けられる変換式を更新するステップにより更新される。

実装には以下の特徴の１つ以上が含まれる。

ルール仕様を受け取るステップは、ユーザーからルール仕様テーブルの１行を受け取るステップを含み、この行はルールケースを定義し、１セット中の１つ以上の可能な入力のそれぞれに対する関係性を収納する。ルール仕様を受け取るステップは、表の第２行をユーザーから受け取るステップも含み、第２行は第２のルールケースを定義し、第２セット中の１つ以上の可能な入力のそれぞれに対する第２の関係性を収納する。関係性には、「閾値に等しい値を有する」、「閾値を超える値を有する」、「閾値未満の値を有する」、「１セットの値に属する値を有する」、「パターンに一致する値を有する」、「別の入力の値と関係がある」、「別のルール仕様の出力の値と関係がある」、および「メモリ内の値と関係がある」、の内の１つ以上が含まれる。行には、「入力の値」、「所定の値」、および「入力の値の内の１つ以上からの算出値」、の内の１つ以上またはその組合せを含む出力も収納される。各テスト列が１つ以上の可能な入力に対する値を収納する１セットのテスト列を含む表を受け取るステップと、テスト列ごとに、テスト列の入力値を所与とする出力を生成するルール仕様の内の１行を識別するステップ、テスト列ごとに、識別された行の識別をユーザーに出力するステップ。テスト列ごとに結果行を含む表を生成するステップであって、各結果行は、テスト列の入力値を所与として生成される出力を指示する。表を生成するステップは、各結果行において、生成されることになる出力が、以前のバージョンのルール仕様に対して指示された出力から変更されるかどうかを指示するステップを含む。結果行との間のユーザーの相互作用に応じて、ルール仕様のどのルールケースがその結果行に出力を生成するかを指示するステップ。

ルール仕様の各行に対応する評価行を含む表を生成するステップ、表の各評価行に、可能な入力ごとに、その可能な入力に対する第１テスト列内の値がその可能な入力に対する関係性を満たしているかどうかを指示するステップ、第１テスト列の入力値を所与とする出力を生成するルール仕様の行に対応する評価行に、生成される出力を指示するステップ。評価行の順序はルール仕様の行の順序に対応し、出力が指示される評価行は、可能な入力に対する関係性のそれぞれが満たされるルール仕様の第１行に対応する。可能な入力に対する関係性のそれぞれが満たされる１行のルール仕様に対応する各評価行に生成されることになる出力を指示するステップ。ルール仕様の各行に対応する評価行を含む表を生成するステップと、各評価行において、いくつのテスト列が、ルール仕様の対応行における関係性を満たす入力を有するかを指示するステップ。各テスト列は出力期待値も収納し、各結果行は、対応するテスト列の入力値を所与として生成される出力がそのテスト列内の期待出力に一致するかどうかを指示する。テスト列ごとに、第２のルール仕様の内の少なくとも１つの行が、テスト列の入力値を所与として出力を生成することになるとの決定に応じて、第１ルール仕様および第２ルール仕様を含むルールセットが正当であることを決定するステップ。

テスト列ごとに結果行を含む表を生成するステップであって、各結果行は、テスト列の入力値を所与として、ルール仕様の内の１つにおける行により生成されることになる各出力を指示する。第１テスト列の入力値を所与として生成されることになる出力に対して、その出力の生成をもたらすルール仕様の入力と出力との間の相互関係のグラフィック表示を生成するステップ。テスト列の表を受け取るステップは、１セットの入力値をユーザーから受け取るステップ、その入力値セットをルール仕様の可能な入力の値に一致させるステップ、およびその入力値セットを表の列に格納するステップを含む。１セットの入力値を受け取るステップは、可能な入力の値の識別を表示するステップに応じて受け取る。あるセットのルール仕様内の各ルール仕様が少なくとも１つの出力を生成することになるという決定に応じて、そのセットのルール仕様が正当であることを決定するステップ。ルール仕様が不当であるとの決定に対しては、そのルール仕様が不当であることをルール仕様のソースに通信する。

変換式を更新するステップは、ルール仕様が正当であることを確認するステップ、新規または編集されたルール仕様に基づいて新規変換式を生成するステップ、最初の変換式を成分と無関係にするステップ、および新規変換式を成分と関係付けるステップを含む。変換式を更新するステップは、ルール仕様が正当であることを確認するステップ、成分がアクティブ化されるとき、グラフ型計算が実行されることを待機するステップ、新規または編集されたルール仕様に基づいて新規変換式を生成するステップ、および新規変換式を成分と関係付けるステップを含む。変換式を生成するステップは、ルール仕様内の複数のルールケースのそれぞれを論理式に変換して複数の論理式を形成するステップ、および複数の論理式をコンピュータ実行コードにコンパイルするステップを含む。複数の論理式をコンパイルするステップは、式を組合せるステップ、個々の式を最適化するステップ、および式のグループを最適化するステップの１つ以上のステップを含む。複数の論理式をコンパイルするステップは、式とグラフ型計算での使用に適した成分とを関係付けるステップを含む。

総じて、一態様では、計算は、以下のステップによりテストが行われる：１セットのルールケースを含むルール仕様を受け取るステップであって、各ルールケースが可能な入力と対応出力の関係性を含む、ルール仕様を受け取るステップ、１セットのテストケースを受け取るステップであって、各テストケースが１つ以上の可能な入力に対する値を含む、テストケースを受け取るステップ、およびテストケースごとに、テストケースの入力値を所与として出力を生成することになるルールケースの内の１つを識別するステップ。

実装には以下の特徴の１つ以上が含まれる。

テストケースごとに出力を生成することになるルールケースを識別するステップに応じて、ルール仕様が正当であるとの指示を格納または出力するステップ。テストケースごとに出力を生成するルールケースを識別するステップに応じて、生成される出力の指示を格納または出力するステップ。１セットのテストケースを受け取るステップは、１セットのテスト列を含む表を受け取るステップを含み、各テスト列は、対応する１つのテストケースに対する１つ以上の可能な入力に対する値を含む。テストケースごとに、かつそのテストケースに対する識別されたルールケースごとに、識別されたルールケースにより何の出力が生成されるかを指示するステップ。テストケースごとに、かつそのテストデータセットに対する識別されたルールケースごとに、識別されたルールケースに出力を生成させた、テストケース内の１つ以上の入力値を識別するステップ。また、テストケースごとに、各ルールケースに対して、そのルールケースのどの関係性がそのテストケース内の値により満たされたか、どの関係性が満たされなかったかを指示するステップを含む。

ルールケースには順序があり、テストケースごとの識別されたルールケースは、可能な入力に対する関係性のそれぞれが満たされる順序で第１のルールケースに対応する。第２セットのルールケースを含む第２のルール仕様を受け取るステップであって、１つ以上のルールケースは、第１ルール仕様の１つ以上の出力と、第２ルール仕様の対応する出力との関係性を含む。テストケースごとに、テストケースの入力値を所与として出力を生成することになる第２ルール仕様の内の１つのルールケース、および第１ルール仕様の内の識別されたルールケースの出力を識別するステップ。テストケースごとに、第２ルール仕様の出力の生成を生じることになる第１および第２ルール仕様の入出力間の相互関係のグラフィック表示を生成するステップ。テストケースごとに、テストケースの入力値を所与として出力を生成することになる各ルールケースを指示するステップ。ルールケースごとに、いくつのテストケースがそのルールケースに出力を生成させることになる可能な入力に対する値を有するか、を指示するステップ。

テストケースのそれぞれは出力を含む。識別されたルールケースにより生成される出力が、テストケースに含まれる出力に一致することになるかどうかを決定するステップ、およびその決定の結果を格納する、または通信するステップ。テストケースごとに結果行を含むテーブルを生成するステップであって、各結果行は、テストケースの入力値を所与としてルール仕様により生成される出力を指示する。各結果行において、生成されることになる出力が、ルール仕様の以前のバージョンに対して指示された出力から変更されるかどうかを指示するステップ。ユーザーの、結果行との相互作用に応じて、その結果行に出力を生成することになる、識別されたルールケースを指示するステップ。１つのテストケースに対して、ルール仕様の各ルールケースに対応する評価行を含むテーブルを生成するステップ、および可能な入力ごとに、テストケースにおけるその可能な入力に対する値が、その評価行に対応するルールケースでその可能な入力に対する関係性を満たしたかどうかを、表の各評価行に指示するステップ。テストケースに対する識別されたルールケースに対応する表の評価行に、そのルールケースにより生成されることになる出力を指示するステップ。

評価行の順序は、ルール仕様内のルールケースの順序に対応する。出力が指示される評価行は、可能な入力に対するそれぞれの関係性が満たされる第１ルールケースに対応する。可能な入力に対するそれぞれの関係性がテストケースにより満たされるルールケースに対応する各評価行に、生成されることになる出力を指示するステップ。第２セットのルールケースを含む第２ルール仕様を受け取るステップ、およびテストケースごとに、各ルール仕様により生成されることになる出力を指示するステップ。テストケースごとに結果行を含む表を生成するステップであって、各結果行は、テストケースの入力値を所与としてルール仕様により生成される各出力を指示する。結果行で指示される出力とのユーザーの相互作用に応じて、どのルールケースが、指示される出力を生成するかを指示する。指示されるルールケースは、第２ルール仕様からのルールケースであり、指示されるルールケースを指示するステップは、第１ルール仕様からのルールケースと、指示されるルールケースの入力関係性を満たすそのルールケースの出力とを指示するステップを含む。テストケースのセットを受け取るステップは、ユーザーから１セットの入力値を受け取るステップ、入力値のセットをルール仕様の可能な入力の値に一致させるステップ、および入力値のセットを表の列へ格納するステップとを含む。入力値のセットを受け取るステップは、可能な入力の値の識別を表示するステップに応答する。

総じて、一態様では、データフローを表すリンク要素により接続されるデータ処理成分を有するグラフ型計算の成分であって、その成分は、１セットのルールケースを含むルール仕様に基づいてデータを変換するための変換式を含み、可能な入力に対応する出力との関係性を含む各ルールケースは、実行環境において１セットの入力データでグラフ型計算を実行するステップと、入力データおよびそのセットの入力データ内の各データ項目に対する計算により生成される出力をログ記録するステップ、および実行環境とは別のテスト環境で、ログ記録される入力データセット内のデータ項目ごとに、その項目内の入力値を所与としてログ記録される出力を生成するルールケースの内の１つを識別するステップによりテストが行われる。

本発明の１つ以上の実施の形態の詳細について、付帯する図面および以下の記述で説明する。本発明の他の特徴、目的および利点は、その説明および図面から、ならびに特許請求の範囲から明らかになる。

変換の一実施例である。 グラフの一実施例である。 変換式の生成および更新のブロック図である。 スプレッドシートに基づくルール入力の一実施例である。 個々のルールの一実施例である。 テストデータセットである。 テスト結果である。 テスト結果の詳細である。 テスト結果の詳細である。 フロー図である。 変換コードの一実施例である。 フロー図である。

[0027] ビジネスルールは、例えば、あるフォーマットから別のフォーマットへデータを変換したり、データに関して決定を下したり、あるいは１セットの入力データに基づいて新規データを生成したりするために使用可能な１セットの基準として表すことができる。例えば、図１Ａのフライト予約システムのレコード１０２には、乗客氏名１０４、その乗客が今年利用したマイル数１０６、チケットクラス１０８および座席の列１１０が示されている。ビジネスルールは、この乗客を搭乗グループ１に入れることを指示する。ビジネスルールは一般に人が理解し易いように、すなわち「ファーストクラスの乗客はグループ１に入れる」と表現されるが、それを用いてデータを操作する前に、コンピュータが理解できるものに読み替える必要がある。グラフ型計算環境にビジネスルールを実装するには、１つ以上のデータソース、例えば入力データセット１００からレコード１０２等の入力レコードを受け取り、出力レコード、例えば乗客氏名１０４や、その乗客が属するグループ１１８を示すレコード１１４、を出力データセット１２０に挿入する変換式１１２を生成する。入力および出力のデータセットはデータストリームとも呼ばれる。次に、データフローを表すリンク要素により接続されるデータ処理成分を有するグラフ型計算にこの変換式を実装できる。例えば、図１Ｂの単純な計算グラフ１３０は、２つのデータセット１３２、１３４（例えば、頻繁利用客データおよびフライト予約データ）を入力とし、相互に利用できるように、別々のフォーマット成分１３６、１３８で各セットのデータをフォーマットし、それらを結合成分１４０で結合して出力データセット１４２を生成する。変換式自体は、グラフ１３０のようなグラフ型計算でもよく、グラフ１３０を構成する個々の成分１３６、１３８、および１４０のような成分の中に実装してもよい。

[0028] 技術系ではないユーザーにとって変換式の作成が容易になるようにツールを用意して、そのようなユーザーが、変換式に実行させたいことをコンピューターシステムに語りかけるルールセットと呼ぶ１セットのビジネスルールを親しみ易いフォーマットで入力できるようにする。ルールセットは単一の変換を生み出すルールセットである。ルールは、入力に応じたルールの出力に対して異なる値を計算する１つ以上のルールケースで構成することができる。ルールには別のルールがあってもよい。ルールセット内の別のルールは、追加または代替の出力に対して値を生成できる。ルールセットには、本発明者が「被包含」ルールセットと呼ぶ他のルールセットがあってもよい。

[0029] 変換式生成システムの一般モデルを図１Ｃに示す。生成器１５０は、入力としてルールセット１５２をエディタ１５４から受け取り、変換式１５６を生成する。生成された変換式１５６を、システムのアーキテクチャ、変換目的、およびビジネスルールに応じ、グラフ内で使用する成分として、またはそれ自体をグラフ全体として、グラフ型計算システム１５８に提供する。生成器１５０は、例えば、コンパイラであっても、特注プログラムであっても、ルールセット１５２を受け取り、変換式１５６を出力するための標準ツールを使用して構成される別のグラフ型計算であってもよい。

[0030] 生成器１５０は、ルールセット１５２を編集するときに、変換式１５６を更新してもよい。ルールセット１５２を編集する場合、エディタ１５４は、エディタにルールセット全体を提供してもよいし、単に新規ルール、修正ルール、もしくはルールケース１５２ａのみを提供してもよい。生成器１５０は、使用するシステムの能力および必要性に応じて、全面的に新規な変換式を生成して元の変換式１５６を置換してもよいし、変換式を含む成分１５６ａを提供してもよい。

[0031] 実施例によっては、図２Ａに示すように、ルールをスプレッドシートフォーマットで入力することができる。スプレッドシート２００内のトリガー列２０２、２０４、２０６、２０８は、利用可能なデータ値に対応し、行２１０ａから２１０ｈは、ルールケース、すなわち利用可能なデータ値に関連する基準のセットに対応する。基準を有するルールケースを含むトリガー列ごとに、レコードのデータ値がトリガー基準を満たす場合は、所与のレコード（例えば、図１Ａの１０２）にルールケース２１０ｎが適用される。ルールケース２１０ｎが適用されると、１つ以上の出力列２１２に基づいて出力が生成される。全ての入力関係性を満たすルールケースは、「トリガーされた」と言える。各出力列２１２は、可能な出力変数に対応し、変数がある場合、その変数に対して、適用可能な行２１０ｎの対応セル内の値がその出力を決定する。後述するように、セルは変数に割り当てられる値を収納できる、あるいは出力値を生成するために評価しなければならない式を含むことができる。図２Ａには１つだけ示すが、２つ以上の出力列があってもよい。

[0032] 異なる型のトリガー列がいくつかあり、それらには、変数に対応する列、式を収納するが一回計算されたら変数と同様に扱われる列、および式だけを収納する列がある。他の型の列には、データだけを収納する列、およびデータだけを収納する列に基づいて、行ごとに評価するための式を規定する列がある。式だけを収納する列は、変数に対応する列や変数として扱われる列よりも単純である。このような列は以下の内の１つを含むことができる：
― 式。式の評価が非ゼロ、非ヌルの値と評価される場合、この条件は真と見なされる。
― キーワード「ａｎｙ（任意）」または空の文字列。この条件は常に真である。トリガー列内の空の各セルは、キーワード「ａｎｙ」を明示的に収容するものと等価である。
― キーワード「ｅｌｓｅ（その他）」。左側のセル全てが同一である行において、「ｅｌｓｅ」を収納するセルの上のセルがどれも真でない場合、この条件は真である。
― キーワード「ｓａｍｅ（同上）」。上にあるセルが真の場合、この条件は真である。

[0033] 変数に対応する列には２つの型のセルがある。その１つは式型のセルである。これらのセルは、上記の、式だけを収納する列内のセルと全く同様に振る舞う。但し、式内でキーワード「ｔｈｉｓ」を用いて列変数を参照できる。セルの他の型は比較値である。比較値のための例示の文法は以下の通りである：
comparison_value ::= compound_value ("or" compound_value)*
compound_value ::= simple_value ("and"simple_value)*
simple_value ::= ["not"](value_expression│simple_function│membership_expr)
value_expression ::= [operator] value_element
operator ::= ">"│"<"│">="│"<="│"!="│"="│"equals"
value_element ::= constant│constant│variable"("expression")"
simple_function ::= "is_null"│"is_blank"│"is_valid"│"is_defined"│
"is_bzero"
membership_expr ::= "in" "["value_element ( (","│"to"│"or")
value_element)*"]"
ここで、「*」はゼロ回以上繰り返される項目を意味する。

[0034] 任意の適切なプログラミング言語またはシンタックスを用いることができる。実施例としては、Ｃ、Ｊａｖａ（登録商標）、ＤＭＬ、またはＰｒｏｌｏｇがある。列変数は、演算子、関数、またはメンバーシップの式に基づいて比較値と比較される。図２Ａの実施例では、最初の２列２０２、２０４は、「＞＝」演算子を伴う比較値を収納するので、その列の値が、対応する数字以上の場合に、基準が満たされる。「座席のクラス」列のように演算子がない場合は、「等しい」と考える。定数は、基本システムでどのプログラミング言語またはシンタックスを用いた場合でも、任意の正当な定数とすることができる。他の定数および変数は、後述するルールセット内で定義されるようなビジネス項目である。式は、列変数と比較され、互換データ形式を返す使用言語で表される任意の正当な式である。実施例によっては、比較値内部の式は曖昧さを避けるために括弧で閉じる。ｓｉｍｐｌｅ＿ｆｕｎｃｔｉｏｎに関しては、この関数を列変数に適用するので「ｉｓ ｎｕｌｌ（ヌルである）」キーワードは式「ｉｓ＿ｎｕｌｌ(ｔｈｉｓ)」と同じである。

[0035] 図２Ａの実施例では、第１行２１０ａはただ１つの列２０２に基準を有するが、これは、旅行者のフリークエントフライヤー（頻繁利用客）マイル数合計が１，０００，０００マイルを超える場合、他の列が持つ値に関係なくそのルールケースが適用されることを示す。その場合、そのユーザーに対する「搭乗グループ」出力変数はグループ１に設定される。同様に、第２ルールケース２１０ｂは、ファーストクラスのどの乗客もグループ１に入ることを指示している。実施例によっては、ルールを順番に評価し、それにより、１，０００，０００マイルを超え、かつファーストクラスのチケットをもつ旅行者をグループ１に入れることになるが、トリガーされるのは第１のルールケース２１０ａだけである。ルールケースが一旦トリガーされると、そのルール内の他のルールケースを評価する必要はない。

[0036] 次のルールケース２１０ｃは２つの入力値２０２および２０４がベースになっており、フリークエントフライヤーマイル数合計と今年のマイル数の両方で定義される基準が満たされた場合、その乗客はグループ２に入る。第４のルールケース２１０ｄでは、どのビジネスクラスの顧客も同様にグループ２とする。残りのルールケース２１０ｅ〜２１０ｈは、他のルールケース、すなわち「ｅｌｓｅ（その他）」および「ｓａｍｅ（同上）」に関係する基準を含む。上記のように、「その他」は、その列のどの基準も、その上の行で、かつ左側に同一基準を有する行（すなわち、ルール２１０ｂ、２１０ｄ）では合致しなかったことを指示する一方、「同上」は、列上にあるルールケースがその列に適用された場合に、そのルールケースが適用されることを指示する。従って、第５のルールケース２１０ｅは、最初の２つの列２０２および２０４のどの基準にも一致しなかったレコードであり（なぜなら、２つの列はルールケース２１０ａおよび２１０ｃにより扱われたはずであるから）、かつ、「座席のクラス」列で「ファーストクラス」でも「ビジネスクラス」でもなかったレコードであり（列２０６ではキーワード「その他」）、かつ、１０以下の「座席列」の値である、全てのレコードに適用される。残りの各ルールケース２１０ｆ〜２１０ｈは：上位のどのルールケースも、列２０２および２０４の値と一致しなかった；かつ「座席クラス」列が「ファーストクラス」でも「ビジネスクラス」でもなかった；かつ該当する「座席列」の値を有する；レコードに適用される。

[0037] 図２Ａの実施例のルールケース２１０ａ〜２１０ｈは、図２Ｂに示すように、それぞれをそれ自体のスプレッドシートで、個々の単純なルールとして提示することもできる。ルール２２０ａ〜２２０ｄは、図２Ａの行２１０ａ〜２１０ｄにそれぞれ対応する一方、ルール２２０ｅは、全体として行２１０ｅ〜２１０ｈに対応する４つのルールケースを有する。ユーザーは、図２Ａに示されるテーブル全体を生成するのではなく、これら個々のルールを別々に生成できる。各ルールケースには、トリガー列ごとの値、および出力列ごとの値が収められる（その値はブランク、すなわち、事実上「ａｎｙ（任意）」に設定）。多数のルールが同一出力を生成する場合、それらのルールは順序付けられ、１ルール内のルールケースが入力をトリガーし、出力を生成するまで、順に検討される。１ルール内のルールケースがトリガーしない場合、同一出力を生成する次のルールが処理される。どのルール内のケースも出力をトリガーしない場合、既定値が使用される。

[0038] 実施例によっては、エディターインターフェースにより、式を収めたセルをグラフで識別できる。これは、自らの真偽を評価される式と、列変数と比較された値を返す式との違いをユーザーが見分けるのに役立つ。ユーザーはタイプ入力時に、例えば、開始時にアスタリスクをタイプすることにより、特定のセルが式のセルとなるよう指示することができる。

[0039] 実施例によっては、値および式はＤＭＬの式である。完全なＤＭＬ言語をサポートすることができる。フィールドおよび値の特別なキーワードおよびビジネス名は、ＤＭＬの式ではなく予め処理された文字列としてコード化される。その式には、変数に論理名（ビジネス名）を使用できるが、実際の物理名を参照できる（テストの妨げになるかもしれないが）ことに注意のこと。

[0040] 出力変数に対応する列では、以下の内の１つがセルに収められる：
― 値。出力変数に割り当てられる値。
― 式。式の値が出力変数に割り当てられる。式がＮＵＬＬと評価すると、出力フィールドがヌル不可でない限り、フィールドはＮＵＬＬ値を得る。この場合、エラーが生成される。
― キーワード「ｎｕｌｌ」。出力フィールドがヌル可能な場合、フィールドにはＮＵＬＬが割り当てられる。それ以外はエラーが生成される。
― 空文字列。出力フィールドが既定値を有する場合、既定値が割り当てられる。それ以外は、セルにキーワード「ｎｕｌｌ」が収まっているかのように扱う。
― キーワード「ｓａｍｅ」。出力フィールドには、上のセルで計算された値と同じ値が割り当てられる。

[0041] 可能であれば、できるだけ速やかにエラーを報告する（すなわち、ヌル不可フィールドの出力列に「ｎｕｌｌ」を置く場合）。但し、エラーによっては、テスト時間またはランタイムになってから報告できる。

[0042] 式に加え、ユーザーは、ルール内の任意のセルにコメントを添付することが許される。コメントは、マイクロソフトＥｘｃｅｌ（登録商標）のような普通のスプレッドシートプログラム内のセルに添付されるコメントと同じように表示できる。

[0043] 実施例によっては、ルールエディターインターフェースを構成して、インターフェースのテクニカル要件より厳しく、ユーザーによる入力に制約を課すことができる。例えば、より単純で制約の多いユーザーインターフェースを提供するために、インターフェースは、特定の変数型または特定の式型だけを受け入れるよう構成してもよい。インターフェースは、ユーザーの役割またはユーザーＩＤに基づいて、ルール内のどのセルを変更できるか制約を加えるよう構成してもよい。管理者はこの制約をルールセットに適用できる。

[0044] 表の行として生成するにせよ、個々のルールとして生成するにせよ、各ルールは特定の属性群を有する。ルールセットは、ルールセットに含まれるルールに対してこれらの属性を決定できる。これらの属性は、名前、ルール型、説明およびコメントフィールド、出力変数リスト、入力変数リスト、引数リスト、トリガー列リスト、変更履歴、テストデータセット、ならびにエラー取扱いの振る舞いを含んでもよい。名前は字句通りであり、ルールセット内のルールを記載するために用いる。ルール型は、例えば、「標準」または「関数」とすることができる。実施例によっては、ルール型はルールセットの特性である。出力変数リストは、ルールにより値を生成または割り当てられた変数のセットである。これはルールセットから継承されてもよく、１つ以上の出力があってもよい。入力変数リストは、ルールがレコードを評価するために必要となる全ての変数を識別し、列の上位にある変数および式中で使用する変数を含む（例えば、図２Ａのルール２１０ｃで使用される「昨年度のフリークエントフライヤーマイル数」の値は式中で使用されるが、それ自体の列をもたない）。

[0045] 実施例によっては、多数のルールケースを用いて、単一の入力レコードに対して多数の出力レコードを生成することができる。このようなルールセットは正規化ルールセットと呼ばれる。正規化ルールセットでは、出力の１つはキー出力として識別される。キー出力を計算するルールが評価されると、入力にトリガーされて出力を生成したルールケースが着目される。次いで、前回トリガーされたルールケースを無効にして、そのルールが再度評価され、どれか他のルールケースがトリガーされて、出力が生成される。どのルールケースもトリガーされなくなるまでこれが繰り返される。出力はそれぞれ別々の出力レコードとして格納できる。実施例によっては、１つのルールケースがトリガーされたら、同一入力に対する次の繰返しではグループ内の他のルールケースも無効にされるように、ルールケースがグループ化される。

[0046] 実施例によっては、上記とは逆の方法でルールを評価することができ、行のルールケースはＡＮＤを取り、列のルールケースはＯＲを取る。すなわち、ルールは、全ての行がトリガーされる（行のＡＮＤを取る）が、トリガーされる行ごとに単一セルだけ真となる必要がある（列のＯＲを取る）場合だけ、出力を生成する。

[0047] 引数リストは関数ルールに対してのみ存在する。引数リストは、ルールへの入力であるパラメータの名前および型を識別し、ルールセットの特性であってもよい。トリガー列のリストは、どの列がルールの適用をトリガーするかを識別する。図２Ａおよび図２Ｂの実施例に示す入力変数だけでなく、トリガー列は、パラメータ、ルックアップ変数、初期のルールからの出力変数、被包含ルールセットの出力変数、ルールセットへのパラメータ、または式に対応させることができる。それには、関数ルールからの入力変数、すなわち引数、が含まれてもよい。

[0048] 変更履歴は、変更名、日付、およびコメントを含む。実施例によっては、ルールごとに１つ、テストセットごとに１つの変更履歴がある（後述する）。

[0049] エラーを扱う際に決定されるのは、ルールセットから生成される変換式が、ルールを評価するときに発生するエラーをどのように扱うかということである。トリガーの式のエラーを扱う選択肢は、エラーを許容するか（この場合、エラーを起こすレコードを変換式が受け付けない）、エラーを無視する（トリガーの式が偽であると仮定することと等価であり、次のルールへ移動する）かである。出力式では、エラーを許容し、レコードを受け付ける、エラーを無視して出力をＮＵＬＬに設定する、またはルール内の行を無視して次の行に移ることによってエラーを扱うことができる。

テストデータ
[0050] 意図した通りにルールセットが動作するか否かの評価を支援するために、ルールセットにテストデータセットを含めることができる。ルールセットのためのこのテストデータセットは、例えば、図３に示すような、プロトタイプ入力と期待される出力とのセットである。テストデータセットは、ルールが参照するフィールドごとに１つの行４０２ａ〜４０２ｅと、出力ごと（この実施例では１つしかない）に１つの行４０４とを有するスプレッドシート様の表４００で構成される。次いで、ユーザーは、テストデータおよび期待される結果の列４０６ａ〜４０６ｒに表されるテストケースを作成する。このテストデータはルールと併せて保存される。図３の実施例は、図２Ａ〜図２Ｂのルールに対する可能な入力４０２ａ〜４０２ｅと、意図される出力４０４を収納する。フリークエントフライヤーマイル数および座席割り当ての様々な組合せ４０６に対して、搭乗グループ４０４について計算すべき事柄（図示したよりずっと多い可能な入力の組合せがある）を示す。実施例によっては、テスト入力には全てのルックアップ内の全ての変数に対する値が含まれる。テスト入力には、全てのパラメータに対する値、および現在の日付または時間を参照する何らかのルールに対して、「今」として使用するための値も含まれる。個々のユニットをテストするために、テスト入力には、任意の被包含セットに対する値を含めることができ、それにより、包含ルールセットをテストする場合、被包含ルールセットを評価する必要がなくなる。

[0051] 実施例によっては、ユニットテスト表の列４０２、４０４は、ユーザーアクションに基づいて本ソフトウエアにより決定される。ユーザーがルールを編集する場合、ルールの詳細が構文解析され、参照される入力変数の最終リストが生成される。このリストには、列の見出しで使用される変数と、式に組み込まれる変数とが含まれる。変数ごとに、式へ組み込まれる技術変数ごとに、およびルックアップの式ごとに１つの列が生成される。実施例によっては、ユーザーがテストケースを１つずつ提供することにより、テスト表４００を生成する。例えば、ユーザーは、フリークエントフライヤーマイル数合計２，０００，０００マイル、今年のマイル数２００，０００マイル、昨年のマイル数１５０，０００マイル、および５列目のファーストクラス座席チケットを有する顧客を搭乗グループ１に指定できる。本ソフトウエアは、行４０２ａ〜４０２ｅおよび４０４のどれがこれらの入力および出力に対応するかを決定し、表４００に対応する列４０６ａを作成する。ユーザーが記入を希望する数と同じだけこれを繰り返すことができる。場合によっては、どの変数がその値を必要とするかをユーザーが知らなくても値を単に記入または選択できるように、本ソフトウエアが、可能な入力または出力のそれぞれをユーザーに提供するインターフェースを提供できる。

[0052] 次いで、ユーザーは、テストケースに記入し、テストを実行できる。その時点で、本ソフトウエアは、テストデータセット表のラインごとにルールを評価し、結果として得られる値を計算する。得られる値が期待値（出力変数に対応する列内にユーザーが記入する値）と一致する場合、ルールが正当であるという指示、例えば、出力セルを緑で示す、が与えられる。得られた値が期待値と一致しない場合、例えば、そのセルは赤で指示され、期待値および実際の値の両方が表示される。次いで、ユーザーは、テストケースを更新するか、あるいはルールを固定することができる。無論、他のユーザーインターフェースメカニズムを用いることもできる。例えば、計算した出力を、入力の期待出力と比較するのではなく、テスト手順により、計算した出力だけを表示し、ユーザーにそれが正しいかどうか評価させることができる。

[0053] 実施例によっては、ユーザーは、テストデータの作成に使用できるリアルデータを有する。ビジネスルールの最終ユーザーは、テストで使用するためのそのようなデータを開発者に提供できる。テストで使用するリアルデータをユーザーがもたない場合を取り扱うために、本ソフトウエアは、テストデータを１レコードずつ入力するための単純なデータ記入形式を提供できる。ユーザーは、入力データセット内のフィールドそれぞれの値をタイプ入力することができ、これらのレコードは識別されたテストデータセットに追加される。

[0054] 実施例によっては、ルールは記入時に正当性を評価され、期待された出力を生成しないルールは、ワードプロセッサが記入時にスペルミスの語句にマーク付けする場合と同様に、インターフェース内で直ちに識別できる。

[0055] 実施例によっては、テスト実施後に、ユーザーはテストデータセット表の任意の行（テストケース）を選択できる。行を選択すると、そのテストケースの出力を生成したルール表中の対応行が表示される。式に加えて、ユーザーは、テストデータセット表中の任意のセルにコメントを添付できる。

ルールセットの詳細
[0056] 上記のように、変換式はルールセットから生成される。ルールセットは以下の属性を有する。

[0057] 名前、説明、およびコメント―これらはルールセットの識別に役立つ。バックエンドの実装に応じて、ルールセットには、システム内の場所の識別が含まれてもよい。実施例によっては、ルールセットの場所はプロジェクト内のパスである。実施例によっては、ルールセットはリレーショナルデータベース内で体系化され、名前で検索できる。変更履歴には、変更名、日付、およびチェックインのコメントが含まれる。

[0058] 変換式の形式―これは、どの型の変換式がルールセットから生成されるかを決定する。可能性のある値としては、後述するように、再フォーマット、結合、ロールアップ、およびフィルタがある。

[0059] 入力データセット―これらはフィールドのリストおよび編集用の名前を付けた定数を提供する。実施例によっては、変換式を生成する場合、既定設定により、入力データセットの内の１つのレコードフォーマットを用いることを前提とする。多数の入力データセットがあってもよいので、ルールセットは異なる環境のための変換式を生成できる。これにより、多数のセットの論理マッピングを物理的マッピングへ、すなわち、物理的な名前が異なるセットへ、配分することもできる。実施例によっては、１つ以上のデータセットを有する入力マッピング表がある。実施例によっては、結合成分は多数の入力マッピング表を有してもよく、それぞれは多数のデータセットを有する。

[0060] 出力データセット―これらは出力フィールド名のリストを提供する。変換式を生成する場合、既定設定により、出力データセットの内の１つのレコードフォーマットを用いることを前提とする。出力データセットは、入力データセットと同一とすることができる。被包含ルールセットは、出力データセットを持たない。実施例によっては、入力データセットと同様に多数の出力データセットがあるので、ルールセットは異なる環境のための変換式を生成できる。

[0061] 被包含ルールセットのリスト―あるルールセットは、別のルールセットにより計算された出力フィールドを用いることができる（明示的にリストにされた出力フィールド。出力レコードフォーマットのフィールドではない）。被包含ルールセット内の出力変数は、包含ルールセット内に見える被包含ルールセットからの出力変数のセットを定義する被包含ルールセットのマッピング表に基づいて、包含ルールセット内の変数として使用できる。

[0062] 被包含変換式のファイルリスト―ルールセットを処理する際に使用する変換式を指定する１つ以上のファイルをオプションで包含できる。

[0063] 変数および定数をリストにする一連のマッピング表 ― これらの表は入力および出力のデータセットに結びつけられる。これらの表は、変数リストをエディタに知らせ、ビジネス名と技術（ＤＭＬ）名との間のマッピングを記録する。各変数は、ビジネス名、技術名（ＤＭＬの式）、およびベース形式（文字列、数字、日付または日時）を有する。ビジネス名とＤＭＬ定数値との間のマッピングを記録するオプションの定数リストが、各変数と関係付けられる。定数リストの詳細は後述する。

[0064] 外部テストデータファイルへの参照―テストファイルは、上記組込みテストデータセットと同様に、ルールのテストに使用される。

[0065] 非拒否フラグ―このフラグが設定されると、ルールセットが生成する変換式はレコードを拒否しない（エラーを生む）。これは、そのルールが決してトリガーされないかのごとく、エラーを生むルールが無視されるように使用できる。

[0066] 展開表―これは１つ以上の展開をリストにし、どのルールを各ビルドに包含させるべきか（間接的に）指示する。展開表の詳細は後述する。

[0067] オプションキー―これは、結合型およびロールアップ型のルールセットのためのキーを表す特別な入力フィールドのビジネス名をユーザーに指定させる。実施例によっては、このキーは、ある種のキーとともに入力変数表の項目として実装される。

[0068] ルックアップファイルのオプションリスト―これは、ビジネス名、キー情報ならびに入力変数および定数の完全な表、ルックアップファイルごとに１つの表、を提供する。ルックアップファイルのサポートの詳細は後述する。

[0069] パラメータ表―これは、その値が環境、またはランタイム時にパラメーターセットによってもたらされる変数をリストにする。

変数および定数の表
[0070] 上記のように、各ルールセットは、変数および定数が関係する表のセットを有する。実施例によっては、これらの表は、ルールセットに固有であり、ルールセット間で共有することはできない。変数および定数の表はいくつかの目的で使用される：
１．ルールセットが使用する入力変数と、ルールセットが生成し、計算する出力変数との最終的なリストとして。
２．編集中に利用可能なビジネス名のリストとして。編集中に本システムは、変数および定数のビジネス名のリストを提示する。このリストは、変数および定数の表によってもたらされる。
３．ビジネス名を技術名へ読み替えるマッピング表として。このルールはビジネス名を含む（後述するように、テキストで、ＤＭＬプリプロセッサ指令の内部で）。変換式が生成されると、ビジネス名は技術名またはＤＭＬの式により置換される。入力変数および出力変数のような表のいくつかは、多数のデータセットを有することができ、それぞれがビジネス名に対して異なる技術名を有する。使用される読替法は展開に依存する（詳細は後述する）。

[0071] ルールセットは異なるいくつかの表を有する。これらの表はほとんど類似するが、僅かな違いがある。以下の表が含まれる：
１．入力の変数および定数の表。変換式型ルールセットでは、この表は、ルール内で参照される入力レコードフォーマットのフィールドを収納する。レコードフォーマットでのフィールド全てをリストにする必要はないが、普通はそうする。結合型ルールセットでは、多数の入力表があり、各表は結合操作に対して１つの入力データセットを表す。
２．全ての被包含ルールセットのための入力の変数および定数の表。被包含ルールセットを用いる場合、各被包含ルールセットは、それ自体の入力の変数および定数の表を有する。変換式が立てられると、被包含ルールセットが使用する入力変数を、包含を行うルールセットに照らして実際の入力にマッピングしなければならない。従って、このリストは包含ルールセットへ展開される。多数の被包含ルールセットを包含する場合、各入力変数の表が展開される（被包含ルールセットがルールセットを包含する場合、第２レベル変数は展開されない）。被包含ルールセットから展開される入力の変数および定数は、包含ルールセットでの使用には利用できない。この表は単に包含されるだけなので、マッピングは、被包含ルールセットへの入力と包含ルールセットへの入力との間で確立できる。詳細については後述する。
３．全ての被包含ルールセットの出力の変数および定数の表。ルールセットが既に包含されている場合、これらの被包含ルールセットの出力は、包含ルールセットへの入力となる。この表はこれら変数全てをリストにする。この表は、初期状態では、全ての被包含ルールセット内の出力の変数および定数の表から直接読み込まれる。但し、ビジネス名を変更して名前衝突を避けることができる。この表において、技術名は被包含ルールセット内部のビジネス名のままである。
４．出力の変数および定数の表。変換式型ルールセットでは、この表は、ルールセットが計算する出力レコードフォーマットのフィールドを収納する。計算されない出力変数は包含されることができるが、ルールセットにより無視されることになる。（生成される変換式は、入力を出力へコピーするワイルドカードのルールを有する。更に、出力により、既定値を包含させることができるだろう。）
出力変数を中間変数として用いることもできるが、これは１つのルールから生成される出力の値が後のルールで参照できることを意味する。時には、出力をこの方法だけで使用する。出力が、変換式から出力レコード内へ直接的に包含されることはあり得ない。
５．パラメータの表。ルールパラメータへの参照を含む。パラメータは、グラフのパラメーターセットに照らしてランタイム時に変形される。パラメータは、他の変数と同様に、ルールセット内にビジネス名、技術名（例えば、＄ＲＵＮＤＡＴＥ）および型を有する。
６．ルックアップファイルごとの変数マッピングの表。これらは入力表と同様であるが、ルックアップファイル用のレコードフォーマットでフィールドへマッピングする。

[0072] 非共用ルールセット（変換式を生成するよう設計されている）は、入力データセットおよび出力データセットの両方に通常は結びつけられている。入力データセットは入力変数のソースである。出力データセットは出力変数のソースである。時には、ルールセットは、多数の入力データセットおよび／または多数の出力データセットを有する。その場合、入力データセットおよび出力データセットはそれぞれ、可能性のある変換式の入力または出力である。１セットの入力変数だけがあるが（結合操作は除く）、異なるデータセットに対してビジネス名と技術名との間の異なるマッピングがあってもよい。場合によっては、入力変数をルールセットが使用でき、入力変数は、ある入力データセット内には存在するが２番目の入力データセット内には存在しない。その場合、２番目の入力データセット内の欠落した変数の技術名として、ＤＭＬの式を指定しなければならない。ルールセットが入力変数を使用しない場合、全ての入力データセットに対して技術名を提供する必要はない。

[0073] 同様に、１セットの出力変数しかないことがある。所与の出力データセットが出力変数に対応するフィールドを持たない場合（すなわち技術名がない）、その出力データセットに対する変換式を生成する時、その出力は無視される。

[0074] 被包含ルールセット取扱いはいくらか異なる。被包含ルールセットは、関係する入力および出力のデータセットをもたない。その代わりに、入力変数および出力変数だけを有する。被包含ルールセットを包含するルールセットの役割は、入力と出力をマッピングすることである。詳細については後述する。

変数
[0075] 変数は以下の特性を有し、表形式でユーザーに提示される：
１．ビジネス名（論理名）。ビジネス名はルールで使用される名前である。実施例によっては、２つの入力変数が同一名を持たず、２つの出力変数が同一名を持たず、被包含ルールセットからの２つの出力が同一名を持たず、そして同一ルックアップファイル内の２つのルックアップ変数が同一名をもたないように制限される。入力変数は、出力変数と同一名を持つことができる。その場合、ユーザーインターフェースは前後関係に基づくか、または出力変数名の前に「ｏｕｔ」のような接頭語を用いて入力と出力の曖昧さを解消してもよい。異なるルックアップファイル内のルックアップ変数は、同一名を持つことができる。その場合は、ルックアップファイル名自体等の接頭語を用いて曖昧さを解消する。
２．単純な型。実施例によっては、４つの基本型−文字列、数字、日付および日時−をサポートすることができる。これらは、ＤＭＬ型文字列（ｉｎｔ）、１０進数（２０）、日付（“ＹＹＹＹ-ＭＭ-ＤＤ”）および日時（“ＹＹＹＹ-ＭＭ-ＤＤ ＨＨ２４:ＭＩ:ＳＳ．ｎｎｎｎｎｎ”）に対応する。変換式で使用される基本型と実際型の変換は、ビジネスルールの編集とは別に、例えば、生成される変換式成分により、扱われる。
３．既定値。既定値は出力変数だけに必要である。これは、（１）その出力に対するルールの出力列に空のセルがある場合、または（２）ルールがその出力の値を計算するのをトリガーしない場合に用いられる値である。既定値は、出力変数がＮｕｌｌ可能な限りＮＵＬＬとする（および空のセルをＮＵＬＬと解釈する）ことができる。
既定値は、ルール式の表の出力列で使用される式と全く同じ式である。これは、既定値が入力変数または出力定数を参照でき、または式を収納することができるということである。既定値は、循環性が導入されていない限り、他の出力を参照することもできる。
４．技術名（物理名）または式。これは変数を指定する式である。入力変数および被包含変数のフィールド名の代わりに式を使用できる（実施例によっては、式の使用は出力変数には許されない）。ベクトルの場合には、式は完全修飾形であること。
入力要求されている変数および被包含ルールセットからの入力変数および出力変数を処理する場合、変数に関係する技術名は、共有ルールセット内で使用されるビジネス名そのものだけである。共有ルールセット内だけで使用される出力変数を処理する場合（１つのルールで計算されて、後続のルールで使用される中間変数）、技術名をブランクとすることができる。
５．オプションとしての説明およびコメント

定数
[0076] 変数の各種表は、変数だけでなく定数のマッピングも含む。定数はＣ＋＋のｅｎｕｍに対応する。本ソフトウエアは、正当な値および不当な値に由来する初期状態の定数値、ならびに正当な範囲および不当な範囲に由来する初期状態の定数範囲をサポートできる。さらに異なる値および／または範囲のセットを表す定数を生成することができる。

[0077] 定数は変数と関係付けられる。これは、定数のビジネス名がルールセット全体を通じて一意でなくてもよいということである。エディタは、その定数がルール内のどの列に現れるかに基づいて、任意の定数に対するコンテクストを知るのが普通であるが、ユーザーは、式中の異なる変数に属する定数を選択できる。その場合、定数は、変数名（例えば、「Ａｉｒｌｉｎｅ Ｃｌａｓｓ．Ｂｕｓｉｎｅｓｓ（航空路クラス．ビジネス）」により限定される。

[0078] 出力変数を計算する場合、単一の値の定数だけが使用される（出力フィールドに範囲を割り当てるのは無意味である）。

[0079] 定数は、以下の特性を有し、表形式でユーザーに提示される（変数および定数は、表を別の表に組み込む場合と同様に、混ざり合ってもよい）。
１．変数名。全ての定数は１つの変数だけに適用される。変数名は、実際には関係する変数自体の一部である。
２．ビジネス名。ビジネス名はルールで使用される名前である。名前は値で示す識別子でなくてもよい。具体的には、内部スペースおよび句読点が許される。定数に対するビジネス名は、適用する変数の範囲で一意でなければならないということだけである。
３．定数型。値、範囲、またはセットの内の１つ。上記したように、範囲およびセットは、比較で用いる場合（入力）のみ必須であるが、割り当てで用いる場合（出力）は必須ではない。
４．値に関して：実際値。本実施例では、文字列は引用符で囲み、数字は囲まない方がよい。日付および日時は、既定形式にて引用符で囲むのがよい（例えば「“ＹＹＹＹ-ＭＭ-ＤＤ”」）。式が変数型へ自動変換される単純な型を返す限り、式を用いてもよい。
定数が、被包含ルールセットの入力または出力のテーブルの一部である場合、値は存在しない。その代わり、値は、対応する入力または出力の変数に対する関係定数のビジネス名である。
５．範囲に関して：最小値および最大値。ともに、上記実際値とまさに同じく、定数または式である。範囲は、ルール内比較の簡易表現として使用される。等式による比較だけが範囲に許され、本ソフトウエアは、範囲を「変数＞＝最小値および変数＜＝最大値」に読み替える。最小値が規定されない場合、その部分の比較はスキップされる。最大値についても同様である。範囲は、コンマで最小値と最大値を区切って実際に格納される。
６．セットに関して：コンマで区切った値のリスト。リストの各要素は、上記実際値とまさに同じく定数または式である。等式による比較だけがセットに許され、本ソフトウエアは、セットを「［値のベクトルリスト］の変数メンバー」の形式で式に読替える。
７．オプションとしての説明およびコメント

[0080] 共有ルールセットからの展開される変数を処理する場合、定数も展開される。共有ルールセットに対する入力および出力の変数を示す表中に、これらの変数に関係付けた定数も示される。これら定数に対する既定のマッピングは、展開される情報の一部であるが、ユーザーは定数値を書き換えることができる。

[0081] 本ソフトウエアは、変数の使用時に定数不一致に起因するコンフリクトの可能性がある場合を検出する。具体的には、（１）ある変数の値が別の変数へコピーされる場合、（２）両方の変数が、定義された定数を持つ場合、および（３）定数のセットが名前および値の両方で同一でない場合、ユーザーがある変数の値を他の変数の値に読替えねばならなくなるエラーが発生する。ソース変数には、入力変数、ルックアップ変数、被包含ルールセットからの出力、および入力として使用される出力変数が含まれる。ターゲット変数には、出力変数、および被包含ルールセットへの入力が含まれる。割り当ては、ルール式または変数表で行われることがある。

名前の制約
[0082] 入力として用いられるもの全ては、全ルールセット内で一意の名前を持たねばならないことが一般的である。これには、入力変数のビジネス名、パラメータのビジネス名、および全ての被包含ルールセットの出力にマッピングされるビジネス名が含まれる。入力操作に関しては、異なる入力セット内の入力変数は同一名を持てる。同一名は、例えば、入力セットのビジネス名に対応する接頭語により、曖昧さを解消できる。

[0083] 出力変数も一意でなければならない。但し、出力変数は、入力変数と同一名であってもよい。出力変数が入力変数と同一名の場合、および入力変数名が許される場所（ルールに対するトリガー列内のように）で変数名を用いる場合、入力変数を用いることを前提とする。出力変数を代わりに用いるには、変数名を記入するときに、例えば、「ｏｕｔ．<変数名>」を記入することにより、名前に条件を付ける必要がある。これはインターフェース表記だけであり、変数の内部表記に曖昧さはない。

[0084] 同一名を有する変数と定数の曖昧さが依然として存在しうる。その場合、同一名の定数と変数の両方が意味を有する状況では、本ソフトウエアは定数の方をとる。ユーザーは、変数名に、例えば、シンタックス「ｉｎ．<変数名>」を用いて条件付けすることにより、それを書き換えることができる。

[0085] 実施例によっては、ビジネス名は、国際的な文字を含めることができるのでＵＴＦ−８仕様であることを前提とする。ビジネス名には、スペース、ピリオド、括弧等を含めることができる。但し、この実施例には、ビジネス名に０ｘ００〜０ｘ３１の文字（制御文字）を含めることはできない。全てのビジネス名の整合においては大文字と小文字を区別する。ユーザーがユーザーインターフェースでビジネス名の大文字、小文字を間違って入力しても、例えば、オートコンプリート機能を用いて、正しい大文字、小文字が指示される。

変数の序列
[0086] 循環ロジックを防ぐために、本ソフトウエアは、変数およびルールの厳格な序列を実施する。全般的な序列は以下の通りである：
１．入力変数およびパラメータ。
２．第１の被包含ルールセットの入力マッピング。
３．第１の被包含ルールセットの出力値。
４．Ｎ番目の被包含ルールセットの入力マッピング。
５．Ｎ番目の被包含ルールセットの出力値。
６．第１のルックアップファイルの既定キー値。
７．第１のルックアップファイルの出力フィールド。
・・・
８．Ｎ番目のルックアップファイルの既定キー値。
９．Ｎ番目のルックアップファイルの出力フィールド。
１０．全ての出力変数の既定値。

[0087] 各項目の計算では前回のステップで計算された値を用いる。この意味は、例えば、第１の被包含ルールがそのマッピング表の入力変数およびパラメータを参照できるということである。但し、第２の被包含ルールは、その入力を第１の被包含ルールから計算された出力へマッピングできる。同様に、各出力変数の既定値がどのルールよりも前に計算されるので、それら既定値は、入力変数、パラメータ、ルックアップファイル、またはどれかの被包含ルールからの出力の値に基づくルールの出力を実際に計算する時間になると、後のルールが先のルールから計算される値を用いることができるように、ルールは順に評価される。

変数へのデータセットのリンク
[0088] 実施例によっては、入力変数の表は、入力データセットレコード形式から直接得られ、ビジネス名は入力データセットのメタデータから得られる。しかし、実施例によっては、ルールセット内にこのマッピングのコピーを持つと便利である。第１に、ルールセット内に変数マッピング表のコピーを持つことにより、生成環境の状況から外れてルールセットを編集できるようになる。ルールセットと関係するルールとは、サンドボックス内でシリアル化し、サンドボックスプロジェクトの一部として編集できる。第２に、入力変数マッピング表のコピーを持つことにより、コンフリクトをユーザーが解決するか、または既存のメタデータを書き換えることができる。例えば、入力データセット内の２つのフィールドが同じビジネス名にマッピングされたとすると、これらのビジネス名の１つを入力変数表の中で変更できる。

[0089] 初めにルールセットが生成されたとき、入力変数表は空である。ユーザーが入力データセットを識別すると直ぐに、入力変数表が入力データセットのメタデータから自動的に記入される。（同じロジックが出力変数および出力データセットにも適用されるが、これ以降は簡単にするために入力データセットだけに説明を絞る）。

[0090] 簡単にするために、単独の用語「入力データセット」をこの説明で用いる。入力変数にリンクできるゼロ以上の入力データセットと、出力データセットにリンクできる別のゼロ以上の入力データセットとがある。詳細には、入力変数表は、ビジネス名に対して１つの列、型などに対して１つの列、および技術名に対して多数の列（入力データセットあたり１つ）を有する。単一の入力データセットが指定されると、同様な技法を用いて２番目を追加できる。但し、２番目または後続のデータセットの場合には、技術名とビジネス名との間のマッピングが不完全なことがある。その詳細な理由は、本システムが、２番目および後続のデータセットがフィールドごとにどの変数にマッピングされるか理解できないからである。そのような実施例では、ユーザーは、どの情報が失われても手動で訂正できる。

[0091] 最初に入力データセットから入力表を生成するとき、入力データセット内の各フィールドは１つの入力変数を生成させる。入力変数の技術名はフィールド名とする。型はフィールド形式に基づいて割り当てる。ボイドは文字列と同様に処理し、実数は数字と同様に処理する。サブレコード内部のフィールドは対応する入力変数を持つが、サブレコードは対応する入力変数を持たない。ユニオンはユニオンのブランチごとに入力変数を生み出す。要素がベクトルの場合、対応する入力変数の技術名は、ベクトルの最初の要素（ｉｎ．ｖｅｃｔ[０]）から付けることを前提とする。ユーザーはこれを書き換えることができる。例えば、正規化型変換式では、ユーザーは技術名をｉｎ．ｖｅｃｔ[ｉｎｄｅｘ]とするように変更してもよい。さもなければ、ベクトルが固定長の場合、ユーザーは、ベクトルの他の要素に対応する追加の入力変数を生成してもよい。ユニオンおよびベクトルは、出力データセットではサポートされなくてもよい（それらのために出力変数は生成されない）。実施例によっては、正規化成分の変形が、多数の出力レコードの代わりに出力ベクトルを出力してもよい。

[0092] いくつかの実施例では、ビジネス名はメタデータから計算される。フィールドのビジネス名を決定するためのロジックは、以下の通りである：
１．フィールド（物理要素）が表示名を有する場合、フィールドの表示名をビジネス名として用いる。
２．それ以外の、フィールドが論理要素をもち、論理要素が表示名を有する場合、論理要素の表示名がビジネス名として用いられる。
３．それ以外の、フィールドが論理要素を有する場合、論理要素名がビジネス名として用いられる。
４．それ以外の場合、ビジネス名は技術名から算出される。

[0093] コンフリクト（二重の名前）が起きる場合は、唯一のビジネス名が割り当てられる。他のフィールドにはどのビジネス名も割り当てられない。

[0094] 実施例によっては、ルールセットとデータセットのメタデータとの間の動的リンクがない。ユーザーがメタデータのデータを変更する場合（例えば、論理要素の改名）、本ソフトウエアはその変更を自動的にピックアップすることはない。実施例によっては、データ間の双方向の関係性を用いてその変更を検出できるようにする。

[0095] ユーザーが第２データセットをルールセットへ追加する場合、本ソフトウエアは、上で挙げた同じ、物理要素から論理要素へのマッピングルールを用いて、ビジネス名それぞれについてフィールドに満たそうとする。変数をマッピングできない場合、その変数に対する技術語は追加データセットのためにブランクのままとし、ユーザーは、フィールド名または式を手動で記入しなければならない。利用可能フィールドは、ユーザーインターフェースのプルダウンでリスト表示される。

[0096] 入力変数表がデータセットのメタデータから生成されると同時に、定数もデータセットのメタデータから入力変数表に追加される。本ソフトウエアは、論理要素または物理要素のそれぞれに関係する正当性仕様に関連する全ての正当な値および不当な値ならびに全ての正当な範囲および不当な範囲に対して定数を生成する。

[0097] 定数に対するビジネス名を決定するための論理は以下の通りである：
１．正当な値（正当な範囲等）が表示名を有する場合、表示名をビジネス名として用いる。
２．それ以外の、正当な値（正当な範囲等）が記述を有する場合、その記述がビジネス名として用いられる。
３．それ以外の場合、定数は、ビジネス名なしで変数表に含まれる。

[0098] データセットで始まる変数を生成することは必ずしも必要ではない。入力変数のリストを生成する第２の方法は、基本システム内の論理エンティティを識別することである。論理エンティティを選択すると、本ソフトウエアは、論理エンティティ内の論理要素ごとに１つの変数を有する変数表を生成する。変数のビジネス名は論理要素の表示名とする。論理要素が正当性仕様を有する場合、以前の文書ルールを用いて定数も生成する。

[0099] 最後に、入力変数および出力変数を、変数表を相互に追加するか、またはルールを編集しながらそれらを生成するかのいずれかにより、手動で追加できる。例えば、ユーザーがある列をあるルールに追加するとき、ユーザーは、どの入力変数をその列に使用すべきか選択する。但し、ユーザーは「ｎｅｗ...」を選択し、オンザフライで入力変数を生成することもできる。次いで、本ソフトウエアは、ユーザーにデータ型およびオプションのコメントを記入するよう促す。技術名は後で記入してもよい。

[0100] 本ソフトウエアには、ルールの編集を可能にするための変数リストが必要である。しかし、ビジネス名と技術名との間のマッピングは、後で完成させてもよい。マッピングは、ユーザーが外部テストファイルに対して全ルールセットをテストするか、またはルールセットから変換式を実際に生成するかの準備ができている場合だけ必要である。

被包含ルールセット
[0101] 実施例によっては、ルールセットを共有できる。詳細には、被包含ルールセットは、別のルールセット内部に包含されるように設計されるので、その論理は包含ルールセットの生成変換式の一部となる。

[0102] 被包含ルールセットは、専ら共用されるように設計されるのが通常であるが、変換式を生成するために被包含ルールセットを単独でも使用できる。例えば、ユーザーは、フィルタ型変換式のブール出力を計算するルールセットを生成できる。しかし、同時に、そのルールセットを別の変換式内に包含させて、ブール出力（包含ルールセットで利用可能な、共用されるルールセットの出力変数）を用いてもっと複雑な出力を計算することができる。

[0103] 被包含ルールセットは、他の形式のルールセットと同様である。被包含ルールセットは入力変数および出力変数を有する。被包含ルールセットは、それ自体、他の被包含ルールセットを包含できる。しかし、被包含ルールセットの入力および出力の変数の取扱いは、変換式型ルールセットを有するものと異なる。変換式型ルールセットでは、入力および出力の変数は技術名にマッピングされるので、変換式を生成することができる。しかし、被包含ルールセットでは、入力および出力の変数を技術名にマッピングする必要がない。（あるルールセットが変換式を生成するために共用され、かつ使用される場合、変換式を生成する展開のために入力および出力の変数技術名にマッピングされる）。

[0104] ユーザーが被包含ルールセットを別のルールセットに包含させる場合、包含ルールセットは、被包含ルールセットの入力および出力をマッピングするための変数マッピング表を有する必要がある。包含ルールセットに関連して、共用されるルールセットの入力変数および出力変数だけが見える。共用されるルールセットに包含される任意のルールセットのどの変数も、包含ルールセットには現れない。

[0105] 包含ルールセットに関連して、共用ルールセットの入力変数は、包含ルールセットの変数、またはこれらの変数を用いる式にマッピングする必要がある。共用ルールセットのビジネス名は、変数マッピング表にリスト化されるが、これらの名前を包含ルールセット内のルールで使用することはできない。というより、包含ルールセットは、共用ルールセットの各入力変数を包含ルールセット内の式に一致させる（ビジネス名により）ことだけが必要である。

[0106] 被包含ルールセットの評価は、入力変数、パラメータおよびルックアップの前に行うのがよいとされているので、被包含ルールセットの出力をルックアップのキーとして使用できる。実施例によっては、評価の順序はもっとフレキシブルであり、ルックアップ対被包含ルールセットの評価の順序は、依存関係に基づいて自動的に決定される。被包含ルールセットを評価してからいずれかの出力変数を計算するので、包含ルールセット内の出力変数を被包含ルールセット内の入力にマッピングできない。被包含ルールセットの入力へのマッピングを単純な入力変数で済ませることができない場合、代わりに、式を用いることができる。

[0107] 被包含ルールセットの入力変数へのマッピングは、被包含ルールセット内の入力変数がヌル可能な限り、ＮＵＬＬとすることができる。マッピングはブランクのままにできる。マッピングがブランクのままである場合、その入力変数が包含ルールセットの出力の計算で必要とされる場合で、かつその場合に限り、変換式生成時にエラーが報告される。実施例によっては、全てがヌル可能というのが前提であり、それにより、ユーザーインターフェースが簡略化される。

[0108] 包含ルールセットに関連して、共用ルールセットの出力変数も、包含ルールセット内のビジネス名にマッピングする必要がある。このマッピング表は上記のマッピング表とは逆である。共用ルールセットの入力変数をマッピングするとき、その表は、共用ルールセットの入力変数のビジネス名を包含ルールセット内の既存変数にマッピングする。しかし、共用ルールセットの出力変数をマッピングする場合、包含ルールセットは、共用ルールセット出力のビジネス名を規定する表，―包含ルールセット内の名前を、共用ルールセット内の対応する名前にマッピングする表―，を有する。

[0109] 出力変数マッピングは、起きる可能性がある名前コンフリクトを解決するのに必要である。既定のマッピングは、包含ルールセットおよび共用ルールセットの両方で同一ビジネス名を用いているに過ぎない。しかし、共用ルールセット内の出力変数の名前は、包含ルールセットで既に定義されている変数のビジネス名とコンフリクトするかもしれないので、包含ルールセット内の名前を付されたマップを変更できる。

[0110] 共用ルールセットからの出力を全てマッピングする必要はない。ある出力がマッピングされないままの場合、その出力を包含ルールセットで用いることはできず、共用ルールセットからの対応するロジックは無視される。他方、ルールセット設計者が必要ないと確信している場合は、関心のない変数へマッピングできないが、共用ルールセットからの入力を全てマッピングすべきである。実施例によっては、本システム自体は、どの入力を実際にマッピングする必要があるかを決定できる。

[0111] 実施例によっては、マッピング表はビジネス名で行われ、参照によって行われない。共用ルールセットが別のルールセットに包含される場合、包含ルールセットは、共用ルールセットから入力および出力のコピーを得る。これらの名前は、マッピング情報とともに包含ルールセットに格納される。共用ルールセットの変更は可能なので、いくつかの入力または出力を追加、削除、または改名させることができる。

[0112] 包含ルールセットと被包含ルールセットの間の参照整合性問題は、そのルールセットが本システムからロードされるときに、包含ルールセットにより取り扱うことができる。共用ルールセットから消える入力変数は、包含ルールセットから削除される。共用ルールセットに追加される入力変数は、包含ルールセット内のマッピング表に追加されるが、マッピングされないままである。同様に、共用ルールセットに追加される出力変数は、包含ルールセット内のマッピング表に追加されるが、マッピングされないままである。出力変数が共用ルールセットから削除され、包含ルールセット内で使用されない場合、マッピング表から削除されるだけであるが、出力変数が包含ルールセット内で使用される場合は、ユーザーは変数がもはや利用できないというエラーを通知される。

[0113] 包含ルールセットは、共用ルールセットからの冗長な情報を実際に維持する。詳細には、包含ルールセットは、入力および出力の変数マッピング表に、包含ルールセット内の対応する名前と併せて共用ルールセット内のビジネス名のリストを維持することだけが必要である。効率を上げるために、包含ルールセットは、全て共用ルールセットからコピーされた、型、既定値、説明およびコメントも維持する。これらの値は、包含ルールセットを編集するときに読み取られるに過ぎないが、報告書生成および他の分析の効率向上のために包含される。

[0114] 共用ルールセットのマッピング表は、包含ルールセット内に、コメントを追加する１つの追加記入項目も有する。これによりユーザーはマッピングされた値に別のコメントを追加できる。

共用ルールセットのための定数
[0115] 共用ルールセットの入力および出力の変数のための定数が、被包含ルールセットのマッピング表内に包含される。変数自体と同様に、共用ルールセットが使用する定数をマッピングしなければならない。入力変数では、共用ルールセットは、フィールドを入力表で定義される定数と内部比較できる。別のルールセット内に共用ルールセットが包含される場合、その入力変数の定数は、包含ルールセットに重ねてコピーされる。次いで、ユーザーは、包含ルールセットに関連してその値を書き換えることができる。通常は、共用ルールセットの入力変数と包含ルールセット内の変数との間のマッピングをユーザーが定義した場合、２つの変数間の定数はよく調和する。そうでない場合、ユーザーは、共用ルールセットが定義するどれかの定数値に技術的な値を提供する必要がある。

ルックアップファイル
[0116] ルールセットは、オプションとして１つ以上のルックアップファイルを有することができる。ルールセット内のルックアップファイルはそれぞれ以下の情報を含む：
１．ルックアップファイルのビジネス名。
２．オプションの説明およびコメント。
３．キーを作成するフィールドのビジネス名のリスト。これらの名前は、ルックアップファイルが式に追加される場合に用いられるので、ユーザーは次のような文を提示される。ｌｏｏｋｕｐ（Ｍｙ Ｌｏｏｋｕｐ Ｆｉｌｅ，＜顧客名キー＞，＜アカウント形式キー＞）
４．キーそれぞれの既定の式のリスト。
５．ルックアップファイルの技術名。実施例によっては、これを展開の中で書き換えることができる。
６．１つ以上のルックアップデータセット。各ルックアップファイルは、本システム内で、ルールセットが入力データセットと結合されているのと全く同様に、データセットに緩く結合している。既定設定により、ルールセット内の各ルックアップファイルと関係する１つのルックアップデータセットがあるが、代わりの展開で使用するためのもっと多くのルックアップデータセットを存在させることができる。
７．入力の変数および定数の表。これはルックアップファイルごとに１つの表があることを除いて、ルールセットの入力の変数および定数の表と全く同じである。入力変数と同様に、ルックアップファイルの入力の変数および定数の表は、関係するルックアップデータセットそれぞれに対応する多数の技術名を有することができる。

[0117] ２つ以上のルックアップファイルが存在してもよいことを除き、ルックアップファイルは、入力変数と全く同様に取り扱われる。各ルックアップファイルは、１つのページ上で編集され、ビジネス名と技術名との間のマッピング表を有し、多数のデータセットと関係付けることができる。ルックアップファイルは、各フィールドと関係付けられる定数も有する。ルックアップファイルのマッピングは、入力変数のメタデータが入力データセットからロードされるのと全く同様に、ルックアップデータセットのメタデータを読み込むことにより初期化できる。

[0118] ユーザーがルックアップフィールド変数を用いる場合で、そのキーがルックアップ内に見つからない場合、フィールドの値はヌルとするのを前提とする。フィールドがヌルの場合、ルールケースが特にトリガーしない限り、ルールケースは偽と評価され、スキップされる。そのような場合、エラーは発生しない。ユーザーがルックアップファイル変数（ルックアップファイル自体であり、フィールドではない）を用いる場合、関数ルックアップの一致は、ルックアップファイル変数が真または偽の評価するのを前提とする。両方の場合とも、入力または出力の列に対するルール式へ適用される。ユーザーが出力変数の既定設定としてルックアップフィールド変数を用いる場合、ルックアップを見つけるのに失敗するとＮＵＬＬに読み替えられる。

パラメータ
[0119] ルールセットはパラメータを参照できる。実施例によっては、各ルールセットは、オプションのパラメータ表を有し、その表は、変数表と同様に、パラメータのビジネス名を技術名にマッピングする。パラメータ表の各項目は以下の属性を有する：
１．ビジネス名。ビジネス名は、ルール本体に現れるときのパラメータの名前である。一般に、パラメータは、入力変数が使用されるところではどこでも使用できる。
２．技術名。これは、開発環境におけるパラメータの名前である。
３．パラメータの型（文字列、１０進数、日付、日時）。生成された変換式で、パラメータは必要に応じて他の型に変換できる。
４．オプションについての説明およびコメント。

[0120] パラメータは、入力ファイル全体にわたってパラメータ値が定数であることを除いて変数と同様であり、その値は処理が開始されると外部から指定される。

テストルール
[0121] 変換式の生成または更新の一部は、変換式が、対応するルールをテストすることである。ルールは検証もされる。すなわち、ルールのシンタックスおよびセマンティックの一貫性がチェックされる。検証とは対照的に、テストはルールの実行を伴い、例えば、期待される出力がもたらされるか、または出力を期待値と手動で比較することにより、ユーザーが正当性を判定する。

[0122] 本ソフトウエアは、２つのレベルでテストをサポートする。上記のように、各ルールは、値および期待される結果を組み込んだ表形式で、関係するテストデータセットを有することができる。これはユニットテストと呼ばれる。ルールを編集する場合、テストデータのラインごとにルールの出力を再評価することができる。実際の結果と期待される結果との間のなんらかの不一致、または正当な結果の生成失敗は、解決するようハイライトされる。

[0123] 実施例によっては、外部入力テストファイルは、標準メカニズムを用いてサーバープロセスにアクセス可能である。外部ファイルを用いるテストは、ファイルテストと呼ばれる。テストファイルは、ルールセットの入力データセットと一致するレコードフォーマットを有する。実施例によっては、代替のレコードフォーマットが提供される。オプションとして、ユーザーは、期待される結果を収納するデータセットを識別できる。本ソフトウエアは、テストデータセットに対してルールセットを実行し、どのような出力が、なぜ生成されたかを表示する。期待された結果が含まれていた場合、本ソフトウエアは実際の結果を、期待された結果に対して比較し、差異のあるレコードをすべてリストにする。実施例によっては、ユーザーが個々の値をインクリメンタルに再試行できるようインターフェースを拡張することができる。

[0124] ユニットテストとファイルテストとの間のいくつかの差異には以下が含まれる：
１．ルックアップファイルに関して：ユニットテストモードでは、テストケースごとに各ルックアップ変数の値がテストの一部として定義される。キーは規定されない：テストが実行された場合、テストケースごとに、ルックアップ変数ごとに同一の値を前提とする。テストデータセットは、多数のテストケースを収納し、各テストケースは、ルックアップ変数ごとに異なる値を規定できる。ファイルテストモードでは、実際のルックアップファイルが用いられる。この意味は、異なるキーが異なる値を返すということであるが、特定のキーに対する何らかの所与のルックアップ変数に用いられる値がテスト中に変更できないということも意味する。
２．被包含ルールセットに関して：ユニットテストモードでは、被包含ルールセットは実行されず、完全である必要すらない。その代わりに、各被包含ルールセットからの出力ごとに、テストデータセット内で値を指定する。ファイルテストモードでは、被包含ルールセットが、稼働中に実行されるはずの方法で実行される。この意味は、被包含ルールセットが必要とする何らかのルックアップファイルまたはパラメータをも、テスト時に指定しなければならないということである。
３．パラメータに関して：ユニットテストモードでは、各テストケースに対してパラメータごとに異なる値を設定できる。ファイルテストモードでは、各パラメータの値はテスト全体に対して定数である。
４．現在の日付に関して：テスト時に、ルールが現在の日付または時間を参照する場合、ユーザーは、現在の日時に対して想定すべき値を指定する。ユニットテストモードでは、日付および時間はテストケースごとに異なっていてもよい。ファイルテストモードでは、テスト全体に対して単一の日付および時間の値が設定される（この値は、テストが実行時のマシンの日付および時間と異なっていてもよい。
５．レコードフォーマットおよびマッピングに関して：ユニットテストではマッピングを指定する必要はなく、テストは変数のビジネス名に基づいて全体的に実施される。ファイルテストでは、全ての変数は技術名にマッピングされ、入力、出力およびルックアップのレコードフォーマットが指定される。

[0125] 図４Ａの実施例示の出力スクリーンには、結果表４１０が表示され、それには、テストケースおよびそれぞれについて計算される出力を示す列４１３ａ〜４１３ｄを有する別々の行４１２ｉに、テストケースごとの出力が表示される。１つの行４１２ａを選択すると（図４Ａに一点鎖線で示す）、対応するテストケースからの入力値４１４ａ〜４１４ｇを入力表４１４に示す。そのテストケースの出力４１６ａ〜４１６ｃを出力表４１６に示す。表４１６に示す出力４１６ｉはテストケースからの期待出力、実際の計算出力、またはその両方となり得る。様々なインターフェースの合図を用いてテストの状態についてユーザーに知らせることができる。例えば、アイコン４１９は、最後にルールセットがテストされて以降、テストケース２、４の行４１２ｂ、４１２ｄの出力が変更されていることを示す。どれか他のルールセットと一致しない入力値の組合せをとらえる「既定」のルールがない場合、そのような入力を有するテストケースではヌル出力４１８が生成される。入力レコードが、ゼロで除算するような処理エラーにより拒否された場合、同様にエラーを指示することができる。２つ以上のルールケースがテストケースによりトリガーされる場合、トリガーされたルールケースの番号を指示できる（４２２）。表示される出力の内の１つと相互作用することにより、例えば、それをクリックすることにより、図４Ｂに示すように、その出力がどのように決定されたかを詳細に説明するスクリーンにユーザーを導くことができる。

[0126] 図４Ｂの例示の出力スクリーンで、表４３０は、図４Ａからの単一のテストケースに対するルールを表示し、ルールケース４３４ｉのどれかで真であった入力基準４３６ｉそれぞれを太枠で指示する。例えば、６番目のルールケース４３４ｆでは、第３および第４入力４３６ｃ、４３６ｄの値を収納するセルは、テストケース４１２内のこれらの入力の値４１２ｆ、４１２ｇがルールケース内の値（クラスがファーストクラスまたはビジネスクラスでなく、列が＜＝４０）と一致するのでハイライトされる。実際には、ハイライト、色、フォント、または境界線等の、多様なグラフィック技法の任意の技法を用いて、真および偽のセルを区別できる。全ての値がテストケースと一致する最初のルールケースであるルールケース４３４ｃは、そのルールをトリガーし、図４Ａのライン４１２ｂに示される出力を生成したルールケースとして枠を一点鎖線で示す。トリガーされたルールケース４３４ｃだけでなく他のルールケースも表示するので、ユーザーは適用されたルールケースおよび所望の出力を得るのに必要な変更を迅速に決定できる。実施例によっては、トリガーできた複数のルールケース（例えば、上位のものがトリガーされなかった場合）を指示することもできる。各ルールケースが生成する出力（もしトリガーされていた場合）を列４３８に指示することができる。これらの機能は例えば、ルールケースをデバッグする際に役立つ。

[0127] 実施例によっては、あるルールセットの出力は別のルールセットへの入力とすることができる。その場合にルールセットが所与のテストケースをどう評価するかを図４Ｃにグラフで示す。図４Ａ、図４Ｂでテストケース旅行者を搭乗グループ２に分けるビジネスルールを、テストケース表４１２から入力を受け取り、出力表４１６へ出力するボックス４４２として示す。この実施例では、第２のビジネスルールが、年間マイル数が増加している旅行者に報奨を与えるべきことを指示する。そのルールは、テストケースからの入力に加えて、マイル数が増加しているという第１ルールからの決定を入力として受け取り、ボックス４４４として示される。乗客がエコノミー席なので、このルールにより顧客に無料ドリンクを提供する（顧客がファーストクラスなら無料ドリンクを既に受け取っているので別の報奨が準備される）。実施例によっては、表示されるルールをクリックすると、ユーザーは、第１ルール４４２の図４Ｂに示すような、そのルールがどのようにトリガーされたかを示す表示に導かれる。

[0128] ルールセットは、図５に示されるプロセスを用いてテストされ、正当性が評価される。１つ以上のルールセット６０２および対応するテストデータ６０４がこのプロセスに入力される。本ソフトウエアは、ルールセットに基づいて変換式（６０６）を生成し、それを用いてテストデータ内の全てのレコードの出力値を計算する。グラフ計算では、関連成分の「ログ」ポートを出力テストのために用いる。テスト用に生成された変換式は、実行用に生成される変換式と僅かに異なることがある。テスト時には、追加出力が出力レコードに追加される。この出力は、実際に出力を生成したルールセット、およびこれらのルールセットの内でその出力に関わったルールセットの識別を収納するアレイである。テストケースごとに複数の出力、すなわち異なるルールセットから異なる出力を生成できる。このアレイを用いて、上記のように図４Ａ、図４Ｂに示す出力表を生成する。実施例によっては、テスト出力は、単純なアレイではなく複雑である。出力には、所与のレコードに対する全入力の値、全パラメータの値、被包含ルールセットからの全出力の値、および全ルックアップファイルから読み出された値（ルックアップに用いられたキーの指示を含む）が含まれる。

[0129] 第１のテストケースで開始する（６０８）と、テストケースの入力が変換式に入力され（６１０）、どのルールがそれを生成したかの指示と併せて、出力が出力アレイに書き込まれる（６１２）。このプロセスを、最後の行が評価される（６１４）まで、行ごとに繰り返す（６１４、６１６）。次いで、上記のように、出力アレイを用いて結果表４１０、４２０を生成する（６１７）ことができる。図５の残りのステップに示されるように、出力アレイを評価してルールセットが正当かどうかを決定できる。出力値を１つのテストから生成された出力値のテストデータに含めて、以前のテストで生成された値と比較できる。出力アレイの第１行で開始する（６１８）と、生成された出力が、テストデータ６０４からの期待出力または以前のテスト結果６１７と比較される（６２０）。どの出力も一致しない場合、不一致がログに記録される（６２２）。行ごとにこれを繰り返す（６２４、６２６）。実施例によっては、評価ステップが出力生成ステップに統合され、生成出力はそれぞれ、生成されたときに、対応する期待出力と比較される。テストデータ結果を処理する際の何らかの不一致または他のエラーは、ログに記録される。上記のように、ルールセットの出力を別のルールセットに入力でき、その場合、被包含ルールセットが包含ルールセットの一部として評価される。

[0130] ユーザーは、出力フィールドがテストするルールを制限できる。実施例によっては、ユーザーは、テスト中にルールを無効にするよう選択できる。実施例によっては、ユーザーは、処理されるテストファイル全体を待たなくてもよい。すなわち、テスト結果は、第１の少数のレコードが出力へ達すると直ぐに利用可能となる。

[0131] テストデータ自体に加えて、以下の情報のどれかをファイルテストに用いることができ、ルールセットの一部として含めることができる：
１．入力データセットの物理場所。これは、入力データセットごとに入力変数表内のルールセットに格納される。結合型データセットでは、全ての物理場所が必要である。物理場所が必要な場合、データベース内の表の名前を用いることができる。
１．入力データセットのレコードフォーマット。既定設定によれば、これは入力データセット用のデータセット定義から得られる。サンドボックス内で点検された別のレコードフォーマットでこれを書き換えるための場所が入力変数内にある。結合型変換式では全てのレコードフォーマットが必要である。
２．どの展開を使用するか。
３．全てのルックアップファイルの物理場所。これはルックアップファイル表内に格納される。
４．ルックアップファイルごとのレコードフォーマット。ルックアップファイルそれぞれと関係するデータセット定義から、または書き換えレコードフォーマットファイルから得られる。
５．パラメータごとの値。テストパラメータダイアログ内で設定される。
６．出力ファイルの物理場所。回帰（比較）テストを行う場合にだけ必要である。出力変数表に格納される。
７．出力ファイル用のレコードフォーマット。上記と同様に、回帰テストを行う場合にだけ必要であり、出力データセット定義から、またはオプションの書き換えレコードフォーマットファイルから得られる。
８．プロジェクトサンドボックスの場所。テストはホスト上のサンドボックスの外で行わねばならない。サンドボックスは、ルールセットを収納するプロジェクトの点検済みコピーでなければならない。全てのレコードフォーマットファイルは、サンドボックスから得られる。
９．ルールが「今」、「今日」または類似の値を参照する場合の日付および時間に使用する値。

[0132] ３つの変換形式が可能である：ログを記録しないもの、全ての入力、出力、実行されるルール等をログ記録するもの、および各ルール内のどのセルが偽またはヌルかについての詳細を追加して含むもの。テストは、後者２つのログ形式のどちらかを用いることができる。変換がセル状態を記録しない場合、これはユーザーインターフェースに示されないだけである。入力、出力等のログ記録は実行速度を低下させるがその量は僅かである。セル状態のログ記録は実行速度を大幅に低下させ、おそらく一桁は小さくなる。

[0133] テストでない場合、ユーザーはやはり入力、出力等のログを記録する変換式を生成でき、稼働時にその変換式を用いることができる。強化した変換式は同一出力を生成するが、どのルールが実行されたかを決定するよう実行後に解析できる一連のログメッセージも生成する。生成されたログをユーザーが保存しておくと、図４Ａ、図４Ｂ、図４Ｃの情報を計算するためにテスト入力を用いなくても、ログ情報を用いて稼働中のルールセット実行を事後に再現するよう、「ビジネスルール環境」を使用できる。本発明者は、これを実行の再生と呼び、監査に役立てる。

オーバーラップ解析
[0134] 実施例によっては、上記のように、ユーザーがルールセットに対してテストデータセットを実行すると、トリガーされたどのルールも追跡することができる、すなわち、優先度が高いルールケースも、その全ての入力条件を満たさなかったとしても、全ての入力条件を満たすようにしたルールケースが、出力を生成したはずである。テストデータを処理した後、本ソフトウエアはテスト出力データを後処理し、どのテストケースにもトリガーされなかった全てのルールまたはルールケースのリストを生成できる。この情報は、エディタ内のルールの表示上にオーバーレイして、どのルールがトリガーされたか、またはされなかったかをユーザーに直ちに示すことができる。この情報から、ユーザーは他のルールにより覆い隠されている可能性のあるルール、すなわち、重なりあっているルールを探すことができる。ルールケースごとにカウントを示すこともできる。カウントは、ルールケースがトリガーされたかどうかを知ることと同じくらい有用なことがあり、特に、出力の所望の分布を達成するよう値を調整し、性能を調整するのに最適なルールセットを識別するのに有用である。

変換式生成
[0135] ビジネスルールは、各ルールセットを変換式へ変換することにより、アプリケーション（グラフ）で評価される。次いで、変換式をグラフ内の成分へ貼り付ける。そのような成分は、変換式を実行するために特定の方法でリンクされる１セットの標準成分を収納するサブグラフであってもよい。次いで、これらのサブグラフを追加した成分とともに用いて、例えば、結合およびロールアップのためのキーを使用できる。

[0136] 変換コードを、様々な方法でビジネスルールから生成することができる。例えば、変換式の内部が、ユーザー編集できるようには設計されていない場合、生成プロセスは理解が困難な変換式を生じることがあるが、変換式は、ルールを１つずつ適用するよりずっと効率的にルールを実施する。実施例によっては、図６に示すように、単純な「ｉｆ−ｔｈｅｎ−ｅｌｓｅ」のチェーン文５００を用いてルールセット内のロジックを取得できる（図２Ａのルールセット表２００を参照のために繰り返す）。図示のチェーン文５００では、ルールケース２１０ａごとに１つの「ｉｆ．．．ｔｈｅｎ．．．」節５０２ｉがある。このようなチェーンはそのまま用いることができるし、あるいは、適切な計算リソースの利用可能性および本システムのユーザーの優先度に応じてさらに最適化することもできる。場合によっては、特別なルックアップファイルまたは他の技術を用いて変換式生成の性能を向上させることができる。変換式を生成する方法のいくつかの詳細は、展開内に格納することができる。多数のグラフで使用されるルールセットは、可能性がある別のユーザーのための多数の展開を有してもよい。ルールセットは、ルールのスーパーセットを収納することもでき、その内のいくつかだけが各展開で要求され、その展開は、変換式の生成時に、どのルールを使用するかを識別する。

[0137] 実施例によっては、ルールが１０進数である列を含み、その列に合う大きな数字の別の値がある場合、指示される列に分岐する「スイッチ」文を書くことにより、変換式の性能を向上させることができる。例えば、以下のルールを考える：

[0138] このルールに対する変換式は、以下のように、２つの方法で生成することができる：
if (NUM == 1 and ROW < 10) then BG = 1
else if (NUM == 1) then BG = 2
else if (NUM == 2 and ROW < 15) then BG = 1
else if (NUM == 2) then BG = 2
else if ...
もう１つは：
Switch(NUM)
Case 1: if (ROW < 10) then BG = 1 else BG = 2
Case 2: if (ROW < 15) then BG = 1 else BG = 2
...

[0139] 使用できる別の手法は、メモリ内ルックアップファイルである。あったにせよ、ほとんどないに等しい式を有するルールが、多数の定数値を有する場合、「ｉｆ−ｔｈｅｎ−ｅｌｓｅ」ロジックの代わりに使用できるのが、まさにルックアップ表である。この場合、ルックアップ表はルールの一部である（別々に保存されない）。例えば、このルールを考えてみると：

[0140] このルールは、以下の情報によりメモリ内ルックアップ表を構成することにより取り扱われる：

次いで、変換式は以下のようになる：
int expr = lookup(from, dest, class).expr
int miles = lookup(from, dest, class).miles

if (expr == 1 and is_using_miles) miles = 0
return miles;

[0141] 各ルールセットは展開表を有する。展開表は、その展開の構成に関して名前を細部へマッピングする。展開表の各項目は、以下の情報を収納する：
１．展開名。ルールセット内部で一意でなければならない任意の文字列。
２．入力データセット名。入力変数表に挙げた複数の入力データセットがある場合、展開表内の項目はそれぞれ、その展開でどの入力データセットが使用されるかを指示する。
３．出力データセット名。出力変数表にリスト化された複数の出力データセットがある場合、展開表内の項目はそれぞれ、その展開でどの出力データセットが使用されるかを指示する。
４．被包含ルールセットごとの展開名。被包含ルールセットごとに、実施者は、対応する被包含ルールセットの展開ごとにどの展開を使用すべきかを指示する必要がある。
５．成分および生成されるべき変換式ファイルに対するターゲットの場所。

[0142] 実施例によっては、常に、少なくとも１つの、既定設定と呼ばれる展開がある。これは他の展開が規定されない場合に使用される展開である。

[0143] 例示一の実施の形態には、変換式生成の基本が示される。最初に、本ソフトウエアは、ルールセット内で計算される出力のためのルールを生成するだけである。他の出力は全て、変換式内でワイルドカードルールを使って扱われる。概して、内部だけで使用される出力変数は、作成された変換式内でローカル変数を生成させる。とはいえ、作成された変換式は、重複計算を避けるために、必要に応じてさらにローカルな変数を含んでもよい（例えば、最適化が空き領域より速度を目的とする場合）。

[0144] 図７は、生成された変換式内でどのようにルールセットが評価されるかを示す。出力ごとに（７０２）、関連ルールが順に評価される。互いに素である出力を生成するルールでは、変換式作成器は依存関係解析に基づいてルール評価の順序を決定する。巡回性は認められず、エラーとして報告される。２つ以上のルールが同一出力を生成する場合、その実行順序は、ルールセット内のリストの順序と同一である。各ルール内部で（７０４）、ルールケースは上から下へと順に評価される。ルールケースごとに（７０６）、各ルールのトリガー列は未定義の順序で評価（７０８）することができる（例えば、ソフトウエアが単一のルールケース内部の評価順序を保証しないことがある）。全てのトリガーが真である（ゼロ／偽でなく、ヌルでもない）１つのルールケースが見つかると直ちに（７１４）、対応する出力値が用いられる（７１６）。ルールケースが偽と評価する限り、プロセスは継続される（７１８、７１２、７２０、７２２）。どのルールも所与の出力をトリガーしない場合（７２０）、変換式は、その出力値を明示的にＮＵＬＬまたは適切な既定値に設定する（７２４）。

[0145] 変換の型に応じて、変換にはいくつかの差異がある：
― 再フォーマット―入力は「ｉｎ」と呼ばれ、入力変数は「ｉｎ．ｆｉｅｌｄ」等の技術名を有することができる。出力は「ｏｕｔ」と呼ばれ、出力変数は「ｏｕｔｆｉｅｌｄ」等の技術名を有することができる。
― 結合―２つの入力は「ｉｎ０」および「ｉｎ１」と呼ばれる。出力は「ｏｕｔ」と呼ばれ、ワイルドカードルールは「ｉｎ０」を「ｏｕｔ」にコピーすることを前提とする。全てのパラメータは成分が生成されたときに設定できる。ルールセットは、その結合への入力ごとに１つの、多数の入力セットを有する。ルールセットは、入力を重複除外すべきか、フィールドのビジネス名を結合に対するキーとして使用すべきかの、結合型の指定も行う（実施例によっては、これは各入力セットで提示されなければならない）。また、ユーザーは、入力ごとに、入力フィルタとして使用される式を指定することもできる。
― ロールアップ―入力は「ｉｎ」、出力は「ｏｕｔ」と呼ばれる。ロールアップ型のルールセットの場合には、ユーザーは集合関数を使用することが許される（他の変換型ではサポートされない）。技術名が「ｉｎｐｕｔ ｓｅｌｅｃｔ（入力選択）」または「ｏｕｔｐｕｔ ｓｅｌｅｃｔ（出力選択）」の出力変数をユーザーが生成する場合、「ｉｎｐｕｔ ｓｅｌｅｃｔ」および／または「ｏｕｔｐｕｔ ｓｅｌｅｃｔ」の関数を、これらの出力を計算するルールのロジックとともに変換式に追加する。これら両関数の入力は「ｉｎ」と呼ばれる（「ｏｕｔｐｕｔ ｓｅｌｅｃｔ」は通常、そのパラメータを「ｏｕｔ」と名付けるが）。結合型と同様に、成分が生成されたときに全てのパラメータが設定される。
― フィルタ―２つの所定の定数の一方が出力される。フィルタ型変換式の出力変数は、型成分の「ｓｅｌｅｃｔ,（選択,）」だけであり、出力を通過させるには非ゼロ、非ＮＵＬＬである。実施例によっては、これはサブグラフ内の再フォーマット成分として実装される。

[0146] 追加の変換型も実装できる。
― スキャン―スキャン関数は、「ｔｅｍｐ（一時的）」および「ｉｎ」と名付けた２つの入力をとり、「ｏｕｔ」と名付けた出力を生成する。ルールセット内のルールは「ｔｅｍｐ」レコードおよび「ｉｎ」レコードの両方のフィールドを使用することができる。これは入力変数のための技術名により決定できる（例えば、技術名は、文字列「ｔｅｍｐ．ｆｉｅｌｄ」または「ｉｎ．ｆｉｅｌｄ」に設定できる）。
変換式の一時的変数（「ｔｅｍｐ」）のためのレコードフォーマットは、ルールセットにより生成される全ての出力を収納する。初期化関数がソフトウエアにより自動的に作成されて、一時的なレコードフォーマット内の全てのフィールドを既定値に初期化する。終了関数もソフトウエアにより自動的に作成され、この関数は、一時的レコードを出力にコピーし、ワイルドカードルールを追加するだけである。スキャン型変換式も、ロールアップの場合と同様に、これらの技術名を有する変数が出力変数表にある場合、入力選択関数および出力選択関数の作成をサポートする。
― 正規化―正規化関数は「ｉｎ」および「ｉｎｄｅｘ」の２つの入力をとり、「ｏｕｔ」と名付けられる出力を生成する。インデックス入力はレコードではなく、ユーザーがルール内のインデックスを用いたい場合、インデックスの技術名にマッピングされた入力をユーザーが生成する。（インデックス変数は各種のＤＭＬ式内でも使用される）。本ソフトウエアは上記したように、ルールを通過するときにある長さ。
正規化型ルールセットは、ロールアップ型ルールセットと全く同様に、「ｉｎｐｕｔ＿ｓｅｌｅｃｔ（入力選択）」および「ｏｕｔｐｕｔ＿ｓｅｌｅｃｔ（出力選択）」と名付けられた出力変数もサポートする。
― 分類―ルールはＮ個の出力をもち、変換式は、レコードごとにどの出力を用いるべきか決定する。この成分では、本ソフトウエアはｏｕｔ::ｃｌａｓｓｉｆｙ(ｉｎ)関数を作成する。出力は一個の整数値であり、どの出力ポート（２つ以上ある）を使用すべきか指示する。０の出力は、０番のポートを意味し、１の出力は１番のポートを意味する。
分類型変換の出力変数は、型成分の「ｓｅｌｅｃｔ（選択）」だけであり、それを出力ポートのインデックス（ゼロ基準）とする。これは、出力の２の代わりにＮ値が用いられることを除けばフィルタと同様である。
― 関数―関数型ルールセットを、ＤＭＬ変換ファイルに変えることができるが、成分変換としてではない。代わりに、関数型ルールセットを変換式に変える場合、構築した変換ファイルは、他の変換式に含まれるように設計される。出力変数それぞれをＤＭＬ関数に変える。これら関数の入力は、ルールの型に依存する。関数型ルールでは、入力は表にリスト化した順序のルールへの入力である。非関数型ルールでは、出力関数はそれぞれ、「ｉｎ」と名付けられた単一の入力をとり、その入力は、入力変数に対応するフィールド全てを有するレコードである。

[0147] ルールセットを用いて、次にグラフの一部となる変換式を生成する場合、グラフ成分には、ルールセットおよび展開の名前が含まれる。次いで、グラフ開発者は、成分内で生成された変換式の代わりに、そのルールセットを編集することができる。ルールセットの変更により、その変換式は再生成される。

[0148] 他の特徴および改変には、特別なルールセットで使用するルールに関するレポート、例えば、何人かのユーザーにルールを編集させるが入力は追加させないようにするもっときめ細かい許可モデル、を生成するステップを含めてもよい。出力ごとに内部規則依存性ツリーを実装できる。ルールまたはルールセットは発効日または有効期限を持つことができる。単一の入力レコードは多数の出力を生成でき、例えば、多数のルールがそれらの基準を満たす場合、それらは全て最初の１つに代わって動作できる。ベクトル出力のサポートを提供することができる。ユーザーは編集中に自身の正当性関数を規定でき、例えば、ビジネスユーザーをさらに保護または抑制することができる。

[0149] 上記のビジネスルール管理手法は、コンピュータ上で実行するためのソフトウエアを用いて実装することができる。例えば、本ソフトウエアは、１台以上のプログラムされた、またはプログラム可能なコンピューターシステム（分散型、クライアント／サーバ型、またはグリッド型等の、多様なアーキテクチャからなる）上で実行される１つ以上のコンピュータープログラム内の手順を形成し、それぞれのコンピューターシステムには、少なくとも１つのプロセッサ、少なくとも１つのデータ格納システム（揮発性および不揮発性メモリおよび／または格納素子を含む）、少なくとも１つの入力装置またはポート、および少なくとも１つの出力装置またはポートを含む。本ソフトウエアは、例えば、計算グラフの設計および構成に関連する他のサービスを提供する更に大きなプログラムの１つ以上のモジュールを形成できる。グラフのノードおよび要素を、コンピュータで読み取り可能な媒体に格納されるデータ構造として、またはデータ収納庫に格納されるデータモデルに準拠する他の体系化データとして実装できる。

[0150] 本ソフトウエアは、汎用または専用のプログラマブルコンピュータにより読み取り可能なＣＤ−ＲＯＭ等の媒体上で提供されるか、またはネットワークを介して本ソフトウエアが実行される場所のコンピュータに配送される（伝搬信号にコード化される）。全ての関数は、専用コンピュータ上で、またはコプロセッサ等の専用ハードウエアを用いて実行できる。本ソフトウエアは、本ソフトウエアが規定する計算の異なる部分が、異なるコンピュータにより実行される分散方式で実装できる。そのようなコンピュータープログラムはそれぞれ、格納媒体または格納装置をコンピューターシステムで読み取って、本明細書に記載した手順を実行する場合、コンピュータを構成し、動作させるための、汎用または専用のプログラマブルコンピュータ読み取り可能格納媒体または格納装置（例えば、固体メモリや媒体、または磁気媒体や光媒体）に格納されるか、またはダウンロードされるのが好ましい。本発明のシステムは、コンピュータープログラムで構成されたコンピュータ読み取り可能格納媒体として実施されると考えることもでき、その場合、そのように構成された格納媒体により、コンピューターシステムは、本明細書で説明した関数を実行する特定の、予め定義された方法で動作する。

[0151] 本発明のいくつかの実施の形態を説明したが、言うまでもなく、本発明の精神および範囲を逸脱することなく多様な改変を実施できる。例えば、上記のいくつかのステップの順序は自由であるので、説明した順序と異なって実行できる。

[0152] 言うまでもなく、上記説明の意図は、本発明の範囲を説明するためであって、制限するためではなく、本発明は付帯する特許請求の範囲により定義される。例えば、上記のいくつかの関数ステップは、全体の工程に実質的に影響を与えずに、異なる順序で実行できる。他の実施の形態は付帯する特許請求の範囲に含まれる。

Claims (75)

1. 計算をテストするための方法であって、
   第１のセットのルールケースを含む第１のルール仕様を受け取るステップであって、各ルールケースは、可能な入力と対応出力との関係性を含み、前記ルールケースの内の少なくとも１つは、２セット以上の可能な入力が満たす関係性を含む、ルール仕様を受け取るステップ、
   １セットのテストケースを受け取るステップであって、前記各テストケースは１つ以上の前記可能な入力に対する値を収納する、テストケースを受け取るステップ、
   前記テストケースごとに、前記テストケースの入力値を所与として出力を生成することになる前記第１のルール仕様内に含まれる前記ルールケースの内の１つを識別するステップ、
   第２のセットのルールケースを含む第２のルール仕様を受け取るステップ、
   前記テストケースごとに、前記テストケースの前記入力値を所与として、前記第１または第２のルール仕様によって生成された各出力を指示する結果行を表示するステップ、および
   前記第２のルール仕様から、第２のルールケースの出力を指示する結果行中で指示された出力とのユーザーの相互作用に応じて、前記第１のルール仕様からの第１のルールケースと、前記第１のルールケースの出力とを指示し、前記第１のルールケースの前記出力は、単独で、または他の値との組み合わせで、前記第２のルールケースの入力関係性を満たすステップ、
   を含む方法。
2. 前記テストケースごとに、出力を生成するルールケースを識別するステップに応じて、生成されることになる前記出力の指示を格納または出力するステップをさらに含む、
   請求項１に記載の方法。
3. 前記セットのテストケースを受け取るステップは、
   １セットのテスト列を含む表を受け取るステップを含み、前記各テスト列は、対応する前記１つのテストケースに対する前記１つ以上の可能な入力に対する値を収納する、
   請求項１に記載の方法。
4. テストケースごとに、かつそのテストケースに対する前記識別されたルールケースごとに、前記識別されたルールケースにより何の出力が生成されるかを指示するステップをさらに含む、
   請求項１に記載の方法。
5. テストケースごとに、かつそのテストデータセットに対する前記識別されたルールケースごとに、前記識別されたルールケースに出力を生成させる原因となった、前記テストケース内の１つ以上の前記入力値を識別するステップをさらに含む、
   請求項１に記載の方法。
6. テストケースごとに、前記各ルールケースに対して、そのルールケースのどの関係性が前記テストケース内の値により満たされたか、そしてどの関係性が満たされなかったかを指示するステップをさらに含む、
   請求項５に記載の方法。
7. 前記ルールケースには順序があり、前記テストケースごとの前記識別されたルールケースは、前記可能な入力に対する関係性のそれぞれが満たされる順序で第１のルールケースに対応する、
   請求項１に記載の方法。
8. 第２セットのルールケースを含む第２ルール仕様を受け取るステップをさらに含み、１つ以上の前記ルールケースは、第１ルール仕様の１つ以上の出力と前記第２ルール仕様の対応入力とに対する関係性を含む、
   請求項１に記載の方法。
9. テストケースごとに、前記テストケースの前記入力値を所与として出力を生成することになる前記第２ルール仕様の内の１つの前記ルールケース、および前記第１ルール仕様の内の前記識別されたルールケースの前記出力を識別するステップをさらに含む、
   請求項８に記載の方法。
10. テストケースごとに、前記第２ルール仕様の出力の生成をもたらす前記第１および第２ルール仕様の入出力間の相互関係のグラフィック表示を生成するステップをさらに含む、
    請求項９に記載の方法。
11. テストケースごとに、前記テストケースの前記入力値を所与として出力を生成する前記各ルールケースを指示するステップをさらに含む、
    請求項１に記載の方法。
12. ルールケースごとに、いくつの前記テストケースがそのルールケースに出力を生成させる前記可能な入力に対する値を有するかを指示するステップをさらに含む、
    請求項１に記載の方法。
13. 前記テストケースのそれぞれが出力を含み、前記識別されたルールケースで生成される前記出力が、前記テストケースに含まれる前記出力と一致するかどうかを決定するステップ、および
    前記決定の結果を格納する、または通信するステップをさらに含む、
    請求項１に記載の方法。
14. テストケースごとに結果行を含むテーブルを生成するステップをさらに含み、前記各結果行は、前記テストケースの前記入力値を所与として前記ルール仕様により生成される出力を指示する、
    請求項１に記載の方法。
15. 各結果行において、生成されることになる前記出力が、前記ルール仕様の以前のバージョンに対して指示された出力から変更されるかどうかを指示するステップをさらに含む、
    請求項１４に記載の方法。
16. ユーザーの結果行との相互作用に応じて、その結果行に前記出力を生成することになる識別された前記ルールケースを指示するステップをさらに含む、
    請求項１４に記載の方法。
17. １つの前記テストケースに対して、前記ルール仕様の各ルールケースに対応する評価行を含むテーブルを生成するステップ、および
    前記表の各評価行において、可能な入力ごとに、前記テストケースにおけるその可能な入力に対する値が、その評価行に対応する前記ルールケースでその可能な入力に対する関係性を満たしたかどうかを指示するステップをさらに含む、
    請求項１４に記載の方法。
18. 前記テストケースに対する前記識別されたルールケースに対応する前記表の評価行において、そのルールケースにより生成される前記出力を指示するステップをさらに含む、
    請求項１７に記載の方法。
19. 前記評価行は、前記ルール仕様内の前記ルールケースの順序に対応する順序を有し、
    前記出力が指示される前記評価行は、前記可能な入力に対するそれぞれの関係性が満たされる第１のルールケースに対応する、
    請求項１８に記載の方法。
20. 前記可能な入力に対するそれぞれの関係性が前記テストケースにより満たされるルールケースに対応する前記各評価行で生成されることになる出力を指示するステップをさらに含む、
    請求項１７に記載の方法。
21. 第２ルール仕様を受け取るステップは、第２セットのルールケースを含み、
    テストケースごとに結果行を表示するステップは、前記テストケースの入力値を所与として第１または第２ルール仕様により生成される各出力を指示し、
    ユーザーの、前記第２ルール仕様からのルールケースの出力を指示する結果行に指示される出力との相互作用に応じて、前記指示されるルールケースを指示するステップが、前記第１ルール仕様からのルールケースと、前記指示されるルールケースの入力関係性を満たすそのルールケースの出力とを指示するステップを含む、
    請求項１に記載の方法。
22. 前記テストケースのセットを受け取るステップは、
    ユーザーから１セットの入力値を受け取るステップ、
    前記入力値のセットを前記ルール仕様の可能な入力の値へ一致させるステップ、および
    前記入力値のセットを表の列へ格納するステップを含む、
    請求項１に記載の方法。
23. 入力値のセットを受け取る前記ステップは、前記可能な入力の値の識別を表示するステップに応答する、
    請求項２２に記載の方法。
24. 計算をテストするためのシステムであって、
    第１のセットのルールケースを含む第１のルール仕様を受け取るための手段であって、前記各ルールケースは可能な入力と対応出力との関係性を含み、前記ルールケースの内の少なくとも１つは２セット以上の可能な入力が満たす関係性を含む、ルール仕様を受け取るための手段、
    １セットのテストケースを受け取るための手段であって、前記各テストケースは１つ以上の前記可能な入力に対する値を収納する、テストケースを受け取るための手段、
    前記テストケースごとに、前記テストケースの入力値を所与として出力を生成する前記第１のルール仕様内に含まれる前記ルールケースの内の１つを識別し、
    第２のセットのルールケースを含む第２のルール仕様を受け取り、
    前記テストケースごとに、前記テストケースの前記入力値を所与として、前記第１または第２のルール仕様によって生成された各出力を指示する結果行を表示し、および
    前記第２のルール仕様から、第２のルールケースの出力を指示する結果行中で指示された出力とのユーザーの相互作用に応じて、前記第１のルール仕様からの第１のルールケースと、前記第１のルールケースの出力とを指示し、前記第１のルールケースの前記出力は、単独で、または他の値との組み合わせで、前記第２のルールケースの入力関係性を満たす
    よう構成されるプロセッサ、
    を備えるシステム。
25. 計算をテストするための、コンピュータ読み取り可能媒体上に格納されたコンピュータプログラムであって、
    第１のセットのルールケースを含む第１のルール仕様を受け取るステップであって、前記各ルールケースは、可能な入力と対応出力との関係性を含み、前記ルールケースの内の少なくとも１つは、２セット以上の可能な入力が満たす関係性を含む、ルール仕様を受け取るステップ、
    １セットのテストケースを受け取るステップであって、前記各テストケースは１つ以上の前記可能な入力に対する値を収納する、テストケースを受け取るステップ、
    前記テストケースごとに前記テストケースの入力値を所与として出力を生成する前記第１のルール仕様内に含まれる前記ルールケースの内の１つを識別するステップ、
    第２のセットのルールケースを含む第２のルール仕様を受け取るステップ、
    前記テストケースごとに、前記テストケースの前記入力値を所与として、前記第１または第２のルール仕様によって生成された各出力を指示する結果行を表示するステップ、および
    前記第２のルール仕様から、第２のルールケースの出力を指示する結果行中で指示された出力とのユーザーの相互作用に応じて、前記第１のルール仕様からの第１のルールケースと、前記第１のルールケースの出力とを指示し、前記第１のルールケースの前記出力は、単独で、または他の値との組み合わせで、前記第２のルールケースの入力関係性を満たすステップ、をコンピュータに実行させるための命令を含むコンピュータプログラム。
26. データフローを表すリンク要素により接続されるデータ処理成分を有するグラフ型計算の成分をテストするための方法であって、前記成分は、１セットのルールケースを含むルール仕様に基づいてデータを変換するための変換式を含み、前記各ルールケースは、可能な入力と前記ルールケースがトリガされる場合に生成される対応出力との関係性を含み、少なくとも１つの前記ルールケースは、２つ以上の可能な入力が満たす関係性を含み、前記方法は、
    実行環境において１セットの入力データでグラフ型計算を実行し、前記入力データの少なくともいくつかのアイテムのそれぞれに対し、少なくとも１つのルールケースがトリガされて、前記対応出力が生成されることをもたらし、少なくとも１つのルールケースはトリガされないステップ、
    前記入力データと、前記入力データセット内の各データ項目に対する前記計算により生成される前記出力とをログ記録するステップ、および
    前記実行環境とは別のテスト環境において、前記ログ記録される入力データセット内の前記データ項目ごとに、前記項目内の前記入力値を所与として前記ログ記録される出力を生成する前記ルールケースの内の１つを識別するステップを含む方法。
27. データフローを表すリンク要素により接続されるデータ処理成分を有するグラフ型計算の成分をテストするためのシステムであって、前記成分は、１セットのルールケースを含むルール仕様に基づいてデータを変換するための変換式を含み、前記各ルールケースは、可能な入力と前記ルールケースがトリガされる場合に生成される対応出力との関係性を含み、少なくとも１つの前記ルールケースは、２つ以上の可能な入力が満たす関係性を含み、前記システムは、
    i.１セットの入力データで前記グラフ型計算を実行し、前記入力データの少なくともいくつかのアイテムのそれぞれに対し、少なくとも１つのルールケースがトリガされて、前記対応出力が生成されることをもたらし、少なくとも１つのルールケースはトリガされないように、および
    ii.前記入力データと、前記入力データセット内の各データ項目に対する前記計算により生成される前記出力とをログ記録するように
    構成された実行環境、および
    前記実行環境とは別の、前記ログ記録される入力データセット内の前記データ項目ごとに、前記項目内の前記入力値を所与として前記ログ記録される出力を生成する前記ルールケースの内の１つを識別するよう構成されたテスト環境を備えるシステム。
28. データフローを表すリンク要素により接続されるデータ処理成分を有するグラフ型計算の成分をテストするための、コンピュータ読み取り可能媒体上に格納されたコンピュータプログラムであって、前記成分は、１セットのルールケースを含むルール仕様に基づいてデータを変換するための変換式を含み、前記各ルールケースは、可能な入力と前記ルールケースがトリガされる場合に生成される対応出力との関係性を含み、少なくとも１つの前記ルールケースは、２つ以上の可能な入力が満たす関係性を含み、前記コンピュータプログラムは、
    実行環境において、
    iii.１セットの入力データで前記グラフ型計算を実行し、前記入力データの少なくともいくつかのアイテムのそれぞれに対し、少なくとも１つのルールケースがトリガされて、前記対応出力が生成されることをもたらし、少なくとも１つのルールケースはトリガされないステップ、
    iv.前記入力データと、前記入力データセット内の各データ項目に対する前記計算により生成される前記出力とをログ記録するステップ、および
    前記実行環境とは別のテスト環境において、前記ログ記録される入力データセット内の前記データ項目ごとに、前記項目内の前記入力値を所与として前記ログ記録される出力を生成する前記ルールケースの内の１つを識別するステップ、をコンピュータに実行させるための命令を含むコンピュータプログラム。
29. 計算システムの関数成分の振舞いを指定するための方法であって、
    ルールケースを定義する１セットの論理式を含むルール仕様を受け取るステップであって、各ルールケースは、可能な入力と前記ルールケースがトリガされる場合に生成される対応出力との関係性を含み、前記ルールケースの内の少なくとも１つは２つ以上の論理式により定義され、前記ルール仕様が１セットの入力データに適用される場合に、前記入力データの少なくともいくつかのアイテムのそれぞれに対し、少なくとも１つのルールケースがトリガされて、前記対応出力が生成されることをもたらし、少なくとも１つのルールケースはトリガされないように前記ルールケースは設計されている、ルール仕様を受け取るステップ、
    前記ルール仕様に基づいてデータを変換するための関数を生成するステップ、および
    前記関数を関数成分と関係付けるステップを含む方法。
30. 前記テストケースごとに、出力を生成するルールケースを識別することに応じて、生成されることになる前記出力の指示を格納または出力する手段をさらに含む、
    請求項２４に記載のシステム。
31. 前記セットのテストケースを受け取る手段は、
    １セットのテスト列を含む表を受け取る手段を含み、前記各テスト列は、対応する前記１つのテストケースに対する前記１つ以上の可能な入力に対する値を収納する、
    請求項２４に記載のシステム。
32. テストケースごとに、かつそのテストケースに対する前記識別されたルールケースごとに、前記識別されたルールケースにより何の出力が生成されるかを指示する手段をさらに含む、
    請求項２４に記載のシステム。
33. テストケースごとに、かつそのテストデータセットに対する前記識別されたルールケースごとに、前記識別されたルールケースに出力を生成させる原因となった、前記テストケース内の１つ以上の前記入力値を識別する手段をさらに含む、
    請求項２４に記載のシステム。
34. テストケースごとに、前記各ルールケースに対して、そのルールケースのどの関係性が前記テストケース内の値により満たされたか、そしてどの関係性が満たされなかったかを指示する手段をさらに含む、
    請求項３３に記載のシステム。
35. 前記ルールケースには順序があり、前記テストケースごとの前記識別されたルールケースは、前記可能な入力に対する関係性のそれぞれが満たされる順序で第１のルールケースに対応する、
    請求項２４に記載のシステム。
36. 第２セットのルールケースを含む第２ルール仕様を受け取る手段をさらに含み、１つ以上の前記ルールケースは、第１ルール仕様の１つ以上の出力と前記第２ルール仕様の対応入力とに対する関係性を含む、
    請求項２４に記載のシステム。
37. テストケースごとに、前記テストケースの前記入力値を所与として出力を生成することになる前記第２ルール仕様の内の１つの前記ルールケース、および前記第１ルール仕様の内の前記識別されたルールケースの前記出力を識別する手段をさらに含む、
    請求項３６に記載のシステム。
38. テストケースごとに、前記第２ルール仕様の出力の生成をもたらす前記第１および第２ルール仕様の入出力間の相互関係のグラフィック表示を生成する手段をさらに含む、
    請求項３７に記載のシステム。
39. テストケースごとに、前記テストケースの前記入力値を所与として出力を生成する前記各ルールケースを指示する手段をさらに含む、
    請求項２４に記載のシステム。
40. ルールケースごとに、いくつの前記テストケースがそのルールケースに出力を生成させる前記可能な入力に対する値を有するかを指示する手段をさらに含む、
    請求項２４に記載のシステム。
41. 前記テストケースのそれぞれが出力を含み、前記識別されたルールケースで生成される前記出力が、前記テストケースに含まれる前記出力と一致するかどうかを決定する手段、および
    前記決定の結果を格納する、または通信する手段をさらに含む、
    請求項２４に記載のシステム。
42. テストケースごとに結果行を含むテーブルを生成する手段をさらに含み、前記各結果行は、前記テストケースの前記入力値を所与として前記ルール仕様により生成される出力を指示する、
    請求項２４に記載のシステム。
43. 各結果行において、生成されることになる前記出力が、前記ルール仕様の以前のバージョンに対して指示された出力から変更されるかどうかを指示する手段をさらに含む、
    請求項４２に記載のシステム。
44. ユーザーの結果行との相互作用に応じて、その結果行に前記出力を生成することになる識別された前記ルールケースを指示する手段をさらに含む、
    請求項４２に記載のシステム。
45. １つの前記テストケースに対して、前記ルール仕様の各ルールケースに対応する評価行を含むテーブルを生成する手段、および
    前記表の各評価行において、可能な入力ごとに、前記テストケースにおけるその可能な入力に対する値が、その評価行に対応する前記ルールケースでその可能な入力に対する関係性を満たしたかどうかを指示する手段をさらに含む、
    請求項４２に記載のシステム。
46. 前記テストケースに対する前記識別されたルールケースに対応する前記表の評価行において、そのルールケースにより生成される前記出力を指示する手段をさらに含む、
    請求項４５に記載のシステム。
47. 前記評価行は、前記ルール仕様内の前記ルールケースの順序に対応する順序を有し、
    前記出力が指示される前記評価行は、前記可能な入力に対するそれぞれの関係性が満たされる第１のルールケースに対応する、
    請求項４６に記載のシステム。
48. 前記可能な入力に対するそれぞれの関係性が前記テストケースにより満たされるルールケースに対応する前記各評価行で生成されることになる出力を指示する手段をさらに含む、
    請求項４５に記載のシステム。
49. 第２ルール仕様を受け取る手段は、第２セットのルールケースを含み、
    テストケースごとに結果行を表示する手段は、前記テストケースの入力値を所与として第１または第２ルール仕様により生成される各出力を指示し、
    ユーザーの、前記第２ルール仕様からのルールケースの出力を指示する結果行に指示される出力との相互作用に応じて、前記指示されるルールケースを指示する手段が、前記第１ルール仕様からのルールケースと、前記指示されるルールケースの入力関係性を満たすそのルールケースの出力とを指示する手段を含む、
    請求項２４に記載のシステム。
50. 前記テストケースのセットを受け取る手段は、
    ユーザーから１セットの入力値を受け取る手段、
    前記入力値のセットを前記ルール仕様の可能な入力の値へ一致させる手段、および
    前記入力値のセットを表の列へ格納する手段を含む、
    請求項２４に記載のシステム。
51. 入力値のセットを受け取る前記手段は、前記可能な入力の値の識別を表示する手段に応答する、
    請求項５０に記載のシステム。
52. 前記テストケースごとに、出力を生成するルールケースを識別するステップに応じて、生成されることになる前記出力の指示を格納または出力するステップをコンピュータに実行させるための命令をさらに含む、
    請求項２５に記載のコンピュータプログラム。
53. 前記セットのテストケースを受け取るステップは、
    １セットのテスト列を含む表を受け取るステップを含み、前記各テスト列は、対応する前記１つのテストケースに対する前記１つ以上の可能な入力に対する値を収納する、
    請求項２５に記載のコンピュータプログラム。
54. テストケースごとに、かつそのテストケースに対する前記識別されたルールケースごとに、前記識別されたルールケースにより何の出力が生成されるかを指示するステップをコンピュータに実行させるための命令をさらに含む、
    請求項２５に記載のコンピュータプログラム。
55. テストケースごとに、かつそのテストデータセットに対する前記識別されたルールケースごとに、前記識別されたルールケースに出力を生成させる原因となった、前記テストケース内の１つ以上の前記入力値を識別するステップをコンピュータに実行させるための命令をさらに含む、
    請求項２５に記載のコンピュータプログラム。
56. テストケースごとに、前記各ルールケースに対して、そのルールケースのどの関係性が前記テストケース内の値により満たされたか、そしてどの関係性が満たされなかったかを指示するステップをコンピュータに実行させるための命令をさらに含む、
    請求項５５に記載のコンピュータプログラム。
57. 前記ルールケースには順序があり、前記テストケースごとの前記識別されたルールケースは、前記可能な入力に対する関係性のそれぞれが満たされる順序で第１のルールケースに対応する、
    請求項２５に記載のコンピュータプログラム。
58. 第２セットのルールケースを含む第２ルール仕様を受け取るステップをコンピュータに実行させるための命令をさらに含み、１つ以上の前記ルールケースは、第１ルール仕様の１つ以上の出力と前記第２ルール仕様の対応入力とに対する関係性を含む、
    請求項２５に記載のコンピュータプログラム。
59. テストケースごとに、前記テストケースの前記入力値を所与として出力を生成することになる前記第２ルール仕様の内の１つの前記ルールケース、および前記第１ルール仕様の内の前記識別されたルールケースの前記出力を識別するステップをコンピュータに実行させるための命令をさらに含む、
    請求項５８に記載のコンピュータプログラム。
60. テストケースごとに、前記第２ルール仕様の出力の生成をもたらす前記第１および第２ルール仕様の入出力間の相互関係のグラフィック表示を生成するステップをコンピュータに実行させるための命令をさらに含む、
    請求項５９に記載のコンピュータプログラム。
61. テストケースごとに、前記テストケースの前記入力値を所与として出力を生成する前記各ルールケースを指示するステップをコンピュータに実行させるための命令をさらに含む、
    請求項２５に記載のコンピュータプログラム。
62. ルールケースごとに、いくつの前記テストケースがそのルールケースに出力を生成させる前記可能な入力に対する値を有するかを指示するステップをコンピュータに実行させるための命令をさらに含む、
    請求項２５に記載のコンピュータプログラム。
63. 前記テストケースのそれぞれが出力を含み、前記識別されたルールケースで生成される前記出力が、前記テストケースに含まれる前記出力と一致するかどうかを決定するステップ、および
    前記決定の結果を格納する、または通信するステップをコンピュータに実行させるための命令をさらに含む、
    請求項２５に記載のコンピュータプログラム。
64. テストケースごとに結果行を含むテーブルを生成するステップをコンピュータに実行させるための命令をさらに含み、前記各結果行は、前記テストケースの前記入力値を所与として前記ルール仕様により生成される出力を指示する、
    請求項２５に記載のコンピュータプログラム。
65. 各結果行において、生成されることになる前記出力が、前記ルール仕様の以前のバージョンに対して指示された出力から変更されるかどうかを指示するステップをコンピュータに実行させるための命令をさらに含む、
    請求項６４に記載のコンピュータプログラム。
66. ユーザーの結果行との相互作用に応じて、その結果行に前記出力を生成することになる識別された前記ルールケースを指示するステップをコンピュータに実行させるための命令をさらに含む、
    請求項６４に記載のコンピュータプログラム。
67. １つの前記テストケースに対して、前記ルール仕様の各ルールケースに対応する評価行を含むテーブルを生成するステップ、および
    前記表の各評価行において、可能な入力ごとに、前記テストケースにおけるその可能な入力に対する値が、その評価行に対応する前記ルールケースでその可能な入力に対する関係性を満たしたかどうかを指示するステップをコンピュータに実行させるための命令をさらに含む、
    請求項６４に記載のコンピュータプログラム。
68. 前記テストケースに対する前記識別されたルールケースに対応する前記表の評価行において、そのルールケースにより生成される前記出力を指示するステップをコンピュータに実行させるための命令をさらに含む、
    請求項６７に記載のコンピュータプログラム。
69. 前記評価行は、前記ルール仕様内の前記ルールケースの順序に対応する順序を有し、
    前記出力が指示される前記評価行は、前記可能な入力に対するそれぞれの関係性が満たされる第１のルールケースに対応する、
    請求項６８に記載のコンピュータプログラム。
70. 前記可能な入力に対するそれぞれの関係性が前記テストケースにより満たされるルールケースに対応する前記各評価行で生成されることになる出力を指示するステップをコンピュータに実行させるための命令をさらに含む、
    請求項６７に記載のコンピュータプログラム。
71. 第２ルール仕様を受け取るステップは、第２セットのルールケースを含み、
    テストケースごとに結果行を表示するステップは、前記テストケースの入力値を所与として第１または第２ルール仕様により生成される各出力を指示し、
    ユーザーの、前記第２ルール仕様からのルールケースの出力を指示する結果行に指示される出力との相互作用に応じて、前記指示されるルールケースを指示するステップが、前記第１ルール仕様からのルールケースと、前記指示されるルールケースの入力関係性を満たすそのルールケースの出力とを指示するステップをコンピュータに実行させるための命令を含む、
    請求項２５に記載のコンピュータプログラム。
72. 前記テストケースのセットを受け取るステップは、
    ユーザーから１セットの入力値を受け取るステップ、
    前記入力値のセットを前記ルール仕様の可能な入力の値へ一致させるステップ、および
    前記入力値のセットを表の列へ格納するステップを含む、
    請求項２５に記載のコンピュータプログラム。
73. 入力値のセットを受け取る前記ステップは、前記可能な入力の値の識別を表示するステップに応答する、
    請求項７２に記載のコンピュータプログラム。
74. 前記テストケースに前記ルールケースのそれぞれを適用するステップを含み、
    一旦ルールケースがトリガされると、その他のルールケース、または前記ルール仕様内のケースは評価されない、請求項１に記載の方法。
75. 計算をテストするための方法であって、
    １セットのルールケースを含むルール仕様を受け取るステップであって、各ルールケースは、可能な入力と前記ルールケースがトリガされる場合に生成される対応出力との関係性を含み、前記ルールケースの内の少なくとも１つは、１セット以上の可能な入力が満たす関係性を含む、ルール仕様を受け取るステップ、
    １セットのテストケースを受け取るステップであって、各テストケースは１つ以上の前記可能な入力に対する値を収納し、前記テストケースの少なくともいくつかのそれぞれに対して、少なくとも１つのルールケースがトリガされて、前記対応出力が生成されることをもたらし、少なくとも１つのルールケースはトリガされない、テストケースを受け取るステップ、
    各テストケースに対し、前記テストケースの前記入力値を所与として出力を生成することになる前記ルール仕様内に含まれる前記ルールケースの内の１つを識別するステップ、および
    前記出力を生成することになる前記識別されたルールケースと、トリガされないその他のルールケースとを表示し、前記識別されたルールケースの指示を提供するステップ、
    を含む方法。

Images