Programmation orienteagent: valuation comparative doutils et environnements

1
Programmation orientée-agent  évaluation
comparative doutils et environnements

• Tony Garneau Sylvain Delisle
• Département de mathématiques et dinformatique
• Université du Québec à Trois-Rivières

JFIADSMA 2002, 28-30 octobre, Lille, France
2
Plan de la présentation

• Introduction
• Évaluation
• Objectifs et choix des outils
• Critères dévaluation
• Résultats
• Résultats par outil
• Classement global
• Conclusion

3
Introduction

• La programmation orientée-agent
• Nouveau paradigme de programmation,
• Évolution de la programmation orientée-objet,
• Façon plus naturelle de concevoir les systèmes.
• Méthodologies et architectures
• Patrons théoriques pour la modélisation,
• Les systèmes spécifiés à partir de ces
  méthodologies sont difficiles à implémenter par
  des langages de programmation standards (C,
  Java ou autres).

4
Introduction

• Méthodologies et architectures développées
• MaSE, Aalaadin ou AGR, RETSINA, dMARS, OAA,
  DESIRE, Gaia, Tropos, Kaos et bien dautres
• Outils POA
• JADE, Zeus, MadKit, AgentBuilder, Jack, JAFMAS,
  AgentTool, DECAF, RMIT, Brainstorm / J, ADK, ABEL
  et autres
• Créés pour supporter une méthodologie.
• Créés pour démontrer une idée ou un concept en
  particulier.

5
Évaluation

• Objectifs à atteindre pour quun outil soit
  considéré comme un environnement de développement
  de SMA
• Accélérer le développement et diminuer leffort
  de programmation,
• Abstraire les mécanismes de communication,
  dinteraction et de coordination,
• Permettre limplémentation de systèmes
  relativement complexes,
• Permettre une bonne extensibilité du code,
• Fournir un support pour le déploiement (et
  lexécution) des systèmes.

6
Critères dévaluation

• 15 critères dévaluation
• Pondération pour chaque critère
• 4 si loutil répond très bien au critère,
• 3 si loutil répond bien au critère,
• 2 si loutil répond moyennement au critère,
• 1 si loutil répond peu au critère,
• 0 si loutil ne répond pas du tout au critère.

7
Critères dévaluation

• 1. Méthodologie
• La méthodologie couvre les différentes étapes du
  processus de développement de SMA
• Analyse, développement, implémentation,
  déploiement.
• 2. Facilité dapprentissage de loutil
• Qualité de la documentation,
• La complexité des composants,
• Les concepts utilisés,
• Et autres

8
Critères dévaluation

• 3. Transition entre les étapes
• Facilité de transition entre le développement et
  limplémentation.
• 4. Souplesse de loutil
• Flexibilité de loutil par rapport à
  lutilisation de ses composants et de sa
  méthodologie.

9
Critères dévaluation

• 5. Communication inter-agents
• Fournir limplémentation des différents services
  de communication entre les agents
• Connections entre les machines, protocoles de
  communication, sécurité, synchronisation,
  services de messagerie.
• 6. Outil de débuggage
• Entre autre, il faut être capable de
• Retracer les agents des différentes machines, les
  messages transmis, les erreurs survenues.

10
Critères dévaluation

• 7 et 8. Support graphique pour le développement
  et implémentation
• Lenvironnement propose des interfaces aidant
• La création du modèle et des agents,
  lélaboration des conversations, le transport des
  messages, le déploiement sur différentes
  machines.
• 9. Support pour la gestion du système
• Loutil permet linteraction avec le système
• Ajouter, modifier, supprimer (agents ou
  sous-systèmes) dynamiquement dans le système.

11
Critères dévaluation

• 10. Diminution de leffort demandé et simplicité
  dimplémentation
• Composants facilement identifiables
• Noms, packages, documentation, paramètres, etc
• Langage de programmation
• Orienté-objet, multi-threads, programmation
  réseau simple.
• Classes et services disponibles faciles à
  utiliser.
• Diminution de la quantité de code à écrire.

12
Critères dévaluation

• 11. Support pour les bases de données
• Abstraction du processus de sauvegarde des
  informations.
• 12. Génération de code
• Génération automatique du code source des
  différents composants du système.
• 13. Extensibilité du code
• Facilité dajout de code à celui déjà existant
  (ou généré).
• Simple de modifier les classes et services déjà
  implémentés.

13
Critères dévaluation

• 14. Le déploiement
• Permettre le déploiement sur plusieurs machines,
• Exécution simple du système,
• Exécution indépendante de lenvironnement.
• 15. La documentation
• Documentation de qualité
• Elle couvre lensemble des composants de loutil.
• Elle est claire, concise et non-ambiguë.

14
Outils évalués

• AgentTool
• Outil et méthodologie qui mettent laccent sur
  les premières phases du développement (analyse et
  développement).
• Méthodologie MaSE extension au modèle OO (7
  phases)
• Trouver les buts, appliquer les cas
  dutilisation, raffiner les rôles, créer les
  classes dagents, construire les conversations,
  assembler les classes dagents et
  limplémentation.
• Loutil permet la validation des conversations.
• Génération du code des conversations (en Java).

15
Outils évalués

• AgentBuilder
• Environnement de développement complet
• Méthodologie OMT à laquelle on ajoute une partie
  ontologie,
• Agents construits à partir dun modèle BDI et de
  AGENT-0,
• Langage de communication entre les agents KQML,
• Exécution à partir de lengin dAgentBuilder,
• Possibilité de générer les fichiers  .class  et
  dexécuter les systèmes sur une JVM standard.

16
Outils évalués

