Vue d’ensemble de la mise en oeuvre de notre mod` ele Eass

Dans un premier temps, nous pr´esentons le g´en´erateur de syst`_{emes experts Jess, puis} nous d´_{etaillons le couplage de Jess avec Madkit pour mettre en oeuvre notre architecture} fonctionnelle et plus pr´ecis´ement notre environnement de simulation.

Le travail de d´eveloppement est commun `a la plate-forme de communications s’ap- puyant sur le mod`<sub>ele Easi [Saunier, 2008], et `a la plate-forme de simulation s’appuyant</sub> sur le mod`_{ele Eass.}

3.3.1.1 Pr´esentation du g´en´erateur de syst`emes experts Jess

Jess (Java Expert System Shell) [Friedman-Hill, 2003]14est un g´en´erateur de syst`emes experts `a base de r`egles fond´<sub>e sur l’algorithme Rete [Forgy, 1990] qui est un algorithme</sub> incr´emental d’unification. L’architecture d’un syst`eme expert `a base de r`egles est compos´e d’une base de connaissances (contenant des r`egles) qui repr´esente les d´eductions possibles du syst`eme `a partir de faits, une m´emoire de travail qui contient les faits et un moteur d’inf´erence qui d´eclenche les r`egles `a partir des faits avec une politique de gestion des conflits. Le moteur d’inf´erence doit, en cas de conflits dans le d´eclenchement des r`egles, d´eterminer la r`egle qui sera d´eclench´ee avant les autres `a partir d’une strat´egie de r´eso- lution de conflits. Le processus d’ex´ecution du syst`eme expert par le moteur d’inf´erence est classique et se divise en trois phases. Dans un premier temps, il compare les faits avec les conditions exprim´ees dans les r`egles (appariement r`egle/faits) ce qui lui permet de construire l’ensemble des r`egles d´eclenchables (stock´ee dans un agenda). Ensuite, il applique une strat´egie de r´esolution de conflits (par exemple la premi`ere rencontr´ee) pour d´eterminer la r`egle `a d´eclencher. Et la derni`ere phase d´eclenche la r`egle afin d’ex´ecuter le

code qui lui est associ´e.

L’avantage de Jess est de permettre `a des objets qui sont des instanciations de classes Java d’ˆetre repr´esent´es dans le syst`eme expert sous forme de faits. Sans entrer dans le d´etail, les classes correspondent `a des template de la base de faits qui permettent ensuite dans la d´eclaration des r`egles de simplifier l’expression des conditions sur les faits associ´es aux templates.

L’´evaluation des conditions avec les faits est fond´_{ee sur l’algorithme Rete. L’algo-} rithme de Rete est un algorithme incr´emental d’unification dont l’objectif est de reduire fortement le temps d’ex´ecution du syst`eme expert. Une r`egle, identifi´ee par le mot cl´e defrule, est divis´ee en deux parties : les pr´emisses et les actions `a ex´ecuter si les pr´emisses sont v´erifi´ees. Une r`_{egle est de la forme : si (condition 1) et (condition 2) et . . . et (condi-} tion n) alors (action 1) (action 2) . . . (action m), qui exprime que si un fait 1 v´erifie la condition 1 et un fait 2 v´erifie la condition 2, ... alors l’ensemble des actions associ´ees `a la r`egle est ex´ecut´e. Pour notre utilisation, les faits de la base de connaissances respectent la structure des template de Jess o`u un template est r´ef´erenc´e par un nom et est constitu´e de champs associant une propri´et´e `a soit une valeur soit une liste de valeurs.

L’algorithme Rete construit un arbre de d´ecision o`u chaque noeud (except´e la racine) correspond `a un sous-ensemble des pr´emisses d’une r`egle, alors que le chemin du noeud racine `a une feuille de l’arbre d´efinit l’ensemble des pr´emisses au complet d’une r`egle. Chaque noeud a une m´emoire des faits qui satisfont les conditions. Lorsque de nouveaux faits sont affirm´es ou modifi´es, ils se propagent le long de l’arbre, annotant les noeuds quand les faits correspondent aux pr´emisses. Quand un fait ou une combinaison des faits satisfait tous les noeuds de la racine `a la feuille de l’arbre ce qui correspond `a une r`egle donn´ee, la r`egle est d´eclench´<sub>ee. L’algorithme Rete privil´egie la vitesse d’ex´ecution du</sub> syst`eme expert pour r´esoudre un probl`eme au d´etriment de la m´emoire n´ecessaire `a sa r´esolution. Dans les tr`es grands syst`_{emes experts, la limite de l’algorithme Rete classique} est le probl`eme li´e `a la consommation et l’acc`es `a la m´emoire.

