6. Ingénierie logicielle orienté agent
6.3 Méthodologies orientées agent

Il y a deux grands groupes de méthodologies pour le développement du logiciel orienté agent. Le premier groupe étend ou adapte les méthodologies orientées objet pour prendre en compte les caractéristiques des agents, alors que le deuxième groupe part des méthodologies de l'ingénierie de connaissances.

6.3.1 Méthodologies orientées agent basées sur l'orientation objet

Beaucoup de méthodologies orientées objet sont utilisées dans l'industrie avec succès, par exemple la Technique de Modélisation à base d'Objets (OMT- Object Modelling Technique - Rumbaugh, 1991), l'Ingénierie du Logiciel Orientée Objet (OOSE- Object Oriented Software Engineering - Jacobson e.a., 1992), la Conception Orientée Objet (Booch, 1994) et UML (Unified Modelling Language - Rational Software Corporation, 1997). Les extensions et les modifications des méthodologies orientées objet doivent prendre en compte les différences qui existent entre les objets et les agents (pour ces différences, voir la section 2.3.2.

La méthodologie AAII (Australian Artificial Intelligence Institute)

L'Institut australien d'intelligence artificielle a développé plusieurs systèmes multi-agents en utilisant leur technologie BDI-PRS (Belief-Desire-Intention - Procedural Reasoning System, voir plus de détails dans la section 2.2.2). La méthodologie AAII a été développée en partant de l'expérience accumulée pendant la construction de ces systèmes. Dans cette méthodologie, on a un ensemble de modèles qui, dès qu'on les a élaborés entièrement, définissent les spécifications des agents. Il y a un modèle externe qui spécifie : (i) le point de vue système, notamment les agents et les relations entre ces agents ; (ii) le modèle d'agent, notamment les classes d'agents et les instances associées ; (iii) les rapports d'héritage entre les classes d'agents et les instanciations de ces classes au moment de l'exécution. Chaque agent a trois attributs : croyances, désirs et intentions, et on peut spécifier comment un agent hérite de ces attributs dans la hiérarchie des classes. Il y a aussi un modèle interne qui représente l'implémentation de l'agent.

Les étapes pour concevoir un système multi-agents en utilisant la méthodologie AAII sont :

• Identifier les rôles pertinents pour le domaine d'application et développer une hiérarchie de classes d'agents ;
• Identifier les responsabilités associées à chaque rôle, les services exigés et fournis par le rôle et les buts associés à chaque service ;
• Pour chaque rôle, déterminer les plans qui peuvent être utilisés pour accomplir le rôle et les conditions du contexte pour lesquelles un plan est opportun ;
• Déterminer la structure de croyances du système, notamment l'information exigée par chaque plan et chaque but à accomplir.

La méthodologie Gaia

La méthodologie Gaia, proposé par Wooldridge (Wooldridge e.a., 2001), permet de parcourir systématiquement le chemin qui commence par l'énoncé des demandes du problème et mène à une conception assez détaillée pour être implémentée tout de suite (le nom Gaia vient de l'hypothèse faite par James Lovelock qui dit qu'on peut voir tous les organismes de la biosphère comme participant ensemble à la régulation de l'environnement).

Gaia permet de concevoir un système multi-agents en utilisant un paradigme organisationnel. Les concepts (ou entités) de Gaia sont de deux types : abstraits et concrets (voir figure 6.2). Les entités abstraites sont utilisées pour la conceptualisation du système et n'ont pas nécessairement un correspondant direct dans l'implémentation du système. Les entités concrètes sont utilisées dans le processus de conception et ont, typiquement, un correspondant dans le système logiciel. Le paradigme organisationnel utilisé par la méthodologie est centré sur le concept de rôle. Un rôle est défini par quatre attributs : responsabilités, permissions, activités, et protocoles. Les responsabilités indiquent la fonctionnalité de l'entité. Par exemple, un agent peut avoir le rôle de coordonnateur avec les responsabilités de repartir de tâches et de vérifier l'accomplissement de ces tâches, ou le rôle d'agent de ventes avec les responsabilités d'organiser une enchère et de vendre un certain produit.

Pour réaliser les responsabilités, un rôle est associé à un certain nombre de permissions. Les permissions sont les droits correspondant à un rôle et représentent, dans beaucoup de cas, des ressources informationnelles. Par exemple, un rôle peut être associé à la permission de lire une certaine information dans le système ou de modifier une autre information. Les activités associées à un rôle sont les calculs nécessaires pour réaliser les responsabilités et qui peuvent être exécutés par l'agent sans l'aide d'un autre agent. Les activités peuvent être des propriétés actives, notamment ce que l'agent doit faire pour arriver à remplir ces responsabilités, ou des propriétés de sûreté, notamment les conditions que l'agent doit maintenir pendant l'exécution des activités.

Un rôle a aussi un nombre de protocoles associés. Par exemple, le rôle agent de vente peut avoir accès aux protocoles enchère anglaise et enchère hollandaise, le protocole réseau contractuel est associé aux rôles gestionnaire et contractant (voir la section 5.3.2 pour la négociation aux enchères et la section 5.4.1 pour la négociation par réseau contractuel).

La méthodologie AUML (Agent Unified Modelling Language)

Le langage de modélisation unifiée (Unified Modelling Language) est un essai d'unifier les divers paradigmes d'analyse et de conception orientée objet du logiciel et offrir une notation unique pour la modélisation des systèmes orientés objet. Il faut noter qu'UML n'est pas une méthodologie, mais, comme son nom le dit, un langage pour faire la documentation des modèles de systèmes. Il y a aussi une méthodologie associée à UML qui s'appelle "Rational Unified Process" (Booch e.a., 1998).

Dans ce contexte, on a proposé d'adapter les notations d'UML pour décrire la modélisation orientée agent. Les modifications proposées à UML sont :

• soutien pour la représentation des threads simultanés d'interaction (par exemple transmission de messages à plusieurs agents) permettant ainsi à UML de modéliser les protocoles d'interactions entre agents, par exemple le réseau contractuel ;
• la notion de rôle qui étend celle fournie par UML et permet de modéliser un agent qui joue plusieurs rôles.

L'initiative la plus connue pour étendre UML avec des facilités permettant de décrire les agents s'appelle AUML (Agent Unified Modelling Language) et a comme but de :

• recommander une technologie pour l'adoption d'une sémantique, un meta-modèle et une syntaxe abstraite communes pour l'analyse et la conception des méthodologies basées sur agents ;
• recommander une technologie qui permet l'interopérabilité à travers le cycle de vie des produits et d'outils de travail AUML ;
• être en accord avec les spécifications existantes de FIPA (Foundation for Intelligent Physical Agents) et OMG (Object Management Group).

Il faut noter que, actuellement, AUML est plutôt un but qu'un langage de modélisation existant. L'OMG (Object Management Group) et la FIPA (voir la section 4.5) appuient le développement des notations UML pour la modélisation des systèmes multi-agents et prévoient des efforts considérables dans cette direction.