Implantation des protocoles de communication FIPA dans la plate-forme GAMA

Dimension: px
Commencer à balayer dès la page:

Download "Implantation des protocoles de communication FIPA dans la plate-forme GAMA"

Transcription

1 L Institut de la Francophonie pour l Informatique L unité de recherche Geodes, Institut de Recherche pour le Développement (UR079, IRD) Master INTELLIGENCE ARTIFICIELLE ET MULTIMEDIA, 2 ème année, Spécialité RECHERCHE Année universitaire Implantation des protocoles de communication FIPA dans la plate-forme GAMA Mémoire présenté par VO Duc An Stage effectué à l UR079, IRD Bondy et au laboratoire MSI, IFI. Directeur : Alexis DROGOUL Directeur de Recherche, UR079, IRD. HaNoi, Septembre 2008.

2 L Institut de la Francophonie pour l Informatique L unité de recherche Geodes, Institut de Recherche pour le Développement (UR079, IRD) Master INTELLIGENCE ARTIFICIELLE ET MULTIMEDIA, 2 ème année, Spécialité RECHERCHE Année universitaire Implantation des protocoles de communication FIPA dans la plate-forme GAMA Mémoire présenté par VO Duc An Stage effectué à l UR079, IRD Bondy et au laboratoire MSI, IFI. Directeur : Alexis DROGOUL Directeur de Recherche, UR079, IRD. HaNoi, Septembre 2008.

3 Remerciements Je tiens à remercier tout particulièrement Alexis DROGOUL pour m avoir encadré ces six mois. En fait, j ai de la chance de travailler sous la direction de Alexis DROGOUL dans le projet GAMA depuis plus d un an. Il est un professeur extraordinaire. Je le remercie pour son amitié, sa patience avec mes questions souvent stupides, son encouragement, son soutien, et la liberté de recherche qu il a bien voulu me laisser. Les moments où il m a aidé à faire le debug sur Eclipse sont des moments inoubliables pour moi. Je remercie Quang de son amitié, son encouragement et son soutien tout au long de ce travail. Je le remercie pour son aide à Bondy ainsi qu à MSI. Je lui souhaite tout le succès pour sa thèse. Je remercie François Sempé d avoir accepté de rapporter sur ce travail. Je remercie Minh Thu, Khanh, Edouard et Doanh pour leur amitié, leur aide pour le temps à MSI. Je remercie chaleureusement mes camarades de la promotion XII pour leur amitié sans faille et leur souhaite bonne chance pour la soutenance. Je remercie les professeurs de l IFI pour leurs aides pendant ces derniers trois ans à IFI. Enfin, je remercie mes parents pour leur soutien et leur encouragement à tout instant. Je leurs dédie ce travail.

4 Tableaux des matières I. Introduction... 6 II. Problème actuel et les protocoles d interaction de FIPA... 7 II.1. Problème actuel de la communication dans GAMA... 7 II.2. Les protocoles d interaction de FIPA... 8 II.2.1. Message FIPA ACL... 9 II.2.2. Protocole d interaction «FIPA Request»... 9 III. L implémentation des protocoles d interaction de FIPA dans GAMA III.1. Diagramme de classe III.2. Structure d un «Message» III.3. Abstraction des protocoles d interaction III.4. Mécanisme d envoi et de réception d un message III.5. Vérification d un message avec le protocole d interaction employé III.6. Langage GAML III.6.1. Les primitifs, les variables, les objets d un agent communicant III.6.2. Exemple de GAML IV. Validation dans le modèle «fourmis» IV.1. Le modèle «fourmis» original IV.2. Le modèle «fourmis» avec la communication IV.2.1. Fonctionnement du modèle IV.2.2. La communication entre les agents IV.2.3. Le fonctionnement du nouveau modèle dans GAMA IV.3. Commentaire sur le fonctionnement de deux versions de «fourmis» V. Validation dans le modèle «AROUND» V.1. Modèle AROUND original V.2. Modèle AROUND avec la communication V.3. Commentaire sur le fonctionnement de deux versions de «AROUND» VI. Conclusion et perspectives Bibliographie Annexe Annexe A Code source du modèle «fourmis» avec la communication Annexe B Code source du modèle AROUND avec la communication... 59

5 Tableau des figures Figure 1 - L architecture d une plate-forme d agent proposée par FIPA... 8 Figure 2 - Protocole d interaction «FIPA Request» Figure 3 - Les classes principales de l implémentation Figure 4 - Structure d un message Figure 5 - Les protocoles d interaction de FIPA implémentés dans GAMA Figure 6 - Modélisation d un protocole d interaction Figure 7 - Protocole d interaction FIPA Request Figure 8 - Itinéraire d un message de l envoyeur au récepteur Figure 9 - Un message respecte le protocole d interaction employé Figure 10 - Un message ne respecte pas le protocole d interaction employé Figure 11 - Protocole d interaction FIPA Request Figure 12 - Le comportement d une fourmi dans le modèle «fourmis» original Figure 13 - Le modèle «fourmis» original Figure 14 - Le comportement d un «foodfinder» Figure 15 - Le comportement d un «foodcarrier» Figure 16 - Protocole «FIPA Contract Net» dans le modèle «fourmis» Figure 17 - Protocole «No Protocol» entre foodcarrier et foodfinder Figure 18 - Modèle «fourmis» avec la communication dans GAMA Figure 19 - Deux ambulances vont prendre une même victime Figure 20 - Relation entre military et explorer Figure 21 - Procotole d Interaction FIPA Request entre military et explorer Figure 22 - Protocole d Interaction «No Protocol» entre explorer et military Figure 23 - Relation entre military et fireman Figure 24 - Protocole d Interaction FIPA Request entre military et fireman Figure 25 - Protocole d Interaction FIPA Request entre military et hospital Figure 26 - Protocole d Interaction «No Protocol» entre military et hospital Figure 27 - Relation entre hospital et ambulance Figure 28 - Protocole d Interaction FIPA Request entre ambulance et hospital Figure 29 - Protocole d Interaction «No Protocol» entre les hôpitaux Figure 30 - Protocole d Interaction «No Protocol» entre hospital et ambulance Figure 31 - Protocole d Interaction FIPA Request entre hospital et ambulance Figure 32 - Protocole d Interaction FIPA Request When entre hospital et ambulance Figure 33 Repartition des ambulances dans la version originale Figure 34 Repartition des ambulances dans la nouvelle version Figure 35 - Repartition des voitures des pompiers dans la version originale Figure 36 - Repartition des voitures des pompiers dans la nouvelle version... 47

6 I. Introduction GAMA (GIS & Agent-based Modelling Architecture) est une plateforme générique pour la modélisation et simulation orientée agent. GAMA est actuellement développée au sein du laboratoire MSI et est financée principalement par l IRD. Ce projet regroupe plusieurs partenaires : IFI, IRD, CIRAD, EDF. Le développement de cette plateforme est en parallèle avec l implémentation de plusieurs modèles complexes qui appartiennent à différents domaines. La diversité des modèles développés nous aide à vérifier la généralité de la plateforme et l assurer d une part. Elle sert également à découvrir les fonctionnalités manquantes de la plateforme d autre part. En observant le déroulement de la simulation de quelques modèles, nous avons fait le constat qu il n existe pas encore actuellement de mécanisme de communication standardisé entre les agents dans GAMA. En raison de cette absence, le fonctionnement de ces modèles peut ne pas être réaliste, n est pas efficace et parfois n est pas correct. Sans un mécanisme de communication, il n est par exemple pas possible ou difficile pour les modélisateurs d implémenter de mécanismes de coordination entre les agents. Ce stage de fin d étude a donc pour but d implémenter des protocoles de communication dans GAMA et de valider le fonctionnement de ces protocoles en les utilisant dans quelques modèles existants. Ce rapport présente le travail réalisé au cours du stage. Il se compose de six parties. Cette première partie donne une présentation générale du stage. La deuxième partie introduit le problématique : la nécessité d introduire des protocoles d interaction dans GAMA. Dans la troisième partie, l implémentation de ces protocoles dans GAMA est détaillée. Les quatrième et cinqième parties présentent la validation du travail réalisé. Dans la quatrième partie, une implémentation des protocoles d interaction dans un modèle simple est présentée. Puis une implémentation de ces protocoles d interaction dans un modèle complexe est le contenu de la cinqième partie. Ce rapport se termine avec une partie de conclusion et perspectives. 6

7 II. Problème actuel et les protocoles d interaction de FIPA II.1. Problème actuel de la communication dans GAMA Comme nous l avons souligné au-dessus, actuellement, GAMA ne fournit pas encore de capacité pour modéliser une «vraie» communication entre des agents. Les deux mécanismes existants, la communication par signal et la commande «ask», sont en effet très limités. Avec la communication par signal, un agent est capable de transférer des informations dans son environnement. Après quoi, d autres agents peuvent les lire puis réagir de façon appropriée. Comme un signal est transféré par l environnement, tous les autres agents peuvent le percevoir. Dans le cas où un agent A veut communiquer seulement avec un agent B, cela peut poser un problème : si A veut que les informations transférées ne soient visibles que par B, il n y a aucun moyen pour lui de le préciser. L utilisation du signal n est pas donc convenable dans ce cas. De plus, la communication par signal est couteuse en temps de calcul quand le rayon du signal est grand. Dans GAMA, on peut également utiliser l appel «ask» pour demander à un agent (ou à des agents) d exécuter du code. Cette commande est équivalente à l envoi de messages entre objets. On peut donc l utiliser pour simuler le processus de l envoi et de la réception de messages entre les agents. Mais il n est pas possible de modéliser un processus de négociation avec la commande «ask». Plus précisément, l agent A peut utiliser un «ask» pour demander à l agent B à faire quelque chose, mais il n y a aucune possibilité pour l agent B de refuser de le faire, et, de plus, aucune possibilité pour B d informer A de ce refus. Et si B exécute la demande de A, rien n est prévu dans le langage GAML (langage de modélisation de GAMA) pour que B informe A du résultat. Enfin, si B exécute l action demandée par A, mais que l exécution de cette action n est pas réussie, aucun mécanisme n est disponible pour prévenir A. Une autre nécessité est la capacité de coordination et de négociation entre des agents. Considérons un exemple inspiré par le protocole Contract Net. Supposons que l on a deux types d agent. Un agent qui joue le rôle d un gestionnaire. Plusieurs autres agents qui jouent le rôle des participants. Le gestionnaire souhaite faire effectuer une certaine tâche par un des participants. Le gestionnaire sollicite des propositions de m autres participants en publiant un appel d offres (call for proposals, ou cfp en anglais). Cet appel spécifie la tâche, ainsi que toutes les condition que le gestionnaire souhaite placer sur l exécution de cette tâche (temps minimum d exécution, qualité de la réalisation, etc.). Les participants recevant cet appel d offres sont considérés comme des «entrepreneurs». Parmi les m participants, j participants (j <= m) acceptent la sollicitation du gestionnaire en envoyant des offres au gestionnaire. Et i participants (i = m j) la refusent. En recevant j appels d offre de j participants, le gestionnaire choisit le participant le plus convenable pour exécuter la tâche. Actuellement, il n est pas possible de modéliser un scénario comme celui-ci dans GAMA, alors qu il est pourtant très utile dans un environnement multi-agent (où les 7

8 agents ne sont pas forcément tous égaux en terme de capacité, et pas forcément tous disponibles pour réaliser une tâche). En implémentant différents modèles classiques des SMA, nous percevons qu il existe bien des cas dans lesquels la coordination entre les agents joue un rôle vital. Sans une bonne coordination et la capacité de négociation, le fonctionnement de tels modèles n est pas efficace et parfois n est pas correct. Donc il est nécessaire d avoir un vrai mécanisme de communication dans GAMA. Ce mécanisme devra nous aider à modéliser la communication, la négociation et la coordination entre les agents. En plus, il devra fournir aux modélisateurs des primitives de haut-niveau pour manipuler les protocoles de communications et traiter les messages de façon confortable. II.2. Les protocoles d interaction de FIPA FIPA (Foundation of Intelligent Physical Agents) est un membre de l IEEE. Cette organisation a pour objectif de standardiser le développement des technologies orientées agent. Elle propose des normes et des spécifications pour l interaction entre agents et pour les systèmes orientés agent. Les spécifications de FIPA sont classées dans les catégories suivantes : communication entre agents, gestion des agents, transport d agents, architecture abstraite des applications orientées agent. Ces spécifications jouent un rôle d indications pour la conception et le développement des applications orientées agent. Elles aident aussi à augmenter l interopérabilité entre ces applications. La figure 1 est l architecture d une plate-forme d agent proposée par FIPA. Figure 1 - L architecture d une plate-forme d agent proposée par FIPA On voit que cette plate-forme se divise en plusieurs sous-systèmes comme : Agent, Agent Management System, Directory Facilitator, Message Transport System. Pour chacun de ces sous-systèmes, FIPA fournit plusieurs spécifications qui le décrivent. Parmi les spécifications de FIPA, nous nous intéressons aux spécifications qui concernent la communication d agent. Ces spécifications définissent les protocoles d interaction entre les agents. Les protocoles d interaction de FIPA sont des protocoles éprouvés pour 8

9 la communication d agent. Ils sont déjà implémentés dans quelques plate-formes d agent comme JADE, FIPA-OS, Un protocole d interaction est en fait une série de messages échangés entre des participants. La spécification du protocole stipule l ordre des messages que les participants doivent respecter. Les protocoles d interaction caractérisent différents scénarios de la communication. En se basant sur chaque situation concrète, le modélisateur emploie le protocole approprié. Les protocoles d interaction définis par FIPA sont FIPA Request, FIPA Query, FIPA Request When, FIPA Contract Net, FIPA Interated Contract Net, FIPA Brokering, FIPA Recruiting, FIPA Subscribe, FIPA Propose. Nous allons présenter en détail le protocole d interaction «FIPA Request». Pour le détail des autres protocoles, vous pouvez suivre le lien de FIPA donné dans la section bibliographie. Mais pour faciliter la présentation du protocole «FIPA Request», nous regardons maintenant la notion Message de FIPA. II.2.1. Message FIPA ACL Les agents réalisent des actions de communication en envoyant des messages et en les recevant. FIPA définit plusieurs attributs qu un message doit posséder. Les plateformes d agent qui implémentent la spécification de FIPA ne sont pas obligées d implémenter tous les attributs définis. L auteur de la plateforme peut choisir les attributs qui sont considérés comme convenable pour sa plateforme. Voici quelques attributs de message définis par FIPA : Sender : cet attribut indique l envoyeur du message. Receiver : cet attribut contient le nom (les noms) d un (des) récepteur(s) de message. Performative : cet attribut fait savoir le type de message. Normalement, la valeur de cet attribut donne une signification au message. FIPA définit une série de performatifs avec les significations correspondantes. Si vous vous intéressez, vous pouvez suivre le lien du document «FIPA Communicative Act Library Specification» qui se trouve dans la section bibliographie. Protocol : cet attribut indique le protocole d interaction que l envoyeur de message emploie pour envoyer ce message. Content : cet attribut contient le contenu du message. Conversation-id : cet attribut indique la conversation à laquelle ce message appartient. La notion de conversation est utilisée pour représenter le déroulement d un dialogue entre les agents. II.2.2. Protocole d interaction «FIPA Request» Dans cette partie, nous regardons en détail le protocole d interaction «FIPA Request» de FIPA. Ce protocole permet un agent à demander un autre agent à effectuer une certaine action. La représentation de ce protocole est donnée dans la figure 2. 9

10 Figure 2 - Protocole d interaction «FIPA Request» Dans un protocole d interaction, il y a deux types d agent : l initiateur (l agent qui initie le protocole) et le(s) participant(s). Le déroulement de ce protocole est comme suit : L initiateur commence le protocole en envoyant un message avec le performatif «request». En recevant ce premier message de l initiateur, le participant peut décider d accepter la demande ou de la refuser. Si le participant refuse la demande, il répond à l initiateur un message avec le performatif «refuse» et le protocole se termine. Si le participant accepte la demande, il communique cet accord à l initiateur en utilisant un message avec le performatif «agree». Après avoir accepté la demande, le participant effectue l action demandée. Quand le participant termine l exécution, il informe l initiateur en envoyant un message avec le performative «inform». Ou bien si l exécution a échoué, il informe l initiateur en utilisant un message avec le performatif «failure». Dans ce protocole, les messages avec les performatifs «refuse», «failure» ou «inform» du participant sont considérés comme des messages terminaux. Après avoir reçu un de ces messages, le protocole d interaction (ou bien la conversion correspondante) est donc considéré comme terminé. En se basant sur les spécifications des protocoles d interaction de FIPA, nous avons réalisé une implémentation de ces spécifications dans GAMA, qui est détaillée dans la section suivante. 10

11 III. L implémentation des protocoles d interaction de FIPA dans GAMA Comme nous l avons présenté dans l introduction, le travail de ce stage se divise en deux parties principales. La première partie a consisté à implémenter les protocoles d interaction de FIPA dans GAMA. Puis, dans la deuxième partie, la validation du fonctionnement de ces protocoles d interaction a été réalisée. Plus précisément, nous utilisons le travail de la première partie pour faire communiquer (et coordonner) des agents dans différents modèles. Dans cette partie, nous présentons l implémentation des protocoles d interaction de FIPA dans GAMA. III.1. Diagramme de classe Premièrement, nous présentons les classes principales de cette implémentation. Figure 3 - Les classes principales de l implémentation Agent : Cette classe est utilisée pour représenter un agent. Un agent peut participer à plusieurs conversations à la fois. Il peut jouer le rôle d un initiateur ou d un participant d une conversation. CommunicatingSkill : Cette classe définit les primitives qui servent à l envoi et à la réception des messages. Dans GAMA, on utilise la notion de Skill pour représenter une compétence particulière d un agent. Plusieurs classes ont été développées pour implémenter différentes compétences des agents. Par exemple, on a la classe CarryingSkill pour implémenter la compétence de porter des agents, la classe MovingSkill pour les compétences de déplacement, etc.. La classe CommunicatingSkill est donc développée pour la compétence de l envoi et de la réception des messages. Le modélisateur a besoin seulement de déclarer cette compétence pour les agents dans son modèle, et ses agents seront automatiquement dotés de tous les attributs et comportements nécessaires. IMessage : Cette interface définit les attributs d un message. Elle représente le morceau d information transmis entre les agents. On va décrire en détail cette classe dans la section qui suit. FIPAProtocol : Cette classe abstraite représente la notion de protocole d interaction de FIPA. Elle sert à vérifier si un message respecte la spécification d un protocole d interaction de FIPA ou pas. On va décrire en détail cette classe et ses sous-classes dans la section qui suit. 11

12 Conversation : cette classe représente une conversation/un dialogue entre les agents. Dans une conversation, les agents échangent les informations en envoyant les messages et en les recevant. Comme cela a déjà été décrit, il y a deux types d agent dans une conversation : un initiateur et un/des participant(s). Une conversation est commencée par un initiateur. La conversation suit un protocole d interaction défini par FIPA. Cela veut dire que les messages échangés entre l initiateur et le(s) participant(s) doivent respecter la structure du protocole d interaction actuellement employé. III.2. Structure d un «Message» Figure 4 - Structure d un message En se basant sur la spécification de FIPA, nous concevons notre propre classe de messages. Dans GAMA, un IMessage représente donc le morceau d information échangé entre les agents. Il se compose des attributs suivants : sender : cet attribut détermine l envoyeur du message. receivers : c est une liste qui contient le(s) récepteur(s) du message. content : c est une liste qui contient le contenu du message. On peut mettre n importe quel type de donnée dans cette liste. On laisse donc la liberté au modélisateur de manipuler le contenu du message dans son modèle. performative : cet attribut fait savoir la signification du message. FIPA définit une série de performatifs ainsi que les significations correspondantes. Pour plus d information, vous pouvez suivre le lien de FIPA donné dans la section bibliographie. conversation : un message appartient à une conversation. Une conversation suit un certain protocole d interaction. Cet attribut et l attribut «performative» servent donc à vérifier si le message échangé respecte bien le protocole d interaction actuellement employé. 12

13 III.3. Abstraction des protocoles d interaction Figure 5 - Les protocoles d interaction de FIPA implémentés dans GAMA La classe abstraite FIPAProtocol définit une méthode qui sert à vérifier si un message échangé respecte un protocole d interaction ou pas. FIPA fournit les protocoles d interaction comme : FIPA Request, FIPA Query, FIPA Request When, FIPA Contract Net, FIPA Interated Contract Net, FIPA Brokering, FIPA Subscribe, FIPA Propose. Pour chaque protocole, on décrit la structure de ce protocole dans une classe correspondante avec le même nom. Dans les classes de la figure ci-dessus, on voit la classe NoProtocol. Cette classe est spécifique à GAMA. Quand le modélisateur trouve que aucun protocole d interaction de FIPA n est convenable pour lui, il peut utiliser le protocole d interaction NoProtocol. Avec ce protocole, on peut envoyer et recevoir n importe quel message. Les performatifs des messages sont libres. Mais c est au modélisateur de terminer manuellement le protocole d interaction en utilisant le primitif «end» fourni par le CommunicatingSkill. Figure 6 - Modélisation d un protocole d interaction 13

14 On sait qu une Conversation suit un protocole d interaction. La classe correspondante a donc une référence à une sous-classe de FIPAProtocol qui détermine le protocole actuellement utilisé. Un protocole d interaction définit la série de messages autorisée. La question qui se pose maintenant est : comment peut-on modéliser la série de messages autorisée par un protocole d interaction? Pour le faire, on utilise la notion de ProtocolNode. Un ProtocolNode contient les méta-informations d un message. Pour chaque protocole d interaction, en se basant sur la structure définie dans la classe correspondante du protocole, on construit une liste de ProtocolNode. Cette liste contient les informations qui nous permettent de vérifier si un message échangé respecte bien un protocole d interaction ou pas. Un ProtocolNode se compose donc des attributs suivants : performative : cet attribut contient la valeur du performatif autorisé du message correspondant. sentbyinitiator : cet attribut détermine si le message correspondant est envoyé par l initiateur ou par un des participants. Si cette valeur est égale à vrai, le message correspondant vient de l initiateur. Sinon, il est envoyé par un des participants. followingnodes : cette liste contient les ProtocolNodes suivants autorisés par le protocole d interaction. Si cette liste est vide ou si la valeur de cet attribut est null, le ProtocoleNode actuel est le noeud terminal du protocole. Un protocole d interaction peut avoir plusieurs noeuds terminaux. Pour être plus clair, reconsidérons l exemple du protocole d interaction FIPA Request : nous regardons la série de message autorisée par ce protocole dans la figure suivante. 14

15 Figure 7 - Protocole d interaction FIPA Request A partir de la figure 7, on a la liste des ProtocolNodes correspondants. Numéro performative sentbyinitiator followingnodes 1 request true 2, 3 2 refuse false null 3 agree false 4, 5 4 failure false null 5 inform false null Tableau 1 - Listes des ProtocolNodes de FIPA Request Notons que l on a un seul noeud avec le performatif «inform». Dans la spécification de FIPA, on voit deux nœuds «inform» différents. Ils sont «inform-done» et «informresult». Mais grâce à notre conception de IMessage, l attribut contenu du message est une liste d objets. Cela veut dire que l on peut mettre n importe quelle donnée dans le contenu d un message, et qu on peut donc regrouper ces deux nœuds «inform» de FIPA en un seul nœud pour simplifier sa spécification. A partir de cet exemple, on peut voir que tous les protocoles d interaction de FIPA peuvent être modélisés en se basant sur l approche des ProtocolNodes. Si un message échangé ne respecte pas le protocole d interaction employé, on lèvera des exceptions. On a les exceptions suivantes (présentées dans la figure 6) : GamaException : C est une exception générique de GAMA. Une exception dans GAMA est une sous-classe directe ou indirecte de cette classe. 15

