Bernon 09 Industrie Sma

Chapitre 2
Mthodes orientes agent et multi-agent
2.1. Introduction
Les systmes multi-agents (SMA) ont montr leur pertinence pour la conception
dapplications distribues (logiquement ou physiquement), complexes et robustes. Le
concept dagent est aujourdhui plus quune technologie efficace, il reprsente un
nouveau paradigme pour le dveloppement de logiciels dans lesquels lagent est un
logiciel autonome qui a un objectif, volue dans un environnement et interagit avec
dautres agents au moyen de langages et de protocoles (voir le chapitre 1 Introduction aux systmes multi-agents ). Souvent, lagent est considr comme un objet
intelligent ou comme un niveau dabstraction au-dessus des objets et des composants (voir le chapitre 5 Composants logiciels et systmes multi-agents ). Les
mthodes de dveloppement orientes objet au vu des diffrences entre les objets
et les agents ne sont pas directement applicables au dveloppement de SMA. Il est
alors devenu ncessaire dtendre ou de dvelopper de nouveaux modles, de nouvelles mthodologies et de nouveaux outils adapts au concept dagent.
Aprs la rvolution de la conception et de la programmation oriente objet, nous
sommes donc laube dune nouvelle rvolution qui serait celle de la conception et
de la programmation oriente agent/interaction/organisation. Le constat concernant la
conception de SMA, dans les annes 1998-1999, est que le dveloppement de SMA
est coteux en temps cause de leur complexit, mais aussi par le fait que pour chaque
application, il faut crer tout le SMA adquat. En effet, la majorit des applications
existantes en SMA ont t dveloppes de manire ad hoc [TRE 98]. Ce foisonnement
a conduit en parallle de multiples propositions de modles dagents, notamment par
Chapitre rdig par Carole Bernon, Marie-Pierre Gleizes et Gauthier Picard.
45
46
Technologies des systmes multi-agents
le rapprochement effectu avec lapproche objet. De l, plusieurs formalismes sont

