Contrôle de cohérence

Le mécanisme d'analyse de cohérence des règles détecte les règles sémantiquement contradictoires, telles que les règles qui ne sont jamais sélectionnées, celles qui ne s'appliquent jamais, les règles équivalentes, les règles redondantes et les règles en conflit, ainsi que les conflits entre tables de décision ou arbres de décision.

Le contrôle de cohérence est un mécanisme qui permet de vérifier que les règles ne contiennent pas d'éléments présentant un conflit sémantique.

Les ambiguïtés peuvent être détectées dans une règle unique ou dans un ensemble de règles. Par exemple :

Une seule règle peut contenir des conditions contradictoires et, par conséquent, ne jamais s'appliquer.
Deux règles peuvent s'appliquer au même objet et affecter à un attribut donné deux valeurs différentes. De telles règles sont dites en conflit.

Le contrôle de cohérence va au-delà des aspects purement syntaxiques et considère également la sémantique, c'est-à-dire le comportement d'une règle lors de son exécution. A l'aide de Rule Designer , vous pouvez choisir les vérifications à effectuer.

Les contrôles de cohérence peuvent être classés en différentes catégories :

Contrôles qui analysent une règle individuelle. Ces contrôles sont activés lorsque vous créez la règle et lorsque vous exécutez l'analyse de contrôle de cohérence :
Contrôles qui analysent les règles en relation avec d'autres règles. Ces contrôles ne sont activés que lorsque vous exécutez l'analyse de contrôle de cohérence.

Le contrôle de cohérence signale les problèmes concernant les règles :

Si votre projet de règles contient un flux d'exécution de règles, le mécanisme de contrôle de cohérence signale les problèmes relatifs aux règles qui sont incluses dans une tâche de règle et qui sont susceptibles d'être sélectionnées lors de l'exécution.
Le mécanisme ne compare que les règles susceptibles de faire partie de la même tâche. Dans le cas d'une tâche de règle à filtrage de sélection dynamique, le mécanisme prend en compte les règles qui sont potentiellement sélectionnées par cette tâche. Une règle est considérée comme potentiellement sélectionnable lorsqu'il ne peut pas être établi qu'elle ne peut jamais être sélectionnée.
Si votre projet de règles ne contient aucun flux d'exécution de règles, toutes les règles du projet seront vraisemblablement sélectionnées.
Il donne une indication de la cohérence de vos règles, mais ne peut pas identifier tous les problèmes potentiels. Par conséquent, si le rapport de contrôle de cohérence est vide, cela ne signifie pas nécessairement que les règles analysées ne présentent aucun problème.

Pour plus d'informations, voir Sélection de règles d'exécution et Remplacement de règles.

Conseil : dans la vue d'analyse des règles, vous pouvez définir une limite pour le nombre de résultats renvoyés :

Si l'ensemble de règles comporte de nombreux problèmes, la fixation d'une limite peut permettre d'obtenir des résultats plus rapidement et de générer un rapport plus petit et plus facile à gérer. L'analyse s'arrête lorsqu'elle atteint la limite.

Si vous souhaitez poursuivre l'analyse, cliquez sur Poursuivre l'analyse des règles dans le rapport de statistiques.

Règles jamais sélectionnées

Les règles sont signalées comme jamais sélectionnées si elles ne font pas partie d'une tâche de règle et ne peuvent pas être sélectionnées lors de l'exécution. Pour plus d'informations, voir Sélection de règles d'exécution et Remplacement de règles.

Règles qui ne s'appliquent jamais

Une règle est analysée comme jamais applicable lorsque ses conditions ne peuvent jamais être satisfaites.

Généralement, la syntaxe de ces règles est correcte mais elle contient des erreurs de logique courantes. Par exemple :

Le mauvais opérateur est utilisé pour combiner des instructions de condition, par exemple and au lieu de or: the category of the customer is Gold and the category of the customer is Platinum.
Les valeurs sont inversées, par exemple, dans la règle suivante: the age of the customer is between 70 and 50.
Des valeurs dans les conditions ne sont pas dans la plage autorisée.

Règles présentant des violations de plage autorisée

Afin de réduire le risque d'erreurs, il n'est possible d'affecter à certains membres que des valeurs situées dans une plage donnée. Par exemple, le taux d'intérêt annuel d'un prêt peut être limité aux valeurs comprises entre 0 et 10.

Si une règle contient une action qui tente d'affecter une valeur qui n'est pas comprise dans la plage autorisée, Rule Designer affiche une erreur de violation de plage dans le rapport et dans l'éditeur de règles.

Règles présentant des conditions équivalentes

Le mécanisme de contrôle de cohérence signale également les règles dans lesquelles les parties condition ont la même signification, et où les parties action sont différentes mais ne sont pas en conflit.