16 CommunicatingException : Cette exception est levée quand il y a une erreur générique de communication. ConversationFinishedException : Cette exception est levée quand un message est échangé dans une conversation déjà terminée. Une conversation est considérée comme terminée si un message terminal est échangé. Cela veut dire que, après qu un message terminal est échangé, l initiateur et le(s) participant(s) ne sont pas autorisés à échanger autres messages. Sinon cette exception sera levée. InvalidConversationException : cette exception est levée quand un message est échangé dans une conversation qui est différente de l attribut «conversation» du message. ProtocolErrorException : cette exception est levée quand le performatif du message actuel est différent du performatif autorisé par le protocole d interaction actuellement employé. UnknownProtocolException : cette exception est levée quand un message emploie un protocole d interaction qui n est pas reconnu par GAMA. III.4. Mécanisme d envoi et de réception d un message Dans cette section, nous regardons l itinéraire d un message de l envoyeur au récepteur. Considérons le diagramme de séquence suivant : Figure 8 - Itinéraire d un message de l envoyeur au récepteur L envoyeur commence ce processus en demandant à son CommunicatingSkill d envoyer un message. En recevant la demande de l envoyeur et toutes les informations nécessaires, le CommunicatingSkill crée une instance de Message et la met dans la liste des messages à envoyer de MessageBroker. Au cycle suivant de la simulation, le MessageBroker prendra les messages dans la queue d attente et fera deux choses suivantes avec chaque message : 1. Premièrement, on ajoute le message à la conversation correspondante : Si le message est le premier message d une conversation, on crée une nouvelle conversation avec le protocole d interaction déterminé et on met le message dans la nouvelle conversation. Si ce n est pas le premier message, on cherche la conversation correspondante du message et on le met dans la conversation trouvée. Le fait d ajouter un message à une conversation permet de vérifier si le message respecte 16

17 bien le protocole employé actuellement ou pas. On va détailler ce processus de vérification dans la section qui suit. 2. Deuxièmement, on ajoute le message à la liste des messages du récepteur. Chaque agent qui est capable de communiquer est doté d une liste qui joue le rôle d une boîte aux lettres. Cette liste contient les messages de l agent correspondant qui ne sont pas encore lus. Quand un agent lit un message dans sa boîte aux lettres, ce message est supprimé automatiquement par GAMA. Un agent communiquant possède aussi une liste de ses conversations actuellement en cours. Quand une conversation est terminée, cette conversation et tous les messages correspondants seront aussi supprimés automatiquement par GAMA. Le modélisateur n a donc pas besoin (sauf s il utilise le protocole NoProtocol) de gérer manuellement les messages. Quand un message arrive dans la boîte aux lettres d un agent, le modélisateur a toute la liberté de le lire et de traiter le contenu de ce message en implémentant le code GAML correspondant dans son modèle. III.5. Vérification d un message avec le protocole d interaction employé Comme nous l avons présenté, les classes Conversation, FIPAProtocol, les sous-classes de FIPAProtocol et ProtocolNode servent à vérifier si un message échangé respecte bien le protocole d interaction actuellement employé ou pas. Dans cette section, nous regardons comment un message est vérifié par rapport à son protocole d interaction. Nous considérons deux cas différents. Premièrement, le cas dans lequel le message respecte bien le protocole d interaction employé. Ce cas est décrit dans la figure suivante : Figure 9 - Un message respecte le protocole d interaction employé A chaque cycle de la simulation, le moteur de la simulation fait envoyer les messages dans la queue d attente du MessageBroker. Chaque message est ajouté à la conversation correspondante. Et la conversation fera une validation du message nouvellement ajouté par rapport au protocole d interaction que cette conversation suit. Plus précisément, elle fait des vérifications suivantes : 17

18 Vérifier le performatif du message par rapport aux performatifs autorisés par le protocole. Si le performatif du message n appartient pas aux performatifs autorisés pour le nœud suivant, un ProtocolErrorException sera levé. Si c est le premier message de la conversation, vérifier si le protocole employé est reconnu par GAMA. Si le protocole employé n est pas reconnu par GAMA, un UnknownProtocolException sera levé. Vérifier si la conversation actuelle est déjà terminée ou pas encore. Si un message est échangé dans une conversation déjà terminée, un ProtocolFinishedException sera levé. Si aucune exception n est levée, le message sera ajouté à la conversation correspondante et à la boîte aux lettres du récepteur. Si un des exceptions ci-dessus est levé, on aura le cas décrit dans la figure suivant. Figure 10 - Un message ne respecte pas le protocole d interaction employé III.6. Langage GAML GAML (GAMA Modelling Language) est un langage qui sert à écrire les modèles dans GAMA. C est un langage spécifique au domaine du multi-agent et de la modélisation, où tout est prévu pour simplifier le travail d un modélisateur. On utilise GAML pour modéliser les comportements des agents. La syntaxe de GAML s appuie sur une structure en XML. Alexis DROGOUL, responsable de ce stage, se charge de réaliser la conception et le développement de ce langage. Le développement de GAML se divise en deux tâches principales. Premièrement, écrire un compilateur. Deuxièmement, définir la syntaxe du langage. Dans ce rapport, nous ne présentons pas le détail de GAML. Si vous vous intéressez à ce langage, il existe un tutoriel détaillé sur le site web de GAMA. Nous nous concentrons plutôt sur le sujet du stage : la communication entre agents. Nous présentons donc dans la section suivante seulement les primitifs, les variables et les objets qu un agent est doté quand il est déclaré comme capable de faire la communication. III.6.1. Les primitifs, les variables, les objets d un agent communicant Quand le modélisateur déclare que son agent est capable de faire la communication, son agent est automatiquement doté des primitifs, des variables et des objets dans la classe CommunicationSkill. Concernant la syntaxe détaillée de GAML pour la déclaration de la 18

19 compétence de communication des agents, vous pouvez regarder le tutoriel en ligne qui se trouve sur le site web de GAMA. III Les primitifs En ce qui concerne les primitifs, nous avons fournit les primitifs qui aident les agents à envoyer et répondre les messages. Les primitifs de communication se divisent en deux catégories : les primitifs de base et les primitifs de haut-niveau. Deux primitifs de base sont send et reply. Ces deux primitifs servent respectivement à envoyer et répondre les messages. Les primitifs de haut-niveau sont agree, cancel, cfp, end, failure, inform, propose, query, refuse, rejectproposal, request, subscribe. Comme vous voyez, le nom de ces primitifs est identique avec le nom des performatifs définits par FIPA. Si vous vous intéressez aux spécifications détaillées des performatifs de FIPA, vous pouvez suivre le lien du document «FIPA Communicative Act Library Specification» qui se trouve dans la section bibliographie. Un primitif de haut-niveau est utilisé pour répondre à un message. L intérêt de ces primitifs est que le modélisateur ne doit pas fournir la valeur du performatif du message répondu. Cette valeur est remplie automatiquement en se basant sur le nom du primitif correspondant. Tous ces primitifs de haut-niveau ont deux arguments : message et content. message est le message à répondre et est un argument obligatoire. L envoyeur de l argument message joue le rôle du récepteur du message répondu. content est le contenu du message répondu et est un argument facultatif. Primitif «send» Ce primitif est employé pour envoyer un message. Les arguments de ce primitif sont comme suit : No Argument Obligatoire Signification 1 message non Le message à envoyer. 2 receivers oui Le(s) récepteur(s) du message. 3 content non Le contenu du message. 4 performative oui Le performatif du message. 5 protocol Le protocole d interaction que la conversation de ce message suit. Si le message à envoyer est le premier message d un protocole d interaction, le modélisateur doit fournir cet argument. Ca sert à créer une nouvelle conversation avec le protocole d interaction correspondant. Sinon, le modélisateur ne fournit pas cet argument. Cet argument et l argument «conversation» sont exclusifs. 6 conversation La conversation que ce message appartient. Si le message à envoyer n est pas le premier message d une conversation, le modélisateur doit fournir cet argument. Ca sert à ajouter le message correspondant à la bonne conversation. Sinon, le modélisateur ne 19

20 Primitive «reply» fournit pas cet argument. Cet argument est l argument «protocol» sont exclusifs. Tableau 2 Les arguments du primitif «send» Ce primitif est employé pour répondre à un message. Les arguments de ce primitif sont comme suit : No Argument Obligatoire Signification 1 message oui Le message à répondre. 2 performative oui Le performatif du message répondu. 3 content non Le contenu du message répondu. Les primitifs de haut-niveau Tableau 3 Les arguments du primitif «reply» No Primitif Signification 1 agree Répondre un message avec le primitif «agree». 2 cancel Répondre un message avec le primitif «cancel». 3 cfp Répondre un message avec le primitif «cfp». 4 end Répondre un message avec le primitif «end». 5 failure Répondre un message avec le primitif «failure». 6 inform Répondre un message avec le primitif «inform». 7 propose Répondre un message avec le primitif «propose». 8 query Répondre un message avec le primitif «query». 9 refuse Répondre un message avec le primitif «refuse». 10 rejectproposal Répondre un message avec le primitif «reject-proposal». 11 request Répondre un message avec le primitif «request». 12 subscribe Répondre un message avec le primitif «subscribe». Tableau 4 Les primitifs de haut-niveau III Les variables A côté des primitifs présenté ci-dessus, un agent communicant possède quelques variables supplémentaires. Ces variables sont les listes des messages recus d un agent communicant. L intérêt de ces variables est que à partir du code GAML du modèle, le modélisateur peut récupérer les messages dans la boîte aux lettres de l agent de façon simple. Ces variables sont présentés dans le tableau suivant : No Variable Signification 1 acceptproposals Une liste des messages avec le performatif «accept-proposal» de l agent correspondant. 20

21 2 agrees Une liste des messages avec le performatif «agree» de l agent correspondant. 3 cancels Une liste des messages avec le performatif «cancel» de l agent correspondant. 4 cfps Une liste des messages avec le performatif «cfp» de l agent correspondant. 5 failures Une liste des messages avec le performatif «failure» de l agent correspondant. 6 informs Une liste des messages avec le performatif «inform» de l agent correspondant. 7 proposes Une liste des messages avec le performatif «propose» de l agent correspondant. 8 queries Une liste des messages avec le performatif «query» de l agent correspondant. 9 refuses Une liste des messages avec le performatif «refuse» de l agent correspondant. 10 rejectproposals Une liste des messages avec le performatif «reject-proposal» de l agent correspondant. 11 requests Une liste des messages avec le performatif «request» de l agent correspondant. 12 requestwhens Une liste des messages avec le performatif «request-when» de l agent correspondant. 13 subscribes Une liste des messages avec le performatif «subscribe» de l agent correspondant. 14 messages Une liste de tous les messages dans la boîte aux lettres de l agent correspondant. 15 conversations Une liste de toutes les conversations en cours de l agent correspondant. Tableau 5 Les variables d un agent communicant III Les objets En plus des primitifs et des variables, un agent communicant est doté automatiquement deux types : message et conversation. Cela veut dire que le modélisateur peut manipuler les objets de ces deux types dans le code GAML de son modèle. Ou bien il peut utiliser les primitifs fournis par ces deux objets et accéder aux variables de ces deux objets. III.6.2. Exemple de GAML Dans cette section, nous vous présentons un exemple GAML. Nous avons implémenté une dizaine de protocole d interaction de FIPA dans GAMA. Mais par manque de place, nous présentons ici seulement le protocole d interaction «FIPA Request». L intérêt de cet exemple est seulement de montrer l utilisation de quelques primitifs de communication présenté ci-dessus. Nous n avons pas ambitieux de présenter tous les aspects du langage GAML. Nous ne présentons pas donc un modèle complet (seulement quelques fragments du code GAML concernant la communication). Reconsidérons le protocole d interaction «FIPA Request» dans la figure ci-dessous : 21

22 Figure 11 - Protocole d interaction FIPA Request Supposons que l on a deux agents qui s appellent «initiator» et «participant» respectivement. Ils participent à une conversation qui emploie le protocole d interaction «FIPA Request». L agent «initiator» joue le rôle de l initiateur du protocole. L agent «participant» joue le rôle du participant du protocole. Nous considérons les scénarios suivants du protocole «FIPA Request» : 1. Scénario 1 : L agent «initiator» demande à l agent «participant» de faire quelque chose mais l agent «participant» refuse la demande. 2. Scénario 2 : L agent «initiator» demande à l agent «participant» de faire quelque chose. L agent «participant» accepte la demande mais l exécution de l action demandée échoue. 3. Scénario 3 : L agent «initiator» demande à l agent «participant» de faire quelque chose. L agent «participant» accepte la demande et l exécution de l action demandée se termine avec succès. Ensuite, nous allons présenter le code source GAML de chaque scénario avec les explications correspondantes. III Scénario 1 L agent «initiator» envoie une demande à l agent «participant» <do action="send"> <arg name="receivers" value="[participant]" /> <arg name="protocol" value="'fipa-request'" /> <arg name="performative" value="'request'" /> <arg name="content" value="['aller dormir']" /> 22

23 L agent «initiator» commence le protocole d interaction «FIPA Request» en envoyant un message à l agent «participant» avec le contenu «aller dormir». Comme vous voyez, le primitif «send» est employé ici. Comme c est le premier message de la conversation, l argument «protocol» fait savoir le protocole d interaction employé. L argument «receivers» contient une liste des récepteurs. Dans ce cas, l agent «participant» est le seul récepteur du message. Le performatif du message est «request». C est le performatif initial du protocole d interaction «FIPA Request». L agent «participant» refuse la demande <do action="refuse"> <arg name="message" value="requestfrominitiator"/> <arg name="content" value="['je ne veux pas']" /> Supposons que le message «request» envoyé par l agent «initiator» se trouve dans la variable «requestfrominitiator». L agent «participant» refuse donc la demande de «initiator» en répondant un message avec le contenu «je ne veux pas». Le primitif «refuse» est employé. Un message avec le performatif «refuse» est donc envoyé par l agent «participant». C est un message terminal du protocole d interaction «FIPA Request», la conversation correspondante entre l agent «initiator» et l agent «participant» se termine. III Scénario 2 L agent «initiator» envoie une demande à l agent «participant» en utilisant le prmitif «send» avec les arguments nécessaire. <do action="send"> <arg name="receivers" value="[participant]" /> <arg name="protocol" value="'fipa-request'" /> <arg name="performative" value="'request'" /> <arg name="content" value="['aller dormir']" /> L agent «participant» accepte la demande <do action="agree"> <arg name="message" value="requestfrominitiator"/> <arg name="content" value="['je vais le faire']" /> En recevant la demande de l agent «initiator», l agent «participant» accepte la demande en répondant à l agent «initiator» un message avec le performative «agree». Le primitif «agree» est utilisé dans ce cas. Donc on ne doit pas fournir l argument «performative» avec la valeur «agree». L agent «participant» informe l agent «initiator» que l exécution de l action demandée a échoué. «failure» est un des performatifs terminaux de ce protocole, donc après l envoi de ce message, la conversation entre l agent «initiator» et l agent «participant» se termine. Dans ce cas, le contenu de la réponse contient la raison d échec. Attention : l attribut «content» est un argument facultatif. Le primitif «failure» est employé, donc le message une répondu a «failure» comme la valeur du performatif. <do action="failure"> 23

24 <arg name="message" value="requestfrominitiator"/> <arg name="content" value="['le lit est en panne']" /> III Scénario 3 L agent «initiator» envoie une demande à l agent «participant» en utilisant le primitif «send». <do action="send"> <arg name="receivers" value="[participant]" /> <arg name="protocol" value="'fipa-request'" /> <arg name="performative" value="'request'" /> <arg name="content" value="['aller dormir']" /> L agent «participant» accepte la demande et répond l initiator un message avec le performatif «agree» en employant le primitif «agree» <do action="agree"> <arg name="message" value="requestfrominitiator"/> <arg name="content" value="['je vais le faire']" /> L agent «participant» informe l agent «initiator» que l exécution de l action demandée se termine avec succès. Le primitif «inform» est employé pour faire la réponse. <do action="inform"> <arg name="message" value="requestfrominitiator"/> <arg name="content" value="['je me trouve dans le lit']" /> 24

25 IV. Validation dans le modèle «fourmis» IV.1. Le modèle «fourmis» original Le modèle «fourmis» original est le résultat du projet MANTA. Ce projet est une partie du travail de la thèse de doctorat de Alexis DROGOUL. Selon Alexis DROGOUL dans [3], «l'objectif du projet MANTA est de concevoir un modèle multi-agent d'une colonie de fourmis afin d'étudier les mécanismes de sociogenèse, de création de hiérarchies, de polyéthisme d'âge. Les comportements des fourmis sont exprimés sous la forme de tâches (enchaînements fixes d actions) ellesmêmes organisées dans une architecture de sélection d actions, EMF (EthoModeling Framework). La communication entre agents utilise la propagation de stimuli dans leur environnement commun, ces stimuli jouant le double rôle de déclencheurs de comportements et de guides pour la navigation des agents.» Alexis DROGOUL a re-implémenté dans GAMA une version simplifiée du modèle original. Ce modèle a une seule espèce qui s appelle «ants». Le comportement de cette espèce est très simple. Il est décrit dans le diagramme suivant : Figure 12 - Le comportement d une fourmi dans le modèle «fourmis» original La signification des variables booléennes est comme suit : No Variable Signification true false 1 placeactuelleavoirnourriture La place actuelle de la fourmi contient de la nourriture. La place actuelle de la fourmi ne contient pas de nourriture. 2 avoirsignalnourriture Une des places voisine de la fourmi a un signal de nourriture. Une des places voisine de la fourmi n a pas de signal de nourriture. 3 avoirnourriture La fourmi est en train de prendre la nourriture. La fourmi n est pas en train de prendre la nourriture. 4 aunid La fourmi est au nid. La fourmi n est pas au nid. 25

26 L explication de ce diagramme est donc comme suit : Tant que [(placeactuelleavoirnourriture = false) and (avoirsignalnourriture = false) and (avoirnourriture = false)], la fourmi se déplace aléatoirement sur l environnement. Tant que [(placeactuelleavoirnourriture = false) and (avoirsignalnourriture = false) and (avoirnourriture = false)], la fourmi suit le signal de la nourriture. Cela veut dire qu elle se déplace vers la case qui a l intensité du signal de nourriture la plus grande. Le signal est un mécanisme de communication dans lequel l environnement joue le rôle du médium de communication. Ce signal de nourriture aide les autres fourmis à aller chercher la nourriture. Dans ce cas, l intensité du signal diminue au cours du temps. Ceci modélise la notion de phéromone des fourmis et l évaporation des phéromones au cours du temps. Tant que [(placeactuelleavoirnourriture = true) and (avoirnourriture = false)], la fourmi prend la nourriture. Tant que [(avoirnourriture = true) and (aunid = false)], la fourmi se déplace vers son nid et met le signal de la nourriture sur l environnement. Tant que [(avoirnourriture = true) and (aunid = true)], la fourmi met la nourriture sur le nid. Le fonctionnement de ce modèle dans GAMA est montré dans la figure ci-dessous : Figure 13 - Le modèle «fourmis» original Dans la figure ci-dessus, on voit les cases qui contiennent la nourriture, les cas qui ont le signal de la nourriture, le nid et les fourmis. On a trois types de fourmis ou bien on voit trois états différents des agents de l espèce «ants». Les fourmis de type 1 sont les fourmis qui sont en train de se déplacer aléatoirement sur l environnement. 26

27 Les fourmis de type 2 sont les fourmis qui sont en train de suivre le signal de la nourriture. Les fourmis de type 3 sont les fourmis qui sont en train se déplacer vers son nid et met le signal de la nourriture, ou bien la phéromone de la fourmi, sur l environnement. L intensité du signal de la nourriture d une case est reflétée par la couleur de la case. Plus l intensité du signal d une case est grande, plus la couleur de la case correspondante est claire. IV.2. Le modèle «fourmis» avec la communication En se basant sur la version originale du modèle «fourmis» dans GAMA, nous reimplémentons ce modèle en utilisant des protocoles d interaction de FIPA. Au lieu d utiliser le signal et l environnement pour la communication, les agents vont maintenant échanger des messages. L intérêt de ce modèle est seulement de montrer le fonctionnement des protocoles d interaction de FIPA dans GAMA. Bien sûr que les vraies fourmis n utilisent pas ce mécanisme! IV.2.1. Fonctionnement du modèle Imaginons que l on a des «fourmis intelligentes» capables de faire de la communication en échangeant des messages. Dans cette version du modèle, on a deux espèces de fourmis qui s appellent «foodfinder» et «foodcarrier» respectivement. Les fourmis de l espèce «foodfinder» se chargent de se déplacer aléatoirement dans l environnement pour chercher la nourriture. Quand elles ont les informations concernant la nourriture, elles envoient ces informations aux fourmis de l espèce «foodcarrier» en utilisant les protocoles d interaction. En recevant les informations envoyées par un «foodfinder», les fourmis de l espèce «foodcarrier» se chargent d aller prendre la nourriture et de la déposer dans le nid. A chaque cycle de la simulation, les agents de l espèce «foodfinder» et l espèce «foodreceiver» font les choses suivantes : 27

28 Figure 14 - Le comportement d un «foodfinder» Selon la figure ci-dessus, à chaque cycle de la simulation, un foodfinder fait donc deux tâches suivantes : «communiquer avec les foodcarriers» : cette tâche sera détaillée dans la section qui suit. «se déplacer aléatoirement pour chercher la nourriture» : à chaque cycle de la simulation, la foodfinder choisit au hasard une case parmi ses huit cases voisins et se déplace dessus. Il vérifie si la case actuelle contient de la nourriture. Si oui, il envoie cette information aux foodcarriers. Figure 15 - Le comportement d un «foodcarrier» Selon la figure ci-dessus, à chaque cycle de la simulation, un foodcarrier fait deux tâches suivantes : 28

29 «communiquer avec les foodfinders» : cette communication sera détaillée dans la section qui suit. «aller prendre la nourriture et la déposer dans le nid» : si un foodcarrier a une information concernant la localisation de la nourriture, il ira la prendre et la déposer dans le nid. Si un foodfinder n a aucune information, il ne bouge pas. IV.2.2. La communication entre les agents «FIPA Contract Net» et «No Protocol» sont les deux protocoles d interaction employés pour implémenter la communication entre les foodfinders et les foodcarriers. Le choix de ces deux protocoles est totalement subjectif. Ce n est pas le meilleur choix. On peut bien entendu utiliser autre protocole comme «FIPA Request» pour résoudre ce problème. L implémentation de ces deux protocoles d interaction dans ce modèle est comme suit : Figure 16 - Protocole «FIPA Contract Net» dans le modèle «fourmis» Si une fourmi de l espèce «foodfinder» a des informations sur les positions qui contiennent la nourriture, elle commence la communication avec les fourmis de l espèce 29