apparus, chacun mettant en avant une reprsentation de lagent et de son systme. En
1999, se fait donc sentir le besoin de fournir des modles, des mthodologies, des
plates-formes pour faciliter la prise en compte de la complexit des systmes concevoir [JEN 99] et pour aider les concepteurs qui ne sont pas ncessairement spcialistes
des SMA. Paralllement au dveloppement des mthodes, des modles ont t dfinis
pour aider les concepteurs tels que AGR [FER 98] ou BDI [RAO 95]. Pour le dveloppement, les concepteurs disposent de langages orients agent dont les prcurseurs ont
t Agent0 et son volution PLACA, ou LALO et METATEM. Des approches impratives (comme JAL1), dclaratives (comme CLAIM [ELF 03]) ou hybrides (comme
3APL2) ont vu le jour depuis [BOR 06], lies ou non des plates-formes de dveloppement dont les plus clbres sont Madkit3 ou JADE4. Bien entendu, lutilisation de
langages de programmation classiques (C++, Java, etc.) reste envisageable.
Les grandes familles de travaux concernant les mthodes orientes agent tendent
les concepts soit des mthodes orientes objet, soit des mthodes issues de lintelligence artificielle et plus particulirement de lingnierie des connaissances, soit utilisent les deux [IGL 99]. Les premiers travaux sur les mthodologies sont ceux sur
AAII [KIN 96], sur Cassiope [COL 96] ou sur DESIRE [BRA 97]. En 2000, cet
axe des SMA se confirme et les aspects ingnierie des SMA reprsentent alors le
thme de groupes de travail au niveau national, avec le groupe Architecture et socit
dagents (ASA) de lAssociation franaise dintelligence artificielle (PRC-GDRI3AFIA) ou europen avec les groupes Methodologies and Software Engineering for
Agent Systems (MSEAS) dAgentLink II (2000-2003) et Agent-oriented Sotware Engineering (AOSE) dAgentLink III (2003-2005) ainsi que le thme de confrences
ou de workshops comme AOIS (Agent-oriented Information Systems), AOM (Agentoriented Methodologies), AOSE (Agent-oriented Software Engineering), ESOA (Engineering Self-Organising Applications), ou les JFIADSMA (1999 et 2000). De nombreuses mthodologies sont alors conues [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 mthodes orientes objet, pousses et portes par des industriels, les mthodes orientes agents sont dveloppes et essentiellement utilises dans
le monde acadmique mme si la motivation premire de leurs concepteurs tait de
promouvoir la programmation et le dveloppement orients agent dans un contexte
industriel. Toutefois, bien que ntant pas moteurs, les industriels sont aussi intresss
par une approche dingnierie base 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.
47
le cycle de vie du logiciel [BUS 98] comme en tmoignent AML (agent modeling language) et ADEM (agent development methodology), le processus de dveloppement
associ, de Whitestein Technologies5 [CER 04b]. Actuellement, on peut constater que
de nombreuses mthodologies ont t dveloppes [BER 04, HEN 05] et que les travaux sorientent vers la conception de mtamodles et vers la prise en compte des
phases de dveloppement de test et de dploiement [GAR 03]. En effet, lorganisme
FIPA6 (Foundation for Intelligent Physical Agents) uvre dans le sens dune standardisation dune mthode au travers de la dfinition dun mtamodle [ODE 04b]. Les
premiers travaux sur la standardisation dans le domaine des agents a eu pour objectif
de faire communiquer des agents dvelopps par diffrents concepteurs. Pour mettre
en uvre cette interoprabilit, le langage ACL (agent communication language) est
devenu le langage standard de communication entre les agents. Une architecture et
des protocoles ont aussi t dvelopps par la FIPA pour prendre en charge les agents
communicants.
Lobjectif de ce chapitre est de donner un panorama des principales mthodes de
conception de SMA et de la standardisation des techniques dans ce domaine. Les
mthodes seront dcrites en suivant un mme plan pour faciliter leur comparaison.
Des prospectives court, moyen et long termes seront ensuite exprimes avant de
conclure ce chapitre.
2.2. Les mthodes de conception de systmes multi-agents
Une mthodologie doit permettre de faciliter le processus dingnierie des systmes. [BOO 92] donne la dfinition suivante dune mthodologie : Une mthodologie est un ensemble de mthodes appliques tout au long du cycle de dveloppement
dun logiciel, ces mthodes tant unifies par une certaine approche philosophique gnrale. Pour [SHE 01], une mthodologie est un ensemble de guides qui couvrent
tout le cycle de vie du dveloppement dun logiciel, ils sont la fois techniques et
grent le projet. Une mthode est dfinie comme un processus rigoureux permettant
de gnrer un ensemble de modles qui dcrivent divers aspects dun logiciel en cours
de dveloppement en utilisant une certaine notation bien dfinie . Une mthode de
dveloppement de systmes multi-agents est constitue dun processus, de notations
et doutils pour prendre en charge ce processus et ces notations et/ou pour aider le
dveloppeur ; on parle alors de CAME (computer aided method engineering).
Les mthodes de conception oriente agent visent donc construire des systmes
o les comptences sont attribues des entits logicielles autonomes, qui interagissent dans un environnement commun et peuvent avoir la facult de naviguer dans
5. http://www.whitestein.com.
6. http://www.fipa.org.
48
les rseaux pour accomplir des tches relevant de leurs comptences dfinies au moment de la conception du systme. Ce qui est complexe tient au fait quil nest pas
possible de dfinir lavance les squences temporelles des diffrentes interactions
entre les agents, bien quil soit possible de dfinir les rgles qui rgiront les interactions entre les diffrents agents en fonction de leurs modles daccointances, de leurs
comptences et de leurs perceptions.
Lobjectif dune mthode est de guider un utilisateur tout au long du processus de
dveloppement, au niveau du dveloppement lui-mme mais aussi de la gestion et de
la qualit. Il doit permettre de dcrire la smantique sans les dtails dimplmentation
et de fournir un moyen de vrifier, valider et tester les fonctionnalits du systme. Il
est actuellement largement admis que les phases principales dune mthode sont les
suivantes :
lanalyse des besoins, appele aussi spcification dans certaines mthodes, est
ltape au cours de laquelle ce que doit faire le systme est exprim du point de vue
des utilisateurs. Cette tape peut aussi tre divise en deux sous-tapes :
- les besoins prliminaires reprsentent un travail dintercomprhension et/ou
une description consensuelle du problme du cahier des charges entre clients, utilisateurs et concepteurs sur ce que doit tre et ce que doit faire le systme, ses limites
et ses contraintes. Cette phase doit permettre de transformer le cahier des charges ou
des besoins exprims par le client en un cahier des charges consensuel entre client et
fournisseur,
- les besoins finaux fournissent un modle de lenvironnement. Les objectifs
sont de dfinir une vue du systme, dorganiser et de grer les besoins (fonctionnels
ou non) et leurs priorits. De manire pratique, ce stade, le concepteur doit dfinir le
systme tudi et modliser lenvironnement du systme ;
lanalyse, appele aussi conception de larchitecture, doit permettre de fournir la
description des besoins de lutilisateur en termes lis au domaine et ce que le systme doit faire. Elle dcrit le problme rsoudre par le systme sil est clairement
identifi. En effet, les applications ddies aux systmes multi-agents ne possdent
pas toutes une tche clairement dfinie. Dans le premier cas, les produits de lanalyse
sont utiliss pour dfinir les fonctions du systme. Par fonction, on entend les comportements visibles et testables de lextrieur du systme. Dans ce dernier cas, la phase
danalyse doit permettre une description des entits relles intervenant dans lapplication. La phase danalyse dfinit larchitecture du systme. Dans le contexte SMA, les
tapes essentielles sont lidentification des agents qui interviennent dans le domaine
dapplication et la dfinition de leurs interactions ;
la conception, appele aussi conception dtaille, a pour objectif de dfinir les
entits et les mcanismes qui donnent le comportement dfini par la phase danalyse
et larchitecture dtaille du systme. Elle permet de rgler les problmes lis limplmentation. La conception consiste dire comment le systme va tre construit
partir de larchitecture dfinie la phase danalyse. Cette phase peut dmarrer ds
quun modle de ce que doit faire le systme a t tabli. Ce modle va tre enrichi
49
progressivement au cours de la phase de conception. A lissue de la phase de conception, un modle de larchitecture logicielle du systme doit tre ralis et la conception
dtaille fournit les composants logiciels coder. La conception doit dfinir une architecture dtaille pour le systme en termes de paquetages, de sous-systmes, dobjets
et dagents ;
le dveloppement correspond aux phases classiques de codage, de test et dintgration dun logiciel. Lobjectif de cette phase est de produire un code compilable
ou interprtable. Au cours de cette opration, des outils sont fournis pour gnrer du
code. Dans cette phase, la vrification et la validation du logiciel sont raliser. La
vrification consiste sassurer quil ny a plus derreurs durant lexcution du logiciel alors que la validation consiste vrifier que les besoins du client, exprims lors
de la phase danalyse des besoins, sont satisfaits ;
la phase de maintenance consiste soit corriger dventuelles erreurs, soit
ajouter des fonctionnalits demandes par lutilisateur.
2.3. Comparaison de mthodes
La problmatique de la comparaison de mthodes a t souvent souleve dans
la littrature pour aider le concepteur choisir la mthode la plus adapte au problme donn ou pour exhiber les diffrences essentielles entre les diffrentes mthodes
[HEN 05, SUD 04]. Dans ce sens, le TFG AOSE dAgentLink III propose un questionnaire7 pour lvaluation des mthodes orientes agent et [ELA 06] propose une
approche statistique pour valuer leurs diffrences.
[DAM 03, SHE 01, STU 03] comparent les mthodes suivant quatre ou cinq axes :
les concepts manipuls, les notations utilises (et les techniques de modlisation), le
processus de dveloppement et la pragmatique. [CER 02] se focalisent seulement sur
les concepts de modlisation des agents (les rles, les buts, lorganisation, etc.), mais
proposent une valuation chiffre par une somme pondre des diffrentes prises en
compte des concepts par les mthodes. Cette valuation ncessite, par contre, une
grande expertise dans toutes les mthodes et un grand nombre dvaluateurs afin de
dterminer au mieux les coefficients. [BER 02] ont de leur ct compar des mthodes
suivant huit axes : ltendue de la couverture du processus, la spcialisation de la mthode une application, larchitecture dagent sous-jacente, lutilisation de notations
existantes, le domaine dapplication (dynamique ou non), le modle de rle, le modle
de lenvironnement et lidentification des agents.
La comparaison qui va suivre sera faite suivant les quatre axes de [DAM 03], mais
en gardant en sous-catgorie les points de [BER 02], qui semblent mieux exhiber les
caractristiques propres aux agents.
7. http://www.pa.icar.cur.it/cossentino/al3tf3/docs/questionnaire.doc.
50
2.3.1. Les concepts-cls et les proprits

Afin dvaluer une mthode, il est intressant de vrifier quels concepts agents
et multi-agents sont pris en compte [CER 02, DAM 03, SHE 01, STU 03]. Pour plus
dinformation, [BOI 04] recensent de manire exhaustive les caractristiques propres
aux systmes multi-agents et leurs applications. Citons par exemple adaptation, autonomie, but, concurrence, croyance, dsir, distribution, environnement, groupe, intention, interaction, norme, organisation, ouverture, proactivit, protocole, ractivit,
rle ou tche. Cet axe de comparaison va donc aussi sattacher valuer les problmes
auxquels la mthode peut rpondre.
2.3.2. Langages de modlisation et notations

Les langages de modlisation agent sont souvent graphiques, inspirs de lingnierie objet, des besoins ou des connaissances. Ils comportent des symboles, une syntaxe
et une smantique propres. L encore, lvaluation stablit sur lanalyse des proprits des langages utiliss [ARL 04, CER 02, DAM 03, SHE 01] :
accessibilit : le langage est-il facile apprendre et utiliser ? Demande-t-il un
long temps dapprentissage ?
complexit : est-il possible de visualiser la complexit du systme plusieurs
niveaux dabstraction ?
consistance : est-il possible de vrifier la consistance dune spcification ?
excution : une fonctionnalit de prototypage permettant des excutions prliminaires existe-t-elle ?
expressivit : tous les aspects de la conception de lapplication sont-ils pris en
compte par la notation ?
modularit : la modification des spcifications en amont implique-t-elle une remise en cause de la totalit des spcifications ?
portabilit : le langage est-il indpendant de quelconques choix de dveloppement (langage de programmation par exemple, ou architecture) ?
prcision : le langage ne doit pas tre ambigu. Des dfinitions prcises sont-elles
tablies ?
raffinage : le concepteur est-il guid pour raffiner les modles utiliss ?
traabilit : est-il facile de modifier des spcifications passes, de tracer ses
changements sans avoir de rpercussion sur les spcifications en cours ?
Tous ces critres sont prendre en compte lors du choix dune mthode utilisant
un langage ddi ou bien lorsquun dveloppeur veut lui-mme dfinir son propre
langage de modlisation.
51
2.3.3. Le processus de dveloppement

Les cycles de vie et processus utiliss dans la conception de systmes multi-agents
sont de types classiquement utiliss en conception modulaire : cascades, itratifs, en V,
en spirales. Or, toutes les mthodes ne couvrent pas tout ce cycle, et il est ncessaire de
le prendre en compte lors de lvaluation dune mthode. Pour les mthodes proposes
nous allons aussi analyser :
le contexte de dveloppement, cest--dire le processus est-il adquat pour le
dveloppement de nouvelles applications, la ringnierie (reengineering), le prototypage, la rutilisation, pour faire appel des schmas de conception prexistants,
utiliser des bibliothques ddies, faire du reverse engineering ?
les livrables sont-ils bien identifis et associs des tapes prcises ?
la vrification et la validation sont-elles faciles et rapides, voire automatisables ?
la gestion de la qualit est-elle prise en compte ?
les directives de conduite de projet sont-elles claires ?
2.3.4. La pragmatique
[DAM 03, SHE 01] proposent de sintresser laspect pragmatique de la mthode, cest--dire la gestion et les questions techniques. Ceci inclut les supports mis
en place pour lutilisation de la mthode (livres, textes en ligne, ou logiciels daide au
suivi), le prix payer pour choisir une nouvelle mthode, ou le besoin dexpertise. Le
critre technique porte plutt sur la spcialisation des mthodes des domaines particuliers (gestion de collectifs humains, donnes distribues, rsolution de problmes,
simulations, etc.).
2.4. Principales mthodes existantes

Dans cette section, nous allons prsenter les principales mthodes orientes agent
ordonnes alphabtiquement. Chaque mthode sera dcrite brivement puis nous examinerons les quatre axes de comparaison. Ces mthodes, pour la plupart, sont disponibles en ligne, les outils associs tant le plus souvent libres.
2.4.1. ADELFE
ADELFE (atelier de dveloppement de logiciels fonctionnalit mergente) est
ddie des systmes multi-agents trs spcifiques : auto-organisateurs par coopration [PIC 04]. Ceci implique que certains concepts ne soient pas abords explicitement, ou bien que leur manipulation ne soit pas immdiate. Par exemple, les concepts
52
de groupes ou dorganisations ne sont pas utiliss en tant que concepts de modlisation, mais plutt comme des observations, donc utiliss a posteriori.
Les concepts manipuls par ADELFE sont directement issus des AMAS (adaptive
multi-agent systems) [GEO 03a]. En effet, ladaptation du systme est obtenue par
interactions coopratives entre les agents autonomes ayant des buts locaux. Ces derniers sont intgrs dans le module de comptence des agents. De mme, les croyances
peuvent tre vues comme des reprsentations qui sont forcment locales et relatives.
Lautonomie dun agent est assure par lencapsulation des comptences et des reprsentations dans les modules de lagent, ainsi que par laccs priv aux dcisions de
lagent qui garantit la proactivit. La ractivit des agents est obtenue par lutilisation
de machines tats finis pour transcrire les comportements dynamiques et sociaux.
Les interactions sont en effet prises en compte dans le module dinteraction via les
actions et les perceptions. Ladaptation dun systme auto-organisateur peut aussi passer par lajout et la suppression dagents, et donc par louverture du systme. Enfin,
lenvironnement est trs clairement cit comme concept majeur. Cest grce la pression quil exerce sur le systme, que les agents vont sorganiser et fournir la bonne
fonction.
ADELFE utilise UML (unified modeling language) et AUML (agent UML). Les
agents sont vus comme des agents strotyps possdant des attributs et oprations
strotyps en fonction des modules. Lutilisation de ces strotypes est rgle et en
limite la mauvaise utilisation (en fonction de loutil de conception utilis, bien sr).
UML et AUML ont les dsavantages suivants, dont hrite ADELFE : aucune gestion de la cohrence ou de la vrification derreurs nest possible, et ces notations
manquent de prcision lors de la modlisation et dexpressivit dans la reprsentation
de raisonnements logiques. La prise en compte de la complexit ne passe que par la
structuration en paquetages, modles et sous-systmes, mais nest pas aussi efficace
que dans Gaia ou MaSE.
ADELFE sappuie sur le RUP (rational unified process) [JAC 99]. Cependant,
ADELFE nintgre la notion dagent que dans les travaux danalyse et de conception.
Par contre, la gestion des tests, via des scnarios issus des protocoles de communication, et donc simulables, est envisageable lors du prototypage rapide. Lanalyse de ces
tests est faite partir des diagrammes de squences gnrs en cours de simulation. Le
processus dADELFE a t dfini de manire claire, en termes dactivits, dtapes,
de participants et de documents, mais la gestion de la qualit est identique celle
propose par le RUP et ne tient pas compte de la problmatique agent. La gestion de
projet et de suivi du processus est facilite par lutilisation dAdelfeToolkit qui guide
le concepteur tout au long du processus de dveloppement. Enfin, comme le RUP, le
processus dADELFE est adquat pour nimporte quel contexte de dveloppement :
cration de logiciels, reverse engineering, prototypage ou rutilisation.
53
Ce processus se divise en cinq dfinitions de travaux : les besoins prliminaires,

les besoins finaux, lanalyse, la conception et le codage. Chaque ensemble de travaux
ainsi que ses artefacts sont dfinis en utilisant la notation issue de SPEM (software process engineering metamodel) permettant de dfinir des processus de manire simple
et comprhensible pour les utilisateurs dUML. Certaines activits ont t ajoutes au
RUP pour ladapter cette technologie :
1) durant lexpression des besoins finaux :
- caractrisation de lenvironnement partir des cas dutilisation et des diagramme dactivits,
- identification des checs la coopration qui seront les dclencheurs de la
rorganisation du systme ;
2) durant lanalyse :
- vrification de ladquation aux AMAS afin de souligner la ncessit ou non
dune telle approche,
- identification des agents impliqus dans le systme construire partir du
domaine,
- tude des relations entre ces agents par protocoles AUML ;
3) durant la conception :
- tude des langages dinteraction par diagrammes de protocoles ou de machines tats,
- conception complte de ces agents par la dfinition des comptences, des
aptitudes, un langage dinteraction, des reprsentations du monde et rgles dautoorganisation cooprative,
- prototypage rapide partir de machines tats et de pseudo-code.
La description complte des activits sarrte actuellement la fin de la conception.
Bien que les dveloppements actuels se portent sur les phases prliminaires, des ponts
vers limplmentation reposant sur la transformation de modles ont t dvelopps :
des protocoles en machines tats puis en code Java, et des classes de conception en
code Java [OTT 06]. Des ressources diverses ont t mises la disposition des utilisateurs via un site web 8 dcrivant le processus et un exemple dapplication la conception dun logiciel de gestion demploi du temps adaptatif, et permettant laccs aux
logiciels dADELFE. Cest une mthode gnrique dans le sens o aucun domaine
dapplication nest rellement privilgi. Cependant, il est possible que les AMAS
ne soient pas ncessaires au dveloppement dune application donne, vus les fondements systmiques de la mthode. Dans de telles circonstances, lutilisateur est invit
se tourner vers une autre mthode de dveloppement, plus adapte. Cependant, les
retours restent mitigs lorsque des utilisateurs, concepteurs dADELFE exclus, tentent
dappliquer ADELFE. Certes, le processus est bien compris, mais le manque de clart
des phnomnes auto-organisateurs mettre en place reste un problme majeur.
8. http://www.irit.fr/ADELFE.
54
2.4.2. Gaia
Gaia est une extension des approches dingnierie logicielle classique [WOO 00].
Cest une mthode de la seconde gnration, par opposition la premire gnration
que formaient AAII ou DESIRE. Elle est donc plus complte et bnficie, de plus,
dune large reconnaissance dans le domaine multi-agent. Gaia se veut tre gnrale
et applicable nimporte quel domaine, et comprhensible par la distinction entre
macro-niveau et micro-niveau. Les agents modliss, pouvant tre htrognes, sont
des systmes computationnels gros grain, qui vont essayer de maximiser une mesure
de qualit globale. Toutefois, Gaia ne prend pas en compte les systmes admettant de
rels conflits. Lorganisation (dune centaine dagents environ) est clairement statique
dans le temps, de mme que les services offerts par les agents.
Gaia manipule six modles danalyse et de conception diffrents :
le modle de rle, qui identifie les diffrents rles devant tre jous par les agents
du systme ;
le modle dinteraction qui dfinit les protocoles de communication entre
agents ;
le modle dagent qui attribue les rles aux diffrents agents du systme ;
le modle de service qui dfinit, comme son nom lindique, les diffrents services
offerts par le systme, et les agents tributaires ;
le modle dorganisation qui dfinit la structure de lorganisation grce des
graphes orients reprsentant les voies de communication entre agents ;
le modle environnemental qui dcrit les diffrentes ressources accessibles caractrises par les types dactions que les agents peuvent entreprendre pour les modifier.
Gaia rend facile la manipulation dun grand nombre de concepts multi-agents,
grce ces modles, ce qui a certainement fait sa popularit. La proprit dautonomie
de contrle ou de rle des agents est exprime par le fait quun rle encapsule sa
fonctionnalit, qui est interne et non affecte par lenvironnement. La ractivit et la
proactivit sont, elles, plus ou moins exprimes grce aux proprits de vivacit des
responsabilits. On peut regretter que lenvironnement ne soit dfini que comme une
liste de variables caractrises en lecture ou criture. Enfin, les notions sociales sont
abordes dans le modle organisationnel daccointances.
Gaia ne fournit pas de notation graphique proprement parler. En effet, le modle
de rles et les protocoles ne sont dcrits que par des tables. Ceci nenlve en rien
la prcision obtenue grce, notamment, aux proprits de sret ou de vivacit. Les
autres modles sont aussi clairement accessibles. Les rles tant clairement distincts,
la modularit fait partie des avantages de cette approche. Par contre, comme aucune
55
prsentation hirarchique nest disponible, la gestion de la complexit organisationnelle ou fonctionnelle nest pas prise en compte et limite donc les systmes dvelopps grce Gaia, des organisations simples et rigides. Rcemment, ladaptation
dans Gaia a t tudie mais uniquement par le biais de lutilisation de bibliothques
dorganisations [CER 05].
Dans Gaia, trois phases sont principalement abordes : lanalyse, la conception architecturale et la conception dtaille. Lors de lanalyse, le systme se voit divis en
sous-organisations, dont vont dcouler les modles denvironnement, de rle et dinteraction (prliminaires). A partir de ces modles, lanalyse doit spcifier les rgles
organisationnelles (permissions, vivacit et sret) de dpendances entre rles. La
conception architecturale doit aboutir au raffinage des modles de rle et dinteraction
par lanalyse des structures organisationnelles. Enfin, lors de la conception dtaille,
les modles dagents (dtermination des types et instances dagents) et de services
sont implants. Ce processus est donc trs limit et se focalise uniquement sur les premires phases de conception. Nanmoins, les livrables et diffrents modles fournir
au cours du processus sont trs clairement dfinis.
Les ressources disponibles sur Gaia sont assez limites. De plus, Gaia ncessite
de possder une solide matrise de la logique temporelle. Ceci la rend plutt difficile
adopter pour des dveloppeurs. Gaia est limite aux applications agents forte
granularit, peu nombreux, et avec une organisation statique, ce qui rend le passage
lchelle difficile. Malgr quelques travaux sur une spcification de directives de
passage la plate-forme JADE, Gaia ne propose aucune tude dimplmentation, ce
qui a, bien sr, lavantage de laisser le dveloppeur libre dutiliser nimporte quel
langage de programmation [MOR 02].
2.4.3. INGENIAS
INGENIAS [GOM 02] est la continuit du projet MESSAGE (methodology for
engineering systems of software agents) qui tend la notation UML et sintgre dans
lUSDP (unified software development process) dont le RUP est une instanciation
[JAC 99].
Dans INGENIAS, les concepts agents sont manipuls dans des vues (ou modles) :
la vue de lorganisation montre les entits concrtes dans le systme et son environnement, et la relation de haut niveau comme lagrgation, le pouvoir ou les accointances (qui implique la dfinition dinteractions) ;
la vue des buts/tches montre les buts, les tches, les situations et les relations
entre eux. Les dpendances temporelles peuvent tre dfinies, ainsi que les dpendances dordre compositionnel ;
la vue des agents/rles associe les rles aux agents, en spcifiant les vnements
dclenchant lattribution de rles aux agents et les ressources exploites ;
56
la vue des interactions dfinit, pour chaque interaction agent/rle, linitiateur,

