Une des principales classes d'un moteur de faits reste Fact. Comprendre la différence entre fait et donnée est déjà difficile. Mais pour implémenter une classe de faits, il faut se poser un certain nombre de questions. On va en faire profiter la communauté...

 D'abord, dans les moteurs standards, tout changement d'un attribut d'un fait donnera lieu à une reprise du graphe de RETE. Donc, "tout se passe comme si" le moteur de règles observait (pattern Observer, GoF) les changements du fait.

Ensuite, on peut voir un fait comme la donnée de la classe qu'il implémente, ainsi qu'une map<string,object> avec les clés sont les noms des attributs, et les objets sont les valeurs des attributs. Le nom de la classe permet de passer les ObjectNode, autrement dit les noeuds qui vérifient la classe de l'objet. Un premier contrôle des attributs peut avoir lieu à cet endroit, même si ce n'est pas la vocation des ObjectNode.

 Coté faits, c'est donc plutôt facile (sur le papier). Reste la question des méta data (fact meta data, FMD dans la suite). La question se pose comme suit. Un utilisateur définit une classe (un POJO disons) pour la structure de son fait. C'est çà qu'on appelle FMD. Il y a deux possibilités: soit une source externe (DSL, declare de JBoss) ou une classe dans le langage cible (java pour JBoss). La classe définit le FMD. Comment le coder, et comment procéder dans un langage comme le C++ sans classe Object?

Un type s'instancie en instances, hein, et les instances ont une classe. Jusque là, rien de neuf. Le truc avec les méta données, c'est que les instances de méta données sont des types. On peut les manipuler comme des objets, notamment ajouter des attributs, etc. La question devient donc lier les FMD aux facts. L'équation est de dire: les facts sont des instances des FMD.

Et donc, les FMD définissent les possibilités du langage de règles. On a une première limite qui est celle du c++. Enfin, en pratique, car en théorie, tout est possible en C++. Enfin, tout... Bref, comment architecturer les FMD et leurs liens avec les faits? A priori, on doit pouvoir disposer d'une fonction newInstance sur FMD qui donne un fact avec la structure de données déjà prête. Le fait est revu pour disposer d'observer et calibré pour le contrôle de types. Pour garder une trace sur les modifications de faits, Drools expert utilise un modify et un FactHandler.

Donc, comment construire un système de faits sans super classe pour les objects? A suivre!

 

Comments are closed.

Set your Twitter account name in your settings to use the TwitterBar Section.