30 «foodcarrier» en employant le protocole d interaction «FIPA Contract Net». Plus précisément, le foodfinder envoie un message avec le performative «cfp» pour démarrer un appel d offres. Quand un foodcarrier reçoit un message «cfp», s il est occupé, il répond avec un message «refuse». Un foodcarrier est considéré comme occupé s il a déjà envoyé un message «propose» à un foodfinder et s il n a pas reçu de message «reject-proposal» ou s il a une information sur la position de la nourriture. Sinon le foodcarrier répond au foodfinder avec un message «propose». Si tous les foodcarriers répondent avec un «refuse», le protocole d interaction se termine. Et le foodfinder continuera d envoyer un message «cfp» au cycle suivant de la simulation. Si au moins un foodcarrier répond avec un message «propose», le foodfinder répond au premier message «propose» avec un message «accept-proposal» et refuse tous les autres messages «propose» en envoyant un message «reject-proposal». En recevant un message «reject-proposal» de foodfinder, le foodcarrier correspondant est considéré comme disponible pour autres messages «cfp». En recevant un message «propose» du foodfinder, le foodcarrier lit la position de la nourriture dans le contenu du message et y va pour prendre la nourriture. Quand le foodcarrier trouve que la position envoyée par le foodfinder n a plus de nourriture, il envoie un message «inform» au foodfinder correspondant pour l informer ce fait et indiquer qu il est disponible. Le foodcarrier envoie alors un message «inform» aux autres foodfinders pour faire savoir à ces foodfinders qu il est disponible. Cette fois, le foodcarrier emploie le protocole d interaction «no-protocol». Figure 17 - Protocole «No Protocol» entre foodcarrier et foodfinder En recevant des messages «inform» du protocole d interaction «No Protocol» des foodfinders, le foodcarrier fait une mise à jours de la liste des foodfinders libres. Parce qu il envoie des messages «cfp» seulement aux foodfinders qu il considère comme libres. 30

31 IV.2.3. Le fonctionnement du nouveau modèle dans GAMA Figure 18 - Modèle «fourmis» avec la communication dans GAMA Dans la figure ci-dessus, on voit les deux types de fourmi : foodfinder et foodcarrier. Nous utilisons les images différentes pour les deux espèces et les différents états de l agent. Numéro Image Espèce Signification 1 foodfinder Un agent de l espèce foodfinder 2 foodcarrier Un agent de l espèce foodcarrier qui n a pas d information sur la nourriture. 3 foodcarrier Un agent de l espèce foodcarrier qui a l information sur la nourriture. 4 foodcarrier Un agent de l espèce foodcarrier qui est en train de porter la nourriture. Tableau 6 - Les images de fourmi Nous venons de présenter deux versions du modèle «fourmis». La première version utilise le signal comme mécanisme de communication. La deuxième version emploie deux protocoles d interactions FIPA Contract Net et «No Protocol» pour échanger des messages. L intérêt de la deuxième version est de montrer le fonctionnement des protocoles d interaction de FIPA dans GAMA dans un modèle simple. Dans la section suivante, nous allons présenter le fonctionnement des protocoles d interaction dans un modèle plus complexe. IV.3. Commentaire sur le fonctionnement de deux versions de «fourmis» Le fonctionnement de deux versions du modèle «fourmis» se base sur la communication entre les fourmis. La version originale utilise le signal et l environnement pour faire la 31

32 communication. Tandis que la nouvelle version emploie les protocoles d interaction de FIPA pour la communication. Dans la version originale, le signal est employé pour modéliser la phéromone des fourmis. La phéromone s évapore au cours du temps et se diminue en fonction de la distance. Si le nombre de fourmi est petit (moins que 10 fourmis par exemple), on ne voit pas la communication et/ou la coordination entre les fourmis. Parce que la phéromone mise par une fourmi s est évapore avant que autres fourmis puissent la percevoir et la suivre. Par contre, si le nombre de fourmis est suffisament grand (50 fourmis par exemple), on voit bien la communication et/ou la coordination entre les fourmis. Parce que dans ce cas si une fourmi met un signal, la possibilité que ce signal est percu par autres fourmis est plus grande. Et la quantité ainsi que l intensité du signal sur l environnement augmentent en fonction du nombre de fourmi. Dans la nouvelle version, les protocoles d interaction FIPA sont employés pour faire la communication. Bien entendu que avec ce modèle, l utilisant du signal est plus réaliste que l utisation des protocoles d interaction de FIPA. Dans la version originale, en raison de l évaporation de phéromone, parfois on perd l information. Avec cette version, la perte d information n existe plus. 32

33 V. Validation dans le modèle «AROUND» V.1. Modèle AROUND original Ce modèle est développé par CHU Thanh Quang dans sa thèse de doctorat. Ce modèle modélise les activités des secours terrestres après un tremblement de terre. Il se compose des espèces suivantes : Numéro Image Espèce Skills 1 ambulance Moving (implique situated), Carrying 2 Un agent de cet espèce hospital Situated, Carrying est représenté par un polygone. 3 victim Situated 4 fireman Moving 5 Un agent de cet espèce military Situated est représenté par un polygone. 6 fire Situated Tableau 7 - Les agents du modèle AROUND ambulance : un agent de cette espèce représente une ambulance. Sa tâche principale est d aller prendre les victimes sur le terrain puis de les déposer dans un hôpital. Une ambulance a une capacité qui représente le nombre de victimes qu elle peut contenir. hôpital : un agent de cette espèce représente un hôpital. Un hôpital se charge de prendre et de soigner les victimes déposées par les ambulances. victime : un agent de cette espèce représente une victime. Si une victime est sur le terrain, son état de santé s aggrave au cours du temps. Si une victime n est pas prise à l heure par une ambulance, elle meurt sur le terrain. Si une victime est dans une ambulance ou dans un hôpital, son état de la santé s améliore au fur et à mesure. fireman : un agent de cette espèce représente une voiture de pompiers. Elle est responsable d aller chercher les incendies et les éteindre. Cette espèce a un attribut qui représente la capacité d eau de chaque agent. La quantité d eau d un fireman diminue au cours du temps quand il éteint un incendie. Dès qu un fireman n a plus d eau, il va à une caserne pour prendre de l eau. military : un agent de cette espèce représente une caserne. Une caserne est responsable de fournir de l eau aux firemen. fire : un agent de cette espèce représente un incendie. Si un incendie n est pas pris en charge par des firemen, son intensité augmenté au cours du temps. Ou 33

34 inversement, l intensité d un incendie diminue en fonction du nombre de voitures des pompiers qui sont en train de l éteindre. Avec le modèle AROUND actuel, la modélisation de certaines situations pose problème. Premièrement, quand une ambulance veut aller chercher une victime, elle demande au «service de recherche de chemin de GAMA» la position d une victime. Ce service renvoie la position de la victime actuellement la plus proche de l ambulance. Il y a cependant des cas où plusieurs ambulances sont toutes proches d une même victime. Toutes iront donc chercher la même, ce qui n est pas très efficace, ni très réaliste. On a besoin donc d un mécanisme pour organiser une certaine coordination entre les ambulances. Figure 19 - Deux ambulances vont prendre une même victime Deuxièmement, le modèle utilise actuellement le signal comme mécanisme de diffusion de l information. Ca pose quelques problèmes: Une ambulance diffuse un signal dans un rayon prédéfini. Si une victime se trouve dans ce rayon, elle est considérée comme déjà dans l ambulance. Comme ça, son état de santé est augmenté, ce qui n est pas très correct. Parce que dans la réalité, la victime n est pas encore dans l ambulance. De la même façon, avec le signal de l hôpital, si une victime est proche d un hôpital, elle est considérée comme déjà dans l hôpital. Ce n est pas correct non plus. Si un incendie est dans le rayon du signal d une voiture de pompiers, on considère que cette voiture est en train d éteindre l incendie. Si plusieurs incendies sont dans le rayon du signal d une voiture de pompiers à la fois, on considère que cette voiture des pompiers est en train d éteindre ces incendies. Ce qui n est pas correct. Parce que dans la réalité, une voiture des pompiers ne peut prendre en charge qu un incendie à la fois. Troisièmement, au début de la simulation, les voitures des pompiers sont distribuées actuellement partout dans le plan. Dès le commencement de la simulation, chaque voiture des pompiers ira chercher l incendie qui est le plus proche d elle. Dans la réalité, les voitures des pompiers sont normalement gérées par des casernes. Et avant un 34

35 tremblement de terre, elles se trouvent dans les casernes. Dès qu un tremblement de terre a lieu, toutes les voitures des pompiers d une caserne iront éteindre le même incendie. Parce que avec les voitures des pompiers d une caserne (qui normalement se trouvent dans la même position), le «service de recherche de chemin» de GAMA renverra le même incendie. On voit que s il y a plusieurs incendies à la fois, il faut que l on distribue les voitures des pompiers entre ces incendies. Le point le plus irréaliste dans le modèle actuel est que normalement après un tremblement de terre, on ne connaît pas réellement l environnement. Notamment, on ne connaît pas les positions des victimes ni celle des incendies. Actuellement, on suppose que l on connaît tout l environnement, ce qui n est pas correct. Pour améliorer le modèle actuel, nous le modifions en ajoutons une espèce et la capacité de communication en utilisant les protocoles d interaction aux espèces actuelles. Et nous n utilisons plus le signal. Le choix des protocoles d interaction à utiliser dépend de chaque situation et de l expérience du modélisateur. Dans le cadre de ce modèle, les protocoles d interaction choisis permettent d implémenter la communication et la coordination entre les agents. L objectif est de montrer le fonctionnement des protocoles d interaction de FIPA et non pas de faire une version optimisée du modèle. Si le choix de certains protocoles entraine des envois superflus de messages, il permet de tester les protocoles en question. V.2. Modèle AROUND avec la communication Nous ajoutons une espèce qui s appelle «explorer». Un explorer se déplace dans l environnement. Il envoie les informations concernant les victimes et les incendies aux casernes. L organisation des espèces dans la nouvelle version du AROUND est donc comme suit : On divise les explorers en équipes. Chaque caserne a sa propre équipe d explorers. Dans le plan (du quartier BaDinh par exemple), on a plusieurs casernes. Une caserne se charge d une zone du plan. Dès que le tremblement de terre a lieu, la caserne demande à chaque explorer dans son équipe d aller faire une patrouille dans sa zone. Chaque explorer fait la patrouille sur des routes données par sa caserne. Quand l explorer voit des victimes ou des incendies, il envoie ces informations à sa caserne. Ci-dessous, c est la figure qui représente la relation entre une caserne (un agent de l espèce military) et son équipe d explorers. 35

36 Figure 20 - Relation entre military et explorer Deux protocoles d interaction «FIPA Request» et «No Protocol» sont employés pour implémenter la communication entre le military et l explorer. Premièrement, c est le protocole «FIPA Request». Figure 21 - Procotole d Interaction FIPA Request entre military et explorer Si un military veut qu un explorer fasse une patrouille, il commence le protocole en envoyant un message «request». Le contenu de ce message contient une liste des points à patrouiller. Si un explorer est occupé avec une patrouille en cours, il refuse la demande. 36

37 Le protocole se termine. S il est libre, il accepte la demande en répondant un message «agree». Quand la patrouille est terminée, l explorer envoie un message «inform» à son military pour l informer ce fait. Le protocole est donc terminé et l explorer devient libre pour d autres patrouilles. Deuxièmement, c est le protocole «No Protocol». Figure 22 - Protocole d Interaction «No Protocol» entre explorer et military Sur la route de la patrouille, si un explorer voit des victimes et des incendies sur le terrain, il envoie ces informations à son military en utilisant le protocole «No Protocol». A côté de l équipe des explorers, chaque military a aussi une équipe des firemen (les voitures des pompiers). Figure 23 - Relation entre military et fireman La communication entre l espèce military et l espèce fireman est réalisée en utilisant principalement le protocole d interaction FIPA Request. 37

38 Figure 24 - Protocole d Interaction FIPA Request entre military et fireman En recevant les informations sur les incendies envoyées par les explorers, le military demande aux firemen de son équipe d aller les éteindre. Il envoie cette demande en utilisant le procotole FIPA Request. Le military commence le protocole en envoyant le message avec le performatif «request». Si le fireman est occupé, il refuse la demande en répondant un message avec le performatif «refuse». S il est libre, il accepte la demande en répondant un message «agree». Quand l incendie est éteint, le fireman correspondant envoie un message «inform» à son military pour l informer de ce fait. Le protocole se termine. En ce qui concerne les informations concernant les victimes, le military envoie ces informations aux hôpitaux qui sont les plus proches de lui. Nous employons ce scénario parce que chaque military est responsable d une zone du plan. Cette zone se trouve autour du military correspondant. Les victimes découvertes par ses explorers sont donc des victimes qui se trouvent normalement autour du military. Ca nous aide à économiser le temps pour prendre les victimes vers les hôpitaux les plus proches. Nous utilisons deux protocoles d interaction pour implémenter la communication entre l espèce military et l espèce hospital. Premièrement, le protocole FIPA Request est employé par le military pour demander à un hospital son nombre de places disponible pour les victimes. Ce protocole est montré dans la figure suivante : 38

39 Figure 25 - Protocole d Interaction FIPA Request entre military et hospital Quand un military reçoit les informations des victimes envoyées par ses explorers, il fait la communication avec les hôpitaux pour savoir les places libres de chaque hôpital. En recevant la demande du military, chaque hôpital informe le military correspondant de son nombre de place disponible. Figure 26 - Protocole d Interaction «No Protocol» entre military et hospital Après avoir reçu les informations concernant les places disponibles des hôpitaux, le military distribue les victimes à prendre en charge aux hôpitaux. Le military donne une priorité plus haute aux hôpitaux qui sont les plus proches de lui. 39

40 Les ambulances sont aussi divisées en équipes. Chaque hôpital gère une équipe d ambulances. Cette relation est représentée dans la figure suivante : Figure 27 - Relation entre hospital et ambulance En recevant les informations sur les victimes envoyées par les militaries, un hôpital distribue le travail à ses ambulances. Un hôpital demande à une ambulance d aller prendre une victime en utilisant le protocole d interaction FIPA Request comme suit : Figure 28 - Protocole d Interaction FIPA Request entre ambulance et hospital 40

41 En recevant un message «request» de l hôpital, si une ambulance est occupée, elle refuse la demande en répondant un message «refuse». Si elle est libre, elle ira prendre la victime qui est le contenu du message «request». Quand l ambulance arrive à la position de la victime, si la victime est morte, l ambulance envoie un «refuse» à son hôpital pour l informer ce fait. Quand l ambulance arrive à la position de la victime, si la victime n est pas encore morte, L ambulance la prend. Puis elle envoie un message «agree» et un message «inform» à son hôpital pour informer qu elle a pris la victime demandée. Quand un hôpital reçoit les messages de ses ambulances informant les victimes déjà prises, l hôpital envoie ces informations aux autres hôpitaux pour les informer de ce fait en utilisant le procotole d interaction «No Protocol». Figure 29 - Protocole d Interaction «No Protocol» entre les hôpitaux En recevant les informations concernant les victimes déjà prises par les ambulances des autres hôpitaux. Un hôpital envoie ces informations aux ambulances dans son équipe en utilisant le «No Protocol» comme suit : Figure 30 - Protocole d Interaction «No Protocol» entre hospital et ambulance 41

42 En recevant les informations concernant les victimes déjà prises par les autres ambulances, si une ambulance est en train d aller prendre une victime déjà prise, elle s arrête et envoie un message «refuse» à son hôpital pour informer qu elle est disponible pour les autres victimes. Une ambulance peut contenir un nombre de victime prédéfini : si l ambulance est complète, elle revient à son hôpital pour déposer les victimes. Quand une ambulance arrive à son hôpital, si elle contient des victimes, elle les dépose. Puis elle demande à son hôpital de prendre les victimes en utilisant le protocole d interaction FIPA Request. Figure 31 - Protocole d Interaction FIPA Request entre hospital et ambulance Dans une situation comme après un tremblement de terre, l hôpital essayera de prendre toutes les victimes demandées. Il accepte donc toutes les demandes des ambulances. Quand un hôpital n a plus d information sur d éventuelles victimes, il demande à toutes ses ambulances de revenir chez lui pour déposer les victimes. Le protocole d interaction Request-When est employé pour demander aux ambulances de revenir dans son hôpital. 42

43 Figure 32 - Protocole d Interaction FIPA Request When entre hospital et ambulance V.3. Commentaire sur le fonctionnement de deux versions de «AROUND» Nous donnons dans cette cette section quelques commentaires concernant le fonctionnement de deux versions de «AROUND» pour voir la différence entre eux. Concernant la répartition des ambulances, dans la version originale de «AROUND», il existe pleins de cas que plusieurs ambulances vont chercher une même victime en même temps. Parce que le «moteur de recherche de GAMA» revoie une même victime pour les ambulances qui se trouvent proches l'un de l'autre. Donc le fonctionnement des ambulances n est pas efficace parce qu il n existe presque pas encore la coordination entre les ambulances. Dans la figure ci-dessous, nous donnons un scénario dans lequel cinq ambulances vont chercher une même victime en même temps. 43

44 Figure 333 Repartition des ambulances dans la version originale Par contre, dans la nouvelle version de «AROUND», les hôpitaux distribuent les victimes entre ces ambulances. Donc le cas que plusieurs ambulances vont chercher une même victime est presque éliminé. Si il a lieu, il est résolu de façon correcte en utilisant la communication. Comme nous présentons dans la figure ci-dessous, chaque ambulance va chercher une victime différente. Les lignes rouges d une ambulance vers une victime indiquent les victimes actuellements ciblées des ambulances. 44

45 Figure 34 Repartition des ambulances dans la nouvelle version En ce qui concerne la répartion des voitures des pompiers, dans la version originale, s il y a plusieurs voitures des pompiers qui sont proches l un de l autre et il y a plusieurs incendies en cours, ces voitures des pompiers vont chercher un même incendie. Les voitures des pompiers ne sont pas distribuées entre les incendies. De plus, s il existe plusieurs incendies dans le rayon du signal d une voiture des pompiers, on considère que cette voiture des pompiers est en train d éteindre ces incendies en même temps. Ce n est pas correct. La figure ci-dessous montre un scénario dans lequel cinquante voitures des pompiers vont chercher un même incendie en même temps. Et comme il y a quatre incendies qui se trouvent dans le rayon du signal de ces voitures des pompiers. Donc chaque voiture des pompiers est considérée comme «être en train d éteindre ces quatre incendies en même temps». 45

46 Figure 35 - Repartition des voitures des pompiers dans la version originale Dans la nouvelle version du «AROUND», grâce a la communication entre les casernes (l espèce «military») et les voitures des pompiers (l espèce «fireman»), les voitures des pompiers sont distribuées de façon égale entre les incendies. 46

47 Figure 36 - Repartition des voitures des pompiers dans la nouvelle version 47

48 VI. Conclusion et perspectives Nous venons de présenter le travail réalisé du stage. Ce travail se compose de deux parties principales : Partie 1 : Implantation des protocoles d interaction de FIPA dans la plate-forme GAMA. Partie 2 : Vérification du fonctionnement des protocoles d interaction de FIPA dans deux modèles. Dans la partie 1, à partir des spécifications de FIPA, nous avons fait la conception et l implémentation des protocoles d interaction de FIPA dans GAMA. Même si cela ne figure pas dans le rapport par manque de place, l ajout de ces fonctionnalités de communication nous a amené à travailler aussi sur la conception de la plate-forme ellemême et de son langage de modélisation, GAML. Concernant la partie 2, nous avons employé le travail de la partie 1 pour faire communiquer les agents dans certains modèles. Le but de cette partie était de vérifier le fonctionnement des protocoles d interaction de FIPA dans GAMA. Nous avons donc utilisé les protocoles d interaction dans deux modèles : le modèle «fourmis» et le modèle «AROUND». En ce qui concerne le modèle «fourmis», deux protocoles d interaction «FIPA Contract Net» et «No Protocol» ont été employés. Au lieu d employer le signal et l environnement pour la communication, les fourmis échangent les messages. L intérêt de ce modèle est seulement de montrer le bon fonctionnement des protocoles d interaction d un modèle simple. Pour le modèle AROUND, nous avons modifié la version originale du modèle, développée par Chu Thanh Quang, en ajoutant la capacité de communication aux agents et en utilisant des prococoles d interaction. L intérêt de cette modification est, non seulement, d augmenter le réalisme du modèle par l ajout de mécanismes de coordination, mais aussi de commencer à explorer les principes de base de la coopération multi-agent. En utilisant principalement les deux protocoles d interaction FIPA Request et FIPA Request When, nous voyons que nous avons déjà pu améliorer considérablement la coordination entre agents dans le modèle AROUND, et ainsi modéliser un peu plus correctement une situation réaliste (où les agents communiquent autrement que par l environnement). Evidemment, ce modèle est loin d être parfait, et il faudrait encore l améliorer en : - ajoutant des contraintes réalistes sur la communication (par exemple, des erreurs, etc.) - remplaçant le protocole FIPA Request entre ambulances et hôpitaux par le protocole FIPA Contract Net, afin que l hôpital puisse choisir la meilleure ambulance disponible (en fonction de sa capacité restante, de son autonomie, etc.) - ajoutant une possibilité pour les hôpitaux de refuser des victimes (s ils sont pleins) et de négocier avec d autres hôpitaux pour les prendre en charge. Beaucoup d autres améliorations sont possibles. 48

49 Par contre, en implémentant un mécanisme générique de communication (maintenant complètement intégré à GAMA dans sa version actuelle), nous avons donné la possibilité au modélisateur de pouvoir programmer facilement la communication entre des agents avec des primitifs de haut-niveau. En ce sens, nous pouvons considérer que l objectif initial de ce stage a été atteint. En ce qui concerne les perspectives, premièrerement, en utilisant le langage GAML pour écrire les modèles, nous trouvons que l environnement de développement actuel de GAMA n est pas très facile à utiliser. Notamment quand le modélisateur développe des modèles complexes, il a besoin d un vrai environnement de développement. Cet environnement devra fournir au modélisateur des fonctionnalités un peu comme un environnement de développement intégré (IDE, Integrated Development Environment) pour les langages de programmation d une part et les fonctionnalités spécifiques d une plate-forme de simulation orientée agents d autre part. De plus, GAMA est construit comme une plate-forme générique pour la modélisation et simulation des systèmes complexes. Cela veut dire que les utilisateurs finaux du GAMA seront les modélisateurs des différents domaines. Ces modélisateurs ne sont donc pas des informaticiens. Nous trouvons donc qu un environnement de développement intuitive et facile à utiliser est un des éléments qui décidera le succès de cette plate-forme. Si je continue à travailler dans le cadre du projet GAMA, je souhaiterais faire des recherches sur cet aspect de la modélisation. Une autre perspective concerne l ajout de nouvelles méthodes de coordination parmi celles présentées dans la littérature multi-agent. A priori, l architecture implémentée, dans la mesure où elle respecte pleinement les spécifications de FIPA, devrait permettre de rajouter de nouveaux protocoles, comme les protocoles d enchères, de négociation, etc. Il peut être utile, par exemple dans des domaines où l interaction est très codifiée (comme en économie), de pouvoir modéliser finement ces protocoles afin de permettre à GAMA d être utilisée dans d autres domaines. 49

50 Bibliographie [1] FIPA Communicative Act Library Specification [2] FIPA Request Interaction Protocol Specification [3] FIPA Query Interaction Protocol Specification [4] FIPA Request When Interaction Protocol Specification [5] FIPA Contract Net Interaction Protocol Specification [6] FIPA Iteracted Contract Net Interaction Protocol Specification [7] FIPA Brokering Interaction Protocol Specification [8] FIPA Subscribe Interaction Protocol Specification [9] FIPA Propose Interaction Protocol Specification [10] Alexis DROGOUL, Projet MANTA, [11] Alexis DROGOUL, Système Multi-agents situés, Dossier d habilitation à diriger des recherches de l Université Pierre et Marie Curie [12] Site web du projet GAMA, [13] Edouard AMOUROUX, CHU Thanh Quang, Alain Boucher, Alexis DROGOUL, GAMA: an environment for implementing and running spatially explicit multi-agents simulation, 10 th Pacific Internation Workshop on Multi-Agents, November 2007, Bangkok (Thailand). 50