les collaborateurs, les motivateurs , les informations changes, les vnements
dclenchant les interactions, et les autres effets possibles comme lattribution de nouveaux rles par exemple ;
la vue du domaine est une vue classique en analyse oriente objet qui dcrit le
domaine dapplication du systme en termes dentits et de relations entre elles.
Comme dans Gaia, lautonomie des agents est assure par lencapsulation des buts.
La ractivit des agents est obtenue grce la spcification dvnements et dactions
dans les modles dagent/rle et dinteraction. De mme, la proactivit est relie aux
buts. Les concepts sociaux propres aux systmes multi-agents sont exprims, telles,
par exemple, les notions dorganisation ou de collaboration.
INGENIAS propose une extension dUML, non pas en utilisant les strotypes
(comme dans AUML par exemple), mais en modifiant le mtamodle UML par profilage. INGENIAS hrite donc des avantages et des inconvnients dUML, qui nest
pas un langage formel et qui perd donc en prcision, mais gagne en modularit, excutabilit (avec AUML et certains travaux sur le prototypage rapide), en analysabilit
(grce aux outils UML). Par contre, UML nest pas le plus adquat pour reprsenter
les connaissances ou les raisonnements logiques.
Le processus dINGENIAS consiste en la transformation et le raffinage des vues
prcdemment prsentes tout au long du droulement de lUSDP. Initialement, pour
un dveloppement donn, toutes les vues existent, et sont amliores chaque phase
du processus. Tout le cycle de dveloppement est couvert, des besoins la maintenance, et ses tapes sont bien dfinies et couples aux artefacts et livrables produire.
Cependant, INGENIAS ne fait que modifier les activits danalyse et de conception
pour prendre en compte la problmatique agent, sans se soucier des ventuels besoins technologiques ncessaires lors de limplmentation. INGENIAS est fortement
dirige vers Java et la plate-forme JADE. Des outils, comme IDK (INGENIAS development kit) sont disponibles9, ce qui facilite les phases danalyse et conception. La
validation et la vrification, dans INGENIAS, reposent sur la thorie des activits, et
un outil de vrification est inclu dans IDK.
2.4.4. MaSE
MaSE (multiagent software engineering) est un exemple dapproche complte de
dveloppement de systmes multi-agents de lanalyse au dploiement, avec de nombreux modles graphiques et une approche logique [DEL 01].
9. http://grasia.fdi.ucm.es/ingenias.
57
MaSE manipule neufs modles trs proches de ceux utiliss en conception oriente
objet :
la hirarchie de buts est obtenue en dcomposant le but principal du systme en
sous-buts ;
les cas dutilisation qui permettent notamment didentifier les rles jous par le
systme (et donc ses agents) ;
les diagrammes de squences sont dfinis pour chaque cas dutilisation identifi ;
les rles qui sont vus comme le moyen datteindre les buts fixs au systme ;
les tches concurrentes qui dcrivent les moyens pour les rles datteindre les
buts par des automates tats finis (ou bien des rseaux de Petri) ;
les classes dagents qui sont cres partir des rles identifis dont les architectures ne sont pas imposes (BDI ou autres) ;
les conversations qui dfinissent les protocoles de coordination entre deux agents
par deux automates tats finis ;
larchitecture qui consiste en un ensemble de composants qui peuvent tre des
classes ou des ensembles de classes ;
les diagrammes de dploiement permettent de spcifier la place des agents sur les
plates-formes utilises et les liens de discussion ncessaires entre les plates-formes.
Dans MaSE, lautonomie des agents est, comme dans Gaia, assure par lencapsulation des fonctionnalits dans les rles. De mme, la proactivit est exprime par
les tches, spcifies par des automates, qui sont attribues aux rles. Par contre, la
ractivit nest pas clairement aborde. En effet, il ny a pas de lien direct entre les
vnements et les actions ; mais il est possible de le dfinir en utilisant des machines
tats. Les proprits sociales (groupe, organisation) ne sont pas non plus clairement
dfinies, contrairement aux normes (rgles organisationnelles) ou protocoles (conversations).
Les nombreux modles de MaSE utilisent des notations directement inspires de la

