RetePlus アルゴリズム

RetePlus は、Rete アルゴリズムをベースとするルール実行モードです。これは、作業メモリーとアジェンダに依存し、否定パターン、オブジェクト通知、および論理オブジェクトをサポートしています。

RetePlus は、Rete アルゴリズムをベースとする Decision Server 拡張機能です。 RetePlus モードでは、ルール実行は、作業メモリーとアジェンダに基づいて環境を使用します。

作業メモリーとアジェンダ
否定パターン
オブジェクトの通知
RetePlus ネットワーク操作

作業メモリーとアジェンダ

RetePlus 実行モードでは、ルール・エンジンは作業メモリーとアジェンダを使用して機能し、条件が満たされた場合に実行するルール・インスタンスを追加します。

作業記憶

RetePlus 実行モードでは、 Decision Server のルール・エンジンは、作業メモリーとペアになります。作業メモリーには、関連する Engine オブジェクトに含まれているすべてのオブジェクトが含まれます。作業メモリーを変更するには、ルールのアクション部分にステートメントを追加するか、またはアプリケーション・プログラミング・インターフェース (API) を使用します。したがって、ルール・エンジンは、作業メモリー内に存在するオブジェクトとそれらのオブジェクトにリンクされているオブジェクトを認識します。ルール・エンジンが使用できるオブジェクトは、作業メモリーからアクセス可能なオブジェクトのみです。

スケジュール

アジェンダは、パターンがすべて一致したルールを Decision Server が保管する場所です。アジェンダに入ったルールは、インスタンス化されたと見なされ、ルール・インスタンスになります。ルール・インスタンスを参照してください。

アジェンダには、 rundとして適格なルール・インスタンスが保管されます。アジェンダが空の場合、実行は無効です。アジェンダに置かれたルールは、実行可能と見なされます。通常、アジェンダ内には、実行可能なルールが複数あります。結果として、ルール・エンジンは、アジェンダ内のどの特定のルールを実行すべきかを決定する何らかの方法を持つ必要があります。

アジェンダ内では、ルール・インスタンスは、最初に実行する必要があるルールを決定する 3 つの基準に従って順序付けられます。より複雑な機能の実装により、追加の実行制御が提供されます。オブジェクト通知を参照してください。

屈折

新規ファクトが発生しなかった場合、つまり、ルールに一致するオブジェクトが何も変更されていない場合、またはルールによって一致する新規オブジェクトがない場合は、実行されたルール・インスタンスをアジェンダに再挿入することはできません。

屈折方針では、所定のタプルに対して作成されるルール・インスタンスが 1 つのみになります。エンジン・サイクルのデータ単位は作業メモリーであるため、エンジンはすべての可能なタプルを簡単に記録し、タプルごとに 1 つのルール・インスタンスのみが存在することを確認できます。

例えば、次のようなルール・セットがあるとします。

class Person {
  Person(int age, boolean sick);
  boolean sick;
  int age;
}

