2.5 Modèle agent proposé
2.5.3 Modèle de données
Les Agents Compétence stockent concrètement les données descriptives qu’ils manipulent et qu’ils créent dans une base de données. Dans ce paragraphe, le schéma de la figure 10 expose une vue des tables les plus importantes.
80
81
Présenter le modèle avec l’intégralité des tables qui le composent est trop fastidieux. Nous limitons notre description aux tables principales, en lien direct avec la modélisation des ACs. La table « agent » est au cœur du système et contient un enregistrement Enri par AC. Soit Ci la valeur du champ « code » identifiant un AC dans chaque Enri..
Champ Description Exemple de contenu
code Identifiant unique 1556
descriptionagent Description textuelle Accompagner chefs de projets / M.O.
learning_mode Mode apprentissage TRUE
usage_number Nombre de sollicitations cumulées dans tous les projets
10
rules Règles comportementales <?xml version="1.0" encoding="UTF-8"?>……</xml>
age_id Identifiant de l’âge courant 1 basic_rules_id Identifiant des règles de
base
541
key_words Mots clé Projet, Maîtrise d’œuvre, Pilotage
abstract_content Description détaillée L’accompagnement des chefs de projet permet d’aider les chefs de projet à : piloter leurs projets, gérer les risques (Identification et mise en place de plans d’actions), mettre en place des tableaux de bord et les rapports, améliorer la communication au sein des projets, améliorer la gestion de la documentation projets
82
Parmi les tables liées à agent on trouve celle nommée age qui décrit les étapes du cycle de vie des ACs. La table basicrules contient les règles éducatives de base comme par exemple les règles de croissance entre les différents âges des ACs. Autre table importante : memory. En fait, il existe dans le modèle 1 table memory_Ci pour chaque AC. Ces memory_Ci assurent l’étanchéité des souvenirs de chaque AC et concrétisent le souhait de n’offrir qu’une vue partielle de l’environnement global à chacun d’eux. On notera qu’au moment de sa « naissance » dans le SMA, chaque AC recopie les règles de
basicrules qui le concernent dans le champ rules de son Enri dans la table agent. De même, la table memory_Ci qui lui est dédiée est créée si elle n’existe pas.
Champ Description Exemple de contenu
code Identifiant unique 1
evt_date Date de création 2013-09-30
evt_id Type d’évènement
sur le souvenir (1 =
création, 2 =
validation humaine) 1
agent_id Identifiant de l’agent 3192
parameters_in Paramètres en entrée stepNumber=1;useOnlyResponses=false; controller=RDEngine;resultsNumber=1;si gnalCode=200;useMemory=true;action=c allRdEngineForBestActor;agentId=3192 decision_string Décision prise <reponses><reponse><num>1</num><m
emoryCode>#</memoryCode><userid>3 152</userid><firstname>Xavier</firstna me><lastname>PASTEAU</lastname><s ervice>XPS</service></reponse></repon ses>
human_validated Validation humaine TRUE
comment Commentaire
décrivant à quel type de comportement de l’agent s’applique le souvenir
Trouver meilleur acteur
Tableau 3 : Illustration du contenu d’un enregistrement de la table mémoire d’un agent Tout AC appartient à un domaine de compétence intégré à la table agt_domain. Chacun de ces domaines peut avoir un ou plusieurs domaines pères référencé dans
agt_domain_agt_domain. On notera simplement que la valeur du champ rang_domain_agt est utilisée dans l’interface GRAILS de l’utilisateur pour déterminer
l’ordre de restitution à l’écran des domaines dans un explorateur6 de compétences. Comme pour les compétences, tout objectif enregistré dans objective appartient à un
83
domaine d’objectif de obj_domain. Ces derniers sont également hiérarchisables entre eux via la valeur du champ pere_id.
Chaque AC est concrétisé dans le mode réel par un ou plusieurs acteurs humains. Ceux-ci sont recensés dans une table des utilisateurs absente de la figure 10. Chacun d’eux peut alors être lié à un AC via des enregistrements dans la table agt_user. Chaque acteur peut posséder un certain niveau de compétence défini pour une compétence donnée, ce qui se traduit par un enregistrement dans agt_user_level. Dans le chapitre 2, nous avons vu que les ACs peuvent être liés entre eux. Ces liens sont fournis (puis appris) dans la table agent_agent. Nous avons également proposé qu’une compétence soit vu dans nos travaux comme décomposable en n compétences élémentaires, encore appelées critères d’efficacité. La table « efficency » liste ces critères. La jointure avec la table agent est assurée par les enregistrements de la table agent_efficency.
Les projets sont des instances d’objectifs7 pris dans objective. Nous avons proposé dans notre modèle théorique que les projets soient composés d’un enchainement d’AC. Ils sont évalués à postériori par un ou plusieurs acteurs humains, et selon un ensemble de critères d’efficacité. Chaque enregistrement de la table agt_objective décrit un projet avec en particulier le lien entre celui-ci (objective), les ACs (agent) qui le composent et les critères d’efficacité (efficency). La table agt_objective_eval stocke les données relatives aux formulaires d’évaluation de chaque projet. On y trouve, par exemple, l’identifiant de chaque évaluateur (e.g. demandeur et offreur de compétence au CG33) dans le champ evaluator_id. Les détails de chacun de ces formulaires, c’est-à-dire la valorisation accordée à chaque critère d’efficacité, pour chaque projet, sont stockés dans les enregistrements de la table agt_objective_eval_agt_objective_eval_criterias.