conception objet. La hirarchie de but est simplement dfinie grce un arbre dont les
nuds sont les buts et les liens reprsentent les dcompositions. Les autres modles
sont exprims en UML. MaSE retire donc tous les avantages dune telle notation graphique : accessibilit (mais avec le dsavantage de la synchronisation ncessaire lors
de la transformation de modles), analysabilit, gestion de la complexit par dcomposition des buts et des classes (mais pas pour les tches et les rles), expressivit
(mis part les flots de donnes et la reprsentation des connaissances comme dans
DESIRE). Les diagrammes dagents de MaSE permettent une certaine rutilisabilit,
mais pas pour les tches, les rles ni les protocoles. L o lon pourrait sattendre un
58
dfaut dexcutabilit, d la filiation UML, MaSE fournit un outil, agentTool10, qui

permet une gnration de code partielle.
Le processus de MaSE est trs clair, et se dcompose en deux phases :
1) lanalyse qui consiste :
a) identifier les rles,
b) identifier les cas dutilisations et crer les diagrammes de squences,
c) transformer les buts en ensembles de rles : crer un modle de rle puis
dfinir un modle de tches concurrentes ;
2) la conception qui a pour rle de :
d) assigner les rles des classes dagents spcifiques, et identifier les conversations,
e) construire les conversations,
f) dfinir les classes internes dagents,
g) dfinir la structure finale du systme.
Ce processus est valide pour nimporte quel contexte de dveloppement (nouvelles
applications, re-engineering, ou conception avec rutilisation). MaSE a le net avantage de couvrir la totalit du cycle de vie du systme, malgr le manque de gestion
de qualit. De nombreux articles et rapports sont ddis MaSE, ainsi, et grce
agentTool, il devient facile de lutiliser pour dvelopper un systme multi-agent. De
plus, malgr la large couverture du processus, MaSE nimpose lutilisation daucun
langage de programmation particulier et sapplique nimporte quel domaine. Cependant, le concepteur devra certainement matriser la logique temporelle afin dexploiter
au mieux le potentiel des modles proposs. De plus, les architectures dveloppes
sont statiques, fermes et ne permettent pas de dfinir des socits grand nombre
dagents. Toutefois, O-MaSE, une version tendue de MaSE [DEL 05], dfinit un mtamodle permettant aux agents dadapter leur organisation lexcution.
2.4.5. PASSI
PASSI (process for agent societies specification and implementation) est une mthode pas pas intgrant des modles de conception et concepts provenant de lingnierie oriente objet et de lintelligence artificielle en utilisant UML [COS 01].
Le mtamodle dagent de PASSI manipule beaucoup de concepts communs aux
agents et y ajoute les notions provenant des contraintes FIPA pour tre adapt FIPAOS ou JADE [BER 03]. Ces notions sont encapsules dans cinq modles : le modle
des besoins, le modle de socit dagent, le modle dimplmentation dagent, le
modle de codage et le modle de dploiement. Lautonomie des agents est lie aux
10. http://macr.cis.ksu.edu/projects/agentTool/agentool.htm.
59
diffrents rles qui leur sont attribus. La ractivit des agents est dfinie dans un
ensemble de modles comportementaux, ainsi que la proactivit. Les aspects sociaux
sont intgrs dans le modle de socit dagents.
PASSI rutilise fortement UML. Par exemple, le modle des besoins est exprim
grce des diagrammes de cas dutilisation, de paquetages strotyps, de squences
(associs aux cas dutilisation) et dactivit. Le modle de socit dagents utilise des
diagrammes de classes et de squences. Les modles dimplmentation dagent et de
codage utilise des diagrammes de classes et dactivits classiques. Enfin, le modle
de dploiement utilise des diagrammes de dploiement UML. Lutilisation dUML,
comme pour ADELFE ou INGENIAS par exemple, implique le manque de formalisme (et donc de prcision), et les connaissances ne peuvent tre reprsentes quen
utilisant des diagrammes de classes.
Le processus de PASSI est un processus pas--pas, mais ritrable. Il est compos de cinq phases, composes dtapes, correspondant aux spcifications des cinq
modles prsents ci-dessus :
1) les besoins :
a) description du domaine avec cas dutilisation,
b) identification des agents avec regroupement en paquetages,
c) identification des rles avec des diagrammes de squences,
d) spcification des tches ;
2) la dfinition de la socit dagents :
e) identification des rles,
f) description de lontologie avec des diagrammes de classes appels diagrammes dontologies,
g) description des rles grce des diagrammes de classes et de paquetages,
h) description des protocoles avec des diagrammes de squences ou de protocoles AUML ;
3) limplmentation des agents :
i) dfinition de la structure des agents,
j) dfinition du comportement des agents avec diagrammes dactivits ;
4) le codage :
k) rutilisation du code,
l) compltion du code ;
5) le dploiement :
m) configuration du dploiement.
Des besoins au dploiement, les tapes de PASSI sont trs clairement dfinies ainsi
que les modles fournir tout au long du processus. PASSI est une mthode pouvant
sappliquer nimporte quel domaine, mais est plutt oriente agents mobiles, avec
60
notamment les aspects respectueux des spcifications FIPA. Le manque de formalisme, cependant, rend les phases de test peu efficaces.
PASSI est riche en ressources, et possde notamment un site11 expliquant le processus ainsi que tous les modles. Aucune expertise particulire nest recommande
bien que la connaissance des spcifications FIPA soit prfrable. PASSI nest relie
aucun langage particulier, bien que loutil PTK (PASSI toolkit) soit orient Java afin
dtre compatible avec JADE et FIPA-OS. Tous les diagrammes et strotypes spcifiques sont intgrs dans une extension au logiciel Rational Rose [COS 02].
2.4.6. Prometheus
[PAD 03] ont dvelopp Prometheus comme une mthode complte (processus,
notations et outils) pour des agents BDI, bien quaujourdhui elle ait volu et se dise
indpendante de toute architecture. Prometheus est le fruit dune exprience de programmation avec la plate-forme JACK, ce qui implique certains choix de conception.
On retrouve dans Prometheus les mmes concepts que dans Gaia ou MaSE. Les
agents sont gros grains, BDI et fortement proactifs. Lautonomie des agents est assure par lencapsulation des buts et des plans. Bien que la notion de groupe soit avance, les notions de rles sont inexistantes, et leur gestion non aborde. Par contre la
sret est assure lors de regroupements (en termes de droits daccs). Une notion intressante, et peu prsente dans les autres mthodes, est la notion dincident pouvant
survenir en cours de fonctionnement. Cette notion reste cependant floue, et semble
correspondre la notion dexception.
Prometheus dfinit des notations ddies et rutilise UML et AUML. Nous pouvons distinguer sept notations spcifiques. Des descripteurs textuels permettent de
spcifier des fonctionnalits du systme, des scnarios, ou des agents partir de
champs textuels (comme les buts, les actions, les interactions possibles). Les diagrammes de couplage de donnes permettent de regrouper les fonctionnalits du systme aux donnes produites en termes de production, de modification ou dexploitation. Les diagrammes daccointances dagent dcrivent les interconnexions entre
agents de diffrents types. Cest un diagramme de classes UML simplifi o les agents
sont reprsents par des classes (sans compartiment) et les connexions sont reprsentes par des associations binaires avec multiplicit. Les diagrammes de vue du systme
relient les agents, les vnements et les objets partags dans un mme modle en utilisant une notation ddie. Les diagrammes dinteraction montrent les interactions
entre agents. Prometheus exploite les diagrammes de squences UML et AUML pour
modliser les protocoles. Les diagrammes de vue des agents sont similaires aux diagrammes de vue du systme mais montrent les interactions entre capacits au sein
11. http://mozart.csai.unipa.it/passi/.
61
dun agent. Chaque message, perception ou action identifi au niveau du systme doit
tre pris en compte ce niveau. Les diagrammes de vue des capacits montrent les
interactions et contraintes sur les actions et vnements entre les plans et les capacits.
Ces notations sont claires, smantiquement bien dfinies, et donc faciles utiliser et
apprendre. Bases sur le paradigme objet, la modularit est prise en compte et la gestion de la complexit est rendue possible par la dcomposition des agents en activits
et des activits en sous-activits. Comme Prometheus est couple JACK, le langage
Java est prfrable pour limplmentation.
Le processus de Prometheus, ainsi que les modles produits, se dcompose en trois
phases majeures :
1) la spcification du systme voit lidentification des buts et sous-buts du systme
(sous forme de listes) par le dveloppement des scnarios de cas dutilisation. A ce
niveau, il est alors possible didentifier les interfaces avec lenvironnement (actions
et perceptions). Les fonctionnalits du systme sont regroupes dans un descripteur
prliminaire de capacits, ce qui ncessite, en parallle, la dfinition des donnes de
travail associes grce des diagrammes de couplage de donnes ;
2) la conception architecturale groupe les fonctionnalits identifies la phase
prcdente. Ces fonctionnalits permettent didentifier des agents auxquels les affecter. Les interactions entre agents, donnes et perceptions sont alors spcifies dans un
diagramme de vue du systme. Un diagramme de couplage est aussi utilis pour spcifier les relations entre donnes et fonctionnalits regroupes. Les interactions sont
aussi dcrites grce des diagrammes de squences ;
3) la conception dtaille commence par la vue interne des agents, qui est spcifique larchitecture choisie (principalement BDI, si lon veut bnficier des outils
proposs). Il convient alors de prciser ou de raffiner toutes les composantes internes
aux agents capacits, plans, croyances et donnes dans des diagrammes de vue
dagent et de capacits.
Prometheus couvre une grande partie du cycle de dveloppement, mme si les
besoins ne sont que peu abords. Les phases de test, validation, dploiement et maintenance sont totalement absentes, ainsi que la gestion de qualit et de conduite de projet. Nanmoins, Prometheus convient des applications orientes utilisateurs, comme
Tropos, et non la rsolution de problmes ou la simulation. Des ressources sur
Prometheus sont disponibles depuis peu. Prometheus est associe deux outils : JDE
et PDT. JDE (JACK development environment) permet dditer les modles proposs
pour les porter vers la plate-forme JACK. Seules quelques vrifications de consistance
sont faites sur certains modles. PDT12 (Prometheus design tool) manipule les descripteurs et vrifie partiellement les interactions entre objets du modle.
12. http://www.cs.rmit.edu.au/agents/pdt.
62
2.4.7. Tropos
Tropos est une mthode de dveloppement fonde sur les concepts utiliss en ingnierie des besoins et adopte une approche transformationnelle, dans le sens o,
chaque tape, les modles vont tre raffins de manire itrative par ajout ou suppression dlments ou relations dans les modles [GIO 05].
Les concepts manipuls par Tropos sont : lacteur (BDI de prfrence), le rle, la
position, le but (soft ou hard), le plan, la ressource et la dpendance (avec depender
et dependee). Dautres notions sont manipules comme les capacits dun acteur
dfinir, choisir et excuter un plan pour remplir un but et les croyances qui sont une
reprsentation de la connaissance dun acteur sur le monde. Le but est de dfinir les
obligations des acteurs envers les autres acteurs.
Tropos dfinit une modlisation selon cinq points de vue complmentaires :
social : quels sont les diffrents acteurs et que font-ils ? Quelles sont leurs obligations et leurs capacits ?
intentionnel : quels sont les buts adquats et comment sont-ils relis ? Comment
sont-ils remplis et par qui des dpendances sont-elles demandes ?
communicationnel : comment les acteurs dialoguent-ils et comment interagissent-ils ?
orient procd (processus) : quels sont les processus (business/computer) adquats ?
orient objet : quels sont les classes et objets adquats et quels sont leurs liens ?
Tropos utilise principalement i! pour modliser les systmes. Cette notation provient de lingnierie des besoins. Lutilisation de diagrammes dtats/transitions est
ncessaire la modlisation des capacits (diagrammes de capacits) et des plans
(diagrammes de plan). Les interactions entre agents sont spcifies grce des diagrammes de protocoles AUML. Une approche plus formelle, appele Formal Tropos,
propose des descriptions textuelles et logiques dexpression des besoins et des possibilits de traduction automatique vers i! [PER 03]. Ceci ajoute de la prcision aux
notations et langages. Les modles de Tropos sont simples, accessibles et trs expressifs. La gestion de la complexit passe nanmoins par plusieurs modles. Tropos
a dvelopp un outil de gnration de prototypes vers la plate-forme JACK, ce qui
ne rduit pas ses capacits de portabilit, bien que larchitecture agent soit impose
(agents BDI). Enfin, de nombreux outils permettent danalyser les spcifications.
Tropos, comme INGENIAS, a lavantage de couvrir une grande partie du cycle de
dveloppement logiciel multi-agent. Cinq phases sont clairement dfinies :
1) lanalyse des besoins initiaux qui produit un modle de dpendances stratgiques (acteurs, buts et dpendances) et un modle de raisonnement stratgique
(moyen datteindre les buts collectivement) ;
63
2) lanalyse des besoins finaux fournit une description du systme tudi dans
son environnement oprationnel et modlise le systme en tant quensemble dacteurs
possdant des dpendances ;
3) la conception architecturale qui dfinit larchitecture globale du systme en
termes de sous-systmes interconnects par des flots de donnes et de contrle ;
4) la conception dtaille qui dfinit chaque composant architectural en termes
dentres, de sorties, de contrle et qui permet de dtailler la communication entre
acteurs et le comportement des acteurs en diffrents niveaux ;
5) limplantation fournit une architecture dagents BDI sous la plate-forme JACK.
Tropos est adquat dans nimporte quel contexte et couvre la totalit du cycle
de dveloppement, mme la vrification et la validation sont abordes de manire
formelle. Par contre, les activits et les livrables associs au sein des phases ne sont pas
si clairement dfinis (la lecture de nombreux articles est ncessaire). Contrairement
INGENIAS, et au RUP en gnral, Tropos ne touche pas aux aspects qualit et gestion
de projet. Ici encore architecture BDI oblige des notions de logique temporelle
peuvent tre ncessaires. Tropos est plutt conue pour des systmes de e-Business ou
de gestion partage des connaissances. En effet, aucune relle identification des agents
nest prcise. Ainsi, les acteurs de lenvironnement seront toujours reprsents par
des agents. Des applications sans acteurs humains du type simulation ou rsolution
de problmes sont proscrites.
2.4.8. Lapproche Voyelles
Voyelles est une approche de haut niveau (peu de directives techniques sont donnes), difficile classer en tant que mthode, mais trs souvent cite car reposant sur
des principes purement multi-agents [DEM 03]. Nous lexposons ici car elle propose
un cadre danalyse trs usit dans la communaut multi-agent en France, notamment.
Elle repose sur la dcomposition de la vue dun systme suivant cinq dimensions (ou
voyelles) : Agent, Environnement, Interaction, Organisation et Utilisateur.
Cette approche permet un jeu dcriture par associativit, afin dexprimer le type
dapproche choisie pour le dveloppement dun systme, ou bien un domaine
dapplication. Par exemple, Demazeau attribue linformatique une approche
(((A + E) + I) + O) dans laquelle les agents et lenvironnement sont les priorits de dveloppement (approche centre agent/environnement), alors que les sciences de lconomie se caractriseraient plutt comme (((O + I) + E) + A). Les concepts comme
lautonomie, la ractivit, la proactivit ou les aspects sociaux ne sont pas techniquement expliqus, mais prsupposs.
Voyelles laisse les concepteurs libres dutiliser les formalismes, les notations ou
langages de leur choix pour spcifier chaque lettre du systme. Cependant quelques
64
exemples permettent de les guider. Pour modliser les agents, on peut par exemple
utiliser des logiques formelles, des arbres, des graphes ou des automates. La modlisation de lenvironnement peut elle aussi passer par des formalismes trs diffrents
comme par lexpression de diffrentes configurations darbres, telle que lorganisation. Comme dans de nombreuses autres mthodes, les protocoles exprims par des
diagrammes de squences ou des machines tats sont un moyen dexprimer des interactions.
Voyelles peut se coupler un processus de dveloppement logiciel classique dans
lequel les concepts Voyelles se greffent tout moment :
1) lanalyse porte sur le domaine dapplication et le type du problme, et consiste
en la dcomposition du problme en voyelles, cest--dire les diffrentes composantes
du systme ;
2) la conception correspond lidentification des modles utiliser pour chacune
des voyelles [OCC 01] :
- ASTRO pour les agents hybrides ou PACORG pour les agents ractifs,
- les langages protocoles (IL) ou les forces de PACO pour les interactions,
- les organisations statiques de RESO ;
3) la programmation (ou implmentation) consiste en linstanciation des modles,
en utilisant des plates-formes et des langages choisis.
Ce processus est complet, mais comme son niveau dabstraction est lev, aucune
des phases nest rellement dtaille. Par consquent, les livrables ne sont pas dcrits, car leur nature peut diffrer dune application une autre. La vrification et la
validation sont prises en compte, avec par exemple loutil AGIP de vrification de
protocoles. La gestion de projet et de qualit sont absentes dans Voyelles.
Voyelles est certainement lapproche mthodologique qui se distingue le plus des
autres, et leur est difficilement comparable, du moins partir des critres choisis. Ici,
la priorit est la libert totale de choix ce qui est toutefois problmatique lorsque
lon veut enseigner les moyens de concevoir des systmes, ce qui est le but, au final,
dune mthode de dveloppement. Le niveau de dtail est trop faible pour lutiliser
sans connaissance approfondie de lapproche. De plus, les ressources sont quasi inexistantes. Le seul moyen de savoir quels modles utiliser, comment dcomposer son
problme, ou quels outils choisir est de parcourir les travaux (la plupart tant des
thses) ayant utilis la mthode. La plate-forme MASK (Multi-agent system kernel)
est dveloppe pour fournir des outils de dveloppement Voyelles et permet lajout
de modles. Elle fonctionne sous UNIX et les librairies pour les botes outils sont
crites en C, C++ et Java. Les agents sont distribus en utilisant les communications
UNIX (TCP/IP), le systme Xenoops ou le WEB. Cependant elle reste ltat de prototype et son portage reste difficile. Enfin, le dveloppement et le dploiement des
systmes peuvent tre assurs par la plate-forme Volcano [RIC 01].
65
2.5. Comparaison des mthodes prsentes

