2.5. Méthodologies de développement de SMA
Actuellement, il existe un nombre important de méthodologies et d’outils de conception de SMA [Bauer et Müller, 2004]. Chacune d’entre elles se fonde sur une base conceptuelle propre et recouvre un certain nombre d’aspects dont la prise en compte est considérée essentielle. La plupart de ces propositions méthodologiques sont inspirées des résultats du domaine du génie logiciel orienté objets. Dans cette section nous présentons un certain nombre d’exemples de ces méthodologies et nous terminons par quelques arguments qui renforcent notre choix de la méthodologie à utiliser pour notre application SMA dans le domaine de la chaîne logistique.
AUML [Odell et al, 2001] a pour but d’étendre UML avec des facilités permettant de décrire des agents. Ce formalisme a comme but de recommander une technologie pour l'adoption d'une sémantique, d’un méta-modèle et d’une syntaxe abstraite communes pour l'analyse et la conception des méthodologies basées sur les agents. Cette technologie devra permettre de couvrir le cycle de vie des produits et des outils de travail AUML et être en accord avec les spécifications existantes de FIPA et l’OMG (Object Management Group). Actuellement, les versions 2.0 et 2.1 d’UML ont intégré plusieurs concepts d’Agent UML, comme ceci est montré sur le site21 officiel d’AUML. Ainsi avec UML 2.0 et versions ultérieures, on pourra modéliser une application orientée agent. Pour plus de détails sur ce point, le lecteur pourra se référer à l’article de B. Bauer et J. Odell [Bauer et Odell, 2005].
M-UML a été proposée par K. Saleh et C. El-Morr [Saleh et El-Morr, 2004] pour modéliser les agents mobiles.
GAIA [Wooldridge et al., 2000] est une méthodologie où le système multi-agent est vu comme une organisation composée de rôles interagissant entre eux. La méthodologie prend comme point de départ une description de la structure organisationnelle du système, composée de rôles et d’interactions entre eux. Deux phases sont distinguées (figure 2.2) : la phase d’analyse qui permet de constituer le modèle des rôles et le modèle des interactions, et la phase de conception durant laquelle sont créés les modèles d’agents, de services et d’accointances.
Cette méthodologie aborde la conception d’un SMA sans un modèle d’architecture d’agent préétabli. Son utilisation conduit à un ensemble de spécifications qui peuvent se considérer au niveau d’analyse. Mais la conception est très faible, puisque aucun modèle computationnel n’est envisagé. Il n’y a pas non plus de guides méthodologiques, par exemple, pour assigner les rôles aux agents [Pavón, 2006]. Et bien que dans sa version la plus récente sont envisagés des aspects organisationnels [Zambonelli et al., 2003], aucun patron d’organisation n’est proposé, ni comment déterminer le type de rôles qui devrait exister dans une organisation. Par conséquent l’utilité de Gaia pour la réalisation de SMA est assez limitée, mis à part les apports qui peuvent être obtenus quant à l’étude qu’il fait sur la définition de rôles et d’interactions, bien que ces dernières se spécifient de manière assez simple et sans considérer les aspects de concurrence [Pavón, 2006].
MaSE [DeLoach et al., 2001] (Multi-agent System Engineering) est une méthodologie générique qui considère comme point de départ le contexte initial du système, supposé contenir un ensemble bien défini d’exigences fonctionnelles, et permettre d’en extraire un ensemble de buts hiérarchisés. Elle est centrée sur les aspects pratiques de construction de SMA. Cette méthodologie est composée de deux phases (figure 2.3). La phase d’analyse se déroule en trois étapes : capture des buts, application des cas d’utilisation et raffinement des rôles. La phase de conception comporte quatre étapes: création des classes d’agents, construction des conversations, assemblage des classes d’agents et conception du système. La méthodologie MaSE utilise des notations similaires à UML et propose un cycle de développement interactif et incrémental avec des activités d’analyse et de conception, qui sont assistées par l’outil AgentTool [DeLoach et Wood, 2000].
MaSE propose de commencer avec une analyse des buts car elle considère que les buts sont plus stables dans l’analyse et la conception que les fonctions, les processus et les structures d’information. Cette analyse des buts et leur distinction claire par rapport à une analyse fonctionnelle classique sont les apports les plus intéressants de MaSE. Elle propose aussi un mécanisme pour l’identification des rôles et leur assignation aux agents. Pour arriver finalement à un modèle computationnel des agents, il réalise, cependant, une certaine simplification quand on considère que chaque type d’agent correspond à une classe d’objets. D’autre part, certaines considérations, comme celle d’assumer que l’on dispose d’un ensemble de besoins fonctionnels initial ou la détermination d’un ensemble établi de conversations, font que leur applicabilité se limite à résoudre des problèmes similaires à ceux traités avec une méthodologie orientée objets classique [Pavón, 2006]. C’est ainsi que le résultat est un ensemble de classes dont le comportement est défini par des automates mais il n’est pas clair comment on pourrait aborder la construction des agents délibératifs, comme c’est le cas des agents BDI, puisque on ne définit plus, par exemple, comment gérer et contrôler la satisfaction ou l’échec des buts.
AALAADIN [Ferber et Gutknecht, 1998] est un méta-modèle reposant sur les concepts organisationnels que sont les agents, groupes et rôles (AGR), pris ici comme concepts primitifs, et issus d’une analyse préalable du système envisagé. L’organisation est définie comme un cadre d'activité et d'interaction, mis en place par la définition de groupes, rôles et de leurs relations, et considérée comme l’ensemble des relations structurelles dans un ensemble d'agents. Un SMA est vu par l’approche AALAADIN, comme un ensemble de groupes d’agents interconnectés par l’intermédiaire d’agents appartenant à plusieurs groupes (figure 2.4). Aucune contrainte ou pré-requis n’est imposée sur l’architecture interne des agents et aucun formalisme où modèle particulier n’est supposé pour en décrire leur comportement. Chaque agent est simplement décrit comme une entité autonome communicante qui joue des rôles au sein des différents groupes. La méthode AALAADIN a donné lieu au développement de la plate-forme MadKit, développée par O. Gutknecht et J. Ferber [Gutknecht et Ferber, 2001], sur laquelle nous reviendrons.
La liste présentée ci-dessus n’est pas limitative. Dans la littérature on trouve d’autres méthodologies partant des résultats du domaine du génie logiciel orienté objets (ADELFE [Picard et al., 2002], AAII/BDI [Rao et Georgeff, 1991], Kendall [Kendall, 1995], MASB [Moulin et Brassard, 1996], ODAC [Gervais, 2003], MESSAGE [Caire et al., 2001]) ou appliquent des techniques de construction de systèmes experts (CoMoMAS [Glaser, 1996], MAS-CommonKADS [Iglesias, 1998]). D’autres donnent plus d’importance aux relations entre les divers aspects du SMA, comme dans VOYELLES [Demazeau, 1995], INGENIAS [Pavón et Gómez-Sanz, 2003] ou MASSIVE [Lind, 2001].
Ci-dessous, nous montrons quelques arguments guidant et renforçant notre choix de la méthodologie à utiliser pour la phase de modélisation de notre architecture :
- Il existe un nombre important de méthodologies et d’outils de conception de SMA et la communauté travaillant dans le domaine des agents se trouve en face du problème d’identification d’un vocabulaire commun pour les supporter [Bauer et Müller, 2004]. Cependant, il n’existe pas encore une méthodologie standard suffisamment mature qui aborde tous les aspects nécessaires pour définir un SMA, ni tout le cycle de développement de ce type de logiciel.
- J. Pavón, l’un des auteurs de la méthodologie INGENIAS [Pavón et Gómez-Sanz, 2003] affirme dans [Pavón, 2006] que malgré l’existence de beaucoup d’applications basées sur les agents, il manque encore l’expérience pour la conception et la construction de SMA à un niveau industriel (une révision plus récente de l’état de l’art et des applications de la technologie des agents se trouve dans [Luck, 2004]). La grande majorité des applications basées sur les agents est construite sans utiliser des composants agents réutilisables et ne sont pas généralisables. C’est pour cela que la recherche sur les méthodes, les outils et les plates-formes d’agents a beaucoup d’importance pour l’implantation de la technologie d’agents en dehors du domaine purement académique. Dans la situation actuelle, peu de méthodologies ont amené des cas réels significatifs à la pratique et sont assistées par des outils. En plus, les méthodologies existantes ne considèrent que certains aspects du cycle de vie, généralement l’analyse et la conception. Pour l’implémentation, la plupart des méthodologies sont conditionnées par l’utilisation d’une architecture d’agents déterminée.
- Le paradigme d’agent peut s’étendre à celui d’objet. En conséquence, une méthodologie de développement de SMA devrait profiter de l’expérience de l’approche objet. Les méthodologies orientées objets ont acquis un haut niveau de maturité et leurs avantages sont largement reconnus. Une grande partie des développeurs de logiciel sont familiarisés avec elles et utilisent la large gamme d’outils disponibles [Pavón, 2006].
Afin de donner un cadre méthodologique au processus de modélisation, nous allons par la suite appliquer le formalisme AUML et par conséquent UML 2.1 qui contient un grand nombre de concepts liés aux agents. En fait, UML est un standard largement connu, accepté et a fait ses preuves pour la modélisation des applications orientées objet. Le fait que le paradigme des agents est considéré comme une extension du paradigme objet a conduit plusieurs auteurs pour étendre UML afin de tenir compte des concepts agents. Une discussion sur ce sujet a été présentée dans [Bauer et al., 2001]. En choisissant AUML, nos modèles proposés dans ce manuscrit seront largement diffusés et compris. D’autres arguments plus techniques liés à la problématique que nous traitions et qui renforcent notre choix seront présentés dans les prochains chapitres.