• DECAF
• Environnement de développement de plans,
• Loutil fourni des utilitaires pour lélaboration
  de plans et pour la coordination des tâches,
• Un planificateur applique des heuristiques pour
  trouver un ordonnancement aux tâches,
• Éditeur dagent utile pour le  débuggage .

17
Outils évalués

• Jack
• Gestionnaire de projet
• Éditeur de textes où se fait limplémentation du
  système,
• La compilation (passage de JAL à Java),
• Lexécution du système.
• Le langage JAL est une extension au langage Java.
• Compilateur qui transforme le code JAL en java
  pur.
• Les agents sont basés sur un modèle BDI (une
  évolution du modèle BDI de dMars).

18
Outils évalués

• Jade
• Outil qui répond aux normes FIPA.
• Trois modules principaux (nécessaires aux normes
  FIPA)
• Le DF  directory facilitator  fourni un service
  de pages jaunes à la plate-forme.
• Le ACC  agent communication chanel  gère la
  communication entre les agents.
• Le AMS  agent management system  supervise
  lenregistrement des agents, leur
  authentification, leur accès et utilisation du
  système.
• Langage de communication entre les agents FIPA
  ACL.
• Éditeur pour lenregistrement et la gestion des
  agents.

19
Outils évalués

• JAFMAS et JiVE
• JAFMAS met laccent sur les protocoles de
  communication, linteraction entre les agents, la
  coordination et la cohérence à lintérieur du
  système.
• Méthodologie en cinq phases 
• Identifier les agents, les conversations, les
  règles de conversation, analyser le modèle des
  conversations et limplémentation.
• Utilisation des réseaux de Pétri.
• JiVE support graphique pour le développement
  avec JAFMAS.

20
Outils évalués

• Madkit
• Environnement basé sur la méthodologie Aalaadin
  ou AGR (agent / groupe / rôle).
• Un agent joue des rôles à lintérieur de groupes.
• Loutil fourni un éditeur permettant le
  déploiement et la gestion des SMA (G-box).
• Loutil offre aussi un utilitaire pour effectuer
  des simulations à grande échelle.

21
Outils évalués

• Zeus
• Environnement de développement complet
• Méthodologie  role modeling .
• Les agents possèdent trois couches
• La définition lagent est vu comme une entité
  autonome capable de raisonner grâce à ses
  croyances, ressources et préférences.
• Lorganisation relations entre les agents.
• La coordination modes de communication entre
  les agents, protocoles, coordination et autres
  mécanismes dinteraction.

22
Évaluation globale

• Jack et JADE
• Ils peuvent être considérés comme étant des
  frameworks,
• Aucune méthodologie nest spécifiée,
• Lacunes au niveau des utilitaires graphiques,
• Bonne documentation,
• Grandes possibilités au niveau de
  limplémentation.
• Différence majeure
• le développement avec JADE se fait en Java
  contrairement à JAL pour le développement avec
  Jack.

23
Évaluation globale

• AgentTool, DECAF, Jade, Madkit
• Quatre environnements aidant à différents
  niveaux du processus de développement de SMA.
• DECAF et JAFMAS
• Ces deux outils mettent laccent sur les
  interactions, la coordination et la
  planification.
• Ils délaissent le côté implémentation et
  déploiement.
• Comparativement aux trois autres, DECAF noffre
  aucune méthodologie.

24
Évaluation globale

• AgentTool, DECAF, Jade, Madkit (suite)
• AgentTool
• Cet outil met laccent sur les premières phases
  du développement.
• Limplémentation nest pas prise en compte (sauf
  la génération des conversations).
• MadKit
• Il met plus lemphase au niveau du déploiement
  quaux autres étapes du développement (même sil
  se base sur la méthodologie Aalaadin et offre un
  ensemble de classes).
• Il offre une bonne documentation comparativement
  aux trois autres.

25
Évaluation globale

• AgentBuilder et Zeus
• Les deux environnements les plus complets
• Documentation abondante,
• Ces outils offrent plusieurs interfaces
  graphiques aidant lors des différentes étapes du
  développement,
• Les deux outils offrent un utilitaire de
   débuggage ,
• Ils proposent chacun une méthodologie pour le
  développement,
• Les deux outils sont très complexes et leurs
  apprentissages nécessitent beaucoup defforts.

26
Évalutation globale

• AgentBuilder et Zeus (suite)
• AgentBuilder
• Il faut connaître RADL  Reticular Agent
  Definition Language .
• Comprendre la gestion des ontologies, lengin
  dexécution, les protocoles utilisés et maîtriser
  les différents interfaces de lenvironnement.
• Zeus
• Maîtriser la technique de modélisation  Role
  modeling  quil faut obligatoirement utiliser,
  comprendre les différents éditeurs qui
  fournissent plusieurs services plus ou moins
  sophistiqués.
• Les deux outils ont des lacunes aux niveaux de
  lextensibilité et de la souplesse.

27
Conclusion

• Quelques résultats
• Les outils fournissant des utilitaires graphiques
  pour le développement et limplémentation ont un
  manque aux niveaux de lextensibilité et de la
  souplesse.
• Ceux qui fournissent des interfaces pour
  limplémentation diminuent leffort de
  programmation.
• Les outils les plus complets proposent une
  méthodologie.
• La plupart des outils ne supportent aucun
  mécanisme pour la sauvegarde des données.

28
Conclusion

• Constats
• La majorité des outils ont été développés pour
  exploiter un concept en particulier.
• Ces outils négligent, volontairement ou non,
  plusieurs aspects essentiels à limplémentation
  dun SMA.
• Ceci rend leur utilisation souvent impossible
  pour le développement de systèmes réels.

29
(No Transcript)