Le tableau 2.1 montre une synthse de la comparaison des mthodes prsentes
dans la section 2.3. Seule lapproche Voyelles nest pas reprsente dans ce comparatif, pour les raisons cites plus haut.
2.5.1. Lecture suivant laxe des mthodes

Lire le tableau suivant laxe des mthodes (de gauche droite) nous indique si une
notion mthodologique donne est largement prise en compte par les mthodes orientes agent existantes. On peut constater que les interactions ou les notions de rles
sont communment abordes. Par contre, des notions comme ladaptation, louverture
ou lenvironnement sont trs souvent absentes. Lautonomie reste une moyenne de
+ seulement, compte tenu de la partialit de cette proprit, qui ne repose souvent
que sur des prsupposs ou des encapsulations (artificielles) de capacits cognitives.
Concernant les notations, cette lecture reste difficile car aucune notation ne semble
universelle. Seules les mthodes proposant plusieurs types de notations ou langages,
sont polyvalentes, comme MaSE ou Tropos. Deux courants principaux se dgagent :
les notations de type UML qui gagnent en modularit, analysabilit et complexit, et
les notations et langages formels plus prcis et vrifiables.
Toutes les mthodes affiches se concentrent principalement sur les phases danalyse et de conception. Tropos est un cas dexception concernant les besoins ; ceci sexplique par sa filiation lingnierie des besoins avec i! . Les autres exceptions sont des
mthodes dont le processus sinspire de processus orients objet prouvs, comme le
RUP avec ADELFE ou lUSDP avec INGENIAS. Cette limitation ces deux phases
peut sexpliquer de deux faons :
la technologie agent nen est qu ses dbuts et certains concepts, comme lautonomie ou la socialit, restent difficiles implanter ;
le concept dagent na peut-tre aucune spcificit par rapport lobjet en ce qui
concerne limplantation.
La premire hypothse est assez convaincante. En effet, ceci implique aussi le
manque de formalisme et donc de validation. Peu de dfinitions communment admises existent. Mme le concept dagent est sujet polmique. La seconde hypothse
semble par contre discutable. En effet, implanter des agents comme des objets ncessite de se munir de rgles de transformation spcifiques. De plus, le domaine de la
programmation oriente agent, qui propose de nouveaux paradigmes de programmation, non forcment inspirs de lobjet, souligne la ncessit de se munir de nouveaux
langages de programmation afin de palier les difficults des concepts agents et multiagents.
66
Lgende : (++) pour les proprits pleinement et explicitement prises en charge ; (+) pour les proprits prises en charge de
manire indirecte ; () pour des proprits potentiellement prises en charge ; () pour des proprits non prises en charge ;
() pour des proprits explicitement non prises en charge.
Tableau 2.1. Synthse de la comparaison des diffrentes mthodes
67
Enfin, les mthodes orientes agent manquent cruellement de ressources. Rares

