Exécution des règles

Après la sélection des règles, le moteur divise l'ensemble des règles en deux catégories : les règles de vérification et les règles de propagation.

7.4.3.1 Les règles de vérification

Le moteur traite en premier les règles de vérification (Figure 7-14). Il commence par déterminer les règles les plus spécifiques (règles qui ne sont pas inhibées par d'autres règles de cet ensemble) ; il évalue ensuite les conditions de ces règles. Si la condition d'une règle est satisfaite, les autres règles de vérification et de propagation sont abandonnées et le message d'erreur de la règle est retourné à l'opération déclenchante, signalant ainsi l'interruption de l'opération. Si aucune règle de vérification n'a eu sa condition satisfaite, l'ensemble des règles

Evénement déclenché

Sélection des règles

Filtrage des Références Evénementielles

Règles de propagation Règles de vérification

Sélection des règles les plus spécifiques

Evaluation des conditions Interruption

Condition satisfaite Nv= profondeur

Nv=0 Nv>0 Evaluation des conditions

Np= profondeur Sélection des règles les plus spécifiques

Abandon des règles insatisfaites Condition insatisfaite Condition satisfaite Mise de côté des règles satisfaites Np>0 Np=0

Exécution des actions des règles satisfaites

Fin

Figure 7-14 : Algorithme du moteur d'exécution

7.4.3.2 Les règles de propagation

L'exécution d'une règle de propagation se décompose en deux phases : l'évaluation de la condition et l'exécution de l'action. Suivant la stratégie choisie pour la séquentialisation de ces deux phases, les conséquences ne sont pas identiques. Deux stratégies sont alors possibles pour l'exécution des règles :

1. soit le moteur évalue toutes les conditions des règles sélectionnées, puis exécute leur action ;

2. soit il évalue pour chaque règle sélectionnée sa condition suivie de l'exécution de l'action.

La deuxième stratégie pose le problème du contexte d'évaluation de la condition. En effet, celui-ci n'est pas le même que celui du déclenchement de l'événement, car l'action peut modifier ce contexte. Pour cette raison, nous avons choisi la stratégie où on évalue d'abord l'ensemble des conditions, puis on exécute les actions des règles dont la condition est satisfaite.

Pour l'exécution d'un ensemble de règles de propagation, le moteur commence par déterminer les règles les plus spécifiques, et il évalue ensuite les conditions de ces règles. Si la condition d'une règle est satisfaite, la règle est mise de côté afin d'exécuter son action ultérieurement et les règles qu'elle inhibe sont retirées de l'ensemble des règles de propagation de départ. Sinon, la règle insatisfaite est abandonnée. L'algorithme boucle tant que l'ensemble des règles de

propagation est non vide. Ensuite, les actions des règles de propagation mises de côté sont exécutées. Les actions des règles sont exécutées les unes après les autres.

Lors de l'exécution de l'action d'une règle de propagation, celle-ci peut induire l'exécution de règles dites induites. Ce type de règles est sélectionné lorsqu'un événement est détecté dans l'action d'une règle. Trois stratégies sont possibles pour leur évaluation (Figure 7-15):

• Soit les règles induites sont exécutées après l'exécution des actions restantes (Stratégie1, Figure 7-15).

• Soit elles sont exécutées avant les autres actions (Stratégie2, Figure 7-15).

• Soit les conditions des règles induites sont évaluées avant les actions restantes et leurs actions le seront ultérieurement (Stratégie3, Figure 7-15).

Action R1 Action R2 Action R3 R21 R1,R2,R3 Action R21 Condition R1, R2, R3 Condition R21 Stratégie1 Action R1 Action R2 Action R3 R21 R1,R2,R3 Action R21 Condition R1, R2, R3 Condition R21 Stratégie2 Action R1 Action R2 Action R3 R21 R1,R2,R3 Action R21 Condition R1, R2, R3 Condition R21 Stratégie3 Figure 7-15 : Les stratégies d'exécution des règles induites

Nous retrouvons toujours le même problème du contexte de déclenchement de l'événement que précédemment. Dans la Figure 7-15, la première stratégie est rejetée car la condition de la règle R21 ne s'exécute pas dans le contexte de l'action de R2. Nous adoptons la deuxième stratégie car l'action s'exécute immédiatement (ce n'est pas le cas de la stratégie 3). En effet, nous pensons que si l'utilisateur déclenche une règle de propagation, c'est avec l'intention qu'elle soit évaluée dans le contexte de l'action. Par exemple, si la règle est déclenchée par l'appel d'une méthode, c’est que l’utilisateur souhaite qu’elle soit exécutée avant l'action de la règle déclenchante, sinon il aurait choisi l'événement retour méthode. Pour cela, les règles induites seront exécutées immédiatement, interrompant momentanément l'exécution des actions restantes.

