2.4 Méthodologie et comparaison de méthodes
2.4.1 Les cadres de comparaisons existants et problématique
La problématique de la comparaison de méthodes a été souvent soulevée dans la litté- rature pour aider le concepteur à choisir la méthode la plus adaptée au problème donné ou pour exhiber les différences essentielles entre les différentes méthodes.
Shehory et Sturm ou bien Dam et Winikoff comparent les méthodes suivant quatre ou cinq axes : les concepts manipulés, les notations utilisées (et les techniques de modélisation), le processus de développement et la pragmatique [Shehory et Sturm, 2001; Sturm et Shehory, 2003; Dam et Winikoff, 2003]. Dam et Winikoff ont même fait tester trois méthodes (MaSE, Prometheus et Tropos) par des stagiaires afin de les comparer suivant ce schéma. Cernuzzi et Rossi se focalisent seulement que sur les concepts de modélisation des agents (les rôles, les buts, l’organisation, etc.), mais proposent une évaluation chiffrée par une somme pondérée des différentes prises en compte des concepts par les méthodes [Cernuzzi et Rossi, 2002].
8Bien qu’aujourd’hui Prometheus s’ouvre à d’autres architectures et revendique son caractère générique.
2.4. Méthodologie et comparaison de méthodes
Cette évaluation nécessite, par contre, une grande expertise dans toutes les méthodes et un grand nombre d’évaluateurs afin de déterminer au mieux les coefficients. Dans [Bernon et al., 2002b], nous avions comparé des méthodes suivant huit axes : l’étendu de la couver- ture du processus, la spécialisation de la méthode à une application, l’architecture d’agent sous-jacente, l’utilisation de notations existantes, le domaine d’application (dynamique ou non), le modèle de rôle, le modèle de l’environnement et l’identification des agents.
Compte-tenu du large éventail de méthodes à comparer et de notre volonté de s’inté- grer dans des processus existant, la comparaison qui va suivre sera faite suivant les quatre axes de Dam et Winikoff, mais en gardant en sous-catégorie les points de Bernon et al. qui rejoignent nos objectifs.
2.4.1.1 Les concepts clés et propriétés
Afin d’évaluer une méthode, il est intéressant de vérifier quels concepts agents et multi- agents sont pris en compte [Shehory et Sturm, 2001; Sturm et Shehory, 2003; Dam et Wini- koff, 2003; Cernuzzi et Rossi, 2002]. Nous avons vu quels étaient ces concepts, et les pro- priétés des systèmes multi-agents dans le paragraphe 1.2. Pour plus d’information, Boissier et al. recensent de manière exhaustive les caractéristiques propres aux systèmes multi-agents et à leurs applications [Boissier et al., 2004]. Citons par exemple adaptation, autonomie, but, concurrence, croyance, désir, distribution, environnement, groupe, intention, interac- tion, norme, organisation, ouverture, pro-activité, protocole, réactivité, rôle ou tâche. Cet axe de comparaison va donc aussi s’attacher à évaluer les problèmes auxquels la méthode peut répondre.
2.4.1.2 Les notations et langages de modélisation
Comme nous l’avons vu dans les paragraphes précédents, les langages de modélisation agents sont souvent graphiques, inspirés de l’ingénierie objet, des besoins ou des connais- sances. Ils comportent des symboles, une syntaxe et une sémantique propres. Là encore, l’évaluation s’établit sur l’analyse des propriétés des langages utilisés [Shehory et Sturm, 2001; Dam et Winikoff, 2003; Cernuzzi et Rossi, 2002; Arlabosse et al., 2004] :
– Accessibilité : le langage est-il facile à apprendre et à utiliser ? Demande-t-il un long temps d’apprentissage ?
– Complexité : y a-t-il une possibilité de visualiser la complexité du système à plusieurs niveaux d’abstraction ?
– Consistance : y a-t-il possibilité de vérifier la consistance d’une spécification ?
– Exécution : y a-t-il une fonctionnalité de prototypage permettant des exécutions préli- minaires ?
– Expressivité : est-ce que tous les aspects de la conception de l’application sont pris en compte par la notation ?
– Modularité : est-ce que la modification des spécifications en amont implique une remise en cause de la totalité des spécifications ?
– Portabilité : est-ce que le langage est indépendant de quelconques choix de développe- ment (langage de programmation par exemple, ou architecture) ?
– Précision : le langage ne doit pas être ambigu. Y a-t-il des définitions précises établies ?
– Raffinage : le concepteur est-il guidé pour raffiner les modèles utilisés ?
– Traçabilité : est-il facile de modifier des spécifications passées, de tracer ses change- ments sans avoir de répercussion sur les spécifications en cours ?
Tous ces critères sont à prendre en compte lors du choix d’une méthode utilisant un langage dédié ou bien lorsqu’un développeur veut lui-même définir son propre langage de modélisation.
2.4.1.3 Le processus
Compte tenu de l’influence qu’a pu avoir le monde de l’objet, les cycles de vie et pro- cessus utilisés dans la conception de systèmes multi-agents sont de types classiquement utilisés en conception modulaire : cascades, itératifs, en V, en spirales. Comme nous l’avons précisé dans le paragraphe 2.1, les principales phases d’un processus de développement sont : l’analyse des besoins, la conception de l’architecture (ou analyse), la conception dé- taillée, le développement (ou implémentation) et le déploiement. Toutes les méthodes ne couvrent pas tout ce cycle, et il est nécessaire de le prendre en compte lors de l’évaluation d’une méthode.
Pour les méthodes proposées nous allons aussi analyser :
– Le contexte de développement, c.-à-d. est-ce que le processus est adéquat pour le déve- loppement de nouvelles applications, la ré-ingénierie (reengineering), le prototypage, la réutilisation, pour faire appel à des schémas de conception pré-existants, utiliser des bibliothèques dédiées, faire du reverse engineering ?
– Les délivrables sont-ils bien identifiés et associés à des étapes précises ?
– La vérification 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.4.1.4 La pragmatique
Shehory et Sturm ou Dam et Winikoff proposent de s’intéresser à l’aspect pragmatique de la méthode, c.-à.d. la gestion et les questions techniques. Ceci inclut les supports mis en place pour l’utilisation de la méthode (livres, textes en ligne, ou logiciel d’aide au suivi), le prix à payer pour choisir une nouvelle méthode, ou le besoin d’expertise. Le critère tech- nique porte plutôt sur la spécialisation des méthodes à des domaines particuliers (gestion de collectifs humains, données distribuées, résolution de problèmes, simulations, etc).