sont celles proposant des tutoriels, des pages internets ou des livres synthtiques.
2.5.2. Lecture suivant laxe des notions mthodologiques orientes agent
Lire le tableau 2.1 suivant laxe des notions mthodologiques orientes agent/multi-agent nous indique si une mthode donne aborde tous les concepts et proprits,
possde des notations et langages efficaces, propose un cycle de dveloppement complet et clair, et enfin si cette mthode est facilement exploitable. Globalement, un premier constat est quaucune mthode nest parfaite dans ce sens. Chaque mthode
possde ses spcificits en termes darchitecture, de formalisme ou de modles. Ces
diffrences sont souvent dues aux filiations des mthodes ingnierie des connaissances, des besoins, oriente objet, ou simulation.
Toutefois, certaines mthodes sont plus gnrales ou inversement plus spcialises que dautres. Par exemple, Tropos sera plutt utilise pour des systmes orients
ergonomie et utilisateurs ou systmes dinformation, compte tenu de la richesse de
son analyse des besoins. Mais ceci implique aussi une architecture BDI dagents
gros grain. A loppos, INGENIAS, sintgrant dans le USDP, est assez gnrale et
convient tout type de contexte. PASSI, bien quayant fait le choix de la FIPA, propose
un processus et des notations riches et expressives.
2.6. Les standardisations
Les organismes de standardisation de technologies concernes par les agents et
multi-agents sont : lOMG (objet management group) qui comprend un groupe spcialis sur les agents et qui a notamment cr un standard pour les agents mobiles,
MASIF ou MAF (mobile agent system interoperability facility) [GRO 00], le GGF13
(Global Grid Forum) qui sintresse aux standards associs au calcul sur la grille,
le W3C14 (World Wide Web Consortium) qui dveloppe des standards et des guides
pour le web, OASIS15 (Organization for the Advancement of Structured Information
Standards) qui standardise le format de fichiers ouverts bass sur XML et la FIPA qui
dfinit des standards pour linteroprabilit et linteraction entre agents.
Depuis 1996, la FIPA est sans conteste lorganisme moteur principal pour la standardisation de la technologie agent et multi-agent. Ses objectifs sont de promouvoir
lutilisation de ces techniques par des industriels notamment, et dassurer linteroprabilit entre les agents, entre les systmes multi-agents et entre les systmes agents et
13. http://www.gridforum.org.
14. http://www.w3c.org.
15. http://www.oasis-open.org.
68
les autres technologies. Les principaux standards produits sont accessibles en ligne16.
Ils concernent cinq thmes savoir : la communication entre agents, le transport des
messages entre agents, la gestion des agents, larchitecture abstraite dun agent et des
applications. La majorit des travaux raliss sont centrs sur la communication entre
agents et ont fourni les standards concernant lchange de messages avec les spcifications des messages ACL et la dfinition de protocoles. Les principaux dveloppements
issus de ces spcifications sont en accs libre et concernent des plates-formes comme
ZEUS [NWA 99], JADE et lAPI JAS17 (Java agent services). Les comits techniques
ayant pour rle lcriture de spcifications se sont ensuite intresss quatre axes :
les spcifications concernant linteroprabilit. Elles permettent des platesformes agents conformes aux normes FIPA ou des fragments de plates-formes dinteroprer ;
les spcifications concernant la scurit dans les systmes multi-agents. Les travaux ont pris en compte plusieurs niveaux de scurit dans les systmes comme au
niveau des changes de messages, de lattaque du systme par un agent mal intentionn, etc., et ont rvis le modle de scurit FIPA pour dvelopper un service de
scurit bas sur les agents ;
la dfinition dun cadre smantique. Ltude des changes entre les agents pour
tendre le cadre smantique actuel avec des notions telles que le contrat, la confiance,
etc. a t ralise. Un nouveau cadre smantique a t tabli pour assurer et vrifier la
conformit avec les spcifications FIPA ;
lingnierie de systmes oriente agent, avec des travaux sur la ralisation de
mthodes de conception de systmes multi-agents et sur la modlisation de ces systmes. Le groupe sur la modlisation a travaill sur la ralisation dun mtamodle de
lagent conforme aux normes FIPA et sur AUML, lextension dUML pour la prise en
compte des protocoles dinteraction et plus gnralement des spcificits des agents.
Le groupe sur les mthodologies sest orient vers le dcoupage des mthodes existantes en fragments, permettant au concepteur de dfinir la mthode la plus adapte
son application.
Depuis juin 2005, la FIPA est officiellement le onzime comit des standards de
lIEEE (Institute of Electrical and Electronics Engineers) Computer Society18. Les
problmatiques prises en compte actuellement sont de dfinir des standards :
pour linteroprabilit entre les services web et les agents. Lobjectif est de combler le manque dinteraction entre les agents et les services web pour que les agents
puissent utiliser les services web et vice versa ;
16. http://www.fipa.org/specifications/.
17. http://www.sourceforge.net/projects/jas.
18. http://www.computer.org.
69
pour les agents mobiles. Le but est damliorer et dtendre les spcifications
existantes et de dvelopper des implmentations de protocoles sous la forme de composants logiciels pour des botes outils destines aux agents ;
pour les communications avec ltre humain. Lobjectif est dtendre le langage
ACL la communication avec des humains et de produire des standards IEEE ;
pour les applications P2P et les agents nomades. Le but est de dfinir des spcifications pour des agents nomades, capables de sexcuter sur diffrents types de
priphriques au sein dun rseau pair pair.
2.7. Prospective pour lingnierie des logiciels orients agent

2.7.1. La priode actuelle 2007-2008
Un frein lutilisation des systmes bass sur les agents dans lindustrie rside
dans le manque de standards dans le domaine malgr les efforts dj fournis comme
nous venons de le souligner dans la section prcdente. Mme si certaines mthodes
orientes agent reposent sur des standards de fait tels que UML ou le RUP, leur
diffusion dans le monde industriel est limite ; ceci tient essentiellement au fait que
les concepts agent et multi-agent doivent encore tre normaliss, quaucune mthode
nmerge parmi celles existantes et quaucune nest vraiment universelle. La rponse
du groupe de travail Methodology de la FIPA ou du TFG AOSE dAgentLink III
tait de clarifier les notions agent et multi-agent manipules dans les mthodes. Cette
clarification passant par ltablissement dun mtamodle des systmes multi-agents
unificateur des mthodes [BER 03, ODE 04a] permettant une composition de mthodes. En dfinissant et dcrivant des fragments des mthodes existantes, laide
dune notation telle que le SPEM par exemple, un ingnieur a la capacit de les assembler au gr de ses besoins pour constituer une mthode adapte son domaine dapplications. Lide du peuplement dune base de donnes de fragments de mthodes a
t repris dans divers travaux [COS 04, ELA 06, GAR 04, HEN 05] et constitue une
perspective de recherche court terme dans le domaine de lingnierie oriente agent.
Actuellement, les premires phases du cycle de vie du logiciel sont abordes par
toutes les mthodes, par contre, peu traitent les phases de dveloppement et de dploiement. Il semble donc que des efforts doivent tre raliss sur ces phases-l avec
la dfinition doutils facilitant, dune part, le codage et les tests et, dautre part, la mise
en place de ces systmes dans des environnements rels avec des problmes de passage lchelle. Ainsi, il est ncessaire de disposer de langages de programmation, de
plates-formes et denvironnements de dveloppement [BOR 06].
Loffre en termes de plates-formes est assez consquente [DAU 06] pour que les
concepteurs trouvent une plate-forme adapte lapplication dvelopper. Les platesformes cibles des applications peuvent donc tre diverses, ce qui explique que suivre
70
lapproche MDA (model driven architecture) de lOMG constitue un axe de recherche

de plus en plus suivi en ingnierie logicielle oriente agent [COS 05, GIO 05, OTT 06,
ROU 07, SAN 05]. Ceci permettrait de dployer un systme multi-agent sur diffrentes plates-formes. Intgrer la transformation de modles dans les mthodes est
le but de travaux tels ceux de [GER 02, KAS 05, THI 03] et doit tre poursuivi.
Dun autre ct, le living design propos par [GEO 03b] et dont lide est reprise
dans PASSI est dutiliser la simulation pour aider au dveloppement des systmes
multi-agents et plus particulirement la conception du comportement de lagent
[BER 07, LEM 07]. Toujours pour faciliter le rle des concepteurs, des outils dobservation, de dbogage et de validation de ces systmes complexes sont concevoir,
et ce, en lien avec les travaux dj raliss en simulation multi-agent. De mme, ces
outils devraient tre intgrs dans un environnement de dveloppement.
A court terme, les mthodes de dveloppement, les langages et les outils devraient
avoir atteint un degr de maturit et les systmes dvelopps devraient suivre des
standards.
2.7.2. A moyen terme : vers 2018

La grande majorit des systmes multi-agents actuels sont composs dagents
homognes (cest--dire ayant une architecture identique) et sont dvelopps par le
mme concepteur. La communaut scientifique dAgentLink III [LUC 05] prvoit
que de plus en plus, ces systmes seront conus par des dveloppeurs diffrents et
les agents seront htrognes. Cela signifie que soit des systmes existants auront
interagir, soit les systmes seront ouverts en acceptant la cration ou la suppression
dagents. La conception classique dun systme de bout en bout par une seule quipe
de dveloppement va donc rapidement devenir inadquate et il faudra trouver de nouvelles mthodes de dveloppement mettant en avant la modularit et la rutilisabilit
et permettant de prendre en compte linteroprabilit, louverture, la dynamique, la robustesse et ladaptation au sein de ces systmes. Il est vident que les standards auront
un rle essentiel pour prendre en compte cette htrognit et permettre aux agents
dinteragir. Les mthodes devront participer la validation de ces systmes comportant un grand nombre dagents. Ce passage lchelle reprsente un rel dfi. Il faudra
aussi fournir de nouveaux moyens de contrler ces systmes dont le concepteur ne
connatra pas, a priori, lenvironnement dexcution au moment de la conception.
A moyen terme, les mthodes de conception orientes agents devraient donc favoriser la conception de systmes multi-agents interoprables, adaptatifs et grande
chelle.
71
2.7.3. A long terme : au-del de 10 ans