51 Annexe Annexe A Code source du modèle «fourmis» avec la communication <?xml version="1.0" encoding="iso " standalone="yes"?> <!-- An example of the FIPA-ContractNet protocol. FIPA Specification : --> <ants> <modelclass name="msi.gama.kernel.simulation" /> <global> <!-- built-in variables --> <int name="time" init="0" max="10000" /> <int name="step" init="1 s" const="true" /> <int name="display_every" init="2" const="true" /> <bool name="fast_draw" init="false" const="true" /> <float name="seed" init="675" const="true" /> <int name="gridsize" init="75" const="true" min="30" max="200" /> <int name="ants_number" init="15" const="true" min="1" max="200" /> <point name="center" init="{int (gridsize / 2), int (gridsize / 2)}" const="true" /> <string name="file" init="'data/gaml/ants/images/environment' + (string gridsize) + 'x' + (string gridsize) + '.pgm'" const="true" /> <ant_grid name="nest_place" /> <rgb name="black" init="rgb 'black'" const="true" /> <rgb name="blue" init="rgb 'blue'" const="true" /> <rgb name="green" init="rgb 'green'" const="true" /> <rgb name="white" init="rgb 'white'" const="true" /> <rgb name="ff00ff" init="rgb 'gray'" const="true" /> <rgb name="c00cc00" init="rgb '#00CC00'" const="true" /> <rgb name="c009900" init="rgb '#009900'" const="true" /> <rgb name="c005500" init="rgb '#005500'" const="true" /> <rgb name="yellow" init="rgb 'yellow'" const="true" /> <rgb name="red" init="rgb 'red'" const="true" /> <rgb name="orange" init="rgb 'orange'" const="true" /> <string name="ant_foodcarrier_noinformation" init="'data/gaml/communication/foodcarrier_noinformation.png'" const="true" /> <string name="ant_foodcarrier_haveinformation" init="'data/gaml/communication/foodcarrier.png'" const="true" /> <string name="ant_foodcarrier_full" init="'data/gaml/communication/full_foodcarrier.png'" const="true" /> <string name="ant_foodfinder" init="'data/gaml/communication/foodfinder.png'" const="true" /> </global> <environment width="gridsize" height="gridsize"> <grid name="ant_grid" type="'square'" width="gridsize" height="gridsize" neighbours="8"> <bool name="multiagent" value="true" /> <int name="type" from="file" const="true" /> <bool name="isnestlocation" init="((self distance_to (translate center))) < 4" const="true" /> <bool name="isfoodlocation" init="type = 2" const="true" /> <rgb name="color" value="isnestlocation? FF00FF:((food > 0)? blue : C005500)" /> <int name="food" init="isfoodlocation? 5 : 0" /> <int name="nest" init="300 - (self distance_to (translate center))" /> <init if=" location = translate center"> <set var="nest_place" value="self" /> <do action="create" result="new_born_foodcarriers"> <string name="type" value="'foodcarrier'" /> <int name="number" value="ants_number" /> 51

52 <ask target="new_born_foodcarriers"> <set var="location" value="myself.location" /> </ask> <do action="create" result="new_born_foodfinders"> <string name="type" value="'foodfinder'" /> <int name="number" value="ants_number" /> <ask target="new_born_foodfinders"> <set var="location" value="myself.location" /> </ask> </init> </grid> </environment> <entities> <species name="foodfinder" skills="moving, visible, communicating"> <rgb name="color" init="green" const="true" /> <ant_grid name="place" value="ant_grid location" /> <string name="shape" init="ant_foodfinder" /> <float name="speed" init="1m/s" const="true" /> <float name="size" init="1.0" const="true" /> <!-- variables --> <list name="foodcarriers" init="agents where (each.species = 'foodcarrier')"/> <list name="freefoodcarriers" init="foodcarriers"/> <bool name="havingfreefoodcarriers" value="!(empty freefoodcarriers)"/> <list name="foodplaces" init="[]"/> <list name="placestosendcfp" init="[]"/> <bool name="havingplacestosendcfp" value="!(empty placestosendcfp)"/> <ant_grid name="currentplace"/> <int name="numberoffoodcarrierreceivingcfp" init="0"/> <int name="numberofproposefromfoodcarriers" init="0"/> <int name="numberofrefusefromfoodcarriers" init="0"/> <bool name="havingproposemsgsfromfoodcarriers" value="!(empty proposes)"/> <bool name="havingrefusemsgsfromfoodcarriers" value="!(empty refuses)"/> <list name="contractnetinformmsgs" value="informs where ((each.sender.species = 'foodcarrier') and (each.protocol = 'fipa-contract-net'))"/> <bool name="havingcontractnetinformmsgs" value="!(empty contractnetinformmsgs)"/> <list name="noprotocolinformmsgs" value="informs where ((each.sender.species = 'foodcarrier') and (each.protocol = 'no-protocol'))"/> <bool name="havingnoprotocolinformmsgs" value="!(empty noprotocolinformmsgs)"/> <!-- send a 'cfp' message --> <reflex name="send_a_cfp_message_reflex" when="havingplacestosendcfp and havingfreefoodcarriers and (currentplace = nil)"> <set var="currentplace" value="first placestosendcfp"/> <do action="send"> <arg name="receivers" value="freefoodcarriers"/> <arg name="protocol" value="'fipa-contract-net'"/> <arg name="performative" value="'cfp'"/> <arg name="content" value="[currentplace]"/> freefoodcarriers"/> currentplace"/> <set var="numberoffoodcarrierreceivingcfp" value="length <set var="numberofproposefromfoodcarriers" value="0"/> <set var="numberofrefusefromfoodcarriers" value="0"/> <set var="freefoodcarriers" value="[]"/> <set name="placestosendcfp" value="placestosendcfp - 52

53 </reflex> <!-- process the 'propose' messages from the foodcarrier --> <reflex name="process_propose_message_reflex" when="(currentplace!= nil) and havingproposemsgsfromfoodcarriers"> <let var="proposemsgs" value="proposes"/> <set var="numberofproposefromfoodcarriers" value="numberofproposefromfoodcarriers + (length proposemsgs)"/> <do action="debug"> <arg name="message" value="name + ' : (length proposemsgs) before = ' + proposemsgs + ' : process_propose_message_reflex'"/> proposemsgs)"/> <!-- accepts the proposition of the first foodcarrier --> <do action="accept-proposal"> <arg name="message" 0)"/> <arg name="content" value="[currentplace]"/> <set 0).unread" value="false"/> <set var="proposemsgs" value="proposemsgs - (first <do action="debug"> <arg name="message" value="name + ' : (length proposemsgs) after = ' + proposemsgs + ' : process_propose_message_reflex'"/> <!-- rejects the rest --> <if condition="!(empty proposemsgs)"> <do action="reject-proposal"> <arg name="message" value="proposemsgs"/> <let var="messageindex" value="0"/> <let var="looptimes" value="length proposemsgs"/> <loop times="looptimes"> <set messageindex).unread" value="false"/> + 1"/> </loop> <set var="messageindex" value="messageindex <!-- to make another FIPA Contract Net interaction be able to begin --> <if condition="(numberofproposefromfoodcarriers + numberofrefusefromfoodcarriers) = numberoffoodcarrierreceivingcfp"> <set var="currentplace" value="nil"/> </reflex> <!-- process the 'refuse' messages from the foodcarrier --> <reflex name="process_refuse_message_reflex" when="(currentplace!= nil) and havingrefusemsgsfromfoodcarriers"> <let var="refusemsgs" value="refuses"/> <set var="numberofrefusefromfoodcarriers" value="numberofrefusefromfoodcarriers + (length refusemsgs)"/> value="false"/> <let var="messageindex" value="0"/> <let var="looptimes" value="length refusemsgs"/> <loop times="looptimes"> <set messageindex).unread" <set var="messageindex" value="messageindex + 1"/> </loop> 53

54 <!-- to make another FIPA Contract Net interaction be able to begin --> <if condition="(numberofproposefromfoodcarriers + numberofrefusefromfoodcarriers) = numberoffoodcarrierreceivingcfp"> <if condition="(numberofrefusefromfoodcarriers = numberoffoodcarrierreceivingcfp) and!(currentplace in placestosendcfp)"> <set var="placestosendcfp" value="placestosendcfp + currentplace"/> </reflex> <set var="currentplace" value="nil"/> <!-- process the 'inform' messages from the foodcarrier (the 'inform' message of the FIPA Contract Net protocol) --> <reflex name="process_contract_net_inform" when="havingcontractnetinformmsgs"> <let var="messageindex" value="0"/> <loop times="length contractnetinformmsgs"> <if messageindex).sender) in freefoodcarriers)"> <set var="freefoodcarriers" value="freefoodcarriers + messageindex).sender)"/> <set messageindex).unread" value="false"/> <set var="messageindex" value="messageindex + 1"/> </loop> </reflex> <!-- process the 'inform' messages from the foodcarrier (the 'inform' message of the 'no-protocol' protocol) --> <reflex name="process_no_protocol_inform" when="havingnoprotocolinformmsgs"> <let var="messageindex" value="0"/> <loop times="length noprotocolinformmsgs"> <if messageindex).sender) in freefoodcarriers)"> <set var="freefoodcarriers" value="freefoodcarriers + messageindex).sender)"/> <set var="messageindex" value="messageindex + 1"/> </loop> <!-- end the conversations --> <do action="end"> <arg name="message" value="noprotocolinformmsgs"/> </reflex> <!-- move randomly searching for food. --> <reflex name="move_randomly_searching_for_food"> <do action="wander"> <int name="amplitude" value="120" /> <float name="distance" value="1" /> foodplaces)"> place"/> </reflex> </species> <!-- food found --> <if condition="(place.food > 0) and!(place in <set name="foodplaces" value="foodplaces + place"/> <set name="placestosendcfp" value="placestosendcfp + 54

55 <species name="foodcarrier" skills="moving, visible, communicating" control="emf"> <ant_grid name="place" value="ant_grid location" /> <string name="shape" init="ant_foodcarrier_noinformation" /> <float name="speed" init="1m/s" const="true" /> <float name="size" init="1.0" const="true" /> <!-- variables --> <bool name="carryingfood" init="false" /> <ant_grid name="foodplace" init="nil" /> <bool name="findfood" value="(foodplace!= nil) and (!carryingfood)"/> <bool name="gohome" value="carryingfood and!(place.isnestlocation)"/> <bool name="dropfood" value="carryingfood and (place.isnestlocation)"/> <conversation name="currentcontractnetinteraction" init="nil"/> <list name="cfpmsgsfromfoodfinders" value="cfps where (each.sender.species = 'foodfinder')"/> <bool name="havingcfpmsgsfromfoodfinders" value="!(empty cfpmsgsfromfoodfinders)"/> <bool name="havingacceptproposalsfromfoodfinders" value="!(empty acceptproposals)"/> <bool name="havingrejectproposalsfromfoodfinders" value="!(empty rejectproposals)"/> <action name="eat"> <set var="shape" value="ant_foodcarrier_full" /> <set var="carryingfood" value="true" /> <set var="place.food" value="place.food - 1" /> </action> <action name="turn"> <set var="heading" value="heading - 180" /> <return value="heading" /> </action> <!-- having foodinformation and not carrying food --> <task name="findfood"> <priority if="findfood" value="20" else="0"/> <duration max="2 hours" /> <run while="findfood"/> <repeat action="goto"> <arg name="target" value="foodplace"/> </repeat> <if condition="!((foodplace.food) > 0)"> <!-- finish the Contract Net Interaction Protocol -- > <do action="send"> <arg name="receivers" value="[(currentcontractnetinteraction.initiator)]"/> <arg name="performative" value="'inform'"/> <arg name="conversation" value="currentcontractnetinteraction"/> <!-- inform others foodfinders that I'm free! --> <let var="othersfoodfinders" value="agents where (((each.species) = 'foodfinder') and (each!= (currentcontractnetinteraction.initiator)))"/> <if condition="!(empty othersfoodfinders)"> <do action="send"> <arg name="receivers" value="othersfoodfinders"/> <arg name="protocol" value="'noprotocol'"/> <arg name="performative" value="'inform'"/> 55

56 <set var="currentcontractnetinteraction" value="nil"/> <set var="shape" value="ant_foodcarrier_noinformation"/> <set var="foodplace" value="nil"/> </task> <else> <do action="eat"/> </else> <!-- carryingfood then go home to drop food --> <task name="gohome"> <priority if="gohome" value="20" else="0"/> <duration max="2 hours" /> <run while="gohome"/> <repeat action="goto"> <arg name="target" value="nest_place" /> </repeat> </task> <!-- I'm at the nest then drop food --> <task name="dropfood"> <priority if="dropfood" value="20" else="0"/> <duration max="2 hours" /> <run while="dropfood"/> <!-- drop food --> <set var="carryingfood" value="false" /> <set var="shape" value="ant_foodcarrier_haveinformation" /> <do action="turn" /> </task> <!-- receive 'cfp' message --> <reflex name="foodfinder_receive_cfp_msg_reflex" when="havingcfpmsgsfromfoodfinders"> <if condition="currentcontractnetinteraction = nil"> <let var="cfpmsg" value="first cfpmsgsfromfoodfinders"/> <!-- accept the first cfp --> <do action="propose"> <arg name="message" value="cfpmsg"/> <set var="currentcontractnetinteraction" value="cfpmsg.conversation"/> <set var="cfpmsg.unread" value="false"/> <set var="cfpmsgsfromfoodfinders" value="cfpmsgsfromfoodfinders - cfpmsg"/> <!-- refuse the rest "cfp" messages --> <if condition="!(empty cfpmsgsfromfoodfinders)"> <do action="refuse"> <arg name="message" value="cfpmsgsfromfoodfinders"/> <let var="messageindex" value="0"/> <let var="looptimes" value="length cfpmsgsfromfoodfinders"/> <loop times="looptimes"> <set messageindex).unread" value="false"/> 56

57 + 1"/> </reflex> </loop> <set var="messageindex" value="messageindex <!-- receive 'accept-proposal' message --> <reflex name="foodfinder_receive_accept_proposal_msg_reflex" when="havingacceptproposalsfromfoodfinders"> <let var="acceptmsg" value="first acceptproposals"/> <set var="acceptmsg.unread" value="false"/> <set var="shape" value="ant_foodcarrier_haveinformation"/> <set var="foodplace" 0" /> </reflex> <!-- receive 'reject-proposal' message --> <reflex name="foodfinder_receive_reject_proposal_msg_reflex" when="havingrejectproposalsfromfoodfinders"> <let var="rejectmsgs" value="rejectproposals"/> value="false"/> <let var="looptimes" value="length rejectmsgs"/> <let var="messageindex" value="0"/> <loop times="looptimes"> <set messageindex).unread" <if messageindex).conversation) = currentcontractnetinteraction"> <set var="currentcontractnetinteraction" value="nil"/> <set var="messageindex" value="messageindex + 1"/> </loop> = 'foodfinder')"/> <!-- inform all the foodfinders that I'm free --> <let var="foodfinders" value="agents where ((each.species) <if condition="!(empty foodfinders)"> <let var="looptimes" value="length foodfinders"/> <set var="messageindex" value="0"/> <loop times="looptimes"> <do action="send"> <arg name="receivers" messageindex)]"/> <arg name="protocol" value="'noprotocol'"/> <arg name="performative" value="'inform'"/> + 1"/> </reflex> </species> </entities> </loop> <set var="messageindex" value="messageindex <output> <display name="grille" type="grid" environment="ant_grid" fast_draw="fast_draw" refresh_every="2" /> <monitor name="foodcarriers carryingfood" value="(agents where ((each.species = 'foodcarrier') and (each.carryingfood))) sort_by each.index" refresh_every="2"/> <monitor name="foodcarriers not carryingfood" value="(agents where ((each.species = 'foodcarrier') and!(each.carryingfood))) sort_by each.index" refresh_every="2"/> 57

58 <monitor name="foodcarriers with foodplace" value="(agents where ((each.species = 'foodcarrier') and ((each.foodplace)!= nil))) sort_by each.index" refresh_every="2"/> <monitor name="foodcarriers without foodplace" value="(agents where ((each.species = 'foodcarrier') and ((each.foodplace) = nil))) sort_by each.index" refresh_every="2"/> <monitor name="foodcarriers searching for food" value="(agents where ((each.species = 'foodcarrier') and ((each.findfood)))) sort_by each.index" refresh_every="2"/> <monitor name="number of place with food" value="places count (each.food > 0)" refresh_every="2" /> <monitor name="places with food" value="places where (each.food > 0)" refresh_every="2" /> </output> </ants> 58

59 Annexe B Code source du modèle AROUND avec la communication ambulance.xml <?xml version="1.0" encoding="iso " standalone="yes"?> <around> <entities> <species name="ambulance" skills="visible, moving, carrying, communicating" control="emf" globalpathfinder="true"> const="true"/> <!-- built-in variables --> <string name="shape" init="'data/gaml/around/icons/ambulance.png'" <rgb name="color" value="hasvictim? purple : teal"/> <float name="size" init="1" const="true"/> <float name="speed" min="0" max="maxspeed" init="0" /> <!-- variables --> <float name="min_fuel" init="2" const="true"/> <float name="max_fuel" init="100" const="true"/> <float name="fuel" init="100" min="0" max="max_fuel" show_color="aqua"/> <int name="speed" init="0"/> <int name="capacity" init="ambulancecapacity"/> <int name="victim_number" value="length contents" min="0" max="capacity" show_color="olive"/> <bool name="isfull" value="victim_number = capacity"/> <bool name="hasvictim" value="victim_number > 0"/> <conversation name="currentrequestinteractionwithhospital" init="nil"/> <!-- messages of the "No Protocol" protocol --> <list name="noprotocolinformmsgsfromowner" value="informs where ((each.protocol = 'no-protocol') and (each.sender = owner))"/> <bool name="havingnoprotocolinformmsgsfromowner" value="!(empty noprotocolinformmsgsfromowner)"/> <!-- messages of the FIPA Request protocol --> <list name="requestmsgsfromhospital" value="requests where ((each.protocol='fipa-request') and (each.sender.species = 'hospital'))"/> <!-- the ambulance is currently at the entrance of its hospital, waiting for the hospital loading the victims --> <bool name="waitinghospitalloadvictim" init="false"/> <bool name="havingrequestwhenmsgsfromhospital" value="!(empty requestwhens)"/> <bool name="findvictim" value="!isfull and (currentvictim!= nil) and!waitinghospitalloadvictim"/> <bool name="gotohospital" value="(havingrequestwhenmsgsfromhospital or isfull) and!waitinghospitalloadvictim and (currentvictim = nil)"/> <bool name="readrequestmsgsfromhospital" value="!isfull and!havingrequestwhenmsgsfromhospital and (currentvictim = nil) and!(empty requestmsgsfromhospital) and!waitinghospitalloadvictim"/> <victim name="currentvictim" init="nil"/> <hospital name="owner" init="nil"/> <reflex name="ambulance_is_busy" when="(currentvictim!= nil) or (gotohospital) or waitinghospitalloadvictim or isfull"> <if condition="!(empty requestmsgsfromhospital)"> <let var="messageindex" value="0"/> <loop times="length requestmsgsfromhospital"> <do action="refuse"> <arg name="message" messageindex"/> 59

60 <arg name="content" messageindex).content"/> value="messageindex+1"/> </reflex> </loop> <set var="messageindex" <!-- the hospital (owner) informs that some victims have just been picked up by ambulances (of other hospitals). --> <reflex name="having_noprotocol_inform_msgs_from_owner" when="havingnoprotocolinformmsgsfromowner"> <!-- verify if my current victim has already been taken by another ambulance? --> <if condition="currentvictim!= nil"> <let var="looptimes" value="length noprotocolinformmsgsfromowner"/> <let var="messageindex" value="0"/> <let var="takenvictims" value="[]"/> <loop while="(messageindex < looptimes) and (currentvictim!= nil)"> <set var="takenvictims" messageindex).content"/> <if condition="(takenvictims!= nil) and (currentvictim in takenvictims)"> <!-- my current victim has just been taken by another ambulance --> <do action="send"> <arg name="receivers" value="[(currentrequestinteractionwithhospital.initiator)]"/> <arg name="performative" value="'refuse'"/> <arg name="conversation" value="currentrequestinteractionwithhospital"/> <arg name="content" value="[currentvictim,'pickedupbyother']"/> <set var="currentvictim" value="nil"/> <set var="currentrequestinteractionwithhospital" value="nil"/> value="messageindex+1"/> </loop> <set var="messageindex" <!-- end the conversations --> <do action="end"> <arg name="message" value="noprotocolinformmsgsfromowner"/> </reflex> <!-- when the ambulance receives the request message(s) from the hospital informing the places of victims. --> <reflex name="read_request_messages_from_hospital" when="readrequestmsgsfromhospital"> <let var="requestmsg" value="first 0" /> <if condition="requestmsg!= nil"> <!-- accept the first 'request' message --> <set var="currentvictim" value="(requestmsg.content) 60