Pour finir la description du modèle actif nous avons rajouté des commandes dynamiques pour contrôler le moteur d'exécution, telles que l'activation et la désactivation d'un événement ou

7.5 SYNTHESE

Nous avons proposé dans ce chapitre un modèle actif qui permet la génération et la mise en œuvre de règles actives. La syntaxe de ces règles est classique ; une règle s'énonce par trois composantes principales : l'événement, la condition et l'action. Ces règles ne sont pas encapsulées dans les classes, mais contenues dans des bases hiérarchisées. Leur exécution est assurée par un moteur offrant la possibilité de les activer et de les désactiver à tout moment, mais n'offrant malheureusement qu'un mode de couplage (immédiat). Les règles actives présentées dans ce chapitre permettent l’expression de l’évolution de schémas, mais l’inconvénient est que souvent le concepteur se voit obligé d’écrire plusieurs règles ECA pour exprimer une seule règle d’évolution. De plus, ce modèle de règles n’apporte de solutions pour la définition de plusieurs stratégies d’évolution. Le chapitre suivant va tenter d’apporter des solutions à ces inconvénients à travers un mécanisme de règles et de stratégies d’évolution.

Parmi les extensions en cours du modèle actif, nous envisageons la modification du moteur d'exécution afin qu'il puisse accepter de nouveaux types de règles (Exemple : règles de cohérences, permettant de représenter des contraintes faibles), ainsi que l'introduction de nouvelles caractéristiques du modèle actif, comme la notion de priorité, de séquence d'événements et d'événement temporel [Clerc95].

Le modèle actif tel qu'il est présenté a été réalisé sur le prototype SHOOD (Version V1.14), sans modifier le code existant et cela grâce aux capacités d'extensibilité du modèle. Afin de mieux manipuler les concepts du système actif, celui-ci est exploitable à travers une interface homme-machine conviviale (Ecran 7-1 et Ecran 7-2).

L’Ecran 7-1 présente la fenêtre principale du schéma actif. Cette fenêtre est composée de quatre sous fenêtres chacune gérant respectivement les événements méthodes, les événements utilisateurs, les bases de règles et le schéma utilisateur. Au niveau du graphe des événements, les événements "mouchetés" sont inactifs. Pour le graphe des événements méthode, un événement est à moitié moucheté, si seulement un des deux types d'événement (appel ou retour) est inactif.

L’Ecran 7-2 correspond à la fenêtre d’édition d’une règle active. Les quatre sous fenêtres permettent la saisie respectivement de l’expression événementielle, les paramètres et les variables, la condition et l’action. Une aide est fournie pour la saisie des informations telles que les règles inhibées, les filtrages, etc.

Les bases de l’Ecran 7-1 et la règle de l’Ecran 7-2 correspondent à l’exemple de classification des parallélogrammes (cf. Figure 7-7).

8. STRATEGIES ET REGLES D'EVOLUTION

ans le chapitre 4, nous avons défini la stratégie d’évolution par défaut du système SHOOD, codé dans les opérations de manipulation. Dans ce chapitre, nous présentons un mécanisme qui permet la redéfinition de ces opérations, ainsi que la gestion de plusieurs stratégies. Ce mécanisme, le dernier de notre système d’évolution, a nécessité la définition des concepts d’opération, de règle et de stratégie, ainsi que la définition d’un langage de commandes permettant l’exploitation des règles et des stratégies d’évolution [Bounaas95d].