3.10.1 Introduction
Ce comportement n’est pas traduit sous la forme d’une règle dans le modèle comportemental XML global de l’AC. Il l’est dans le tag de configuration
competenceEffectorsList du fichier de configuration globale ${SMA_ROOT}/conf/agents/competence.properties des agents compétence. Il s’agit en effet d’un comportement provoqué suite à demande active de la part de l’utilisateur humain du système à travers son IHM GRAILS.
127
3.10.2 Ecran de paramétrage de la demande utilisateur
La demande de l’utilisateur s’effectue via l’écran présenté figure 15. La compétence à interroger est sélectionnée dans une liste déroulante. Le positionnement de valeurs pour les autres paramètres (généraux ou compétences élémentaires) est facultatif. Des valeurs par défaut seront appliquées par le moteur de R&D si nécessaire.
128
3.10.3 Echanges de flux
La figure 16 propose une vue schématique des échanges de flux, en 2 étapes, pour ce comportement : Agent WebRequester Tables « memory_Ci » (1 par Agent) Agents Compétence SMA - JADE G A T E W A y Conteneur Servlet (Apache Tomcat) ET/OU Application Grails CG33 Web Requester Servlet 1 (valeur signal : 200) 2 (valeur signal : 200) 3 (valeur signal : 200) 4 6 (liste acteurs XML) 7 (liste acteurs XML) 8 Capteur Effecteur 5
Figure 16 Sélection des acteurs : échanges de flux
Pour établir un parallèle avec les fichiers de configuration déjà détaillés plus haut, on notera que la valeur 200 du signal correspond au déclenchement de l’effecteur
FindBestActor qui est déclaré dans le tag de configuration competenceEffectorsList. De
manière plus détaillée, selon l’étape d’échange39, les flux identifiés lors de la mise en œuvre de ce comportement sont présentés dans le tableau 15.
N° Etape 1 : exécution de la demande de liste Etape 2 : validation de la liste des acteurs
1
Exemple de paramètres vers moteur de R&D
signalCode=200 stepNumber=1 agentId=1508 useMemory=true useOnlyResponses=false resultsNumber=1 criteriasWeights=305,0.3:269,0.3:2441,0.2:47,0.2
Exemple de paramètres vers moteur de R&D
signalCode=200 stepNumber=2 agentId=1508
humanDecision=true memoryCode=1
2 Transmission (standard JADE) de la demande entre WebRequester Servlet et WebRequester
Transmission (standard JADE) de la validation entre WebRequester Servlet et WebRequester
129
Agent Agent
3 Transmission de la demande à l’agent compétence interrogé
Transmission de la validation à l’agent compétence
4
Extraction des souvenirs antérieurs validés en mémoire
Calcul des nouveaux poids des compétences élémentaires
Validation du souvenir
5
Extraction de la liste des acteurs
Formatage de la liste des acteurs sous la forme d’un flux XML
Sans Objet
6 Renvoi du flux XML des acteurs vers
WebRequester Agent
Renvoi du flux XML avec le résultat de validation vers WebRequester Agent
7
Transmission (standard JADE) de la liste dans le flux XML entre WebRequester Agent et
WebRequester Servlet
Transmission (standard JADE) du flux XML avec le résultat de validation entre
WebRequester Agent et WebRequester Servlet
8 Affichage de la liste des acteurs au format HTML Affichage du résultat de validation au format HTML
Tableau 15 : Sélection des acteurs : tableau détaillé des flux échangés
On notera que le paramètre criteriasWeights contient la liste des couples (identifiant de compétence élémentaire, poids demandé pour cette demande) définis par l’utilisateur au moment de l’expression de sa requête. Les poids sont normalisés à la valeur 1.
3.10.4 Apprentissage
Il ne s’agit pas ici de reprendre en détail tout l’algorithme qui a déjà été présenté dans le chapitre de modélisation. Le code informatique écrit en langage Java ne fait, en effet, que le traduire. On notera toutefois l’enchainement de certaines étapes de traitement nécessaires à l’apprentissage.
Etape 1 : Suite à la constitution de la liste d’acteurs répondants aux critères renseignés
par l’utilisateur lors de l’émission de sa demande, l’AC qui est interrogé créé un nouvel enregistrement dans sa table mémoire memory_Ci. . Cet enregistrement correspond à un nouveau souvenir et sa colonne human_validated est positionnée à la valeur faux.
Etape 2 : La liste des acteurs fournis par l’AC est renvoyée à l’utilisateur (flux 8, étape
1). Cette liste est considérée comme étant la décision de l’AC suite à la demande utilisateur. Aux âges d’enfance et d’adolescence, une validation humaine doit être acquise40. C’est le rôle rempli par des écrans comme celui présenté figure 17.
130
Figure 17 Sélection des acteurs : écran de validation de la décision de l’AC
Etape 3 : Si la validation humaine est prononcée, l’AC met à jour le souvenir
correspondant à la prise de décision courante. Dans la table mémoire memory_Ci, le champ human_validated passe alors de la valeur faux à la valeur vrai.
L’enchainement des 3 étapes que nous venons de décrire permet de donner un sens réel à l’apprentissage. Grâce aux mécanismes de validation humaine, il fait sens dans le contexte fonctionnel métier où évolue l’AC. Selon l’algorithme de sélection des acteurs, les poids de chaque compétence élémentaire sont recalculés, à chaque demande utilisateur, en tenant compte des souvenirs précédemment validés. D’un point de vue implémentation, on travaille à partir des valeurs des poids de chaque critère d’efficacité disponibles. Ces derniers sont pris dans les différentes valeurs du paramètre
criteriasWeights des souvenirs qui ont été validés antérieurement, c’est-à-dire ayant une
valeur du champ human_validated positionnée à vrai. Pour tout AC, grâce à l’acquisition de plus en plus de souvenirs validés, nous constatons que la valeur des poids recalculés de chaque compétence élémentaire converge. Ce phénomène sera également démontré plus loin via l’utilisation d’un simulateur comportemental dédié à cette sélection des acteurs.