Les règles présentant des conditions équivalentes ne constituent pas nécessairement une erreur, mais il pourrait être intéressant de les fusionner.

Règles équivalentes

Des règles sont signalées comme équivalentes quand leurs conditions et leurs actions sont identiques.

Dans l’exemple ci-dessous, la Règle1 et la Règle2 sont équivalentes :

Rule1

definitions
set minDiscount to 5
set ageDiscount to 10
si
the age of the borrower is more than 65
then 
set the discount to minDiscount + ageDiscount

Rule2

IF
the age of the borrower is at least 66
then
set the discount to 15

Bien que la syntaxe de ces deux règles soit différente, l'analyse de règles évalue les expressions numériques et signale que ces règles sont équivalentes. Vous pouvez donc supprimer l'une des deux.

Remarque: les règles équivalentes apparaissent souvent entre une table de décision que vous créez et une règle existante.

Règles redondantes

Lorsque deux règles ont la même action, l’une d’entre elles devient redondante si ses conditions sont incluses dans les conditions de l’autre.

Dans l’exemple ci-dessous, la partie Else de la Règle2 rend la Règle1 redondante :

Rule1

IF
the category of the customer is Gold
then
set the discount to 10

Rule2

IF
the category of the customer is Platinum
then
set the discount to 15
else
set the discount to 10

Bien que la Règle1 soit correcte, elle est redondante et peut donc être supprimée.

Remarque: des règles redondantes apparaissent souvent entre une table de décision que vous créez et une règle existante.

Règles en conflit et règles de conflit avec elles-mêmes

On considère que des règles sont en conflit lorsque leurs actions sont contradictoires, c'est-à-dire lorsqu'elles affectent une valeur différente au même terme métier. Des conflits peuvent se produire entre deux règles quand les conditions sont équivalentes ou couvrent les mêmes valeurs. Prenons l'exemple des deux règles suivantes :

Rule1

IF
the loan report is approved
and the amount of the loan is at least 300 000
then
set the category of the borrower to Gold

Rule2

IF
the age of the latest bankruptcy of the borrower is less than 1
and the category of the borrower is not Platinum
then
set the category of the borrower to No Category

La Règle1 et la Règle2 sont en conflit dans les circonstances suivantes :

Le rapport de prêt est approuvé.
Le montant du prêt est supérieur ou égal à 300 000.
L'emprunteur n'a pas été mis en faillite au cours de l'année écoulée.
Et la catégorie n'est pas Platinum.

Dans ces circonstances particulières, les règles définissent affectent une valeur différente à la catégorie de l'emprunteur. Vous pouvez corriger les conflits entre règles en modifiant les conditions, en supprimant une des règles ou en leur attribuant des priorités différentes.

Une règle est en conflit avec elle-même quand deux de ses exécutions affectent des valeurs différentes au même membre. Par exemple, une règle qui peut s'appliquer deux fois sur une mémoire de travail (et les paramètres d'ensemble de règles) donnée et qui définit des valeurs différentes pour un attribut commun est en conflit avec elle-même. Par exemple :

IF
the customer category is Gold
then
set the discount of the cart to the bonus points of the customer

Avec cette règle, s'il existe deux objets customer (client) ayant des bonus points (points de bonus) différents dans la mémoire de travail, la règle est exécutée deux fois et un conflit se produit car les deux exécutions de la règle affectent des valeurs différentes à the discount of the cart (la remise sur le panier).

Conflits de tables de décision

Pour vérifier des tables de décision et des arbres de décision, vous devez activer l'option Inclure les tables de décision et les arbres de décision dans les vérifications inter-règles.

Lorsque cette option est activée, vous pouvez vérifier les règles entre et au sein des tables de décision ou des arbres de décision. L'analyseur de règle recherche les conflits, les redondances et les équivalences entre les éléments suivants :

deux lignes d'une même table de décision
deux lignes de deux tables de décision différentes
deux feuilles d'un même arbre de décision
deux feuilles de deux arbres de décision différents
une ligne d'une table de décision et une feuille d'un arbre de décision
une ligne d'une table de décision et une règle d'action
une feuille d'un arbre de décisions et une règle d'action

Lorsque cette option est désactivée, ces contrôles ne sont pas exécutés sur les tables de décision et les arbres de décision, mais uniquement sur les règles d'action.

Cependant, même si cette option est désactivée, les tables de décision et les arbres de décision sont contrôlés afin de détecter les règles qui ne sont jamais applicables et les violations de domaine. Cette option n'a aucune incidence sur les contrôles de chevauchement et de valeurs non couvertes qui ont lieu lorsque vous écrivez les règles.