61 value="requestmsg.conversation"/> <set var="currentrequestinteractionwithhospital" 1"> requestmsgsfromhospital) - 1"> messageindex" /> messageindex).content" /> <!-- refuse others 'request' messages. --> <if condition="(length requestmsgsfromhospital) > <let var="messageindex" value="1"/> <loop times="(length <do action="refuse"> <arg name="message" <arg name="content" value="messageindex+1"/> </reflex> </loop> <set var="messageindex" <!-- when the ambulance has the information of a victim then... --> <task name="goto_victim"> <priority if="!isfull and (currentvictim!= nil) and!waitinghospitalloadvictim" value="10" else="0"/> <duration max="2 hours" /> <run while="!isfull and (currentvictim!= nil) and!waitinghospitalloadvictim"/> <repeat action="decoratedgoto"> <arg name="target" value="currentvictim"/> <arg name="speed" value="80 kmh" /> <arg name="linecolor" value="'#ff0000'"/> </repeat> hospital --> deathgravityofvictim)"> the victim is died. --> <!-- if the victim dies, then inform this reality to <if condition="!((currentvictim.gravity) < <!-- a 'refuse' message informing the hospital that <do action="send"> <arg name="receivers" value="[(currentrequestinteractionwithhospital.initiator)]"/> <arg name="performative" value="'refuse'"/> <arg name="conversation" value="currentrequestinteractionwithhospital"/> <arg name="content" value="[currentvictim,'died']"/> <else> <!-- the victim is still alive, then pick it up --> <!-- eliminate the case that two ambulances try to load the same victim at the same time? --> <if condition="!currentvictim.inambulance"> <ask target="currentvictim"> <set var="inambulance" value="true"/> </ask> value="[currentvictim]"/> <do action="load"> <arg name="agents" 61

62 <!-- inform the hospital --> <do action="send"> <arg name="receivers" value="[(currentrequestinteractionwithhospital.initiator)]"/> <arg name="performative" value="'agree'"/> <arg name="conversation" value="currentrequestinteractionwithhospital"/> value="[currentvictim]"/> capacity"> value="informmsgcontent + 'full'"/> <let var="informmsgcontent" <if condition="(length contents) = <set var="informmsgcontent" <else> var="informmsgcontent" value="informmsgcontent + 'notfull'"/> </else> <do action="send"> <arg name="receivers" value="[(currentrequestinteractionwithhospital.initiator)]"/> <arg name="performative" value="'inform'"/> <arg name="conversation" value="currentrequestinteractionwithhospital"/> <arg name="content" value="informmsgcontent"/> <set </else> value="nil"/> <set var="currentrequestinteractionwithhospital" <set var="currentvictim" value="nil"/> </task> <task name="goto_hospital"> <priority if="gotohospital" value="20" else="0"/> <duration max="2 hours" /> <run while="gotohospital"/> <repeat action="decoratedgoto"> <arg name="target" value="owner"/> <arg name="speed" value="80 kmh"/> <arg name="linecolor" value="'#00ff00'"/> </repeat> <!-- the ambulance is now at the entrance of the hospital then it drops all the victims. --> <reflex name="ambulance_drops_victims"> <if condition="!(empty contents)"> <do action="drop" result="carriedvictims"/> <if condition="(carriedvictims!= nil) and!(empty carriedvictims)"> <!-- assuming that when the ambulance drops all its victims at the entrance of the hospital, the hospital will pick up all these victims. --> <ask target="carriedvictims"> 62

63 value="true"/> </ask> <set var="inhospital" value="false"/> value="true"/> value="[owner]"/> value="'fipa-request'"/> value="'request'"/> value="carriedvictims"/> <ask target="carriedvictims"> <set var="inambulance" </ask> <set var="waitinghospitalloadvictim" <do action="send"> <arg name="receivers" <arg name="protocol" <arg name="performative" <arg name="content" value="requestwhens"/> value="requestwhens"/> </reflex> </task> <if condition="havingrequestwhenmsgsfromhospital"> <do action="agree"> <arg name="message" <do action="inform"> <arg name="message" <!-- the hospital informs the ambulance that it has just finished loading all victims. --> <reflex name="hospital_finish_loading_victims" when="waitinghospitalloadvictim"> <if condition="!(empty (informs where (each.sender.species = 'hospital')))"> <set var="waitinghospitalloadvictim" value="false"/> </reflex> </species> </entities> </around> environment.xml <?xml version="1.0" encoding="iso " standalone="yes"?> <around> <environment width="5 km" height="4 km"> <gis type="openmap" name="badinh" pathfinder="static"> <layer name="road" isref="true" shapefile="'data/gaml/around/with_communication/version5/gis/road.shp'" linecolor ="'#000000'" fillcolor="'000000'" /> <layer name="hospital" isref="false" shapefile="'data/gaml/around/with_communication/version5/gis/hospital.shp'" linecolor="'#000000'" fillcolor="'008000'" /> <layer name="military" isref="false" shapefile="'data/gaml/around/with_communication/version5/gis/militaire_police.shp'" linecolor="'#000000'" fillcolor="'800000'" /> </gis> </environment> </around> 63

64 explorer.xml <?xml version="1.0" encoding="iso " standalone="yes"?> <around> <entities> <species name="explorer" skills="visible, communicating, exploring" control="emf" globalpathfinder="true"> <!-- GIS related informations --> <!-- <gis_layer name="data/gis/fireman.shp" /> --> <terrain name="'road'" speed_max="maxspeed" /> <terrain name="'hospital'" speed_max="(150 kmh) / 20" /> <terrain name="'military'" speed_max="(150 kmh) / 20" /> <!-- built-in variables --> <string name="shape" init="'data/gaml/around/icons/police- 256x256.png'" const="true"/> <float name="size" init="1" const="true"/> <float name="speed" min="0" max="maxspeed" init="0" /> <float name="range" init="200" const="true"/> <! m --> <bool name="showperception" init="true" const="true"/> <rgb name="perceptionalcolor" init="'#ff00ff'" const="true"/> <!-- variables --> <float name="min_fuel" init="2" const="true"/> <float name="max_fuel" init="20" const="true"/> <float name="fuel" init="max_fuel" min="0" max="max_fuel" show_color="aqua"/> <military name="owner" init="nil"/> <list name="requestmsgsfrommilitary" value="requests where ((each.sender = owner) and (each.protocol = 'fipa-request'))"/> <bool name="havingrequestmsgsfrommilitary" value="!(empty requestmsgsfrommilitary)"/> <bool name="readytopatrol" value="(points!= nil) and!(empty points)"/> <bool name="receiverequestmsgsfrommilitary" value="!readytopatrol and havingrequestmsgsfrommilitary"/> <bool name="patroltheterrain" value="readytopatrol and (currentpointindex < (length points)) and!findfuel and!gohome"/> <bool name="findfuel" value="(fuel < min_fuel) and!gohome"/> <bool name="gohome" value="!(empty (requests where ((each.protocol='no-protocol') and (each.sender = owner))))"/> <bool name="ismoving" value="patroltheterrain findfuel"/> <conversation name="currentrequestinteractionwithmilitary" init="nil"/> <!-- the victims that I have already seen on my way --> <list name="alreadyinformedvictims" init="[]"/> <list name="newvictims" value="neighbours where ((each.species = 'victim') and (each.gravity > 0) and (each.gravity < deathgravityofvictim) and!(each.inambulance) and!(each.inhospital) and!(each in alreadyinformedvictims))"/> <!-- the fires that I have already seen on my way --> <list name="alreadyinformedfires" init="[]"/> <list name="newfires" value="neighbours where ((each.species = 'fire') and (each.level > 0) and!(each in alreadyinformedfires))"/> <!-- reflexes --> <!-- process the request messages from the militaries informing the partitions to explore/patrol --> <reflex name="receive_request_msgs_from_military" when="receiverequestmsgsfrommilitary"> <let var="requestmsg" value="first requestmsgsfrommilitary"/>!= nil)"> value="requestmsg.content"/> <if condition="(requestmsg!= nil) and (requestmsg.content <let var="receivedpoints" 64

65 value="requestmsg.conversation"/> receivedpoints)"> receivedpoints"/> <set var="currentrequestinteractionwithmilitary" <if condition="(receivedpoints!= nil) and!(empty <let var="looptimes" value="length <let var="mypoints" value="[]"/> (point_closest_to i))"/> <let var="i" value="0"/> <loop times="looptimes"> <set var="mypoints" value="mypoints + <set var="i" value="i+1"/> </loop> <set var="points" value="mypoints"/> <!-- <do action="debug"> <arg name="message" value="name + ' : (length points) = ' + (length points) + ' : receive_request_msgs_from_military'"/> --> value="[requestmsg]"/> --> value="[requestmsg]"/> value="['the received list is empty']"/> <do action="agree"> <arg name="message" <else> <!-- the received points is empty!!! </else> <do action="refuse"> <arg name="message" <arg name="content" <!-- refuses other requests --> <if condition="(length requestmsgsfrommilitary) > 1"> <do action="refuse"> <arg name="message" value="requestmsgsfrommilitary - requestmsg"/> </reflex> <!-- if the explorer is having a partition to explore/patrol then refuses all the request messages from the military --> <reflex name="refuses_requests_from_hospital" when="readytopatrol"> <do action="refuse"> <arg name="message" value="requestmsgsfrommilitary where (each.conversation!= currentrequestinteractionwithmilitary)"/> </reflex> --> <!-- when the explorer has a partition then it explores it/patrols <task name="patrol_the_terrain" while="patroltheterrain"> <priority if="patroltheterrain" value="10" else="0"/> <duration max="2 hours"/> <repeat action="patrol"> <arg name="speed" value="maxspeed"/> </repeat> 65

66 <!-- informs the hospital that the explorer has just finished the patrol on the givens points --> <do action="send"> <arg name="receivers" value="currentrequestinteractionwithmilitary.initiator"/> <arg name="performative" value="'inform'"/> <arg name="conversation" value="currentrequestinteractionwithmilitary"/> <set var="currentrequestinteractionwithmilitary" value="nil"/> appropriately --> > <!-- update the variables of the ExploringSkill <set var="points" value="[]"/> <set var="currentpointindex" value="0-1"/> <!-- bug here -- <do action="debug"> <arg name="message" value="name + ' : end patrolling one partition ' + ' : patrol_the_terrain'"/> </task> <!-- no more fuel, go home to fill fuel --> <task name="fill_fuel" while="findfuel"> <priority if="findfuel" value="20" else="0"/> <duration max="2 hours"/> <repeat action="decoratedgoto"> <arg name="target" value="owner"/> <arg name="speed" value="maxspeed"/> <arg name="linecolor" value="'#ff0000'"/> </repeat> <set var="fuel" value="max_fuel"/> </task> <task name="go_home" while="gohome"> <priority if="gohome" value="20" else="0"/> <duration max="2 hours"/> <repeat action="decoratedgoto"> <arg name="target" value="owner"/> <arg name="speed" value="maxspeed"/> <arg name="linecolor" value="'#0000ff'"/> </repeat> <!-- end the conversations. --> <do action="end"> <arg name="message" value="requests where ((each.protocol='no-protocol') and ((each.sender.name) = (owner.name)))"/> </task> my military --> victims --> informationtype) + newvictims"/> <!-- on my way, whenever I see the victims or fires, I will inform <reflex name="send_information_to_owner" when="patroltheterrain"> <if condition="!(empty newvictims)"> <let var="informationtype" value="'1'"/> <!-- <let var="msgcontent" value="[]"/> <set var="msgcontent" value="(msgcontent + <do action="send"> <arg name="receivers" value="[owner]"/> <arg name="protocol" value="'no-protocol'"/> <arg name="performative" value="'inform'"/> <arg name="content" value="msgcontent"/> 66

67 <set var="alreadyinformedvictims" value="alreadyinformedvictims + newvictims"/> --> informationtype) + newfires"/> <if condition="!(empty newfires)"> <let var="informationtype" value="'2'"/> <!-- fires <let var="msgcontent" value="[]"/> <set var="msgcontent" value="(msgcontent + <do action="send"> <arg name="receivers" value="[owner]"/> <arg name="protocol" value="'no-protocol'"/> <arg name="performative" value="'inform'"/> <arg name="content" value="msgcontent"/> <set var="alreadyinformedfires" value="alreadyinformedfires + newfires"/> </reflex> <reflex name="fuel_reduce" if="ismoving"> <set var="fuel" value="fuel "/> </reflex> </species> </entities> </around> fire.xml <?xml version="1.0" encoding="iso " standalone="yes"?> <around> <entities> <species name="fire" skills="situated,visible" control="emf"> <!-- GIS related informations --> <gis_layer name="data/gaml/around/with_communication/version5/gis/fire.shp"/> <terrain name="'road'" speed_max="maxspeed"/> <terrain name="'school'" speed_max="(150 kmh) / 20" /> <!-- built-in variables --> <string name="shape" init="'data/gaml/around/icons/fire.png'"/> <rgb name="color" value="yellow" const="true"/> <float name="size" value="level"/> <!-- variables --> <float name="level" init="0.5"/> <float name="speed" init="0"/> <list name="firemen" init="[]"/> <bool name="isbeingextinguished" value="!(empty firemen)"/> <!-- reflexes --> <reflex name="died" if="level < (float 0)"> <set var="shape" value="'dot'"/> </reflex> <reflex name="increase" when="!isbeingextinguished and (level > (float 0))"> <set var="speed" value="speed "/> : the purpose of this variable? --> <set var="level" value="level "/> </reflex> (float 0))"> firemen))"/> <reflex name="reduce" when="isbeingextinguished and!(level < <set var="level" value="level - (0.001 * (length 67

68 </reflex> </species> </entities> </around> fireman.xml <?xml version="1.0" encoding="iso " standalone="yes"?> <around> <entities> <species name="fireman" skills="visible, moving, communicating" control="emf" globalpathfinder="true"> <!-- GIS related informations --> <gis_layer name="data/gaml/around/with_communication/version5/gis/fireman.shp"/> <terrain name="'road'" speed_max="maxspeed"/> <terrain name="'military'" speed_max="(150 kmh) / 20"/> <terrain name="'hospital'" speed_max="(150 kmh) / 20"/> <!-- built-in variables --> <string name="shape" init="'data/gaml/around/icons/fireescape.png'" const="true"/> <rgb name="color" init="'#00ff00'" const="true"/> <float name="size" init="1"/> <float name="range" init="50" const="true"/> <!-- the fireman see fires in the range of 50m --> <!-- variables --> <military name="owner" init="nil"/> <list name="fires" init="[]"/> <fire name="currentfire" init="nil"/> <list name="alreadydiedfires" init="[]"/> <bool name="athome" init="true"/> <int name="min_water" init="10" const="true"/> <int name="max_water" init="waterleveloffireman"/> <float name="min_fuel" init="2" const="true"/> <float name="max_fuel" init="10" const="true"/> <float name="fuel" init="max_fuel" min="0" max="max_fuel" show_color="aqua"/> <int name="water" init="waterleveloffireman" min="0" max="waterleveloffireman" show_color="silver"/> <int name="speed" init="0"/> <bool name="isextinguishing" init="false"/> <bool name="needfuel" value="fuel < min_fuel"/> <bool name="needwater" value="water < min_water"/> <bool name="findwater" value="needwater and!needfuel"/> <bool name="findfire" value="!needwater and!needfuel and!isextinguishing and (currentfire!= nil)"/> <bool name="ismoving" value="needfuel findwater findfire"/> <!-- the 'request' message (of the 'fipa-request' protocol) from my owner requesting me to extinguish a fire --> <list name="requestrequestmsgsfrommilitary" value="requests where ((each.sender.name = owner.name) and (each.protocol = 'fipa-request'))"/> <bool name="havingrequestrequestmsgsfrommilitary" value="!(empty requestrequestmsgsfrommilitary)"/> <!-- the 'inform' messages (of the 'no-protocol' protocol) from my owner informing that some fires have just been extinguished --> <list name="noprotocolinformmsgsfrommilitary" value="informs where ((each.sender = owner) and (each.protocol = 'no-protocol'))"/> <bool name="havingnoprotocolinformmsgsfrommilitary" value="!(empty noprotocolinformmsgsfrommilitary)"/> init="nil"/> <conversation name="currentrequestinteractionwithmilitary" 68

69 <reflex name="look_around_for_fires"> <let var="nearbyfires" value="neighbours where ((each.species = 'fire') and (each!= currentfire) and!(each in fires) and!(each in alreadydiedfires) and (each.level > 0))"/> <if condition="(nearbyfires!= nil) and!(empty nearbyfires)"> <set var="fires" value="nearbyfires + fires"/> </reflex> <!-- read the inform messages from military informing the already extinguished fires. --> <reflex name="having_noprotocol_inform_msgs_from_military" when="havingnoprotocolinformmsgsfrommilitary"> <let var="looptimes" value="length noprotocolinformmsgsfrommilitary"/> <let var="messageindex" value="0"/> <let var="informmsgcontent" value="nil"/> <let var="diedfires" value="[]"/> <loop times="looptimes"> <set var="diedfires" messageindex).content"/> <if condition="(diedfires!= nil) and!(empty diedfires)"> <set var="fires" value="fires - diedfires"/> <set var="alreadydiedfires" value="alreadydiedfires + (diedfires where!(each in alreadydiedfires))"/> <set var="messageindex" value="messageindex+1"/> </loop> <!-- in case, I'm out of water while extinguishing a fire and going to the nearest military for water, and if others firemen have just finished extinguishing my current fire, then... --> <if condition="(currentfire!= nil) and (currentfire in alreadydiedfires)"> <ask target="currentfire"> <set var="firemen" value="firemen - myself"/> </ask> <set var="isextinguishing" value="false"/> <!-- inform my military that a fire has just been extinguished --> <if condition="currentrequestinteractionwithmilitary!= nil"> <do action="send"> <arg name="receivers" value="[(currentrequestinteractionwithmilitary.initiator)]"/> <arg name="performative" value="'inform'"/> <arg name="conversation" value="currentrequestinteractionwithmilitary"/> <arg name="content" value="[currentfire]"/> <set var="currentrequestinteractionwithmilitary" value="nil"/> value="[owner]"/> <else> <do action="send"> <arg name="receivers" 69

70 value="'no-protocol'"/> value="'inform'"/> value="[currentfire]"/> </else> <arg name="protocol" <arg name="performative" <arg name="content" <set var="currentfire" value="nil"/> <!-- end the conversations --> <do action="end"> <arg name="message" value="noprotocolinformmsgsfrommilitary"/> </reflex> <!-- let the "requested fires" from the military (owner) have a higher priority than my already known fires. --> <reflex name="receive_request_msgs_from_military" when="havingrequestrequestmsgsfrommilitary"> <let var="messageindex" value="0"/> <loop while="(currentfire = nil) and (messageindex < (length requestrequestmsgsfrommilitary))"> <if condition="(currentfire = nil) and!((fire 0)) in alreadydiedfires)"> <let var="requestmsg" messageindex"/> <set var="currentfire" value="(fire 0))"/> <set var="fires" value="fires - currentfire"/> <set var="currentrequestinteractionwithmilitary" value="requestmsg.conversation"/> value="requestmsg"/> <do action="agree"> <arg name="message" <set var="requestrequestmsgsfrommilitary" value="requestrequestmsgsfrommilitary - messageindex)"/> <set var="messageindex" value="messageindex+1"/> </loop> <!-- refuse the "unnecessary" requests --> <set var="messageindex" value="messageindex"/> <loop times="(length requestrequestmsgsfrommilitary)"> <do action="refuse"> <arg name="message" messageindex)"/> <arg name="content" messageindex).content"/> <let var="messageindex" value="messageindex+1"/> </loop> </reflex> <!-- reflexes --> <reflex name="water_reduce" if="isextinguishing"> <set var="water" value="water - 1"/> </reflex> <!-- tasks --> 70

71 <!-- when the fireman is out of water, then go to the nearest military (not necessary the owner) to fill water. --> <task name="fill_water"> <priority if="needwater" value="10" else="0"/> <duration max="2 hours" /> <run while="needwater"/> myself"/> <set var="isextinguishing" value="false"/> <if condition="currentfire!= nil"> <ask target="currentfire"> <set var="firemen" value="firemen - </ask> <repeat action="decoratedgoto"> <arg name="target" value="owner" /> <arg name="speed" value="maxspeed" /> <arg name="linecolor" value="'#ff00ff'"/> </repeat> <set var="water" value="max_water"/> </task> <task name="goto_fire"> <priority if="(currentfire!= nil) and!isextinguishing and!needwater" value="20" else="0"/> <duration max="2 hours" /> <run while="(currentfire!= nil) and!isextinguishing and!needwater"/> <set var="athome" value="false"/> <repeat action="decoratedgoto"> <arg name="target" value="currentfire" /> <arg name="speed" value="maxspeed" /> <arg name="linecolor" value="'#0000ff'"/> </repeat> <set var="isextinguishing" value="true"/> <ask target="currentfire"> <set var="firemen" value="firemen + myself"/> </ask> </task> <!-- if the fireman does not have any information of fires from the military and he does not see any fires on his road then... --> <task name="go_home"> <priority if="(currentfire = nil) and!(havingrequestrequestmsgsfrommilitary) and (empty fires) and!athome" value="20" else="0"/> <duration max="2 hours" /> <run while="(currentfire = nil) and!(havingrequestrequestmsgsfrommilitary) and (empty fires) and!athome"/> <!-- inform the military that I'm free --> <do action="send"> <arg name="receivers" value="[owner]"/> <arg name="protocol" value="'no-protocol'"/> <arg name="performative" value="'inform'"/> <arg name="content" value="['free']"/> <!-- go home --> <repeat action="decoratedgoto"> <arg name="target" value="owner"/> <arg name="speed" value="maxspeed"/> <arg name="linecolor" value="'#00ff00'"/> </repeat> <set var="athome" value="true"/> <set var="water" value="max_water"/> </task> 71

72 <reflex name="finish_extinguish" when="isextinguishing and (currentfire!= nil) and!((currentfire.level) > (float 0)) and!needwater"> <ask target="currentfire"> <set var="firemen" value="firemen - myself"/> </ask> <set var="isextinguishing" value="false"/> <!-- inform my military that a fire has just been extinguished --> <if condition="currentrequestinteractionwithmilitary!= nil"> <do action="send"> <arg name="receivers" value="currentrequestinteractionwithmilitary.initiator"/> <arg name="performative" value="'inform'"/> <arg name="conversation" value="currentrequestinteractionwithmilitary"/> <arg name="content" value="[currentfire]"/> <set var="currentrequestinteractionwithmilitary" value="nil"/> <arg name="protocol" value="'no- value="[owner]"/> protocol'"/> value="'inform'"/> value="[currentfire]"/> <else> </else> <do action="send"> <arg name="receivers" <arg name="performative" <arg name="content" + currentfire"/> <if condition="!(currentfire in alreadydiedfires)"> <set var="alreadydiedfires" value="alreadydiedfires <if condition="currentfire in fires"> <set var="fires" value="fires - currentfire"/> <set var="currentfire" value="nil"/> </reflex> <!-- if the fireman does not have any information of fires from the military then but he sees some fires on his road then.. --> <reflex name="check_for_known_fires" when="(currentfire = nil) and!(havingrequestrequestmsgsfrommilitary)"> <if condition="!(empty fires)"> <set var="currentfire" value="first fires"/> <set var="fires" value="fires - (first fires)"/> </reflex> </species> </entities> </around> hospital.xml <?xml version="1.0" encoding="iso " standalone="yes"?> <around> <entities> <species name="hospital" skills="carrying, communicating, visible, situated"> <gis_layer name="data/gaml/around/with_communication/version5/gis/hospital.shp" /> 72

73 <!-- built-in variables --> <int name="radius" init="0" const="true"/> <!-- variables --> <int name="capacity" init="100" const="true"/> <int name="service_rate" init="10" const="true"/> <rgb name="color" init="'#808000'" const="true"/> <int name="victim_number" value="length contents"/> <bool name="hasvictim" value="victim_number > 0"/> <bool name="isfull" value="victim_number = capacity"/> <list name="freeambulances" init="[]"/> <bool name="havingfreeambulances" value="!(empty freeambulances)"/> <list name="alreadysentrequestvictims" init="[]"/> <list name="deathvictims" init="[]"/> <list name="victimsneedambulance" init="[]"/> : sort this list by 'victim.gravity' --> <bool name="havingvictims" value="!(empty victimsneedambulance)"/> <!-- inform messages from others hospitals (using "no-protocol" interaction protocol) informing the positions of victims --> <list name="noprotocolinformmsgsfromothershospitals" value="informs where ((each.protocol='no-protocol') and (each.sender!= self) and (each.sender.species = 'hospital'))"/> <list name="victimstakenbyothershospitals" init="[]"/> <!-- messages of the 'fipa-request' Interaction Protocol with ambulance --> <list name="requestrefusemsgsfromambulances" value="refuses where ((each.protocol = 'fipa-request') and (each.sender.species = 'ambulance'))"/> <list name="requestinformmsgsfromambulances" value="informs where ((each.protocol = 'fipa-request') and (each.sender.species = 'ambulance'))"/> <list name="requestmsgsfromambulances" value="requests where (each.sender.species = 'ambulance')"/> <bool name="requestvictims" value="havingvictims and havingfreeambulances"/> <bool name="havingrequestrefusemsgsfromambulances" value="!(empty requestrefusemsgsfromambulances)"/> <bool name="havingrequestinformmsgsfromambulances" value="!(empty requestinformmsgsfromambulances)"/> <bool name="havingnoprotocolinformmsgsfromothershospitals" value="!(empty noprotocolinformmsgsfromothershospitals)"/> <!-- request messages of the 'fipa-request' Interaction Protocol with military --> <list name="requestrequestmsgsfrommilitary" value="requests where ((each.protocol = 'fipa-request') and (each.sender.species = 'military'))"/> <bool name="havingrequestrequestmsgsfrommilitary" value="!(empty requestrequestmsgsfrommilitary)"/> <!-- inform messages of the 'no-protocol' Interaction Protocol with military --> <list name="noprotocolinformmsgsfrommilitary" value="informs where ((each.sender.species = 'military') and (each.protocol = 'no-protocol'))"/> <bool name="havingnoprotocolinformmsgsfrommilitary" value="!(empty noprotocolinformmsgsfrommilitary)"/> <!-- each hospital has a team of ambulances --> <init> <if condition="numberofambulanceperhospital > 0"> <create species="ambulance" number="numberofambulanceperhospital" result="myambulances"/> <ask target="myambulances"> 73

