Sequenzieller Algorithmus

Tupel

Regelauswahl im sequenziellen Modus

Die Regeln einer Regelaufgabe, die mit der Eigenschaft algorithm gleich sequential festgelegt werden, werden dynamisch in Java-Bytecode umgesetzt. Der Bytecode ist in der Lage, die sequenzielle Verarbeitung auszuführen, wenn die Aufgabe ausgeführt wird.

Die Eigenschaft body einer Regelaufgabe ist verbindlich. Sie wählt die Regeln des Regelsatzes aus, die von der Regelaufgabe berücksichtigt werden.

Siehe auch Laufzeitregelauswahl.

Steuerungseigenschaften im sequenziellen Modus

Steuerungseigenschaften wirken sich auf die Ausführung im sequenziellen Modus und auf die Tupelstruktur aus. Weitere allgemeine Informationen finden Sie unter Steuerungseigenschaften für Regelaufgaben in Ausführungsmodi .

Die Anzahl auszuführender Regeln pro Tupel und die Ausführungsreihenfolge können mit den Steuerungseigenschaften ordering, firing und firinglimit festgelegt werden.

Eigenschaft "ordering"

Die Eigenschaft ordering ist für die sequenzielle Verarbeitung verbindlich. Sie beschreibt die Reihenfolge, in der die Regeln der Regelaufgabe ausgeführt werden.

Es sind zwei Werte verfügbar:

• literal: Die Regeln bleiben in der Reihenfolge, in der sie im Aufgabenhauptteil angegeben werden (mit Aufwärts-/Abwärtspfeilen).

• sorted: Die Regeln werden entsprechend ihren statischen Prioritäten sortiert.

Es ist ein weiterer Wert, dynamic, verfügbar, der nur für Regelaufgaben gilt, die den Ausführungsmodus "RetePlus" verwenden.

Eigenschaft "firing"

Die Eigenschaft firing gibt an, ob für jedes Tupel alle Regeln oder nur die erste zutreffende Regel ausgeführt werden soll. Die Angabe dieser Eigenschaft ist optional.

Es gibt zwei mögliche Werte:

• allrules

  Dieser Wert bedeutet, dass alle zutreffenden Regeln ausgeführt werden müssen, bevor mit dem nächsten Tupel fortgefahren wird. Dies ist der Standardwert.

• rule

  Dieser Wert bedeutet, dass nur die erste zutreffende Regel im ersten Tupel ausgeführt werden muss.

Eigenschaft "firinglimit"

Die Eigenschaft firinglimit legt eine weitere Steuerungsebene fest, wenn die Eigenschaft firing auf allrules gesetzt ist. Mit dieser Eigenschaft wird angegeben, wie viele Regeln maximal ausgeführt werden, bevor mit dem nächsten Tupel fortgefahren wird. Diese Zahl muss größer als null sein.

Bekannte Einschränkungen des sequenziellen Algorithmus

In fast allen Fällen gibt es keine Einschränkung bezüglich der Anzahl der Regeln, die von einer einzelnen Aufgabe verarbeitet werden können, deren Eigenschaft "algorithm" auf "sequential" gesetzt ist. Die einzige Ausnahme bilden extrem große Entscheidungstabellen mit einer Klausel otherwise. Die Verarbeitung ist wie folgt: Alle Bedingungen aller Zeilen werden in einem einzigen Ausdruck verneint. Dieser einzige Ausdruck wird dann nach der Übersetzung in Bytecode in den Hauptteil einer einzelnen Methode übernommen. Dies ist ein Problem, da die Java-Prüffunktion Methoden mit einem zu großen Hauptteil zurückweist. Der für die Regeln verwendete Skalierbarkeitsalgorithmus wird nicht auf den Methodenhauptteil angewendet. Der Benutzer wird über diese Einschränkung benachrichtigt, wenn das Klassenladeprogramm die Regeln zurückweist. Die Einschränkung bezüglich der Regelanzahl ist nicht eindeutig festgelegt, bezieht sich aber wahrscheinlich auf mehrere Tausend Regeln.

In der folgenden Tabelle werden die Einschränkungen der sequenziellen Verarbeitung beschrieben, insbesondere ihre Verwendung in Kombination mit bestimmten IRL-Konstrukten (ILOG ® Rule Language).

IlrContext mycontext="....";
IlrExceptionHandler myhandler="....";
mycontext.setExceptionHandler(myhandler);

ruletask main {
   algorithm = sequential;
   ordering = literal;
   body = {Person,PersonProduct}
}

(Person,Product)

void matchObjects(Object[] tuple) {
   rule_Person((Person)tuple[0]);
   rule_PersonProduct((Person)tuple[0],(Product)tuple[1]);
}

Die folgenden Beispiele zeigen Fälle, die JIT-Kompilierungsfehler (Just-in-time) verursachen, d. h. Fehler zur Ausführungszeit, keine Parsing-Fehler.

Beispiel 1: IRL-Einschränkung, die zu Kompilierungsfehlern führt

Dieses Beispiel führt zu JIT-Kompilierungsfehlern, weil Aufzählungsausdrücke fehlen.

ruletask T {
  algorithm = sequential;
  body = { R1, R2, R3, R4, R5, R6, R7, R8, R9 }
}

rule R1 {
  when {
    not MyObject();  // No enumerator, an error will occur
  }
  then {
  }
}

rule R2 {
  when {
    exists MyObject();  // No enumerator, an error will occur
  }
  then {
  }
}

rule R3 {
  when {
    collect MyObject() where (size() == 1);  // No enumerator, an error
                                                will occur
  }
  then {
  }
}

function Object getObject() {
  return new MyObject();
}

function Object[] getObjects() {
  Object objs = new Object[1];
  objs[0] = getObject();
  return objs;
}

rule R4 {
  when {
    not MyObject() from getObject();  // An enumerator, no error
  }
  then {
  }
} 

rule R5 {
  when {
    not MyObject() in getObjects();  // An enumerator, no error
  }
  then {
  }
} 

rule R6 {
  when {
    exists MyObject() from getObject();  // An enumerator, no error
  }
  then {
  }
} 

rule R7 {
  when {
    exists MyObject() in getObjects();  // An enumerator, no error
  }
  then {
  }
} 

rule R8 {
  when {
    collect MyObject() from getObject() where (size() == 1); 
    // An enumerator, no error
  }
  then {
  }
} 

rule R9 {
  when {
    collect MyObject() in getObjects() where (size() == 1);  
    // An enumerator, no error
  }
  then {
  }
}

Beispiel 2: IRL mit Konstrukteinschränkungen

Im Folgenden sehen Sie ein Beispiel mit einem Konstrukt mit collect, das den Geltungsbereich der Bindungen demonstriert. Dies gilt für not und exists ebenfalls. Dieses Beispiel führt ebenfalls zu JIT-Kompilierungsfehlern, weil nicht unterstützte Konstrukte verwendet werden.

rule R10 {
  when {
    r:MyRootObject();
    c:collect MyObject(n:name; n.startsWith("ilog")) in r.getObjects(); 
    where (s:size(); s > 1);
  }
  then {
    out.println(r);  // correct
    out.println(c);  // correct
    out.println(s);  // correct
    out.println(n);  // error
  }
}