Nous introduisons les ´equivalences entre les actions des agents et leurs d´eclarations dans le syst`eme expert. En langage objet, les cat´egories d’entit´es sont des classes diff´e- rentes. A cette fin, nous d´eclarons les diff´erentes classes avant de les utiliser pour l’appa- riement :

( d e f c l a s s agent Agent )

( d e f c l a s s environment Environment ) . . .

3.3. Premi`ere impl´<sub>ementation : un couplage entre MadKit et Jess</sub> Une fois les classes d´efinies, chaque entit´e est ajout´ee grˆace `a un appel `a definstance ou enlev´ee (undefinstance). Un raccourci int´eressant propos´e par JESS est la traduction de tous les attributs d’une classe impl´ement´ee sous forme de Java Beans en tant que champs de l’objet dans le syst`eme. De la mˆeme fa¸con, la mise `a jour est r´ealis´ee de fa¸con automatique via la fonction update.

Les filtres respectent le principe des r`<sub>egles Jess auxquelles sont ajout´ees le nom, la</sub> priorit´e du filtre et l’´etat de l’automate d’ex´ecution dans lequel le filtre doit se situer. La figure 3.5 illustre la syntaxe d’un filtre `_{a l’aide de Jess.}

Arguments: name , p r i o r i t y , lhs , rhs ( d e f r u l e name

( d e c l a r e ( s a l i e n c e p r i o r i t y ) ) ( s t a t e ( value stateF ) )

l h s

( environment ( time ?tE ) (OBJECT ?o ) ) ( not

( agent ( time ? t&: (< ? t ?tE ) ) ) )

=> rhs

( c a l l ?o setTime (+ ?tE 1 )) )

Fig. 3.5 – Un exemple de r`egle d´efinie avec Jess

La priorit´e d’un filtre est pr´ecis´ee grˆace `a la commande (declare (salience priority)). Ainsi, le filtre avec la plus grande priorit´e est ´evaluer avant les filtres de plus basse priorit´e. L’´etat de l’automate d’ex´ecution auquel le filtre appartient est d´etermin´e `a l’aide du fait (state (value stateF)) qui permet de sp´ecifier que la r`egle ne pourra ˆetre d´eclench´ee qu’`a partir du moment o`u le fait identifi´e par le nom state a sa propri´et´e value `a stateF . stateF est le nom que le concepteur `a donner pour identifier un ´etat de l’automate d’ex´ecution.

Le terme OBJECT permet de d´esigner un objet du langage JAVA. Ainsi `a l’aide de la commande call, nous sommes capables d’ex´ecuter des m´ethodes de l’objet en pr´ecisant les param`etres d’appel de la m´ethode. Sur la r`egle 3.5, nous avec modifi´e l’attribut time de l’objet identifi´e par (OBJECT ?o) qui est du type environment en appelant la m´ethode setT ime() de cet objet avec le param`etre ?tE +1. Cette r`egle traduit le fait que le temps de

l’environnement est incr´ement´e de 1 lorsque tous les agents de la simulation ont ´et´e activ´es, i.e. que le temps interne des agents est sup´erieur ou ´egal au temps de l’environnement. Comme nous le montrerons dans la section 3.3.2 qui d´etaille le d´eveloppement de la classe Environment, nous aurions pu utiliser une autre strat´egie pour modifier le temps ; dans ce cas on aurait fait appel directement `a la m´ethode timeStrategy().

Le retrait s’effectue `a l’inverse par un undefrule. Cette commande est appel´ee unique- ment `a partir du moment o`u la liste des agents concern´es par le filtre est vide (section 2.6.2).

Nous avons identifi´e les primitives minimales `a impl´ementer pour pouvoir interfacer diff´erents syst`emes experts avec notre mod`ele d’environnement (figure 3.6).

enterEnvironment()

addEntity()

removeFilter()

addFilter()

updateObject()

initialize()

put()

execute()

activate()

reset()

implements

JessLayer()

ESLayer

JessLayer

enterEnvironment()