74 value="myself.location"/> </ask> <set name="owner" value="myself"/> <set name="location" myambulances"/> </init> <set var="freeambulances" value="freeambulances + <!-- the "inform" message sent from other hospitals informing the victims picked up by their ambulances --> <reflex name="having_noprotocol_inform_msgs_from_others_hospitals" when="havingnoprotocolinformmsgsfromothershospitals"> <let var="takenvictims" value="[]"/> <let var="looptimes" value="length noprotocolinformmsgsfromothershospitals"/> <let var="messageindex" value="0"/> <loop times="looptimes"> <set var="takenvictims" value="takenvictims + messageindex).content) where!(each in takenvictims))"/> <let var="messageindex" value="messageindex + 1"/> </loop> <if condition="!(empty takenvictims)"> <!-- update internal lists --> <set var="victimsneedambulance" value="victimsneedambulance - takenvictims"/> <set var="victimstakenbyothershospitals" value="victimstakenbyothershospitals + (takenvictims where!(each in victimstakenbyothershospitals))"/> <!-- inform my ambulances --> <let var="busyambulances" value="(agents where ((each.species = 'ambulance') and (each.owner = self))) - freeambulances"/> <if condition="!(empty busyambulances)"> <do action="send"> <arg name="receivers" value="busyambulances" /> <arg name="protocol" value="'noprotocol'" /> <arg name="performative" value="'inform'" /> <arg name="content" value="takenvictims" /> <!-- end the conversations --> <do action="end"> <arg name="message" value="noprotocolinformmsgsfromothershospitals"/> <if condition="empty victimsneedambulance"> <do action="send"> <arg name="receivers" value="agents where ((each.species = 'ambulance') and (each.owner = self))" /> <arg name="protocol" value="'fipa-requestwhen'" /> <arg name="performative" value="'requestwhen'" /> </reflex> 74

75 <!-- the "refuse" messages (of the 'fipa-request' Interaction Protocol) sent from my ambulances. --> <reflex name="having_request_refuse_msgs_from_ambulances" when="havingrequestrefusemsgsfromambulances"> <let var="refusedvictim" value="nil"/> <let var="requestrefuses" value="refuses where ((each.protocol = 'fipa-request') and (each.sender.species = 'ambulance'))"/> <let var="looptimes" value="length (requestrefuses)"/> <let var="messageindex" value="0"/> <loop times="looptimes"> <!-- <let var="msgcontent" messageindex).content"/> --> <let var="msgcontent" messageindex).content"/> <set var="refusedvictim" 0"/> <set var="alreadysentrequestvictims" value="alreadysentrequestvictims - refusedvictim"/> <if condition="(length msgcontent) = 1"> <!-- the ambulance is busy searching for another victim. --> <if condition="!(refusedvictim in victimstakenbyothershospitals)"> <if condition="!(refusedvictim in victimsneedambulance)"> <set var="victimsneedambulance" value="victimsneedambulance + refusedvictim"/> the victim because he has already been died. --> 'died') and!(refusedvictim in deathvictims)"> value="deathvictims + refusedvictim"/> messageindex).sender"/> <else> <!-- the ambulance refuses to pick up <if 1) = <set var="deathvictims" <let var="refusingambulance" <if condition="(refusingambulance!= nil) and!(refusingambulance in freeambulances)"> <set var="freeambulances" value="freeambulances + refusingambulance"/> </else> <set var="messageindex" value="messageindex+1"/> </loop> <!-- if we don't have the information of victims anymore, then request our ambulances to go home. --> <if condition="empty victimsneedambulance"> <do action="send"> <arg name="receivers" value="agents where ((each.species = 'ambulance') and (each.owner = self))"/> <arg name="protocol" value="'fipa-requestwhen'"/> <arg name="performative" value="'requestwhen'"/> 75

76 </reflex> <!-- inform messages of the 'fipa-request' Interaction Protocol from ambulances informing their state. --> <reflex name="having_request_inform_msgs_from_ambulances" when="havingrequestinformmsgsfromambulances"> <let var="takenvictim" value="nil"/> <let var="ambulancestate" value="nil"/> <let var="messageoriginators" value="[]"/> <let var="originator" value="nil"/> <let var="messagecontent" value="[]"/> <let var="victimstakenbymyambulances" value="[]"/> <let var="looptimes" value="length requestinformmsgsfromambulances"/> <let var="messageindex" value="0"/> <loop times="looptimes"> : BUG : this loop is not entered because (looptimes == 0), the "inform messages" have already been removed by the CommunicatingSkill --> <set var="originator" messageindex).sender"/> <set var="messagecontent" messageindex).content"/> <set var="takenvictim" 0"/> <set var="ambulancestate" 1"/> in messageoriginators)"> value="messageoriginators + originator"/> <if condition="(originator!= nil) and!(originator <set var="messageoriginators" <if condition="((ambulancestate = 'notfull') or (ambulancestate = 'pickedupbyother'))"> <if condition="(originator!= nil) and!((ambulance originator) in freeambulances)"> <set var="freeambulances" value="freeambulances + (ambulance originator)"/> <if condition="(ambulancestate = 'notfull') or (ambulancestate = 'full')"> <set var="victimstakenbymyambulances" value="victimstakenbymyambulances + takenvictim"/> <set var="messageindex" value="messageindex+1"/> </loop> <set var="victimsneedambulance" value="victimsneedambulance - victimstakenbyothershospitals"/> <if condition="empty victimsneedambulance"> <do action="send"> <arg name="receivers" value="(agents where ((each.species = 'ambulance') and (each.owner = self)))"/> <arg name="protocol" value="'fipa-requestwhen'"/> <arg name="performative" value="'requestwhen'"/> picked up some victims --> <!-- informs others hospitals that our ambulances have just 76

77 <let var="othershospitals" value="(agents where (each.species = 'hospital')) - self"/> <if condition="(othershospitals!= nil) and!(empty othershospitals) and!(empty victimstakenbymyambulances)"> <do action="send"> <arg name="receivers" value="(agents where (each.species = 'hospital')) - self"/> <arg name="protocol" value="'no-protocol'"/> <arg name="performative" value="'inform'"/> <arg name="content" value="victimstakenbymyambulances"/> <reflex name="send_request_message_to_ambulances" when="!(empty victimsneedambulance) and!(empty freeambulances)"> <let var="numberofvictim" value="length victimsneedambulance"/> <let var="numberoffreeambulances" value="length freeambulances"/> <let var="looptimes" value="(numberofvictim > numberoffreeambulances)? numberoffreeambulances : numberofvictim"/> <loop times="looptimes"> <do action="send"> <arg name="receivers" value="[(first freeambulances)]"/> <arg name="protocol" value="'fiparequest'"/> <arg name="performative" value="'request'"/> <arg name="content" value="[(first victimsneedambulance)]"/> <set var="alreadysentrequestvictims" value="alreadysentrequestvictims + (victim (first victimsneedambulance))"/> <set var="victimsneedambulance" value="victimsneedambulance - (first victimsneedambulance)"/> <set var="freeambulances" value="freeambulances - (first freeambulances)"/> </loop> </reflex> <!-- on receiving the "request" messages from my ambulances, pick up the victims at the entrance --> <reflex name="hospital_pick_up_victims" when="!(empty requestmsgsfromambulances)"> <let var="victimlist" value="[]"/> <let var="messageindex" value="0"/> <let var="looptimes" value="length requestmsgsfromambulances"/> <!-- build the a list of victims waiting to be loaded --> <loop times="looptimes"> <let var="currentvictimlist" messageindex).content"/> <if condition="(currentvictimlist!= nil) and!(empty currentvictimlist)"> <set var="victimlist" value="victimlist + currentvictimlist"/> <!-- update the "freeambulances" list --> <let var="tobefreeambulance" messageindex).sender"/> <if condition="(tobefreeambulance!= nil) and!((ambulance tobefreeambulance) in freeambulances)"> <set var="freeambulances" value="freeambulances + (ambulance tobefreeambulance)"/> 77

78 hospital!!!!!! --> should accept all the victims --> <set var="messageindex" value="messageindex+1"/> </loop> <!-- not yet take into account the capacity of the <!-- in a condition after an earthquake, the hospital <do action="agree"> <arg name="message" value="requestmsgsfromambulances"/> <do action="inform"> <arg name="message" value="requestmsgsfromambulances"/> </reflex> <if condition="!(empty victimlist)"> <do action="load"> <arg name="agents" value="victimlist"/> <!-- the inform messages (of the 'no-protocol' protocol) sent from the militaries informing the places of victims --> <reflex name="read_noprotocol_inform_msgs_from_military" when="havingnoprotocolinformmsgsfrommilitary"> <let var="messageindex" value="0"/> <loop times="length noprotocolinformmsgsfrommilitary"> <let var="victimlist" messageindex).content"/> <let var="victimindex" value="0"/> <loop times="length victimlist"> <if victimindex) in alreadysentrequestvictims) victimindex) in victimsneedambulance)"> <set var="victimsneedambulance" value="victimsneedambulance + victimindex)"/> value="victimindex+1"/> </loop> <set var="victimindex" <set var="messageindex" value="messageindex+1"/> </loop> <!-- end the conversations --> <do action="end"> <arg name="message" value="noprotocolinformmsgsfrommilitary"/> </reflex> <!-- the request messages sent from the militaries to ask for the available places of this hospital. --> <reflex name="read_request_messages_from_militaries" when="havingrequestrequestmsgsfrommilitary"> <!-- calculate the available places --> <let var="availableplaces" value="capacity - (length alreadysentrequestvictims) - (length victimsneedambulance)"/> <if condition="availableplaces > 0"> <let var="looptimes" value="length requestrequestmsgsfrommilitary"/> <let var="i" value="0"/> <loop times="looptimes"> 78

79 <if condition="availableplaces > 0"> <let var="requestedplaces" value="int i).content)"/> <let var="offeringplaces" value="(availableplaces > requestedplaces)? requestedplaces : availableplaces"/> i)]"/> i)]"/> value="[(string offeringplaces)]"/> <do action="agree"> <arg name="message" <do action="inform"> <arg name="message" <arg name="content" value="availableplaces - offeringplaces"/> places then refuse the rested requests --> i)]"/> <set var="availableplaces" <else> <!-- the hospital has no more </else> <do action="refuse"> <arg name="message" </reflex> <set var="i" value="i+1"/> </loop> </species> </entities> </around> military.xml <?xml version="1.0" encoding="iso " standalone="yes"?> <around> <entities> <species name="military" skills="situated, communicating, visible, planning" globalpathfinder="true"> <!-- built-in variables --> <rgb name="color" init="'#808000'" const="true"/> <int name="intersectionsperpartition" init="250" const="true"/> <string name="explorerspecies" init="'explorer'" const="true"/> <float name="range" init="1200" const="true"/> <! m --> <bool name="showrange" init="true" const="true"/> <rgb name="rangecolor" init="#00ff00" const="true"/> <!-- GIS related informations --> <gis_layer name="data/gaml/around/with_communication/version5/gis/militaire_police.shp" /> <terrain name="'road'" speed_max="maxspeed" /> <terrain name="'hospital'" speed_max="(150 kmh) / 20" /> <terrain name="'military'" speed_max="(150 kmh) / 20" /> <list name="freeexplorers" init="[]"/> <list name="freefiremen" init="[]"/> <list name="victims" init="[]"/> <list name="alreadyinformedvictims" init="[]"/> <list name="fires" init="[]"/> <list name="alreadysentrequestfires" init="[]"/> <list name="alreadydiedfires" init="[]"/> <list name="availablehospitals" init="[]"/> 79

80 <bool name="sendrequestmsgstoexplorers" value="!(empty partitions) and!(empty freeexplorers)"/> <!-- 'inform' messages (of the 'no-protocol' protocol) sent from the explorers --> <list name="noprotocolinformmsgsfromexplorers" value="informs where ((each.sender.species = 'explorer') and (each.protocol = 'no-protocol'))"/> <bool name="havingnoprotocolinformmsgsfromexplorers" value="!(empty noprotocolinformmsgsfromexplorers)"/> <!-- 'inform' messages (of the 'fipa-request' Protocol) sent from the explorers --> <list name="requestinformmsgsfromexplorers" value="informs where ((each.sender.species = 'explorer') and (each.protocol='fipa-request'))"/> <bool name="havingrequestinformmsgsfromexplorers" value="!(empty requestinformmsgsfromexplorers)"/> <!-- 'inform' messages (of the 'fipa-request' Protocol) sent from the hospitals --> <list name="requestinformmsgsfromhospitals" value="informs where ((each.sender.species = 'hospital') and (each.protocol = 'fipa-request'))"/> <bool name="havingrequestinformmsgsfromhospitals" value="!(empty requestinformmsgsfromhospitals)"/> <!-- 'refuse' messages (of the 'fipa-request' protocol) sent from firemen --> <list name="requestrefusemsgsfromfiremen" value="refuses where ((each.sender.species = 'fireman') and (each.protocol = 'fipa-request'))"/> <bool name="havingrequestrefusemsgsfromfiremen" value="!(empty requestrefusemsgsfromfiremen)"/> <!-- 'inform' messages (of the 'fipa-request' protocol) sent from firemen --> <list name="requestinformmsgsfromfiremen" value="informs where ((each.sender.species = 'fireman') and (each.protocol = 'fipa-request'))"/> <bool name="havingrequestinformmsgsfromfiremen" value="!(empty requestinformmsgsfromfiremen)"/> <!-- 'inform' messages (of the 'no-protocol' protocol) sent from firemen --> <list name="noprotocolinformmsgsfromfiremen" value="informs where ((each.sender.species = 'fireman') and (each.protocol = 'no-protocol'))"/> <bool name="havingnoprotocolinformmsgsfromfiremen" value="!(empty noprotocolinformmsgsfromfiremen)"/> <!-- 'inform' messages (of the 'no-protocol' protocol' sent from others militaries --> <list name="noprotocolinformmsgsfromothersmilitaries" value="informs where ((each.sender.species = 'military') and (each.sender!= self) and (each.protocol = 'no-protocol'))"/> <bool name="havingnoprotocolinformmsgsfromothersmilitaries" value="!(empty noprotocolinformmsgsfromothersmilitaries)"/> <init name="military_init"> <if condition="numberofexplorerpermilitary > 0"> <create species="explorer" number="numberofexplorerpermilitary" result="myexplorers"/> <ask target="myexplorers"> <set name="owner" value="myself"/> <set name="location" value="myself.location"/> </ask> <set var="freeexplorers" value="freeexplorers + myexplorers"/> <if condition="numberoffiremanpermilitary > 0"> <create species="fireman" number="numberoffiremanpermilitary" result="myfiremen"/> <ask target="myfiremen"> <set name="owner" value="myself"/> 80

81 value="myself.location"/> myfiremen"/> </init> <set name="location" </ask> <set var="freefiremen" value="freefiremen + <reflex name="send_request_msgs_to_explorers" when="sendrequestmsgstoexplorers"> <let var="partitionindex" value="0"/> <let var="looptimes" value="((length partitions) > (length freeexplorers))? (length freeexplorers) : (length partitions)"/> <loop times="looptimes"> <do action="send"> <arg name="receivers" partitionindex"/> <arg name="protocol" value="'fiparequest'"/> <arg name="performative" value="'request'"/> <arg name="content" partitionindex"/> (first freeexplorers)"/> partitions)]"/> </loop> </reflex> <set var="partitionindex" value="partitionindex+1"/> </loop> <loop times="looptimes"> <set var="freeexplorers" value="freeexplorers - <set var="partitions" value="partitions - [(first <!-- the 'inform' messages (of the 'fipa-request' protocol) sent from the firemen informing some fires have just been extinguished --> <reflex name="having_request_inform_msgs_from_firemen" when="!(empty requestinformmsgsfromfiremen)"> <let var="looptimes" value="length requestinformmsgsfromfiremen"/> <let var="messageindex" value="0"/> <let var="diedfires" value="[]"/> <loop times="looptimes"> <let var="diedfire" value="(fire 0))"/> <if condition="(diedfire!= nil) and!(diedfire in diedfires)"> <set var="diedfires" value="diedfires + diedfire"/> <let var="messageindex" value="messageindex+1"/> </loop> <if condition="!(empty diedfires)"> <!-- update internal lists --> <set var="fires" value="fires - diedfires"/> <set var="alreadydiedfires" value="alreadydiedfires + (diedfires where!(each in alreadydiedfires))"/> <set var="alreadysentrequestfires" value="alreadysentrequestfires - diedfires"/> <!-- inform other militaries that some fires have just been extinguished --> <let var="othersmilitaries" value="agents where ((each.species = 'military') and (each!= self))"/> <if condition="(othersmilitaries!= nil) and!(empty othersmilitaries)"> <do action="send"> 81

82 <arg name="receivers" <arg name="protocol" value="'no- <arg name="performative" <arg name="content" value="othersmilitaries"/> protocol'"/> value="'inform'"/> value="diedfires"/> <!-- inform my firemen that some fires have just been extinguished --> <let var="othersfiremen" value="agents where ((each.species = 'fireman') and (each.owner = self))"/> <if condition="(othersfiremen!= nil) and!(empty othersfiremen)"> <do action="send"> <arg name="receivers" value="othersfiremen"/> <arg name="protocol" value="'noprotocol'"/> <arg name="performative" value="'inform'"/> <arg name="content" value="diedfires"/> </reflex> <!-- the 'inform' messages (of the 'no-protocol) sent from the fireman informing a fireman is free --> <reflex name="having_noprotocol_inform_msgs_from_firemen" when="havingnoprotocolinformmsgsfromfiremen"> <let var="diedfires" value="[]"/> <let var="looptimes" value="length noprotocolinformmsgsfromfiremen"/> <let var="messageindex" value="0"/> <loop times="looptimes"> <let var="msgcontent" messageindex).content"/> <if 0) = 'free'"> <!-- the fireman informs that it is free --> <set var="freefiremen" value="freefiremen + (fireman messageindex).sender))"/> <else> <!-- the fireman informs that the fire being taken care of by it has just been extinguished --> <let var="diedfire" 0)"/> diedfires)"> value="diedfires + diedfire"/> </else> <if condition="!(diedfire in <set var="diedfires" <let var="messageindex" value="messageindex+1"/> </loop> <!-- end the conversations --> <do action="end"> <arg name="message" value="noprotocolinformmsgsfromfiremen"/> 82

83 <if condition="!(empty diedfires)"> <!-- update internal lists --> <set var="fires" value="fires - diedfires"/> <set var="alreadydiedfires" value="alreadydiedfires + (diedfires where!(each in alreadydiedfires))"/> <set var="alreadysentrequestfires" value="alreadysentrequestfires - diedfires"/> <!-- inform other militaries that some fires have just been extinguished --> <let var="othersmilitaries" value="agents where ((each.species = 'military') and (each!= self))"/> <if condition="(othersmilitaries!= nil) and!(empty othersmilitaries)"> <do action="send"> <arg name="receivers" value="othersmilitaries"/> <arg name="protocol" value="'noprotocol'"/> <arg name="performative" value="'inform'"/> <arg name="content" value="diedfires"/> <!-- inform others firemen that some fires have just been extinguished --> <let var="myfiremen" value="agents where ((each.species = 'fireman') and (each.owner = self))"/> <if condition="(myfiremen!= nil) and!(empty myfiremen)"> <do action="send"> <arg name="receivers" value="myfiremen"/> <arg name="protocol" value="'noprotocol'"/> <arg name="performative" value="'inform'"/> <arg name="content" value="diedfires"/> </reflex> <!-- the 'inform' messages sent from others militaries informing some fires have just been extinguished --> <reflex name="noprotocol_inform_msgs_from_others_militaries" when="havingnoprotocolinformmsgsfromothersmilitaries"> <let var="looptimes" value="length noprotocolinformmsgsfromothersmilitaries"/> <let var="messageindex" value="0"/> <let var="diedfires" value="[]"/> <loop times="looptimes"> <let var="currentdiedfires" messageindex).content"/> <set var="diedfires" value="diedfires + (currentdiedfires where (!(each in diedfires)))"/> <set var="messageindex" value="messageindex+1"/> </loop> <if condition="!(empty diedfires)"> <!-- update internal lists --> <set var="fires" value="fires - diedfires"/> <set var="alreadydiedfires" value="alreadydiedfires + (diedfires where!(each in alreadydiedfires))"/> <set var="alreadysentrequestfires" value="alreadysentrequestfires - diedfires"/> 83

84 <!-- inform my firemen of that some fires have just been extinguished --> <let var="myfiremen" value="agents where (((each.species) = 'fireman') and ((each.owner) = self))"/> <arg name="protocol" value="'no- value="myfiremen"/> protocol'"/> value="'inform'"/> value="diedfires"/> <if condition="!(empty myfiremen)"> <do action="send"> <arg name="receivers" <arg name="performative" <arg name="content" <!-- end the conversations --> <do action="end"> <arg name="message" value="noprotocolinformmsgsfromothersmilitaries"/> </reflex> <!-- the Explorers inform the military the positions of victims and of fires --> <reflex name="having_noprotocol_inform_msgs_from_explorers" when="havingnoprotocolinformmsgsfromexplorers"> <let var="messageindex" value="0"/> <loop times="length noprotocolinformmsgsfromexplorers"> <let var="msgcontent" messageindex).content"/> <if 0) = '1'"> <set var="msgcontent" value="msgcontent - (first msgcontent)"/> value="victim victimindex)"/> <let var="informedvictim" value="nil"/> <let var="victimindex" value="0"/> <loop times="length msgcontent"> <set var="informedvictim" <if condition="!(informedvictim in victims) and!(informedvictim in alreadyinformedvictims)"> <set var="victims" value="victims + informedvictim"/> value="victimindex + 1"/> </loop> <set var="victimindex" '2'"> <!-- this is a list of fires --> value="msgcontent - (first msgcontent)"/> <else> <if 0) = <set var="msgcontent" value="nil"/> value="0"/> msgcontent"> var="informedfire" value="fire fireindex)"/> <let var="informedfire" <let var="fireindex" <loop times="length <set 84

85 <if condition="(informedfire!= nil) and!(informedfire in fires) and!(informedfire in alreadysentrequestfires) and!(informedfire in alreadydiedfires)"> <set var="fires" value="fires + informedfire"/> value="fireindex+1"/> </loop> <let var="fireindex" </else> <set var="messageindex" value="messageindex+1"/> </loop> <!-- end the conversations with explorers --> <do action="end"> <arg name="message" value="noprotocolinformmsgsfromexplorers"/> </reflex> <!-- request the free hospitals --> <reflex name="request_free_hospitals" when="(empty availablehospitals) and!(empty victims) and!havingrequestinformmsgsfromhospitals"> <let var="hospitals" value="agents where (each.species = 'hospital')"/> <if condition="(hospitals!= nil) and!(empty hospitals)"> <do action="send"> <arg name="receivers" value="hospitals"/> <arg name="protocol" value="'fiparequest'"/> <arg name="performative" value="'request'"/> <arg name="content" value="[(length victims)]"/> <!-- how many places do I need? --> </reflex> <!-- read inform messages from hospitals --> <reflex name="read_inform_msgs_from_hospital" when="(empty availablehospitals) and!(empty victims) and havingrequestinformmsgsfromhospitals"> <let var="looptimes" value="length requestinformmsgsfromhospitals"/> <let var="i" value="0"/> <loop times="looptimes"> <let var="freeplacesofhospital" value="(int 0))"/> <if condition="(freeplacesofhospital > 0) i).sender) in availablehospitals)"> <set var="availablehospitals" value="availablehospitals + i).sender)"/> <set var="availablehospitals" value="availablehospitals + (string freeplacesofhospital)"/> <let var="i" value="i+1"/> </loop> </reflex> <!-- the military informs the hospitals of the victims' informations --> <reflex name="send_victims_information_to_hospitals" when="!(empty availablehospitals) and!(empty victims)"> <!-- sort the list of available hospitals by distance (from this military to each hospital) 85

86 first. --> we would like to consider the nearer hospitals <let var="hospitalnumber" value="(length availablehospitals)/2"/> <let var="myhospitals" value="[]"/> <let var="hospitalindex" value="0"/> <loop times="hospitalnumber"> <set var="myhospitals" value="myhospitals + hospitalindex)"/> distance_to each)"/> <set var="hospitalindex" value="hospitalindex + 2"/> </loop> <set var="myhospitals" value="myhospitals sort_by (self <let var="temphospitals" value="[]"/> <set var="hospitalindex" value="0"/> <loop times="hospitalnumber"> <set var="temphospitals" value="temphospitals + hospitalindex)"/> <set var="temphospitals" value="temphospitals + ((availablehospitals index_of hospitalindex)) + 1))"/> <let var="hospitalindex" value="hospitalindex + 1"/> </loop> <set var="availablehospitals" hospitalindex"/> <set var="hospitalindex" value="0"/> <loop times="((length availablehospitals) / 2)"> <let var="currenthospital" value="availablehospitals availablehospitals)/2"/> <set var="hospitalindex" value="hospitalindex + 2"/> </loop> <!-- calculate the number of hospitals needed --> <let var="victimnumber" value="length victims"/> <let var="numberofvictimsaccepted" value="0"/> <let var="numberofhospital" value="0"/> <let var="i" value="1"/> <let var="looptimes" value="(length <loop times="looptimes"> <if condition="numberofvictimsaccepted < victimnumber"> <set var="numberofvictimsaccepted" value="numberofvictimsaccepted + (int i))"/> <set var="numberofhospital" value="numberofhospital + 1"/> <set var="i" value="i+2"/> </loop> <!-- send the information of victims to the hospitals --> <set var="i" value="0"/> <loop times="numberofhospital"> <let var="numberofvictimstosend" value="((length victims) > (int (i + 1))))? (int (i + 1))) : (length victims)"/> <let var="victimstosend" value="[]"/> <loop times="numberofvictimstosend"> <set var="victimstosend" value="victimstosend + (first victims)"/> <set var="alreadyinformedvictims" value="alreadyinformedvictims + (first victims)"/> 86

87 <arg name="protocol" value="'no- victims)"/> i)]"/> protocol'"/> value="'inform'"/> value="victimstosend"/> </loop> <set var="victims" value="victims - (first <if condition="!(empty victimstosend)"> <do action="send"> <arg name="receivers" <arg name="performative" <arg name="content" <let var="i" value="i+2"/> </loop> <set var="availablehospitals" value="[]"/> </reflex> <!-- the explorers inform the military that it has just finish the patrol on a given partition. see : the "patrol_the_terrain" reflex of the "explorer" species. --> <reflex name="having_request_inform_msgs_from_explorers" when="!(empty (informs where ((each.sender.species = 'explorer') and (each.protocol='fipa-request'))))"> <!-- workaround --> <let var="requestinforms" value="informs where ((each.sender.species = 'explorer') and (each.protocol='fipa-request'))"/> <let var="looptimes" value="length requestinforms"/> <let var="messageindex" value="0"/> <do action="debug"> <arg name="message" value="name + ' : length partitions = ' + (string (length partitions)) + ' : having_request_inform_msgs_from_explorers'"/> <loop times="looptimes"> <if messageindex).sender) in freeexplorers)"> <set var="freeexplorers" value="freeexplorers + messageindex).sender)"/> <!-- if no more partitions then request the explorer to go home --> <if condition="empty partitions"> <do action="debug"> <arg name="message" value="name + ' : no more partition, request ' + (string messageindex).sender)) + ' to go home : having_request_inform_msgs_from_explorers'"/> <do action="send"> <arg name="receivers" messageindex).sender)]"/> <arg name="protocol" value="'no-protocol'"/> <arg name="performative" value="'request'"/> 87

