Tout n’est pas modélisable, ni plus encore implémentable avec un même modèle de système multi-agents. Par contre, les mêmes schémas se répètent souvent au travers des différentes applications. Un des objec-tifs de notre approche est de fournir des modèles et des outils basés sur la réutilisabilité. L’expérience accumulée dans le domaine de la conception d’applications des SMA nous permet d’envisager de réuti-liser des modèles génériques développés pour chacune des notions A, E, I, O, en les instanciant pour les applications visées.
L’objectif de ce niveau est d’obtenir un système de composants à partir de la description informelle du système multi-agents. La construction de nos agents repose sur l’utilisation de composants. Les com-posants sont de très bons outils car ils sont interchangeables et réutilisables. De plus, ils facilitent le travail futur concernant le partitionnement de ce qui deviendra logiciel et matériel.
C.1 Définition du contexte
!
C.2
Construction des tâches applicatives de l’agent
!
C.3
Construction des modules de communication et des structures d’organisation ! C.4 Construction du contrôle de l’agent 5.4.1 Définition du contexte (C.1)
Dans cette étape nous allons préciser le contexte qui a été esquissé durant l’étape précédente. C.1.1
Choisir une architecture pour les différents agents
!
C.1.2
Préciser le diagramme de contexte
92 La démarche de la méthode DIAMOND
Choisir une architecture pour les différents agents (C.1.1). On fait les choix des architectures
pour les agents en accord avec le modèle choisi et les contraintes spécifiées précédemment. Cette archi-tecture comme nous le verrons dans l’étape suivante, servira de patron pour la conception détaillée en composants permettant ainsi de la guider et de la structurer.
Préciser le diagramme de contexte (C.1.2) A ce niveau de l’étude il est temps de procéder aux
choix technologiques des actionneurs et des effecteurs de chaque agent. On prendra garde les contraintes à ne pas violer figurant dans la fiche des contraintes technologiques. Les paramètres qui influent sur ce choix sont traditionnellement le coût, la consommation électrique, le rendement, la fiabilité etc. En fonc-tion de ces choix il nous faut caractériser les interfaces qui permettront de numériser les informafonc-tions (échantillonner, quantifier, coder). On complète ainsi les informations apparaissant sur le diagramme de contexte.
Documentation liée à ce processus C.1 . Au point de départ du travail fait dans cette activité sont
les fiches de contextes élaborée dans la phase individuelle. A ce niveau de l’étude on s’appuie sur les à ne pas violer les contraintes figurant dans la fiche des contraintes technologiques. On va créer une partie Conception dans la documentation de l’agent. On commence par créer une fiche de description
architecturale de l’agent. On y précise les raisons qui ont amené à ce choix. On créé une nouvelle fiche de diagramme de contexte. On y reprend le contenu du diagramme de contexte mais en précisant la nature
physique des informations (il se peut que dans certains cas il soit nécessaire de dégrader le diagramme c’est-à-dire l’adapter à des contraintes particulières de conception).
Application au cas d’étude : Définition du contexte
Le diagramme de contexte donne les spécifications suivantes :
Le concepteur va donc procéder aux différents choix technologiques et spécifier les interfaces avec les éléments dépendant du matériel. Les interfaces choisies, on va spécifier la nature des signaux qui transiteront entre le système que l’on conçoit et ces élément matériels (voir tableau 5.3).
L’étape de conception générique (étape C) 93
TAB. 5.3 – Spécification des interfaces Information Spécification
Reset Actif sur niveau logique haut (1bit).
Moteur rotation Angle, relatif à la direction actuelle, dans l’intervalle [-180,+180] codé en-tier signé sur 10 bits.
Moteur Avance Deux vitesses possibles plus l’arrêt. Entier codé sur 2 bits. (00: arrêt / 01: vitesse lente / 10: vitesse rapide)
Force Deux niveaux de forces possibles. Niveau codé sur 1 bit. (0: passe / 1: tir) Ejecte balle Front montant sur 1bit
Date_heure Nombre de millisecondes écoulées depuis la mise sous tension (Entier codé sur 32 bits).
Msg_recu Suite de bits (émetteur 1octet,dest 1octet,taille_données 1octet, données 1-256octets).
Msg_emi Suite de bits protocole spécifique (émetteur 1octet,dest 1oc-tet,taille_données 1octet, données 1-256octets)
Il est à remarquer que le diagramme de contexte décrit un composant de très haut niveau. Ce dernier contiendra le pattern ainsi que tous les composants que l’on créera ou utilisera.
5.4.2 Construction des tâches applicatives de l’agent (C.2)
C.2.1 Construire la coquille externe de l’agent
!
C.2.2 Construire la coquille interne de l’agent
Nous allons construire les différentes tâches de l’agent. Cette construction se fera via des composants. Un composant peut être défini comme une unité indépendante de production et de déploiement, qui est combinée à d’autres composants pour former une application (dans notre cas ce sera une application multi-agents). Une approche orientée composants permet de bénéficier de plusieurs avantages :
– Réutilisation des composants par une autre application,
– Mise à jour des composants, sans que l’ensemble de l’application ne soit modifié, – Les composants peuvent reposer sur des ressources (Base de données, images).
Néanmoins, comme généralement "le langage est l’environnement", il n’est pas suffisant d’inventer de nouveaux langages de programmation ou des mécanismes de composition. Ceux-ci doivent être aidés par des environnements de développement, de sorte que les développeurs puissent appliquer les nouveaux dispositifs.
94 La démarche de la méthode DIAMOND
Construire la coquille externe de l’agent (C.2.1). On construit la coquille de l’agent c’est-à-dire :
– les parties de l’agent qui vont acquérir l’information provenant des interfaces capteurs afin son interface avec le monde extérieur afin d’établir la représentation du monde,
– les parties de l’agent qui vont agir sur le monde extérieur pour changer son état.
Construire la coquille interne de l’agent (C.2.2). On s’attache ensuite à la création des actions
évoluées : actions paramétrées, composées et situés ainsi que les actions composées. Il est conseillé de respecter l’ordre dans lesquels ont été définies préalablement les différentes actions et perceptions afin d’éviter de devoir revenir sur un composant déjà créé à cause d’une mauvaise appréciation de l’interface d’un composant utilisé.
Documentation liée à ce processus C.2 . Pour chaque composant créé, on saisit une fiche de
des-cription de composant qui permet d’identifier sa desdes-cription externe et sa desdes-cription interne.
Application au cas d’étude : Construction des tâches applicatives de l’agent
A ce stade, on agence les composants pour construire l’application. L’architecture de l’agent servira de patron pour la décomposition en composants (figure 5.16).
Les composants seront dotés d’une description externe (figure 5.14) et d’une description interne (fi-gure 5.15). La description interne peut être un agencement de composants, un formalisme type réseau de Petri, ou une description textuelle pouvant engendrer du logiciel ou du matériel.
L’étape de conception générique (étape C) 95
FIG. 5.15 – Spécification interne des composants
5.4.3 Construction des modules de communication et des structures d’organisation (C.3)
Ce processus a pour objectif la construction des modules de communication. Cette construction se fait, comme précédemment avec des composants. Une fois cette opération effectuée, on va s’intéresser à la construction des protocoles d’interaction et de la structure organisationnelle toujours avec des compo-sants.
Documentation liée à ce processus C.3 . Similaire à la construction de la documentation du
proces-sus C.2 vue en 5.4.2.
Application au cas d’étude : Construction des modules de communication et des structures d’organisation
Cette partie de l’analyse s’intéresse à la création des modules de communication et des structures or-ganisationnelles définies durant l’étape d’analyse avec des composants comme précédemment. La nature des composants manipulés est différente mais la philosophie est la même 5.4.2.
96 La démarche de la méthode DIAMOND
5.4.4 Construction du contrôle de l’agent (C.4)
Cette étape compose avec l’élaboration des comportements des composants/agents. Les parties "éva-luation" et "décision" de l’agent seront créées dans cette étape. Quand un message est reçu le compo-sant/agent doit être capable de fournir une réponse appropriée, de choisir les comportements appropriés qui doivent être exécuter. Cette exécution de tâche va changer alors l’état du composant/agent.
C.4.1
Construire le contrôle (partie environnementale)
Dis moi comment tu réagis et je te dirais d’où tu viens?
!
C.4.2
Construire le contrôle social de l’agent
Dis moi comment tu penses et je te dirai de quelle société tu viens?
Documentation liée à ce processus C.4 . Similaire à la construction de la documentation du
proces-sus C.2 vue en 5.4.2.
Application au cas d’étude : Construire le contrôle de l’agent
La figure 5.16 présente l’agencement des composants selon l’architecture eASTRO.
FIG. 5.16 – Architecture eASTRO comme patron
Le modèle des agents eASTRO3("embedded Agent" Spécialiste pour le Temps Réel et la cOopéra-tion) est basé sur le paradigme perception / évaluation / raisonnement / action. Le centre de l’agent est
L’étape d’implantation (étape D) 97
son modèle du monde. Ce modèle contient les connaissances de l’agent sur l’environnement, les autres agents et son propre état. L’état de l’agent contient en particulier les plans qui sont en cours d’exécution ou sur lesquels travaille le processus de raisonnement de l’agent. Ce modèle est rafraîchi par un pro-cessus d’interprétation des données perçues. Comme il évolue dans un monde dynamique, l’agent est muni de dispositifs de perception qui sont gérés par les modules de perception. Pour assurer la réactivité de l’agent, des évaluateurs examinent en permanence le modèle du monde. Les modules de contrôle de l’agent détectent les situations pour lesquelles l’agent doit réagir, les évaluent, et décident des réactions, qui peuvent consister en l’introduction, la suspension ou la suppression de buts de façon à changer le contexte du processus de planification et de décision. La supervision continue de la situation de l’agent assure la réaction de l’agent à l’occurrence d’événements imprévus à tout instant. Le même mécanisme (modules de communication) prend en compte l’interaction avec les autres agents en utilisant si besoin des protocoles d’interaction. Quand un but est créé (ou modifié) un plan est recherché pour satisfaire ce but avant sa date limite, cette tâche est réalisée par les modules de raisonnement. Les plans construits sont ensuite ordonnancés par les modules de décision. L’ordonnanceur choisit la meilleure façon de réa-liser le plan. Le planificateur et l’ordonnanceur ont la possibilité d’introduire des actions internes comme la replanification, ou l’établissement de conditions de veille pour garantir une meilleure d’adaptation au contexte. Ces gardes fournissent des informations sur la situation courante durant la phase d’exécu-tion des acd’exécu-tions, elles sont stockées dans l’état interne. Ce mécanisme assure l’adaptad’exécu-tion de l’agent à la rapidité de l’évolution de son environnement ; il est indispensable si l’agent poursuit plusieurs buts simultanément.