addEntity()

removeFilter()

addFilter()

updateObject()

initialize()

put()

execute()

activate()

_Rete

Fig. 3.6 – L’interface ESLayer et sa classe JessLayer

Nous pouvons regrouper les fonctions en trois cat´egories : la vie de l’environnement, l’inscription des agents et la gestion des filtres et descriptions. Les fonctions initialize() et activate() sont utiles `a MadKit lors de la cr´eation et du lancement de l’environne- ment. La fonction enterEnvironment() est d´edi´e `a l’inscription des agents dans l’envi- ronnement. L’ajout et le retrait des filtres sont effectu´es par les fonctions addFilter() et removeFilter(). La fonction addEntity() permet de d´eclarer un nouveau type d’objet dont la description sera utilis´ee par la suite. Dans cette plate-forme, les entit´es sont g´e- r´ees de telle sorte qu’elles sont enregistr´ees directement aupr`es de l’environnement qui extrait de fa¸con automatique leur description. L’enregistrement se fait de la mˆeme fa¸con que les agents, par enterEnvironment(). Lorsque la valeur d’une propri´et´e est modifi´ee,

3.3. Premi`ere impl´<sub>ementation : un couplage entre MadKit et Jess</sub> la fonction updateObject() permet de mettre `a jour les donn´ees au sein du syst`eme ex- pert. La fonction put() permet de d´eposer un message dans l’environnement. La fonction execute() n’est pas disponible pour les agents, mais elle est exploit´ee par l’environnement dans le cas o`u l’instruction que le syst`eme expert doit effectuer n’est pas couverte par les autres fonctions.

3.3.1.2 La mise en oeuvre de l’architecture fonctionnelle

Le paquetage impl´ementant le mod`<sub>ele Eass pour la plate-forme MadKit a ´et´e d´eve-</sub> lopp´e de fa¸con `a permettre l’´elaboration d’un environnement d’ex´ecution et interactionnel tout en b´en´eficiant d’une infrastructure d´ej`a existante. Il s’agit donc d’une biblioth`eque pour la mise en oeuvre du mod`ele EASS, contenant `a la fois l’environnement et les pri- mitives d’accession `<sub>a celui-ci. Du fait du principe d’agentification de MadKit, l’environ-</sub> nement est un agent. La mise en oeuvre de l’environnement d’ex´ecution consiste `a d´efinir des r`<sub>egles d’activation en Jess qui seront g´er´ees par ce dernier et dont la particularit´e</sub> est d’avoir une partie action qui correspond au comportement d’un agent (m´ethode d´ev´e- lopp´ee par le concepteur dans l’agent). En ce qui concerne les communications, la partie action des r`egles correspond `<sub>a la primitive de communication de MadKit qui consiste `a</sub> transmettre directement le message dans la boˆıte aux lettres des agents. De ce fait, l’agent environnement est g´er´_{e par le cycle de vie du noyau MadKit et la transmission des mes-} sages aux agents est assur´e ´egalement par le noyau mais elle est conditionn´e par les r`egles de communications (filtres). La plate-forme distribue les messages par invocation d’une m´ethode du micro-noyau, laquelle effectue la s´election des r´ecepteurs et d´epose le message dans leurs boˆıtes aux lettres. Pour communiquer, l’agent choisit soit d’utiliser directement le micro-noyau de MadKit, soit d’utiliser l’environnement.

La figure 3.7 illustre les connexions entre le micro-noyau de la plate-forme MadKit, le g´en´erateur de syst`_{emes experts Jess et notre environnement de simulation. Elle pr´ecise} ´

egalement les diff´erents flux d’information dans le paquetage.

Nous avons choisi l’environnement de d´eveloppement de syst`emes `a base de r`_{egles Jess} pour impl´ementer l’environnement car il r´epond aux diff´erentes sp´ecifications identifi´ees par l’architecture fonctionnelle 3.2. De plus, MadKit est d´evelopp´e en Java et Jess est con¸cu pour s’interfacer parfaitement avec cet environnement.

données module fonctionnel lois flux (description) flux (filtre) flux (message) flux (autre)

vérification état filtres

état Agent Kernel Environnement Système expert JESS communication cycle de vie groupes et roles transmission activation

Fig. 3.7 – Flux d’informations du paquetage impl´ementant le mod`ele Eass pour la plate- forme MadKit