88 </reflex> <set var="messageindex" value="messageindex+1"/> </loop> <reflex name="send_request_msgs_to_firemen" when="!(empty fires) and!(empty freefiremen)"> <let var="numberoffiremen" value="length freefiremen"/> <let var="numberoffire" value="length fires"/> <let var="numberoffiremenperfire" value="(int (numberoffiremen / numberoffire))"/> <let var="remainingfiremen" value="numberoffiremen % numberoffire"/> i)]"/> value="'fipa-request'"/> value="'request'"/> fireindex)]"/> <let var="fireindex" value="0"/> <let var="i" value="0"/> <if condition="numberoffiremenperfire > 0"> <loop times="numberoffiremenperfire"> <set var="fireindex" value="0"/> <loop times="numberoffire"> <do action="send"> <arg name="receivers" <arg name="protocol" <arg name="performative" <arg name="content" + 1"/> <set var="fireindex" value="fireindex <let var="i" value="i+1"/> </loop> </loop> <arg name="protocol" value="'fipa- i)]"/> request'"/> value="'request'"/> fireindex)]"/> <if condition="remainingfiremen > 0"> <set var="fireindex" value="0"/> <loop times="remainingfiremen"> <do action="send"> <arg name="receivers" <arg name="performative" <arg name="content" <let var="i" value="i+1"/> <let var="fireindex" value="fireindex + 1"/> </loop> <set var="freefiremen" value="[]"/> <!-- update the "alreadysentrequestfires" and "fires" lists --> <if condition="numberoffire > numberoffiremen"> <loop times="numberoffiremen"> <set var="alreadysentrequestfires" value="alreadysentrequestfires + (first fires)"/> <set var="fires" value="fires - (first fires)"/> </loop> 88

89 <else> value="alreadysentrequestfires + fires"/> </reflex> <set var="alreadysentrequestfires" <set var="fires" value="[]"/> </else> <!-- 'refuse' messages (of the 'fipa-request' protocol) sent from firemen --> <reflex name="having_request_refuse_msgs_from_firemen" when="!(empty requestrefusemsgsfromfiremen)"> <let var="looptimes" value="length requestrefusemsgsfromfiremen"/> <let var="i" value="0"/> <loop times="looptimes"> <let var="refusedfire" 0"/> <if condition="refusedfire!= nil"> <set var="alreadysentrequestfires" value="alreadysentrequestfires - refusedfire"/> <if condition="!(refusedfire in fires) and!(refusedfire in alreadydiedfires)"> <set var="fires" value="fires + refusedfire"/> <let var="i" value="i+1"/> </loop> </reflex> <!-- when we have free firemen and no more new places on fired then take care of the currently on fired places being extinguished by others firemen. --> <reflex name="recycle_firelist" when="(empty fires) and!(empty alreadysentrequestfires) and!(empty freefiremen)"> <set var="fires" value="fires + (alreadysentrequestfires where (!(each in alreadydiedfires)))"/> <set var="alreadysentrequestfires" value="[]"/> </reflex> </species> </entities> </around> victim.xml <?xml version="1.0" encoding="iso " standalone="yes"?> <around> <entities> <species name="victim" skills="visible, situated"> <!-- GIS related informations --> <gis_layer name="data/gaml/around/with_communications/version5/gis/victim.shp" /> <terrain name="'road'" speed_max="maxspeed" /> <terrain name="'school'" speed_max="(150 kmh) / 20" /> <!-- built-in variables --> <string name="shape" init="'data/gaml/around/icons/threat_person.png'" const="true" /> <string name="color" init="blue" const="true"/> <float name="size" init="0.5" const="true"/> <float name="speed" min="0" max="maxspeed" init="0" /> <!-- variables --> 89

90 <float name="gravity" init="rnd (deathgravityofvictim-1)" min="0" max="deathgravityofvictim" show_color="red"/> <bool name="inambulance" init="false"/> <bool name="inhospital" init="false"/> <!-- reflexes --> <reflex name="stable" when="inambulance and (gravity > 0)"> <set var="gravity" value="gravity "/> </reflex> <reflex name="improvement" when="inhospital and (gravity > 0)"> <set var="gravity" value="gravity "/> </reflex> <reflex name="hurt" when="!(inambulance inhospital) and (gravity < deathgravityofvictim)"> <set var="gravity" value="gravity "/> </reflex> </species> </entities> </around> world.xml <?xml version="1.0" encoding="iso " standalone="yes"?> <around> <modelclass name="msi.gama.kernel.simulation"/> <global> <!-- built-in variables --> <int name="time" init="0" max="100 hours"/> <int name="step" init="4 second" const="true"/> <int name="display_every" init="2"/> <boolean name="fast_draw" init="true"/> <world name="world" init="self"/> <float name="seed" init="234" const="true"/> <!-- variables --> <float name="maxspeed" value="150 kmh" const="true"/> <rgb name="black" init="'#000000'" const="true"/> <rgb name="green" init="'#008000'" const="true"/> <rgb name="silver" init="'#c0c0c0'" const="true"/> <rgb name="lime" init="'#00ff00'" const="true"/> <rgb name="gray" init="'#808080'" const="true"/> <rgb name="olive" init="'#808000'" const="true"/> <rgb name="white" init="'#ffffff'" const="true"/> <rgb name="yellow" init="'#ffff00'" const="true"/> <rgb name="maroon" init="'#800000'" const="true"/> <rgb name="navy" init="'#000080'" const="true"/> <rgb name="red" init="'#ff0000'" const="true"/> <rgb name="blue" init="'#0000ff'" const="true"/> <rgb name="purple" init="'#800080'" const="true"/> <rgb name="teal" init="'#008080'" const="true"/> <rgb name="fuchsia" init="'#ff00ff'" const="true"/> <rgb name="aqua" init="'#00ffff'" const="true"/> <list name="victimsonterrain" value="(agents where ((each.species='victim') and!(each.inambulance) and!(each.inhospital)))"/> <!-- parameters --> <int name="totalvictim" init="100" min="0" max="100" parameter="true"/> <int name="ambulancecapacity" init="10" min="1" max="20" parameter="true"/> <int name="numberofambulanceperhospital" init="8" min="1" max="10" parameter="true"/> <int name="numberofexplorerpermilitary" init="4" min="1" max="10" parameter="true"/> <int name="totalfire" init="0" min="0" max="100" parameter="true"/> <int name="numberoffiremanpermilitary" init="5" min="1" max="20" parameter="true"/> 90

91 <int name="waterleveloffireman" init="500" min="10" max="1000" parameter="true"/> <float name="deathgravityofvictim" init="5" min="5" max="10" parameter="true"/> <init> <if condition="totalvictim > 0"> <create species="victim" number="totalvictim"/> <if condition="totalfire > 0"> <create species="fire" number="totalfire"/> </init> </global> <include file="data/gaml/around/with_communication/version5/environment.xml"/> <include file="data/gaml/around/with_communication/version5/victim.xml"/> <include file="data/gaml/around/with_communication/version5/hospital.xml"/> <include file="data/gaml/around/with_communication/version5/ambulance.xml"/> <include file="data/gaml/around/with_communication/version5/military.xml"/> <include file="data/gaml/around/with_communication/version5/explorer.xml"/> <include file="data/gaml/around/with_communication/version5/fire.xml"/> <include file="data/gaml/around/with_communication/version5/fireman.xml"/> <output> <display name="gis" type="gis" refresh_every="1" /> <monitor name="total victim on terrain" value="length victimsonterrain" refresh_every="2"/> <monitor name="victims on terrain" value="victimsonterrain sort_by each.index" refresh_every="2"/> <monitor name="total victims in ambulances" value="length (agents where ((each.species='victim') and (each.inambulance) and!(each.inhospital)))" refresh_every="2"/> <monitor name="victims in ambulances" value="(agents where ((each.species='victim') and (each.inambulance) and!(each.inhospital))) sort_by each.index" refresh_every="2"/> <monitor name="total victim in hospitals" value="(agents where ((each.species='victim') and!(each.inambulance) and (each.inhospital))) sort_by each.index" refresh_every="2"/> <monitor name="victims in hospitals" value="length (agents where ((each.species='victim') and!(each.inambulance) and (each.inhospital)))" refresh_every="2"/> <monitor name="victims not in hospitals" value="(agents where ((each.species='victim') and!(each.inhospital))) sort_by each.index" refresh_every="2"/> <monitor name="total death victims" value="length (agents where ((each.species='victim') and!(each.gravity < 5)))" refresh_every="2"/> <monitor name="death victims" value="(agents where ((each.species='victim') and!(each.gravity < 5))) sort_by each.index" refresh_every="2"/> <monitor name="total fires on fired" value="length (agents where ((each.species='fire') and ((each.level) > 0)))" refresh_every="2"/> <monitor name="fires on fired" value="(agents where ((each.species='fire') and ((each.level) > 0))) sort_by each.index" refresh_every="2"/> <monitor name="total death fires" value="length (agents where ((each.species='fire') and (((each.level) < 0) or ((each.level) = 0))))" refresh_every="2"/> <monitor name="death fires" value="(agents where ((each.species='fire') and (((each.level) < 0) or ((each.level) = 0)))) sort_by each.index" refresh_every="2"/> </output> </around> 91

Générer du code à partir d une description de haut niveau

Générer du code à partir d une description de haut niveau Cedric Dumoulin Générer du code à partir d une description de haut niveau Ce projet vise à fournir un environnement de développement permettant de modéliser des UI Android à un haut niveau d abstraction,

Plus en détail

JADE : Java Agent DEvelopment framework. Laboratoire IBISC & Départ. GEII Université & IUT d Evry [email protected].

JADE : Java Agent DEvelopment framework. Laboratoire IBISC & Départ. GEII Université & IUT d Evry nadia.abchiche@ibisc.univ-evry. : Java Agent DEvelopment framework Laboratoire IBISC & Départ. GEII Université & IUT d Evry [email protected] Introduction à la plateforme JADE 1) Modèle d agent 2) Services 3) Norme FIPA

Plus en détail

Conception et contrôle des SMA tolérants aux fautes

Conception et contrôle des SMA tolérants aux fautes Conception et contrôle des SMA tolérants aux fautes Une plate-forme multiagents tolérante aux fautes à base de réplication Nora FACI Contexte SMA large échelle Nombre important d agents Ressources éloignées

Plus en détail

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML http://olivier-augereau.com Sommaire Introduction I) Les bases II) Les diagrammes

Plus en détail

Modélisation multi-agents - Agents réactifs

Modélisation multi-agents - Agents réactifs Modélisation multi-agents - Agents réactifs Syma cursus CSI / SCIA Julien Saunier - [email protected] Sources www-lih.univlehavre.fr/~olivier/enseignement/masterrecherche/cours/ support/algofourmis.pdf

Plus en détail

Cours 1 : Qu est-ce que la programmation?

Cours 1 : Qu est-ce que la programmation? 1/65 Introduction à la programmation Cours 1 : Qu est-ce que la programmation? Yann Régis-Gianas [email protected] Université Paris Diderot Paris 7 2/65 1. Sortez un appareil qui peut se rendre

Plus en détail

TP1 : Initiation à Java et Eclipse

TP1 : Initiation à Java et Eclipse TP1 : Initiation à Java et Eclipse 1 TP1 : Initiation à Java et Eclipse Systèmes d Exploitation Avancés I. Objectifs du TP Ce TP est une introduction au langage Java. Il vous permettra de comprendre les

Plus en détail

Nom de l application

Nom de l application Ministère de l Enseignement Supérieur et de la Recherche Scientifique Direction Générale des Etudes Technologiques Institut Supérieur des Etudes Technologiques de Gafsa Département Technologies de l Informatique

Plus en détail

Évaluation et implémentation des langages

Évaluation et implémentation des langages Évaluation et implémentation des langages Les langages de programmation et le processus de programmation Critères de conception et d évaluation des langages de programmation Les fondations de l implémentation

Plus en détail

Programmation de services en téléphonie sur IP

Programmation de services en téléphonie sur IP Programmation de services en téléphonie sur IP Présentation de projet mémoire Grégory Estienne Sous la supervision du Dr. Luigi Logrippo Introduction La téléphonie sur IP comme support à la programmation

Plus en détail

Innovation Francophonie Imagination

Innovation Francophonie Imagination Innovation Francophonie Imagination http://www.ifi.auf.org Qu est-ce que l IFI? Fondé en 1993 à Hanoï (Vietnam), l IFI est un institut universitaire international francophone de troisième cycle soutenu

Plus en détail

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude INF 1250 INTRODUCTION AUX BASES DE DONNÉES Guide d étude Sous la direction de Olga Mariño Télé-université Montréal (Québec) 2011 INF 1250 Introduction aux bases de données 2 INTRODUCTION Le Guide d étude

Plus en détail

LES TYPES DE DONNÉES DU LANGAGE PASCAL

LES TYPES DE DONNÉES DU LANGAGE PASCAL LES TYPES DE DONNÉES DU LANGAGE PASCAL 75 LES TYPES DE DONNÉES DU LANGAGE PASCAL CHAPITRE 4 OBJECTIFS PRÉSENTER LES NOTIONS D ÉTIQUETTE, DE CONS- TANTE ET DE IABLE DANS LE CONTEXTE DU LAN- GAGE PASCAL.

Plus en détail

RAPPORT DE CONCEPTION UML :

RAPPORT DE CONCEPTION UML : Carlo Abi Chahine Sylvain Archenault Yves Houpert Martine Wang RAPPORT DE CONCEPTION UML : Bamboo Ch@t Projet GM4 Juin 2006 Table des matières 1 Introduction 2 2 Présentation du logiciel 3 2.1 Précisions

Plus en détail

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE»

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» Du cours Modélisation Semi -Formelle de Système d Information Du Professeur Jean-Pierre GIRAUDIN Décembre. 2002 1 Table de matière Partie 1...2 1.1

Plus en détail

Atelier Transversal AT11. Activité «Fourmis» Pierre Chauvet. [email protected]

Atelier Transversal AT11. Activité «Fourmis» Pierre Chauvet. pierre.chauvet@uco.fr Atelier Transversal AT11 Activité «Fourmis» Pierre Chauvet [email protected] Ant : un algorithme inspiré de l éthologie L éthologie Etude scientifique des comportements animaux, avec une perspective

Plus en détail

La plate-forme DIMA. Master 1 IMA COLI23 - Université de La Rochelle

La plate-forme DIMA. Master 1 IMA COLI23 - Université de La Rochelle La plate-forme DIMA Master 1 IMA COLI23 - Université de La Rochelle DIMA Bref aperçu Qu'est-ce? Acronyme de «Développement et Implémentation de Systèmes Multi-Agents» Initié par Zahia Guessoum et Jean-Pierre

Plus en détail

IFT785 Approches Orientées Objets. FINAL Été 2002. Remise : Jeudi 19 août 2002 à 9h00 am

IFT785 Approches Orientées Objets. FINAL Été 2002. Remise : Jeudi 19 août 2002 à 9h00 am IFT785 Approches Orientées Objets FINAL Été 2002 2 e session d examen Début : Lundi 16 septembre 2002 à 9h00 am Remise : Jeudi 19 août 2002 à 9h00 am Professeur : Sylvain GIROUX Note : /100 points Remarques

Plus en détail

Information utiles. [email protected]. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/ Systèmes de gestion de bases de données Introduction Université d Evry Val d Essonne, IBISC utiles email : [email protected] webpage : http://www.ibisc.univ-evry.fr/ digiusto/ Google+ : https://plus.google.com/u/0/b/103572780965897723237/

Plus en détail

Chapitre I : le langage UML et le processus unifié

Chapitre I : le langage UML et le processus unifié I. Introduction Les méthodes d analyse orientées objet sont initialement issues des milieux industriels. La préoccupation dominante de leurs auteurs est le génie logiciel, c est-àdire les principes et

Plus en détail

TP1 : Initiation à Java et Eclipse

TP1 : Initiation à Java et Eclipse TP1 : Initiation à Java et Eclipse 1 I. Objectif du TP TP1 : Initiation à Java et Eclipse Programmation Mobile Initiation à l environnement Eclipse et aux notions de base du langage Java. II. Environnement

Plus en détail

Programmation Objet - Cours II

Programmation Objet - Cours II Programmation Objet - Cours II - Exercices - Page 1 Programmation Objet - Cours II Exercices Auteur : E.Thirion - Dernière mise à jour : 05/07/2015 Les exercices suivants sont en majorité des projets à

Plus en détail

Proposition de sujet de thèse CIFRE EUROCOPTER / LGI2P

Proposition de sujet de thèse CIFRE EUROCOPTER / LGI2P EUROCOPTER SAS Groupe EADS Marignane Ecole des Mines d Alès Laboratoire de Génie Informatique et d Ingénierie de Production LGI2P Nîmes Proposition de sujet de thèse CIFRE EUROCOPTER / LGI2P Titre Domaine

Plus en détail

Développement d un interpréteur OCL pour une machine virtuelle UML.

Développement d un interpréteur OCL pour une machine virtuelle UML. ObjeXion Software Prototyping made easy SA au capital de 500 000 F Siret 421 565 565 00015 APE 722Z Téléphone : 03 89 35 70 75 Télécopie : 03 89 35 70 76 L embarcadère 5, rue Gutemberg 68 800 Vieux-Thann,

Plus en détail

Projet Active Object

Projet Active Object Projet Active Object TAO Livrable de conception et validation Romain GAIDIER Enseignant : M. Noël PLOUZEAU, ISTIC / IRISA Pierre-François LEFRANC Master 2 Informatique parcours MIAGE Méthodes Informatiques

Plus en détail

Jean-Philippe Préaux http://www.i2m.univ-amu.fr/~preaux

Jean-Philippe Préaux http://www.i2m.univ-amu.fr/~preaux Colonies de fourmis Comment procèdent les colonies de fourmi pour déterminer un chemin presque géodésique de la fourmilière à un stock de nourriture? Les premières fourmis se déplacent au hasard. Les fourmis

Plus en détail

Manuel d utilisation 26 juin 2011. 1 Tâche à effectuer : écrire un algorithme 2

Manuel d utilisation 26 juin 2011. 1 Tâche à effectuer : écrire un algorithme 2 éducalgo Manuel d utilisation 26 juin 2011 Table des matières 1 Tâche à effectuer : écrire un algorithme 2 2 Comment écrire un algorithme? 3 2.1 Avec quoi écrit-on? Avec les boutons d écriture........

Plus en détail

Master IAC 2013-2014. Philippe Caillou DÉVELOPPEMENT DE SMA. Cours 1b

