Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Chapitre 2 Méthodes orientées agent et multi-agent 2.1. Introduction Les systèm

Chapitre 2 Méthodes orientées agent et multi-agent 2.1. Introduction Les systèmes multi-agents (SMA) ont montré leur pertinence pour la conception d’applications distribuées (logiquement ou physiquement), complexes et robustes. Le concept d’agent est aujourd’hui plus qu’une technologie eﬃcace, il représente un nouveau paradigme pour le développement de logiciels dans lesquels l’agent est un logiciel autonome qui a un objectif, évolue dans un environnement et interagit avec d’autres agents au moyen de langages et de protocoles (voir le chapitre 1 « Intro- duction aux systèmes multi-agents »). Souvent, l’agent est considéré comme un objet « intelligent » ou comme un niveau d’abstraction au-dessus des objets et des com- posants (voir le chapitre 5 « Composants logiciels et systèmes multi-agents »). Les méthodes de développement orientées objet – au vu des diﬀérences entre les objets et les agents – ne sont pas directement applicables au développement de SMA. Il est alors devenu nécessaire d’étendre ou de développer de nouveaux modèles, de nou- velles méthodologies et de nouveaux outils adaptés au concept d’agent. Après la révolution de la conception et de la programmation orientée objet, nous sommes donc à l’aube d’une nouvelle révolution qui serait celle de la conception et de la programmation orientée agent/interaction/organisation. Le constat concernant la conception de SMA, dans les années 1998-1999, est que le développement de SMA est coûteux en temps à cause de leur complexité, mais aussi par le fait que pour chaque application, il faut créer tout le SMA adéquat. En eﬀet, la majorité des applications existantes en SMA ont été développées de manière ad hoc [TRE 98]. Ce foisonnement a conduit en parallèle à de multiples propositions de modèles d’agents, notamment par Chapitre rédigé par Carole Bernon, Marie-Pierre Gleizes et Gauthier Picard. 45 46 Technologies des systèmes multi-agents le rapprochement eﬀectué avec l’approche objet. De là, plusieurs formalismes sont apparus, chacun mettant en avant une représentation de l’agent et de son système. En 1999, se fait donc sentir le besoin de fournir des modèles, des méthodologies, des plates-formes pour faciliter la prise en compte de la complexité des systèmes à conce- voir [JEN 99] et pour aider les concepteurs qui ne sont pas nécessairement spécialistes des SMA. Parallèlement au développement des méthodes, des modèles ont été déﬁnis pour aider les concepteurs tels que AGR [FER 98] ou BDI [RAO 95]. Pour le dévelop- pement, les concepteurs disposent de langages orientés agent dont les précurseurs ont été Agent0 et son évolution PLACA, ou LALO et METATEM. Des approches impé- ratives (comme JAL1), déclaratives (comme CLAIM [ELF 03]) ou hybrides (comme 3APL2) ont vu le jour depuis [BOR 06], liées ou non à des plates-formes de dévelop- pement dont les plus célèbres sont Madkit3 ou JADE4. Bien entendu, l’utilisation de langages de programmation classiques (C++, Java, etc.) reste envisageable. Les grandes familles de travaux concernant les méthodes orientées agent étendent les concepts soit des méthodes orientées objet, soit des méthodes issues de l’intelli- gence artiﬁcielle et plus particulièrement de l’ingénierie des connaissances, soit uti- lisent les deux [IGL 99]. Les premiers travaux sur les méthodologies sont ceux sur AAII [KIN 96], sur Cassiopée [COL 96] ou sur DESIRE [BRA 97]. En 2000, cet axe des SMA se conﬁrme et les aspects ingénierie des SMA représentent alors le thème de groupes de travail au niveau national, avec le groupe Architecture et société d’agents (ASA) de l’Association française d’intelligence artiﬁcielle (PRC-GDRI3- AFIA) ou européen avec les groupes Methodologies and Software Engineering for Agent Systems (MSEAS) d’AgentLink II (2000-2003) et Agent-oriented Sotware En- gineering (AOSE) d’AgentLink III (2003-2005) ainsi que le thème de conférences ou de workshops comme AOIS (Agent-oriented Information Systems), AOM (Agent- oriented Methodologies), AOSE (Agent-oriented Software Engineering), ESOA (En- gineering Self-Organising Applications), ou les JFIADSMA (1999 et 2000). De nom- breuses méthodologies sont alors conçues [BER 04, HEN 05], comme, par exemple, ADELFE [PIC 04], Gaia [CER 04a], INGENIAS [GOM 02], MaSE [DEL 01], PASSI [COS 02], Prometheus [PAD 03], Tropos [CAS 01] et Voyelles [DEM 01]. Contrairement aux méthodes orientées objet, poussées et portées par des indus- triels, les méthodes orientées agents sont développées et essentiellement utilisées dans le monde académique même si la motivation première de leurs concepteurs était de promouvoir la programmation et le développement orientés agent dans un contexte industriel. Toutefois, bien que n’étant pas moteurs, les industriels sont aussi intéressés par une approche d’ingénierie basée sur leurs exigences qui prennent en compte tout 1. http://www.agent-software.com. 2. http://www.cs.uu.nl/3apl/. 3. http://www.madkit.org. 4. http://jade.tilab.com. Méthodes orientées agent et multi-agent 47 le cycle de vie du logiciel [BUS 98] comme en témoignent AML (agent modeling lan- guage) et ADEM (agent development methodology), le processus de développement associé, de Whitestein Technologies5 [CER 04b]. Actuellement, on peut constater que de nombreuses méthodologies ont été développées [BER 04, HEN 05] et que les tra- vaux s’orientent vers la conception de métamodèles et vers la prise en compte des phases de développement de test et de déploiement [GAR 03]. En eﬀet, l’organisme FIPA6 (Foundation for Intelligent Physical Agents) œuvre dans le sens d’une standar- disation d’une méthode au travers de la déﬁnition d’un métamodèle [ODE 04b]. Les premiers travaux sur la standardisation dans le domaine des agents a eu pour objectif de faire communiquer des agents développés par diﬀérents concepteurs. Pour mettre en œuvre cette interopérabilité, le langage ACL (agent communication language) est devenu le langage standard de communication entre les agents. Une architecture et des protocoles ont aussi été développés par la FIPA pour prendre en charge les agents communicants. L’objectif de ce chapitre est de donner un panorama des principales méthodes de conception de SMA et de la standardisation des techniques dans ce domaine. Les méthodes seront décrites en suivant un même plan pour faciliter leur comparaison. Des prospectives à court, moyen et long termes seront ensuite exprimées avant de conclure ce chapitre. 2.2. Les méthodes de conception de systèmes multi-agents Une méthodologie doit permettre de faciliter le processus d’ingénierie des sys- tèmes. [BOO 92] donne la déﬁnition suivante d’une méthodologie : « Une méthodo- logie est un ensemble de méthodes appliquées tout au long du cycle de développement d’un logiciel, ces méthodes étant uniﬁées par une certaine approche philosophique gé- nérale. » Pour [SHE 01], une méthodologie est un ensemble de guides qui couvrent tout le cycle de vie du développement d’un logiciel, ils sont à la fois techniques et gèrent le projet. Une méthode est déﬁnie comme « un processus rigoureux permettant de générer un ensemble de modèles qui décrivent divers aspects d’un logiciel en cours de développement en utilisant une certaine notation bien déﬁnie ». Une méthode de développement de systèmes multi-agents est constituée d’un processus, de notations et d’outils pour prendre en charge ce processus et ces notations et/ou pour aider le développeur; on parle alors de CAME (computer aided method engineering). Les méthodes de conception orientée agent visent donc à construire des systèmes où les compétences sont attribuées à des entités logicielles autonomes, qui inter- agissent dans un environnement commun et peuvent avoir la faculté de naviguer dans 5. http://www.whitestein.com. 6. http://www.ﬁpa.org. 48 Technologies des systèmes multi-agents les réseaux pour accomplir des tâches relevant de leurs compétences déﬁnies au mo- ment de la conception du système. Ce qui est complexe tient au fait qu’il n’est pas possible de déﬁnir à l’avance les séquences temporelles des diﬀérentes interactions entre les agents, bien qu’il soit possible de déﬁnir les règles qui régiront les interac- tions entre les diﬀérents agents en fonction de leurs modèles d’accointances, de leurs compétences et de leurs perceptions. L’objectif d’une méthode est de guider un utilisateur tout au long du processus de développement, au niveau du développement lui-même mais aussi de la gestion et de la qualité. Il doit permettre de décrire la sémantique sans les détails d’implémentation et de fournir un moyen de vériﬁer, valider et tester les fonctionnalités du système. Il est actuellement largement admis que les phases principales d’une méthode sont les suivantes : – l’analyse des besoins, appelée aussi spéciﬁcation dans certaines méthodes, est l’étape au cours de laquelle ce que doit faire le système est exprimé du point de vue des utilisateurs. Cette étape peut aussi être divisée en deux sous-étapes : - les besoins préliminaires représentent un travail d’intercompréhension et/ou une description consensuelle du problème du cahier des charges entre clients, utili- sateurs et concepteurs sur ce que doit être et ce que doit faire le système, ses limites et ses contraintes. Cette phase doit permettre de transformer le cahier des charges ou des besoins exprimés par le client en un cahier des charges consensuel entre client et fournisseur, - les besoins ﬁnaux fournissent un modèle de l’environnement. Les objectifs sont de déﬁnir une vue du système, d’organiser et de gérer les besoins (fonctionnels ou non) et leurs priorités. De manière pratique, à ce stade, le concepteur doit déﬁnir le système étudié et modéliser l’environnement du système ; – l’analyse, appelée aussi conception de l’architecture, doit permettre de fournir la description des besoins de l’utilisateur en termes liés au domaine et à ce que le sys- uploads/Philosophie/ methodes-orientees-agent-et-multi-agent-pdf.pdf