Devant la complexit croissante des systmes concevoir et des environnements
dynamiques dans lesquels ils auront voluer, les agents, ainsi que les systmes seront
dots de capacits dadaptation et dapprentissage. De plus, les facilits dinteraction
entre des entits htrognes devraient permettre ces systmes de sautoconstruire,
et de sautomaintenir. Cette autoconstruction peut tre ralise plusieurs niveaux : au
niveau du programme en ayant une conception automatique du programme par autoorganisation dinstructions comme dans les travaux de [GEO 05], au niveau de lagent
en faisant appel de nouveaux composants (voir le chapitre 5 Composants logiciels
et systmes multi-agents ) pour augmenter ou changer ses comptences, au niveau
du systme en crant ou supprimant des agents pour rpondre un nouveau besoin :
rparation, nouvelle fonction raliser, etc.
A long terme, la mthode de conception pourrait tre vue comme un ensemble
doutils intgrs dans un logiciel minimal lui permettant de sautoconstruire par couplage avec son environnement.
2.8. Conclusion
Comme ce chapitre la prsent, de nombreuses mthodes orientes agent existent
actuellement, chacune rendant compte de la vision de ses concepteurs, sur les concepts
agents ou multi-agents. Dans un souci dunification, court terme, les travaux sur le
dveloppement de systmes multi-agents se focalisent sur trois grands axes : le dveloppement de standards, doutils daide la conception et sur le dveloppement des
dernires phases du cycle de dveloppement de logiciels savoir les phases dimplmentation, validation, de dploiement et de maintenance. A moyen terme, un systme multi-agent ne sera pas forcment conu par le mme concepteur et les agents
dun mme systme ne seront plus homognes. Les mthodes de conception devront
donc voluer vers la prise en compte de cette htrognit. La manire de concevoir, dimplmenter, de dployer et de maintenir ces systmes va changer par rapport
la conception actuelle de ces logiciels. En effet, pour des domaines dapplications
comme les services web, les systmes ambiants, les concepteurs nauront plus concevoir les systmes partir de rien et dans leur globalit mais ils devront interagir et
intgrer un fragment de logiciel (agent) dans un systme existant. A long terme, lautonomie et les capacits dinteraction du systme avec son environnement permettent
dimaginer des systmes qui sautoconstruisent ce qui entranera une rvolution des
mthodes de dveloppement.
Pour assurer ces futurs lingnierie logicielle oriente agent, il est, bien entendu,
important que les chercheurs fassent des propositions mais il est aussi fondamental
que ces actions soient portes par des industriels afin que la technologie agent trouve
une place analogue celle de lobjet dans le monde industriel.
72
2.9. Bibliographie
[ARL 04] Arlabosse F., Gleizes M.-P., Occello M., Mthodes de Conception , Systmes
Multi-Agents, vol. 29 de Arago, Editions Tec & Doc, p. 137-171, 2004.
[BER 02] Bernon C., Gleizes M.-P., Picard G., Glize P., The ADELFE Methodology For an
Intranet System Design , Giorgini P., Lesprance Y., Wagner G., Yu E. (dir.), Fourth International Bi-Conference Workshop on Agent-Oriented Information Systems (AOIS-2002),
vol. 57, Toronto, Canada, CAiSE02, CEUR Workshop Proceedings, mai 2002.
[BER 03] Bernon C., Cossentino M., Gleizes M.-P., Turci P., Zambonelli F., A Study
of Some Multi-Agent Meta-Models , Giorgini P., Mller J. P., Odell J. (dir.), AgentOriented Software Engineering IV, 5th International Workshop, AOSE 2004, New York, 19
juillet 2003, p. 113-130, 2003.
[BER 04] Bergenti F., Gleizes M.-P., Zambonelli F. (dir.), Methodologies and Software Engineering for Agent Systems, Kluwer Publishing, 2004.
[BER 07] Bernon C., Gleizes M.-P., Picard G., Enhancing Self-Organising Emergent Systems Design with Simulation , Seventh International Workshop on Engineering Societies
in the Agents World (ESAW06), Dublin, Ireland from the 6th-8th September, 2006, Springer,
p. 284-299, 2007.
[BOI 04] Boissier O., Gitton S., Glize P., Caractristiques des systmes et des applications , Systmes Multi-Agents, vol. 29 de Arago, Editions Tec & Doc, p. 25-54, 2004.
[BOO 92] Booch G., Conception oriente objets et applications, Addison-Wesley, 1992.
[BOR 06] Bordini R., Braubach L., Dastani M., El Fallah Seghrouchni A., Gomez-Sanz
J., Leite J., OHare G., Pokahr A., Ricci A., A Survey of Programming Languages and
Platforms for Multi-Agent Systems , Informatica, An International Journal of Computing
and Informatics, vol. 30, n 1, p. 33-44, 2006.
[BRA 97] Brazier F., Dunin-Keplicz B., Jennings N., Treur J., DESIRE: Modelling MultiAgent Systems in a Compositional Formal Framework , International Journal of Cooperative Information Systems, vol. 6, n 1, p. 64-94, World Scientific, 1997.
[BUS 98] Bussman S., Position Paper on Agent-Based Software Engineering, Contribution to
Methodologies/software engineering SIG, Rapport, First SIG Meeting AgentLink, 1998.
[CAS 01] Castro J., Kolp M., Mylopoulos J., A Requirements-driven Development Methodology , Dittrich K., Geppert A., Norrie M. (dir.), Proceedings of the 13th International Conference on Advanced Information Systems Engineering (CAiSE01), vol. 2068 de
LNCS, Springer, p. 108-123, 2001.
[CER 02] Cernuzzi L., Rossi G., On The Evaluation Of Agent Oriented Methodologies ,
Debenham J., Henderson-Sellers B., Jennings N., Odell J. (dir.), Proceedings of the
OOPSLA 02 - Workshop on Agent-Oriented Methodologies, COTAR, p. 21-30, 2002.
[CER 04a] Cernuzzi L., Juan T., Sterling L., Zambonelli F., The Gaia Methodology: Basic
Concepts and Extensions , Bergenti F., Gleizes M.-P., Zambonelli F. (dir.), Methodologies and Software Engineering for Agent Systems, Kluwer Publishing, p. 69-88, 2004.
73
[CER 04b] Cervenka R., Trencansk I., Calisti M., Greenwood D. A. P., AML: Agent
Modeling Language Toward Industry-Grade Agent-Based Modeling , Agent Oriented Software Engineering, p. 31-46, 2004.
[CER 05] Cernuzzi L., Zambonelli F., Dealing with Adaptive Multiagent Systems Organizations in the Gaia Methodology , 6th International Workshop on Agent-Oriented Software Engineering (AOSE-05) at AAMAS05, July 25-26, 2005, Utrecht, Pays-Bas, Springer,
2005.
[COL 96] Collinot A., Drogoul A., Agent Oriented Design of a Soccer Robot Team , Tokoro M. Ed., Second International Conference on Multi-Agent Systems (ICMAS96), Nara,
Japan, AAAI Press, p. 41-47, 1996.
[COS 01] Cossentino M., Different Perspectives in Designing Multi-Agent System , Designing Multi-Agent System, AgeS02 (Agent Technology and Software Engineering) Workshop at NodE02, 2001.
[COS 02] Cossentino M., Potts C., A CASE tool supported methodology for the design
of multi-agent systems , The Proceedings of the International Conference on Software
Engineering Research and Practice (SERP02), 2002.
[COS 04] Cossentino M., Seidita V., Composition of a New Process to Meet Agile Needs
Using Method Engineering , Software Engineering for Multi-Agent Systems III, Research
Issues and Practical Applications, p. 36-51, 2004.
[COS 05] Cossentino M., From Requirements to Code with the PASSI Methodology ,
Henderson-Sellers B., Giorgini P. (dir.), Agent Oriented Methodologies, Idea Group, p. 79106, 2005.
[DAM 03] Dam K. H., Winikoff M., Comparing Agent-Oriented Methodologies , Fifth International Bi-Conference Workshop on Agent-Oriented Information Systems (AOIS-2003),
Melbourne, Australia, at AAMAS03, vol. 3030 de LNCS, Springer, p. 78-93, 2003.
[DAU 06] Daures N., tude de la simulation de systmes multiagents pour la conception vivante dagents dans la mthode ADELFE, Rapport de Master 2 Recherche IARCL, Universit Toulouse III, 2006.
[DEL 01] Deloach S., Wood M., Sparkman C., Multiagent Systems Engineering , International Journal of Software Engineering and Knowledge Engineering, vol. 11, n 3,
p. 231-258, World Scientific, 2001.
[DEL 05] DeLoach S. A., Engineering Organization-Based Multiagent Systems , SELMAS,
p. 109-125, 2005.
[DEM 01] Demazeau Y., VOYELLES, Mmoire dhabilitation diriger des recherches, INP
Grenoble, 2001.
[DEM 03] Demazeau Y., Crativit mergente centre utilisateur , Briot J., Khaled G.
(dir.), Dploiement des systmes multi-agents Vers un passage lchelle (Journes francophones sur les systmes multi-agents, JFSMA03), Herms - Lavoisier (Revue RSTI Horssrie), p. 31-36, 2003.
74
[ELA 06] Elamy A.-H., Far B., A Statistical Approach for Evaluating and Assembling
Agent-Oriented Software Engineering Methodologies , Proceedings of AOIS06, p. 1734, 2006.
[ELF 03] El Fallah Seghrouchni A., Suna A., CLAIM : Un langage de programmation
pour des agents autonomes, intelligents et mobiles , Technique et Science Informatiques,
vol. 22, n 4, p. 91-105, 2003.
[FER 98] Ferber J., Gutknecht O., Aalaadin : a meta-model for the analysis and design of
organizations in multi-agent systems , Demazeau, Y. Ed., 3rd International Conference
on Multi-Agent Systems, Paris, IEEE, p. 128-135, 1998.
[GAR 03] Garcia A., Pereira de Lucena C., Zambonelli F., Omicini A., Castro J. (dir.),
Software Engineering for Large-Scale Multi-Agent Systems, vol. 2603 de LNCS, Springer,
2003.
[GAR 04] Garro A., Fortino G., Russo W., Using Method Engineering for the Construction
of Agent-Oriented Methodologies , Proceedings of WOA 04 Dagli Oggetti agli Agenti,
Sistemi Complessi e Agenti razionali, p. 51-54, 2004.
[GEO 03a] Georg J.-P., Gleizes M.-P., Glize P., Conception de systmes adaptatifs fonctionnalit mergente : la thorie AMAS , Revue des sciences et technologie de linformation, vol. 17, n 4, p. 591-626, Herms, 2003.
[GEO 03b] Georg J.-P., Picard G., Gleizes M.-P., Glize P., Living Design for Open Computational Systems , Fredriksson M., Ricci A., Gustavsson R., Omicini A. (dir.), International Workshop on Theory And Practice of Open Computational Systems (TAPOCS) at
12th IEEE International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE03), IEEE Computer Society, p. 389-394, 2003.
[GEO 05] Georg J.-P., Gleizes M.-P., Experiments in Emergent Programming Using Selforganizing Multi-Agent Systems , Pechoucek M., Petta P., Varga L. Z. (dir.), 4th International Central and Eastern European Conference on Multi-Agent Systems (CEEMAS05),
Budapest, Hongrie, Springer, p. 450-459, 2005.
[GER 02] Gervais M.-P., Towards an MDA-Oriented Methodology , 26th International
Computer Software and Applications Conference (COMPSAC 2002), Prolonging Software
Life: Development and Redevelopment, p. 265-270, 2002.
[GIO 05] Giorgini P., Kolp M., Mylopoulos J., Castro J., Tropos: A Requirements-Driven
Methodology for Agent-Oriented Software , Henderson-Sellers B., Giorgini P. (dir.),
Agent Oriented Methodologies, Idea Group, p. 20-45, 2005.
[GOM 02] Gomez Sanz J., Fuentes R., Agent Oriented System Engineering with INGENIAS , Fourth Iberoamerican Workshop on Multi-Agent Systems, Iberagents02, 2002.
[GRO 00] Group O. M., Mobile Agent Facility Specification v1.0, Rapport formal/2000-0102, OMG Document, 2000.
[HEN 05] Henderson-Sellers B., Giorgini P. (dir.), Agent Oriented Methodologies, Idea
Group, 2005.
[IGL 99] Iglesias C., Garijo M., Gonzalez J., A Survey of Agent-Oriented Methodologies , ntelligent Agents V, ATAL98, vol. 1555 de LNAI, Springer, 1999.
75
[JAC 99] Jacobson I., Booch G., Rumbaugh J., The Unified Software Development Process,
Addison-Wesley, 1999.
[JEN 99] Jennings N. R., Agent-Oriented Software Engineering , Garijo F. J., Boman
M. (dir.), Multi-Agent System Engineering, 9th European Workshop on Modelling Autonomous Agents in a Multi-Agent World, MAAMAW99, Valence, Espagne, juin-juillet 1999,
vol. 1647 de LNAI, Springer, 1999.
[KAS 05] Kasinger H., Bauer B., Towards a Model-Driven Software Engineering Methodology for Organic Computing Systems , Press I. Ed., Proceedings of the 4th IASTED
International Conference on Computational Intelligence (CI 2005), p. 141-146, 2005.
[KIN 96] Kinny D., Georgeff M., Rao A., A Methodology and Modelling Technique for
Systems of BDI agents , Van de Velde W., Perram J. W. (dir.), Agents Breaking Away:
Proceedings of the Seventh European Workshop on Modelling Autonomous Agents in a
MultiAgent World, vol. 1038 de LNAI, Springer, p. 51-71, 1996.
[LEM 07] Lemouzy S., Bernon C., Gleizes M.-P., Living Design: Simulation for SelfDesigning Agents , European Workshop on Multi-Agent Systems (EUMAS), Hammamet,
Tunisie, 13/12/2007-14/12/2007, 2007.
[LUC 05] Luck M., Mc Burney P., Shehory O., Willmott S., Agent Technology : Computing
as Interaction, A Roadmap for Agent Based Computing, AgentLink, 2005.
[MOR 02] Moraitis P., Petraki E., Spanoudakis N., Engineering JADE Agents with Gaia
Methodology , Kowalczyk R., Muller J., Tianfield H., Unland R. (dir.), Agent Technologies, Infrastructures, Tools and Applications for E-Services Best (revised) papers of
NODe 2002 Agent-Related Workshops, vol. 2592 de LNAI, Springer, p. 77-92, 2002.
[NWA 99] Nwana H., Ndumu D., Lee L., Collis J., ZEUS: A Tool-Kit for Building Distributed Multi-Agent Systems , Applied Artifical Intelligence Journal, vol. 13, n 1, p. 129186, 1999.
[OCC 01] Occello M., Koning J.-L., Baeijs C., Conception de SMA. Quelques lments
de rflexion mthodologique , Revue technique et science informatiques, vol. 20, n 2,
Herms, 2001.
[ODE 04a] Odell J., Giorgini P., Mller J. P. (dir.), Agent-Oriented Software Engineering V,
5th International Workshop, AOSE 2004, New York, 19 juillet 2004, Revised Selected Papers, vol. 3382 de LNCS, Springer, 2004.
[ODE 04b] Odell J., Nodine M. H., Levy R., A Metamodel for Agents, Roles, and Groups ,
Agent Oriented Software Engineering, p. 78-92, 2004.
[OTT 06] Ottens K., Picard G., Camps V., Transformation de modles dagents dans la
mthode ADELFE : Des strotypes de conception limplmentation , Revue technique
et science informatique Lobjet, vol. 12, n 4, p. 43-72, Herms, 2006.
[PAD 03] Padgham L., Winikoff M., Prometheus: A Methodology for Developing Intelligent Agents , Giunchiglia F., Odell J., Wei G. (dir.), Agent-Oriented Software Engineering III, Third International Workshop, AOSE 2002, Bologne, Italie, 15 juillet 2002,
Revised Papers and Invited Contributions, vol. 2585 de LNCS, Springer, p. 174-185, 2003.
76
[PER 03] Perini A., Pistore M., Roveri M., Susi A., Agent-oriented modeling by interleaving formal and informal specification , Giorgini P., Mller J. P., Odell J. (dir.), AgentOriented Software Engineering IV, 4th International Workshop, AOSE 2003, Melbourne,
Australie, 15 juillet 2003, Revised Papers, vol. 2935 de LNCS, Springer, p. 36-52, 2003.
[PIC 04] Picard G., Gleizes M.-P., The ADELFE Methodology Designing Adaptive Cooperative Multi-Agent Systems , Bergenti F., Gleizes M.-P., Zambonelli F. (dir.), Methodologies and Software Engineering for Agent Systems, Kluwer Publishing, p. 157-176,
2004.
[RAO 95] Rao A. S., Georgeff M. P., BDI-Agents: from Theory to Practice, Rapport n 56,
Australian Artificial Intelligence Institute, Melbourne, Australie, 1995.
[RIC 01] Ricordel P.-M., Programmation oriente multi-agent : dveloppement et dploiement de systmes multi-agents Voyelles, Thse de doctorat, Institut national polytechnique
de Grenoble, 2001.
[ROU 07] Rougemaille S., Migeon F., Maurel C., Gleizes M.-P., Model Driven Engineering for Designing Adaptive Multi-Agent Systems , International Workshop on Engineering Societies in the Agents World (ESAW07), Athnes, Grce, 22/10/07-24/10/07, Springer, 2007.
[SAN 05] Sansores C., Pavn J., Agent-Based Simulation Replication: A Model Driven
Architecture Approach , MICAI, Springer, p. 244-253, 2005.
[SHE 01] Shehory O., Sturm A., Evaluation of Modeling Techniques for Agent-Based Systems , Proceedings of the Fifth International Conference on Autonomous Agents, ACM
Press, p. 624-631, 2001.
[STU 03] Sturm A., Shehory O., A Framework for Evaluating Agent-Oriented Methodologies , Fifth International Bi-Conference Workshop on Agent-Oriented Information Systems
(AOIS-2003), Melbourne, Australia, at AAMAS03, vol. 3030 de LNCS, Springer, p. 94-109,
2003.
[SUD 04] Sudeikat J., Braubach L., Pokahr A., Lamersdorf W., Evaluation of AgentOriented Software Methodologies Examination of the Gap Between Modeling and Platform , Agent Oriented Software Engineering, p. 126-141, 2004.
[THI 03] Thiefaine A., Guessoum Z., Perrot J.-F., Blain G., Gnration de systmes multiagents partir de modles , JFSMA03, Herms, p. 107-111, 2003.
[TRE 98] Treur J., Report of the First SIG Meeting, Contribution to Methodologies/software
engineering SIG, Rapport, First SIG Meeting AgentLink, 1998.
[WOO 00] Wooldridge M., Jennings N. R., Kinny D., The Gaia Methodology for AgentOriented Analysis and Design , Journal of Autonomous Agents and Multi-Agent Systems,
vol. 3, n 3, p. 285-312, Kluwer Academic Publishers, 2000.