Master IAC 2013-2014. Philippe Caillou DÉVELOPPEMENT DE SMA. Cours 1b DÉVELOPPEMENT DE SMA Cours 1b Je veux développer mon application.. Comme toujours, j utilise Java/Python/C#/ Mais : Est-ce que je ne reprogramme pas exactement la même chose que quelqu un d autre? (en

Plus en détail

Groupes et utilisateurs locaux avec Windows XP

Groupes et utilisateurs locaux avec Windows XP Groupes et utilisateurs locaux avec Windows XP 1. Distinction entre comptes de domaine et comptes locaux Pour rappel, et comme avec Windows 2000, il existe deux types de comptes utilisateurs : les comptes

Plus en détail

Jade. Projet Intelligence Artificielle «Devine à quoi je pense»

Jade. Projet Intelligence Artificielle «Devine à quoi je pense» Jade Projet Intelligence Artificielle «Devine à quoi je pense» Réalisé par Djénéba Djikiné, Alexandre Bernard et Julien Lafont EPSI CSII2-2011 TABLE DES MATIÈRES 1. Analyse du besoin a. Cahier des charges

Plus en détail

Diplôme de Comptabilité et de Gestion. D é c r e t N 2 0 0 6-1 7 0 6 d u 2 2 d é c e m b r e 2 0 0 6 - A r r ê t é d u 8 m a r s 2 0 1 0

Diplôme de Comptabilité et de Gestion. D é c r e t N 2 0 0 6-1 7 0 6 d u 2 2 d é c e m b r e 2 0 0 6 - A r r ê t é d u 8 m a r s 2 0 1 0 Diplôme de Comptabilité et de Gestion DCG D é c r e t N 2 0 0 6-1 7 0 6 d u 2 2 d é c e m b r e 2 0 0 6 - A r r ê t é d u 8 m a r s 2 0 1 0 Validation des Acquis de l Expérience VAE R é f é r e n t i e

Plus en détail

Introduction aux concepts d ez Publish

Introduction aux concepts d ez Publish Introduction aux concepts d ez Publish Tutoriel rédigé par Bergfrid Skaara. Traduit de l Anglais par Benjamin Lemoine Mercredi 30 Janvier 2008 Sommaire Concepts d ez Publish... 3 Système de Gestion de

Plus en détail

Chapitre 1 : Introduction aux bases de données

Chapitre 1 : Introduction aux bases de données Chapitre 1 : Introduction aux bases de données Les Bases de Données occupent aujourd'hui une place de plus en plus importante dans les systèmes informatiques. Les Systèmes de Gestion de Bases de Données

Plus en détail

OCL - Object Constraint Language

OCL - Object Constraint Language OCL - Object Constraint Language Laëtitia Matignon [email protected] Département Informatique - Polytech Lyon Université Claude Bernard Lyon 1 2012-2013 Laëtitia Matignon SIMA - OCL - Object

Plus en détail

Bien architecturer une application REST

Bien architecturer une application REST Olivier Gutknecht Bien architecturer une application REST Avec la contribution de Jean Zundel Ce livre traite exactement du sujet suivant : comment faire pour que les services web et les programmes qui

Plus en détail

Devenez un véritable développeur web en 3 mois!

Devenez un véritable développeur web en 3 mois! Devenez un véritable développeur web en 3 mois! L objectif de la 3W Academy est de former des petits groupes d élèves au développement de sites web dynamiques ainsi qu à la création d applications web

Plus en détail

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer Le Processus RUP Database Administrator Project Leader H. Kadima Performance Engineer Release Engineer Analyst Designer / Developer Tester Table des matières 1. De l artisanat à l industrialisation de

Plus en détail

Patrons de Conception (Design Patterns)

Patrons de Conception (Design Patterns) Patrons de Conception (Design Patterns) Introduction 1 Motivation Il est difficile de développer des logiciels efficaces, robustes, extensibles et réutilisables Il est essentiel de comprendre les techniques

Plus en détail

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION

Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Classe de terminale de la série Sciences et Technologie du Management et de la Gestion Préambule Présentation Les technologies de l information

Plus en détail

TP redondance DHCP. Gillard Frédéric Page 1/17. Vue d ensemble du basculement DHCP

TP redondance DHCP. Gillard Frédéric Page 1/17. Vue d ensemble du basculement DHCP Vue d ensemble du basculement DHCP Dans Windows Server 2008 R2, il existe deux options à haute disponibilité dans le cadre du déploiement du serveur DHCP. Chacune de ces options est liée à certains défis.

Plus en détail

L envoi d un formulaire par courriel. Configuration requise... 236 Mail Texte... 237 Mail HTML... 242 Check-list... 248

L envoi d un formulaire par courriel. Configuration requise... 236 Mail Texte... 237 Mail HTML... 242 Check-list... 248 L envoi d un formulaire par courriel Configuration requise... 236 Mail Texte... 237 Mail HTML... 242 Check-list... 248 Chapitre 9 L envoi d un formulaire par courriel L envoi par courriel d informations

Plus en détail

TRAAM STI 2013-2014 Acquisition et exploitations pédagogiques des données sur un système pédagogique

TRAAM STI 2013-2014 Acquisition et exploitations pédagogiques des données sur un système pédagogique TRAAM STI 2013-2014 Acquisition et exploitations pédagogiques des données sur un système pédagogique Bilan technique et éléments de développement Fonctionnalités attendues Une vingtaine d établissements

Plus en détail

Validation de la création des groupes ABM et ajout de l utilisateur SASDEMO

Validation de la création des groupes ABM et ajout de l utilisateur SASDEMO COMMENT VALIDER VOTRE INSTALLATION SAS ACTIVITY-BASED MANAGEMENT 7.2? Vous venez d installer SAS Activity-Based Management 7.2. Ce document va vous aider à valider votre installation. Il pourra également

Plus en détail

Créer et partager des fichiers

Créer et partager des fichiers Créer et partager des fichiers Le rôle Services de fichiers... 246 Les autorisations de fichiers NTFS... 255 Recherche de comptes d utilisateurs et d ordinateurs dans Active Directory... 262 Délégation

Plus en détail

La haute disponibilité

La haute disponibilité Chapitre 3 La haute 3.1 Définition du cluster de serveurs...112 3.2 La mise en cluster des applications...114 3.3 Les composants du cluster de serveurs...115 3.4 Les obets du cluster de serveurs...119

Plus en détail

ET 24 : Modèle de comportement d un système Boucles de programmation avec Labview.

ET 24 : Modèle de comportement d un système Boucles de programmation avec Labview. ET 24 : Modèle de comportement d un système Boucles de programmation avec Labview. Sciences et Technologies de l Industrie et du Développement Durable Formation des enseignants parcours : ET24 Modèle de

Plus en détail

4. SERVICES WEB REST 46

4. SERVICES WEB REST 46 4. SERVICES WEB REST 46 REST REST acronyme de REpresentational State Transfert Concept introduit en 2000 dans la thèse de Roy FIELDING Est un style d architecture inspiré de l architecture WEB En 2010,

Plus en détail

Méthodes d évolution de modèle produit dans les systèmes du type PLM

Méthodes d évolution de modèle produit dans les systèmes du type PLM Résumé de thèse étendu Méthodes d évolution de modèle produit dans les systèmes du type PLM Seyed Hamedreza IZADPANAH Table des matières 1. Introduction...2 2. Approche «Ingénierie Dirigée par les Modèles»

Plus en détail

GOL502 Industries de services

GOL502 Industries de services GOL502 Industries de services Conception d un service Partie IIb Version 2013 Introduction Conception d un service partie IIb Nous verrons dans ce chapitre Modélisation d un service; Langage de modélisation

Plus en détail

Bien programmer. en Java 7. 10 000 ex. couleur. Avec plus de 50 études de cas et des comparaisons avec C++ et C# Emmanuel Puybaret.

Bien programmer. en Java 7. 10 000 ex. couleur. Avec plus de 50 études de cas et des comparaisons avec C++ et C# Emmanuel Puybaret. Bien programmer en Java 7 Avec plus de 50 études de cas et des comparaisons avec C++ et C# Plus de 10 000 ex. vendus! Édition en couleur Emmanuel Puybaret, ISBN : 978-2-212-12974-8 chapitre1 Présentation

Plus en détail

Utilisation d objets : String et ArrayList

Utilisation d objets : String et ArrayList Chapitre 6 Utilisation d objets : String et ArrayList Dans ce chapitre, nous allons aborder l utilisation d objets de deux classes prédéfinies de Java d usage très courant. La première, nous l utilisons

Plus en détail

Cours Bases de données

Cours Bases de données Informations sur le cours Cours Bases de données 9 (10) séances de 3h Polycopié (Cours + TD/TP) 3 année (MISI) Antoine Cornuéjols www.lri.fr/~antoine [email protected] Transparents Disponibles

Plus en détail

Pourquoi archiver les emails

Pourquoi archiver les emails Pourquoi archiver les emails Objectif du document Ce document a pour objectif d'expliquer la nécessité et le bien-fondé de l'archivage des emails. Il a été écrit par Alain Heurtebise, Directeur Général

Plus en détail

Algorithme des fourmis appliqué à la détection et au suivi de contours dans une image

Algorithme des fourmis appliqué à la détection et au suivi de contours dans une image IN52-IN54 A2008 Algorithme des fourmis appliqué à la détection et au suivi de contours dans une image Etudiants : Nicolas MONNERET Alexandre HAFFNER Sébastien DE MELO Responsable : Franck GECHTER Sommaire

Plus en détail

Cours Base de données relationnelles. M. Boughanem, IUP STRI

Cours Base de données relationnelles. M. Boughanem, IUP STRI Cours Base de données relationnelles 1 Plan 1. Notions de base 2. Modèle relationnel 3. SQL 2 Notions de base (1) Définition intuitive : une base de données est un ensemble d informations, (fichiers),

Plus en détail

Université de Bangui. Modélisons en UML

Université de Bangui. Modélisons en UML Université de Bangui CRM Modélisons en UML Ce cours a été possible grâce à l initiative d Apollinaire MOLAYE qui m a contacté pour vous faire bénéficier de mes connaissances en nouvelles technologies et

Plus en détail

Sommaire. Introduction. I. Notions de routage a) Technologies actuelles b) Avantages et désavantages

Sommaire. Introduction. I. Notions de routage a) Technologies actuelles b) Avantages et désavantages Sommaire Introduction I. Notions de routage a) Technologies actuelles b) Avantages et désavantages II. Routage et fourmis a) Principe et avantages b) Structure du simulateur III.Implémentation a) Présentation

Plus en détail

Club informatique Mont-Bruno Séances du 18 janvier et du 17 février 2012 Présentateur : Michel Gagné

Club informatique Mont-Bruno Séances du 18 janvier et du 17 février 2012 Présentateur : Michel Gagné Club informatique Mont-Bruno Séances du 18 janvier et du 17 février 2012 Présentateur : Michel Gagné Le fonctionnement du courrier électronique La différence entre Internet, Web et courrier électronique

Plus en détail

1-Introduction 2. 2-Installation de JBPM 3. 2-JBPM en action.7

1-Introduction 2. 2-Installation de JBPM 3. 2-JBPM en action.7 Sommaire 1-Introduction 2 1-1- BPM (Business Process Management)..2 1-2 J-Boss JBPM 2 2-Installation de JBPM 3 2-1 Architecture de JOBSS JBPM 3 2-2 Installation du moteur JBoss JBPM et le serveur d application

Plus en détail

IBM Tivoli Monitoring, version 6.1

IBM Tivoli Monitoring, version 6.1 Superviser et administrer à partir d une unique console l ensemble de vos ressources, plates-formes et applications. IBM Tivoli Monitoring, version 6.1 Points forts! Surveillez de façon proactive les éléments

Plus en détail

TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile

TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile Dans ce TP, vous apprendrez à définir le type abstrait Pile, à le programmer en Java à l aide d une interface

Plus en détail

Retour d expériences avec UML

Retour d expériences avec UML Retour d expériences avec UML UML pour les systèmes biologiques Marie-Hélène Moirez-Charron, UMR AGIR, équipe MAGE INRA Toulouse mailto:[email protected] PLAN Contexte de travail UML,

Plus en détail

M1 : Ingénierie du Logiciel

M1 : Ingénierie du Logiciel M1 : Ingénierie du Logiciel UNIVERSITE PIERRE & MARIE CURIE (PARIS VI) Examen Réparti 2eme partie 16 Mai 2013 (2 heures avec documents : tous SAUF ANNALES CORRIGEES). Barème indicatif sur 20,5 points (max

Plus en détail

Chapitre 10. Architectures des systèmes de gestion de bases de données

Chapitre 10. Architectures des systèmes de gestion de bases de données Chapitre 10 Architectures des systèmes de gestion de bases de données Introduction Les technologies des dernières années ont amené la notion d environnement distribué (dispersions des données). Pour reliér

Plus en détail

Vérification formelle de la plate-forme Java Card

Vérification formelle de la plate-forme Java Card Vérification formelle de la plate-forme Java Card Thèse de doctorat Guillaume Dufay INRIA Sophia Antipolis Cartes à puce intelligentes Java Card : Environnement de programmation dédié. Dernières générations

Plus en détail

Auto-évaluation Programmation en Java

Auto-évaluation Programmation en Java Auto-évaluation Programmation en Java Document: f0883test.fm 22/01/2013 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INTRODUCTION AUTO-ÉVALUATION PROGRAMMATION EN

Plus en détail

Les Architectures Orientées Services (SOA)

Les Architectures Orientées Services (SOA) Les Architectures Orientées Services (SOA) Ulrich Duvent Guillaume Ansel Université du Littoral Côte d Opale 50, Rue Ferdinand Buisson BP 699 62228 Calais Cedex Téléphone (33) 03.21.46.36.92 Télécopie

Plus en détail

Analyse,, Conception des Systèmes Informatiques

Analyse,, Conception des Systèmes Informatiques Analyse,, Conception des Systèmes Informatiques Méthode Analyse Conception Introduction à UML Génie logiciel Définition «Ensemble de méthodes, techniques et outils pour la production et la maintenance

Plus en détail

WHITE PAPER Une revue de solution par Talend & Infosense

WHITE PAPER Une revue de solution par Talend & Infosense WHITE PAPER Une revue de solution par Talend & Infosense Master Data Management pour les données de référence dans le domaine de la santé Table des matières CAS D ETUDE : COLLABORATION SOCIALE ET ADMINISTRATION

Plus en détail

Rapport d évaluation du master

Rapport d évaluation du master Section des Formations et des diplômes Rapport d évaluation du master Etudes internationales de l Université Paris-Sud Vague E 2015-2019 Campagne d évaluation 2013-2014 Section des Formations et des diplômes

Plus en détail

Cours d introduction à l informatique. Partie 2 : Comment écrire un algorithme? Qu est-ce qu une variable? Expressions et instructions

Cours d introduction à l informatique. Partie 2 : Comment écrire un algorithme? Qu est-ce qu une variable? Expressions et instructions Cours d introduction à l informatique Partie 2 : Comment écrire un algorithme? Qu est-ce qu une variable? Expressions et instructions Qu est-ce qu un Une recette de cuisine algorithme? Protocole expérimental

Plus en détail

Eclipse atelier Java

Eclipse atelier Java Eclipse atelier Java Table des matières 1. Introduction...2 2. Télécharger eclipse...3 3. Installer eclipse...3 4. Premier lancement d eclipse...3 5. Configurer eclipse pour faire du Java...5 6. Développer

Plus en détail

Rappel. Analyse de Données Structurées - Cours 12. Un langage avec des déclaration locales. Exemple d'un programme

Rappel. Analyse de Données Structurées - Cours 12. Un langage avec des déclaration locales. Exemple d'un programme Rappel Ralf Treinen Université Paris Diderot UFR Informatique Laboratoire Preuves, Programmes et Systèmes [email protected] 6 mai 2015 Jusqu'à maintenant : un petit langage de programmation

Plus en détail

Prise en main rapide

Prise en main rapide Objectif terminal Réaliser un objet communicant Pourquoi? : 20 millards d objets connectés en 2020! Quelques mots sur l outil de développement App Inventor App Inventor pour Android est une application

Plus en détail

SQL Server Installation Center et SQL Server Management Studio

SQL Server Installation Center et SQL Server Management Studio SQL Server Installation Center et SQL Server Management Studio Version 1.0 Grégory CASANOVA 2 SQL Server Installation Center et SQL Server Management Studio [03/07/09] Sommaire 1 Installation de SQL Server

Plus en détail

Traduction des Langages : Le Compilateur Micro Java

Traduction des Langages : Le Compilateur Micro Java BARABZAN Jean-René OUAHAB Karim TUCITO David 2A IMA Traduction des Langages : Le Compilateur Micro Java µ Page 1 Introduction Le but de ce projet est d écrire en JAVA un compilateur Micro-Java générant

Plus en détail

Sauvegarde d une base de données

Sauvegarde d une base de données Sauvegarde d une base de données Version 1.0 Grégory CASANOVA 2 Sauvegarde d une base de données Sommaire 1 Introduction... 3 2 Différents types de sauvegarde... 4 2.1 Sauvegarde complète de base de données...

Plus en détail

Les diagrammes de modélisation

Les diagrammes de modélisation L approche Orientée Objet et UML 1 Plan du cours Introduction au Génie Logiciel L approche Orientée Objet et Notation UML Les diagrammes de modélisation Relations entre les différents diagrammes De l analyse

Plus en détail

UTILISER LA MESSAGERIE

UTILISER LA MESSAGERIE UTILISER LA MESSAGERIE OUTLOOK OU WINDOWS MAIL PRESENTATION DE LA MESSAGERIE CONDITIONS POUR UTILISER LE COURRIER ELECTRONIQUE Pour envoyer un courrier sur un PC il faut un programme ou un service de messagerie.

Plus en détail

Formation. Module WEB 4.1. Support de cours

Formation. Module WEB 4.1. Support de cours Formation Module WEB 4.1 Support de cours Rédacteur Date de rédaction F.CHEA 08/02/2012 Les informations contenues dans ce document pourront faire l'objet de modifications sans préavis Sauf mention contraire,

Plus en détail

Cette application développée en C# va récupérer un certain nombre d informations en ligne fournies par la ville de Paris :

Cette application développée en C# va récupérer un certain nombre d informations en ligne fournies par la ville de Paris : Développement d un client REST, l application Vélib 1. Présentation L application présentée permet de visualiser les disponibilités des vélos et des emplacements de parking à la disposition des parisiens

Plus en détail

Sélection du contrôleur

Sélection du contrôleur Démo CoDeSys - 1 - 1. Configuration de l environnement de travail : Lancer le logiciel CoDeSys Fichier Nouveau Lors de la première utilisation, une boîte de dialogue apparaît permettant la sélection du

Plus en détail

IFT2255 : Génie logiciel

IFT2255 : Génie logiciel IFT2255 : Génie logiciel Chapitre 6 - Analyse orientée objets Section 1. Introduction à UML Julie Vachon et Houari Sahraoui 6.1. Introduction à UML 1. Vers une approche orientée objet 2. Introduction ti

Plus en détail

Préparation à l installation d Active Directory

Préparation à l installation d Active Directory Laboratoire 03 Étape 1 : Installation d Active Directory et du service DNS Noter que vous ne pourrez pas réaliser ce laboratoire sans avoir fait le précédent laboratoire. Avant de commencer, le professeur

Plus en détail

eduscol Ressources pour la voie professionnelle Français Ressources pour les classes préparatoires au baccalauréat professionnel

eduscol Ressources pour la voie professionnelle Français Ressources pour les classes préparatoires au baccalauréat professionnel eduscol Ressources pour la voie professionnelle Ressources pour les classes préparatoires au baccalauréat professionnel Français Présentation des programmes 2009 du baccalauréat professionnel Ces documents

Plus en détail

SIP. Plan. Introduction Architecture SIP Messages SIP Exemples d établissement de session Enregistrement

SIP. Plan. Introduction Architecture SIP Messages SIP Exemples d établissement de session Enregistrement SIP Nguyen Thi Mai Trang LIP6/PHARE [email protected] UPMC - M2 Réseaux - UE PTEL 1 Plan Introduction Architecture SIP Messages SIP Exemples d établissement de session Enregistrement UPMC -

Plus en détail

Qu est-ce qu une tâche?

Qu est-ce qu une tâche? Qu est-ce qu une tâche? «Tâches», «Perspective actionnelle», «activités centrées sur le sens» Ce sont des concepts dont on entend beaucoup parler dans notre profession, mais que signifient-ils exactement?

Plus en détail

Iyad Alshabani SysCom - CReSTIC Université de Reims 17/02/2011 1

Iyad Alshabani SysCom - CReSTIC Université de Reims 17/02/2011 1 SysCom - CReSTIC Université de Reims 17/02/2011 1 Motivation Gestion des expérimentations Avec les workflows Simulation Simulation des Systèmes Distribués ANR USS SimGrid Campagne de Test et gestion de

Plus en détail

Objet du document. Version document : 1.00

Objet du document. Version document : 1.00 Version document : 1.00 Objet du document Les dix points de cet article constituent les règles à connaitre pour intégrer une application au sein d AppliDis. Le site des Experts Systancia comporte également

Plus en détail

Organisation de dispositifs pour tous les apprenants : la question de l'évaluation inclusive

Organisation de dispositifs pour tous les apprenants : la question de l'évaluation inclusive Organisation de dispositifs pour tous les apprenants : la question de l'évaluation inclusive Transcription et traduction de la communication de Verity DONNELLY colloque Éducation inclusive, la question

Plus en détail

TD n o 8 - Domain Name System (DNS)

TD n o 8 - Domain Name System (DNS) IUT Montpellier - Architecture (DU) V. Poupet TD n o 8 - Domain Name System (DNS) Dans ce TD nous allons nous intéresser au fonctionnement du Domain Name System (DNS), puis pour illustrer son fonctionnement,

Plus en détail

Méthode universitaire du commentaire de texte

Méthode universitaire du commentaire de texte Méthode universitaire du commentaire de texte Baptiste Mélès Novembre 2014 L objectif du commentaire de texte est de décrire la structure argumentative et de mettre au jour les concepts qui permettent

Plus en détail

Projet L1, S2, 2015: Simulation de fourmis, Soutenance la semaine du 4 mai.

Projet L1, S2, 2015: Simulation de fourmis, Soutenance la semaine du 4 mai. Projet L1, S2, 2015: Simulation de fourmis, Soutenance la semaine du 4 mai. 1 Introduction On considère une grille de 20 lignes 20 colonnes. Une case de la grille peut être vide, ou contenir une et une

Plus en détail

Messagerie asynchrone et Services Web

Messagerie asynchrone et Services Web Article Messagerie asynchrone et Services Web 1 / 10 Messagerie asynchrone et Services Web SOAP, WSDL SONT DES STANDARDS EMERGEANT DES SERVICES WEB, LES IMPLEMENTATIONS DE CEUX-CI SONT ENCORE EN COURS

Plus en détail

Manuel de System Monitor

Manuel de System Monitor Chris Schlaeger John Tapsell Chris Schlaeger Tobias Koenig Traduction française : Yves Dessertine Traduction française : Philippe Guilbert Traduction française : Robin Guitton Relecture de la documentation

Plus en détail

Premiers Pas en Programmation Objet : les Classes et les Objets

Premiers Pas en Programmation Objet : les Classes et les Objets Chapitre 2 Premiers Pas en Programmation Objet : les Classes et les Objets Dans la première partie de ce cours, nous avons appris à manipuler des objets de type simple : entiers, doubles, caractères, booléens.

Plus en détail