rule incrementAge {
when {
  p: Person(!sick; age < 50);
} then {
  p.age += 1;
  update p;
}

rule cure {
when {
  p: Person(sick);
} then {
  p.sick = false;
  update p;
}

オブジェクト Person(18,true) が作業メモリーに挿入された場合、屈折方針により、以下の実行トレースが生成されます。

cure
incrementAge

以下のように、incrementAge ルールで反復可能プロパティーを追加できます。

rule incrementAge {
 property com.ibm.rules.engine.repeatable=true;
when {
  p: Person(!sick; age < 50);
} then {
  p.age += 1;
}

オブジェクト Person(18,true) が作業メモリーに挿入された場合、反復可能プロパティーにより、以下の実行トレースが生成されます。

cure
incrementAge
incrementAge
incrementAge
...
incrementAge
条件 age < 50 が falseになるまで。

反復可能ルール

屈折方針を中断するために、ブール型のルール・プロパティー com.ibm.rules.engine.repeatable を使用できます。意思決定エンジンでは、反復可能にする一連のルールをマークするために、このプロパティーを使用する必要があります。

ルールが反復可能でない場合は、屈折方針によって、ルール・インスタンスがアジェンダに再度送られることが防止されます。
ルールが反復可能であるときは、条件オブジェクトに対して変更が発生した場合に、ルールをルール・インスタンスとしてアジェンダに再度挿入できます。

リーセンシー

2 つのルール・インスタンスが同じ優先順位を持つ場合、最新のオブジェクト ( 最後に挿入されたオブジェクト、変更されたオブジェクト、またはリトラクトされたオブジェクト ) に一致するルールが最初に実行されます。

複数のルール・インスタンスが同時に実行候補となった場合は、優先度とリーセンシーを使用して競合が解決されます。指定された競合解決方法をすべて使用した後も、複数のルール・インスタンスが候補として残っている場合、エンジンは内部のメタルールを使用します。これで、条件が同じであれば、常に同じルール実行順序に従うようになります。

ルール実行順序の例

以下のテクニカル・ルールの例では、ルールが実行される順序を示します。


rule init {
   when {
      angel();
   }
   then {
      insert clown();
      insert dascyllus();
   }
};
rule last {
   priority = -100;
   when {
      dascyllus();
   }
   then {
      System.out.println("last");
   }
};
rule first {
   priority = 100;
   when {
      angel();
      clown();
      dascyllus();
   }
   then {
      System.out.println("first");
   }
};
rule second {
   priority = 0;
   when {
      angel();
      dascyllus();
      clown();
   }
   then {
      System.out.println("second");
   }
};
rule third {
   priority = 0;
   when {
      angel();
      clown();
      dascyllus();
   }
   then {
      System.out.println("third");
   }
};

オブジェクト angel が APIを使用してアプリケーションから挿入されたため、作業メモリーに挿入されているため、実行可能なすべてのルールを実行するとします。

ルールを実行する順序を以下に示します。

init ルール: オブジェクト angel がアプリケーションから挿入されているため、実行できるルールは init ルールのみです。このルールはオブジェクト clown に続いてオブジェクト dascyllus を作業メモリーに挿入します。したがって、最新のオブジェクトは dascyllus です。
first ルール: このルールは、 second ルールの前に実行されます。この 2 つのルールに一致する最新のオブジェクトは同じです。ただし、最初のオブジェクトは 2 番目のオブジェクトよりも優先度が高く、これで実行順序が決まります。
second ルール: このルールは、 third ルールの前に実行されます。 second ルールと third ルールの優先度は同じですが、オブジェクト dascyllus はオブジェクト clown よりも最近のオブジェクトです。
third ルール: このルールは、 last ルールの前に実行されます。オブジェクト dascyllus は clown よりも最近のオブジェクトですが、third ルールは last ルールよりも高い優先度を持っています。
last ルール。

ルール・インスタンス

ルール・インスタンス がアジェンダに追加されるのは、作業メモリー内のオブジェクトがそのルールの条件部分を満たしているときです。

次のテクニカル・ルールがあるとします。


rule rule1 {
   when {
      Fish(color == green; type == shark);
      Fish(type == trigger);
   }
   then {...}
};

次のルール・インスタンスがアジェンダに挿入されます。

ルール	ルール	ルール	ルール
rule1(A,C)	rule1(A,D)	rule1(B,C)	rule1(B,D)

この例で、ルール・インスタンスは動的な概念であることが分かります。ルール・インスタンスは、ルールに指定されたパターンと一致する作業メモリー内のオブジェクトの組み合わせによって生成されます。対照的に、ルールは静的な概念です。

否定パターン

標準的なルール条件は、実際にたまたま存在する 1 つまたは複数のオブジェクトがそれらの条件と一致する可能性があるという意味で、存在条件として表すことができます。 RetePlus 実行モードには、否定パターン と呼ばれる補足概念があります。特定のオブジェクトが作業メモリーに存在しないことを表すには、次に示すように、オブジェクトの条件の前に not キーワードを置きます。


not Fish(type==eel);

対応する肯定パターンと一致するオブジェクトがないため、この否定パターンの場合、マッチングは成功します。


Fish(type==eel);

反対に、次の否定パターンの場合、


not Fish(type==angel);

対応する肯定パターンと一致するオブジェクトがあるという単純な理由で、マッチングは成功しません。


Fish(type==angel);

オブジェクトの通知

RetePlus 実行モードには、以下に示す個々の操作を制御するステートメントがあります。

オブジェクトの挿入
オブジェクトのリトラクト
オブジェクトの更新
#concept_cfl_nsj_hkb__attribute_modification

オブジェクトの挿入

insert ステートメントを使用して、新しいオブジェクトを作成し、それを作業メモリーに挿入することができます。このキーワードの後に、クラスの名前と、作成するオブジェクトの属性の値を指定します。

次に、新しい Course オブジェクトの作成に関する例を示します。このオブジェクトの属性 department および number はそれぞれ値 History および 324 を取ります。


insert Course(History,324);

insert 操作を処理する方法には 2 つの可能性があります。

オブジェクトが作業メモリーに既に存在する。この場合、挿入操作は更新と同様です。
オブジェクトが作業メモリーに存在しない。この場合、オブジェクトは作業メモリーに挿入され、対応するクラスとそのスーパークラスの挿入デーモンが呼び出され (存在する場合)、アジェンダが更新されます。

オブジェクトのリトラクト

retract ステートメントを使用して、ルール変数にバインドされているオブジェクトを作業メモリーから削除することができます。

次の例では、retract プリミティブによって、?c 変数にバインドされているオブジェクトが削除されます。


rule RemoveCourse {
   when {
      ?c: Course(department == History; number == 254);
   }
   then {
      retract ?c;
   }
};

対応するクラスの retract デーモンが呼び出され (存在する場合)、それに従ってアジェンダが更新されます。作業メモリーからオブジェクトをリトラクトすると、論理オブジェクトはその理由付けを 1 つ以上失う可能性があります。

オブジェクトの更新

オブジェクトが Java™によって変更された場合、その変更は Decision Serverによって認識されません。これは、 Decision Server によって保守されるデータが、変更されたオブジェクトの新しい内容と整合しないことを意味します。

不整合を回避するため、このようなオブジェクトでは update ステートメントを呼び出す必要があります。このステートメントにより、 Decision Server は、変更されたオブジェクトの新しい内容に従って内部構造を更新することができます。

次のルールでは、最初のアクションによって number 属性が変更されます。その後、 update プリミティブが呼び出され、オブジェクトが変更されたことを Decision Server に通知します。


rule NumberingUpdate {
   when {
      ?c: Course(department == "history"; number > 300);
   }
   then {
      ?c.updateNumbering(); // This call modifies ?c 
      update ?c;
   }
};

重要:

modifyを使用しない場合は、 update プリミティブを使用して、オブジェクトが変更されたことを Decision Server に通知する必要があります。変更を Decision Server に通知しないと、不整合な状態になります。

ネットワーク操作

RetePlus ネットワークは、ルールと条件の数を最小にすることができます。

RetePlus ネットワーク操作
RetePlus ネットワークの例
RetePlus ネットワーク構造
オブジェクトの追加
オブジェクトの削除

RetePlus ネットワーク操作

RetePlus ネットワークは、ルールをインデックス付けすることで、作業メモリーが変更されるたびに評価する必要があるルールと条件の数を最小限に抑えています。このネットワークでは、ルール間でテストを共有し、変更を増分的に伝搬することによって、評価の数を最小限に抑えています。すべてのテストが完了すると、ネットワークによってルールが指定されます。

一般に、ルールを実行すると作業メモリーが変更されます。これらのルールが参照する作業メモリー内のオブジェクトが、挿入、削除、および変更される可能性があります。このネットワークは、ルールの実行によって推論された変更を処理し、実行対象の新しいルール・セットを生成します。

作業メモリーで変更が発生すると、その変更の性質に応じて以下の 2 つのことが発生する可能性があります。

作業メモリーへのオブジェクトの挿入がある場合 (肯定)、ルールを実行することができます。
作業メモリーからのオブジェクトの削除がある場合 (否定)、ルールをアジェンダから削除する必要があります。アジェンダとは、実行対象の現在のルール・セットが保持される場所です。

このプロセスは、アジェンダにルール・インスタンスが存在しなくなるまで繰り返し実行されます。

注:

単純条件では、作業メモリーにその条件と一致するオブジェクトが含まれていないと、not 条件は true を返します。

RetePlus ネットワークの例

RetePlus ネットワークを説明するために、ここでは、簡単な filter ルールを使用します。このルールは、ルール言語で記述され、A、B、および C というクラスを参照します。


rule filter {
   when {
      A (a1==3; ?x:a2);
      B (b1==2; ?y:b2; b3==?x);
      C (c1==?y);
   }
   then {
      System.out.println("filter");
   }
}

クラス属性は、次のとおりです。

A クラスには a1 および a2 という 2 つの属性があります。
B クラスには b1、b2 および b3 という 3 つの属性があります。
C クラスには c1 というただ 1 つの属性があります。

作業メモリーには次のオブジェクトが含まれているとします。


A( a1=3 a2=10 )
B( b1=2 b2=4 b3=10 )
B( b1=2 b2=7 b3=10 )
C( c1=4 )

RetePlus ネットワーク構造

RetePlus ネットワークは、3 つのゾーンで構成されるグラフとして表すことができます。

判別ツリー

判別ツリーは、テストを実行するパターンマッチングプロセスです。これらのテストは、ネットワークの上部にダイヤモンドの形状で表されます。テストは、オブジェクトのクラスとその属性の値に関係します。このツリーへの入力は、作業メモリー内の現在の各オブジェクトを表すトークン で構成されます。

パターンが 1 つのオブジェクトとその属性のみを処理する場合、そのパターンは判別テストと見なされます。それが組み合わせの場合は、結合と呼ばれます。これらは、グラフの下部に表示されます。

アルファ・ノード

アルファ・ノード は、判別ツリーのテストに合格するトークンごとに、ネットワークの次のレベルに作成されます。各ノードは 1 つまたは複数のトークンで構成されます。トークンは、角が丸い長方形で表されます (この図には 3 つのアルファ・ノードがあります)。 1 つのアルファ・ノードに、2 つの B クラスのトークンが含まれています。他の 2 つのノードには、それぞれ 1 つのクラス・トークン (A クラスと C クラスのトークン) のみが含まれています。

テストとタプル

ネットワークの 3 つの目のゾーンは、オブジェクトの複数のクラスのトークンと一致します。結果として作成されるノードはタプル と呼ばれます。タプルは複数のトークンで構成されます。属性 a2 と b3 の間の等価テストにより 2 つのトークン・ペアからなるノードが生成され、次いで、属性 b2 と c1 の間のテストによりトークンのトリプレットがフィルタリングによって除去されます。 RetePlus ネットワークでは、通常、この種類のタプルは結合ノードと呼ばれます。

オブジェクトの追加

RetePlus ネットワークのこの概念をさらに詳しく説明するため、作業メモリーに追加オブジェクトを挿入するとします。追加されるオブジェクトは C クラスのオブジェクトで、その c1 属性の値は 7 です。


C( c1=7 )

この段階では、ノードのすべてのテストが実行されると、3 番目のテスト C (c1==?y); (class of object = C) のみが満たされます。子ノードのテストは、トークンがネットワーク内を降りていく間、続行されます。

ここでは、判別ツリーに子ノードはありません。このため、オブジェクトはアルファ・ノードに直接格納されます。

トークンが 2 番目の結合ノード B (b1==2; ?y:b2; b3==?x)に到達すると、結合ノードのメモリーと、結合ノードに到着したばかりのトークンに含まれる C オブジェクトの隣に保管されているペアの各 B オブジェクト間でテストが実行されます。テストは 2 つ目のペアの B オブジェクトで満たされます。そのため、先に進み、2 つ目のペアとトークン内のオブジェクトで構成されるトリプレットを作成することができます。

このトリプレットを作成することによって、実際に、ネットワーク全体での下降が完了し、filter ルールの新しいインスタンスを実行することができます。

オブジェクトの削除

次に、作業メモリーに追加したオブジェクトを削除するとします。

判別ツリー内でのトークンの進行は、オブジェクトの追加の場合と同じですが、アルファ・ノードに否定トークンが達すると、そのトークンに含まれているオブジェクトが削除されます。

トークンが 2 つ目の結合ノードに達すると、トークンにオブジェクトが含まれているすべてのトリプレットが削除され、トークンはネットワーク内を進み続けます。

オブジェクトの追加の例に示すように、ルール・ノードに達します。トークン内のオブジェクトに対応する条件を満たすオブジェクトが含まれている filter ルールのインスタンスがアジェンダから削除されます。