Bernon 09 Industrie Sma

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Bernon 09 Industrie Sma

Transféré par

Droits d'auteur :

Formats disponibles

Chapitre 2

Mthodes orientes agent et multi-agent

Chapitre rdig par Carole Bernon, Marie-Pierre Gleizes et Gauthier Picard.

Technologies des systmes multi-agents

le rapprochement effectu avec lapproche objet. De l, plusieurs formalismes sont

Mthodes orientes agent et multi-agent

Technologies des systmes multi-agents

Mthodes orientes agent et multi-agent

Technologies des systmes multi-agents

2.3.1. Les concepts-cls et les proprits

2.3.2. Langages de modlisation et notations

Mthodes orientes agent et multi-agent

2.3.3. Le processus de dveloppement

2.4. Principales mthodes existantes

Technologies des systmes multi-agents

Mthodes orientes agent et multi-agent

Ce processus se divise en cinq dfinitions de travaux : les besoins prliminaires,

Technologies des systmes multi-agents

Mthodes orientes agent et multi-agent

Technologies des systmes multi-agents

la vue des interactions dfinit, pour chaque interaction agent/rle, linitiateur,

Mthodes orientes agent et multi-agent

Les nombreux modles de MaSE utilisent des notations directement inspires de la

Technologies des systmes multi-agents

dfaut dexcutabilit, d la filiation UML, MaSE fournit un outil, agentTool10, qui

Mthodes orientes agent et multi-agent

Technologies des systmes multi-agents

Mthodes orientes agent et multi-agent

Technologies des systmes multi-agents

Mthodes orientes agent et multi-agent

Technologies des systmes multi-agents

Mthodes orientes agent et multi-agent

2.5. Comparaison des mthodes prsentes

2.5.1. Lecture suivant laxe des mthodes

Technologies des systmes multi-agents

Tableau 2.1. Synthse de la comparaison des diffrentes mthodes

Mthodes orientes agent et multi-agent

Enfin, les mthodes orientes agent manquent cruellement de ressources. Rares

Technologies des systmes multi-agents

Mthodes orientes agent et multi-agent

2.7. Prospective pour lingnierie des logiciels orients agent

Technologies des systmes multi-agents

lapproche MDA (model driven architecture) de lOMG constitue un axe de recherche

2.7.2. A moyen terme : vers 2018

Mthodes orientes agent et multi-agent

2.7.3. A long terme : au-del de 10 ans

Technologies des systmes multi-agents

Mthodes orientes agent et multi-agent

Technologies des systmes multi-agents

Mthodes orientes agent et multi-agent

Technologies des systmes multi-agents

Vous aimerez peut-être aussi