Le module de prise de décision individuelle (Individual Decision Making Module, IDMM) réalise le raisonnement à propos des services fournis ou demandés. L’IDMM s’appuie sur les structures de données concrètes dans la base de connaissance individuelle (Individual Knowledge Base, IKB). Les décisions sont prises selon les besoins ou les compétences de l’utilisateur à propos des services, des types de services possibles et des préférences/contraintes de l’utilisateur.
Les utilisateurs indiquent aux agents leurs exigences à travers l’interface graphique en dessinant des diagrammes d’influence (CLEMEN, 1996) où ils peuvent afficher la structure du problème de dé- cision à propos des services fournis ou demandés. Les éléments des problèmes de décisions sont : des décisions à prendre, des croyances incertaines et des valeurs prônées. Ils sont représentés dans des diagrammes d’influence comme des nœuds de différentes formes. Les nœuds sont les suivants : les nœuds de décision (représentés par des rectangles), les nœuds de chance (représentés par des ovales) et les nœuds de valeur (représentés par des rectangles avec des coins arrondis). Les nœuds sont connectés dans un graphe par des arcs, chacun reliant un prédécesseur avec un successeur. Pour chaque nœud, les prédécesseurs sont indépendants et affectent le successeur. Les diagrammes d’in- fluence sont construits sans cycle. Afin de modéliser une décision muti-critère, nous avons ajouté un autre type de nœud qui agrège les résultats des nœuds prédécesseurs. Un nœud de valeur abs- traite est un nœud de valeur spéciale représenté par un rectangle à bord arrondi avec un bord double. Un nœud de valeur concrète est spécifié pour chaque combinaison de décisions et de croyances qui alimentent ce nœud. Par contraste, une valeur abstraite est spécifiée pour chaque combinaison de valeurs qui l’alimentent. Dans de nombreux cas, une décision est le résultat d’un compromis entre des attributs. Dans un tel cas, il est possible de représenter explicitement ces attributs multiples dans une hiérarchie de valeurs où une valeur abstraite supérieure agrège les valeurs concrètes inférieures. De plus, l’interface graphique permet de spécifier les préférences et contraintes de l’utilisateur sur les valeurs et les croyances. Par exemple, la figure 3.4 présente le diagramme d’influence pour l’éva- luation d’un service par un agent de type A, e.g.Al. Le but principal supérieur (provision) est divisé en deux sous-buts abstraits indépendants concernant le coût (cost) et la qualité de données (qos). Ces sous-buts sont réduits à des sous-buts concrets. Par exemple, la qualité de service dépend de la qualité du service Sb(qosb). Alors que les buts abstraits reflètent les besoins de l’utilisateur, les buts
concrets fournissent des critères pour évaluer les différentes alternatives.
Le but principal, i.e. la composition effective du service S, est réalisé par des décisions, e.g. quels services concrets Sa et Sb choisir (en instanciant de manière approriée les variables x et y1dans la
figure 3.4). On note queAlest un candidat pour fournir le service Sa dans notre cas d’usage, mais il
peut fournir plusieurs instances de ce service. En d’autres termes, x peut être instancié de différentes manières. À l’inverse,Aln’est pas un fournisseur potentiel pour le service Sbet il a besoin d’en choisir
un. Ces décisions dépendent de la connaissance de l’agent, c’est-à-dire les informations concernant les services concrets fournis parAllui-même et les agents de type B (e.g.price,warranty).
L’utilisateur indique également ses préférences et contraintes. Par exemple, l’utilisateur indique que le coût est plus important que la qualité de service. Les priorités sont attachées aux buts, aux décisions et aux connaissances dans le diagramme d’influence pour représenter les préférences entre les buts, les utilités espérées des décisions et l’incertitude des connaissances.
La structure du problème de décision relatif à l’évaluation des services et les priorités associées sont stockées dans la base de connaissances de l’agent, en particulier dans la base de connaissances individuelle (IKB). Le raisonnement est effectué par le module IDMM. Au sein du projet ArguGRID, le module IDMM a été réalisé à l’aide du cadre d’argumentation pour la prise de décision. Par exemple, la base de connaissances, qui correspond au diagramme d’influence de la figure 3.6, est représentée dans la figure 3.5. Les règles de but sont représentées en haut alors que les règles de décision sont en
1. Dans ce chapitre, nous adopterons la convention suivante : les variables sont en italique et les constantes sont en police de caractère courrier.
3.3. ARCHITECTURE D’AGENT
bas. Dans cet exemple, il n’y a pas de règle épistémique. C’est la raison pour laquelle l’inclusion de présomptions sur les informations manquantes est cruciale pour réaliser le raisonnement individuel des agents demandeurs. Une règle au-dessus d’une autre a la priorité. Afin de simplifier la présenta- tion, la théorie est subdivisée en couches disjointes, i.e. différents niveaux. Les règles ex æquo sont regroupées au sein d’un même niveau. Les règles incomparables sont arbitrairement assignées à un niveau. Les règles de but expriment le fait qu’atteindre les butscostetqossont dans l’idéal néces- saire pour atteindre le butprovision, mais ceci peut être relâché : atteindre le butcostest suffisant pour atteindreprovision. Contrairement aux autres règles du tableau 3.5,r01n’est pas dans IKB ce qui reflète non pas l’exigence de l’utilisateur représenté parAlmaisr01est le résultat de l’interac- tion précédente entreAlet l’acheteur stocké dans le tableau d’engagement dialogique (Dialogical Commitment Store, DCS).r01reflète la préférence du client représenté par l’agent acheteur.
FIGURE3.5 – Les règles de but (en haut) et les règles de décision (en bas) représentant les exigences
des utilisateurs
Ces structures de données concrètes (règles et priorités) fournissent la colonne vertébrale des arguments. Par exemple,Alpeut construire un argument admissible concluant que le but relatif au coût du service Sb est atteint en sélectionnant Sb(x) si on suppose que le prix du service Sb(x) est
faible.
Le module IDMM interagit avec les autres composants de l’architecture comme suit. Il interagit avec la GUI, à travers le module CM, qui utilise l’environnement GOLEM comme un médiateur pour interagir avec les autres entités du système et avec l’utilisateur. L’IDMM est informé et répond quand un service est (ou doit être) instancié. L’IDMM interagit avec le SDMM en demandant ou en fournis- sant l’instanciation du service abstrait ou partiellement instancé. De cette manière, l’IDMM traduit les buts et préférences de l’utilisateur en une représentation abstraite de services atomiques (ou de services composés, si nécessaire). Par exemple,Alpeut construire un argument admissible concluant que le but relatif à l’approvisionnement du service S est atteint si on suppose que le prix du service Sb(y) est faible. Ceci est à nouveau traduit dans une représentation concrète (le choix de y satisfait la