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

Cours Systèmes Multi-Agents

Cours Systèmes Multi-Agents Un système multi-agents «Un Système Multi-Agents(SMA) comporte plusieurs agents qui interagissent entre eux dans un environnement commun. Certains de ces agents peuvent être des personnes ou leurs représentants

Plus en détail

Communication par messages dans les systèmes multi-agents

Communication par messages dans les systèmes multi-agents Communication par messages dans les systèmes multi-agents Jacques Ferber LIRMM - Université Montpellier II 161 rue Ada 34292 Montpellier Cedex 5 Email: ferber@lirmm.fr Home page: www.lirmm.fr/~ferber Version

Plus en détail

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 MDA : Un Tutoriel Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 1 Sommaire Table des matières 1 Sommaire 1 2 Introduction 2 2.1 A qui s adresse ce tutoriel......................

Plus en détail

Une application de commerce électronique en utilisant CLAIM

Une application de commerce électronique en utilisant CLAIM Rapport du projet A4MA Une application de commerce électronique en utilisant CLAIM Étudiants : DINH Quang Ninh (dinhquangninh@gmail.com) PHAM Trong-Tôn (trongtonfr@yahoo.fr) Wiki : http://dev.deptrai.org/wiki/doku.php?id=projet_a4ma:start

Plus en détail

Les Systèmes Multi-Agents

Les Systèmes Multi-Agents Les Systèmes Multi-Agents Définition d un SMA Un système multi-agents est un ensemble organisé d agents. Il est constitué d une ou plusieurs organisations qui structurent les règles de cohabitation et

Plus en détail

JADE : Java Agent DEvelopment framework. Laboratoire IBISC & Départ. GEII Université & IUT d Evry nadia.abchiche@ibisc.univ-evry.

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 nadia.abchiche@ibisc.univ-evry.fr Introduction à la plateforme JADE 1) Modèle d agent 2) Services 3) Norme FIPA

Plus en détail

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

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

GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

GÉNIE LOGICIEL (SOFTWARE ENGINEERING) GÉNIE LOGICIEL (SOFTWARE ENGINEERING) 5ÈME PARTIE UML (UNIFIED MODELING LANGUAGE) Faculté des Sciences et Techniques http://labh-curien.univ-st-etienne.fr/~fj/gl Francois.Jacquenet@univ-st-etienne.fr Plan

Plus en détail

Rappels sur l objet. Yannick Prié Département Informatique - UFR Sciences et Techniques Université Claude Bernard Lyon 1 2011-2012

Rappels sur l objet. Yannick Prié Département Informatique - UFR Sciences et Techniques Université Claude Bernard Lyon 1 2011-2012 Rappels sur l objet Yannick Prié Département Informatique - UFR Sciences et Techniques Université Claude Bernard Lyon 1 2011-2012 Objectifs de ce cours 2 Rappels sur les concepts fondamentaux liés à la

Plus en détail

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium dans le cadre du projet JASMINe Avril 2008 Table des matières 1 Introduction 3 1.1 Rappel sur JASMINe.......................................

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

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

Document de réalisation Mise en œuvre d une infrastructure de sécurité dans une architecture orientée services

Document de réalisation Mise en œuvre d une infrastructure de sécurité dans une architecture orientée services Document de réalisation Mise en œuvre d une infrastructure de sécurité dans une architecture orientée services Version : 0.9 Auteurs : Olivier MALGRAS Anne-Sophie TRANCHET Encadrants : Olivier PERRIN Aymen

Plus en détail

RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005

RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005 Oussama ELKACHOINDI Wajdi MEHENNI RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005 Sommaire I. Préliminaire : Notice d exécution et mode opératoire...4 II. Architecture globale de l application...5

Plus en détail

Besoin de concevoir des systèmes massivement répartis. Comment tester le système? Solution. Évaluation de systèmes répartis à large échelle

Besoin de concevoir des systèmes massivement répartis. Comment tester le système? Solution. Évaluation de systèmes répartis à large échelle Besoin de concevoir des systèmes massivement répartis. Évaluation de systèmes répartis à large échelle Sergey Legtchenko Motivation : LIP6-INRIA Tolérance aux pannes Stockage de données critiques Coût

Plus en détail

Chapitre 4: Systèmes Multiagents

Chapitre 4: Systèmes Multiagents Chapitre 4: Systèmes Multiagents Dr. Benmerzoug D. Département TLSI Faculté des NTIC Université Constantine 2 INTA - Master 2 - Recherche 124 Systèmes Multi-agents Plan: Intelligence Artificielle (IA)

Plus en détail

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base SOA et Services Web 23 octobre 2011 1 SOA: Concepts de base 2 Du client serveur à la SOA N est Nest pas une démarche entièrement nouvelle: années 1990 avec les solutions C/S Besoins d ouverture et d interopérabilité

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

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

S. Laporte C# mode console DAIGL TS1

S. Laporte C# mode console DAIGL TS1 Bases du langage C# I. C# en mode console (mode texte) Avantages par rapport au mode graphique (Application Windows): - C'est un mode plus proche de l'approche algorithmique (pas de notions de composants,

Plus en détail

Groupe Eyrolles, 2001, 2003, 2004, ISBN : 2-212-11480-X

Groupe Eyrolles, 2001, 2003, 2004, ISBN : 2-212-11480-X Groupe Eyrolles, 2001, 2003, 2004, ISBN : 2-212-11480-X Chapitre 6 Exercices corrigés et conseils méthodologiques Mots-clés Activité continue/finie Transition automatique Contexte statique Événements «after»

Plus en détail

TP1:Priseenmaind Eclipse,élémentsdebasede java

TP1:Priseenmaind Eclipse,élémentsdebasede java TP1:Priseenmaind Eclipse,élémentsdebasede java jean-baptiste.vioix@iut-dijon.u-bourgogne.fr R&T 2ème année Vousavezàvotredisposition(surlerépertoirecommun):lecours,lesTDs, et quelques documents provenant

Plus en détail

Analyse abstraite de missions sous PILOT

Analyse abstraite de missions sous PILOT Analyse abstraite de missions sous PILOT Damien Massé EA 3883, Université de Bretagne Occidentale, Brest damien.masse@univ-brest.fr Résumé Nous étudions la possibilité de réaliser un analyseur par interprétation

Plus en détail

Master Sciences et technologies Mention MI : Management de l Innovation

Master Sciences et technologies Mention MI : Management de l Innovation Master Sciences et technologies Mention MI : Management de l Innovation M2 Spécialité Ingénierie et Management de la Formation (IMFL ) Présentation des UE UE de spécialité UE1 «Management des connaissances

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 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

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

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 yrg@pps.univ-paris-diderot.fr Université Paris Diderot Paris 7 2/65 1. Sortez un appareil qui peut se rendre

Plus en détail

Service combinators for farming virtual machines

Service combinators for farming virtual machines Master d Informatique Fondamentale École Normale Supérieure de Lyon Sémantique du parallélisme Chantal Keller Service combinators for farming virtual machines K. Bhargavan, A. D. Gordon, I. Narasamdya

Plus en détail

RAPPORT DE STAGE «FAIRE RESPECTER UNE PROPRIÉTÉ EXPRIMÉE SOUS FORME D AUTOMATE TEMPORISÉ»

RAPPORT DE STAGE «FAIRE RESPECTER UNE PROPRIÉTÉ EXPRIMÉE SOUS FORME D AUTOMATE TEMPORISÉ» Université Joseph Fourier Département Licence Sciences & Technologie RAPPORT DE STAGE «FAIRE RESPECTER UNE PROPRIÉTÉ EXPRIMÉE SOUS FORME D AUTOMATE TEMPORISÉ» VISAN Vlad Laboratoire d accueil : Verimag

Plus en détail

ASR9 Application de prise de notes basée sur LDP et RWW.io

ASR9 Application de prise de notes basée sur LDP et RWW.io TELECOM SudParis ASR9 Application de prise de notes basée sur LDP et RWW.io Encadrant Olivier Berger Thomas SMAGGHE et Alexis TERRAT Table des matières Présentation du projet... 2 1.1 Contexte... 2 1.2

Plus en détail

Modélisation et conception d'un. environnement de suivi pédagogique synchrone. d'activités d'apprentissage à distance

Modélisation et conception d'un. environnement de suivi pédagogique synchrone. d'activités d'apprentissage à distance Modélisation et conception d'un environnement de suivi pédagogique synchrone d'activités d'apprentissage à distance Christophe DESPRÉS Laboratoire d Informatique de l'université du Maine Plan de la présentation

Plus en détail

12. Conception des applications

12. Conception des applications Conception objet en Java avec BlueJ une approche interactive 12. Conception des applications David J. Barnes, Michael Kölling version française: Patrice Moreaux Rédigé avec 1.0 Principaux concepts abordés

Plus en détail

Architecture Logicielle

Architecture Logicielle Architecture Logicielle Chapitre 3: UML pour la description et la documentation d une architecture logicielle Année universitaire 2013/2014 Semestre 1 Rappel L architecture d un programme ou d un système

Plus en détail

Sollaud Timothée Girard Alexis. Rapport de projet

Sollaud Timothée Girard Alexis. Rapport de projet Sollaud Timothée Girard Alexis Rapport de projet 20 avril 2012 Table des matières Introduction 3 1 Présentation du projet......................................... 3 2 Présentation de l environnement de

Plus en détail

Envoyer un courrier électronique et autres fonctions associées

Envoyer un courrier électronique et autres fonctions associées 19 février 2013 p 1 Envoyer un courrier électronique et autres fonctions associées Ce tutoriel vient compléter celui présenté le 5 février 2013, portant sur les généralités du courrier électronique. Nous

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

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

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

Sylvain Archenault Yves Houpert. Projet Informatique : Langage Java : Jeu De Dames en Java

Sylvain Archenault Yves Houpert. Projet Informatique : Langage Java : Jeu De Dames en Java Sylvain Archenault Yves Houpert Projet Informatique : Langage Java : Jeu De Dames en Java Projet GM3 Mai 2005 Chapitre 1 INTRODUCTION Le projet qui nous a été confié est de réaliser un jeu de dames en

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

Réalisation d un serveur CTI-CSTA sur TCP/IP

Réalisation d un serveur CTI-CSTA sur TCP/IP Alcôve http://www.alcove.fr 1/28 Réalisation d un serveur CTI-CSTA sur TCP/IP Julien Gaulmin Cette présentation est librement diffusable sous les termes de la GNU Free Documentation

Plus en détail

Conception de la base de données

Conception de la base de données Rapport T.E.R HLIN405 Conception de la base de données des projets de licence deuxième et troisième année Réalisé par Achraf Tajani Cvete Maceski Mohamed Bareche Sous l encadrement de Christian Retoré

Plus en détail

Implémentation d une couche MAC (accès au support) dans OMNET++/Castalia pour des réseaux de capteurs pour la surveillance.

Implémentation d une couche MAC (accès au support) dans OMNET++/Castalia pour des réseaux de capteurs pour la surveillance. Implémentation d une couche MAC (accès au support) dans OMNET++/Castalia pour des réseaux de capteurs pour la surveillance. DOS SANTOS Leonel et LALANNE Clément 6 mai 2011 Master Informatique Technologies

Plus en détail

Généralités sur les bases de données

Généralités sur les bases de données Généralités sur les bases de données Qu est-ce donc qu une base de données? Que peut-on attendre d un système de gestion de bases de données? Que peut-on faire avec une base de données? 1 Des données?

Plus en détail

Projet de cryptographie. Algorithme de cryptage de type Bluetooth

Projet de cryptographie. Algorithme de cryptage de type Bluetooth Projet de cryptographie Algorithme de cryptage de type Bluetooth Le but de ce projet est de créer une application qui crypte et décrypte des fichiers en utilisant le principe de cryptage du Bluetooth.

Plus en détail

Gestion d une école. FABRE Maxime FOUCHE Alexis LEPOT Florian

Gestion d une école. FABRE Maxime FOUCHE Alexis LEPOT Florian Gestion d une école FABRE Maxime 2015 Sommaire Introduction... 2 I. Présentation du projet... 3 1- Lancement de l application... 3 Fonctionnalités réalisées... 4 A. Le serveur... 4 1 - Le réseau... 4 2

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 agent d une Architecture Logicielle de commande d un Véhicule Autonome

Modélisation agent d une Architecture Logicielle de commande d un Véhicule Autonome Modélisation agent d une Architecture Logicielle de commande d un Véhicule Autonome ENNAJI Mourad LASC université de Metz Ile du Saulcy B.P 80794 57 012 METZ Ennaji@lasc.sciences.univ-metz.fr Résumé Cet

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

Rapport de Projet Vincent Sallé - Steven Thillier - Jeremy Torres Le deviseur Cs2icar Cs2i 9 avril 2012

Rapport de Projet Vincent Sallé - Steven Thillier - Jeremy Torres Le deviseur Cs2icar Cs2i 9 avril 2012 Rapport de Projet Vincent Sallé - Steven Thillier - Jeremy Torres Le deviseur Cs2icar Cs2i 9 avril 2012 VS - ST - JT Adresse électronique : jrmy.torres@gmail.com Cs2i Sommaire Étude préalable 2 Contexte

Plus en détail

RAPPORT DE STAGE Calcul parallèle sur GPU

RAPPORT DE STAGE Calcul parallèle sur GPU Université Joseph Fourier Département Licence Sciences & Technologie RAPPORT DE STAGE Calcul parallèle sur GPU D Aguanno Carlotta Laboratoire d accueil : INRIA Directeur du laboratoire : GROS Patrick Responsable

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

Système d exploitation

Système d exploitation Chapitre 2 Système d exploitation 2.1 Définition et rôle Un ordinateur serait bien difficile à utiliser sans interface entre le matériel et l utilisateur. Une machine peut exécuter des programmes, mais

Plus en détail

Information utiles. cinzia.digiusto@gmail.com. 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 : cinzia.digiusto@gmail.com webpage : http://www.ibisc.univ-evry.fr/ digiusto/ Google+ : https://plus.google.com/u/0/b/103572780965897723237/

Plus en détail

Description et illustration du processus unifié

Description et illustration du processus unifié USDP Description et illustration du processus unifié Définit un enchaînement d activités Est réalisé par un ensemble de travailleurs Avec des rôles, des métiers Avec pour objectifs de passer des besoins

Plus en détail

SDL: 20 ans de programmation basée modèle

SDL: 20 ans de programmation basée modèle SDL: 20 ans de programmation basée modèle Emmanuel Gaudin emmanuel.gaudin @ pragmadev.com Principes MDE, MDA et MDD: Approche orienté modèle PIM: Platform Independant Model PDM: Platform Definition Model

Plus en détail

CSC4002 : Contrôle continu «Bureau d Étude noté» Date : lundi 3 décembre 2012 Durée : 2H. Coordonnateurs : Christian Bac et Denis Conan

CSC4002 : Contrôle continu «Bureau d Étude noté» Date : lundi 3 décembre 2012 Durée : 2H. Coordonnateurs : Christian Bac et Denis Conan Corrigé et Barème Contrôle de connaissances 2012/2013 des étudiants de 2 è année (EI2) CSC4002 : Contrôle continu «Bureau d Étude noté» Date : lundi 3 décembre 2012 Durée : 2H Coordonnateurs : Christian

Plus en détail

ech-0022 Normes en géoinformation

ech-0022 Normes en géoinformation Normes en cyberadministration Page 1 de 13 ech-0022 Normes en géoinformation Titre Code Type Stade Version 1.10 Statut Normes en géoinformation ech-0022 norme de procédure déployée approuvée Validation

Plus en détail

Université Laval Faculté des sciences et de génie Département d'informatique et de génie logiciel IFT-3101. Travail pratique #2

Université Laval Faculté des sciences et de génie Département d'informatique et de génie logiciel IFT-3101. Travail pratique #2 Université Laval Faculté des sciences et de génie Département d'informatique et de génie logiciel IFT-3101 Danny Dubé Hiver 2014 Version : 11 avril Questions Travail pratique #2 Traduction orientée-syntaxe

Plus en détail

Présentation du projet:

Présentation du projet: : Le but du projet est de réaliser le fonctionnement d'un jeu d échec valide. Plus spécifiquement, il consiste à implémenter l'organisation générale du jeu, et le suivi des règles du mouvement des pièces.

Plus en détail

Partie 4 Créer des parcours pédagogiques

Partie 4 Créer des parcours pédagogiques Partie 4 Créer des parcours pédagogiques Un parcours pédagogique est une séquence d'apprentissage découpée en sections contenant ellesmêmes des activités ou objets d apprentissage. Il peut être organisé

Plus en détail

Systèmes d Information Avancés (et répartis)

Systèmes d Information Avancés (et répartis) Systèmes d Information Avancés (et répartis) Université Lyon 1 MIAGE L. Médini, mars 2005 Plan des cours Protocole HTTP et programmation serveur Architectures réparties Objets distribués Introduction aux

Plus en détail

Fungus VALVASSORI MOÏSE. 9 avril 2004

Fungus VALVASSORI MOÏSE. 9 avril 2004 Fungus VALVASSORI MOÏSE 9 avril 2004 Plan 1. Vie Artificielle 2. Plateforme de simulation 3. Travaux et perspectives 9 avril 2004 séminaire IARM - P8 Valvassori Moïse 1 Vie Artificielle biologie du possible

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

Planification et coordination multiagents sous incertitude

Planification et coordination multiagents sous incertitude Planification et coordination multiagents sous incertitude Aurélie Beynier CoCoMa, Master 2 ANDROIDE 4 novembre 2014 Les plateformes agents Faciliter la mise en place d applications basées sur les systèmes

Plus en détail

INF-130 Travail Pratique #2

INF-130 Travail Pratique #2 École de technologie supérieure INF-30 Travail Pratique #2 Travail individuel Tracé d un métro Francis Bourdeau, Frédérick Henri et Patrick Salois Remise à la 0 e semaine. Objectifs - Amener l étudiant

Plus en détail

LI5a : Développement de programmes (A. Slissenko)

LI5a : Développement de programmes (A. Slissenko) 1 Licence 3 Info LI5a : Développement de programmes (A. Slissenko) Corrigé 1. (1a). Expliquez brièvement à quoi sert la spécification des requis, comment elle peut être décrite et comment elle peut être

Plus en détail

CSC4002 : Contrôle Final Session 1. Date : jeudi 26 janvier 2012 Durée : 1H30. Coordonnateurs : Christian Bac et Denis Conan

CSC4002 : Contrôle Final Session 1. Date : jeudi 26 janvier 2012 Durée : 1H30. Coordonnateurs : Christian Bac et Denis Conan Corrigé et Barème Contrôle de connaissances 2011/2012 des étudiants de 2 è année (EI2) CSC4002 : Contrôle Final Session 1 Date : jeudi 26 janvier 2012 Durée : 1H30 Coordonnateurs : Christian Bac et Denis

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

Algorithmique Programmation

Algorithmique Programmation Algorithmique Programmation 2ème partie DUT en alternance CNAM 2007-2008 2 Table des matières 1 Premiers Pas en Programmation Objet : les Classes et les Objets 7 1.1 Définir une Classe........................................

Plus en détail

5SINF200 : Développement de programmes (A. Slissenko) Examen

5SINF200 : Développement de programmes (A. Slissenko) Examen Licence Info Corrigé 5SINF200 : Développement de programmes (A. Slissenko) Examen Le 21 décembre 2006, 13h30 15h30 Utilisation des notes, des livres, des docs, etc. autorisée. Ce corrigé contient des réponses

Plus en détail

Algorithmie ISI301 TP 1 : Python et premiers algorithmes

Algorithmie ISI301 TP 1 : Python et premiers algorithmes Algorithmie ISI301 TP 1 : Python et premiers algorithmes 1 Python : apprentissage Pour avoir une vision plus large des différentes possibilités du langage Python, nous ne pouvons que vous conseiller d

Plus en détail

Professeur-superviseur Alain April

Professeur-superviseur Alain April RAPPORT TECHNIQUE PRÉSENTÉ À L ÉCOLE DE TECHNOLOGIE SUPÉRIEURE DANS LE CADRE DU COURS LOG792 PROJET DE FIN D ÉTUDES EN GÉNIE LOGICIEL PHP PROJECT TRACKER GESTIONNAIRE DE PROJECT LOGICIEL LOUIS-ALEXANDRE

Plus en détail

Les principaux domaines de l informatique

Les principaux domaines de l informatique Les principaux domaines de l informatique... abordés dans le cadre de ce cours: La Programmation Les Systèmes d Exploitation Les Systèmes d Information La Conception d Interfaces Le Calcul Scientifique

Plus en détail

Programmation orientée domaine pour les services télécoms: Concepts, DSL et outillage

Programmation orientée domaine pour les services télécoms: Concepts, DSL et outillage Programmation orientée domaine pour les services télécoms: Concepts, DSL et outillage Areski Flissi Gilles Vanwormhoudt LIFL/CNRS (UMR 8022) Institut TELECOM 59655 Villeneuve d Ascq 59655 Villeneuve d

Plus en détail

Réunion GDS 13 octobre 2006

Réunion GDS 13 octobre 2006 École normale supérieure de Lyon Réunion GDS 13 octobre 2006 Plan Introduction 1 Introduction 2 3 4 5 6 Les workflows Ensemble de tâches connectées La structure du workflow représente la relation temporelle

Plus en détail

À propos de l intégration continue dans Xcode

À propos de l intégration continue dans Xcode À propos de l intégration continue dans Xcode Table des matières À propos de l intégration continue dans Xcode 4 En bref 4 Installer et configurer le service Xcode 4 Connecter le service Xcode aux dépôts

Plus en détail

Un modèle multi-agents pour la gestion des connaissances

Un modèle multi-agents pour la gestion des connaissances Un modèle multi-agents pour la gestion des connaissances Pierre Maret, Département Informatique et LIRIS, INSA de Lyon Jacques Calmet, IAKS, Université de Karlsruhe, Allemagne Le principe général sous-jacent

Plus en détail

M3301-2: Méthodologie de la production de logiciels Modélisation et construction des logiciels (C. Attiogbé) Travaux dirigés/pratiques - 2015/2016

M3301-2: Méthodologie de la production de logiciels Modélisation et construction des logiciels (C. Attiogbé) Travaux dirigés/pratiques - 2015/2016 M3301-2: Méthodologie de la production de logiciels Modélisation et construction des logiciels (C. Attiogbé) Travaux dirigés/pratiques - 2015/2016 encadrés par Christian Attiogbé, Amine Aouadhi Cahier

Plus en détail

Travaux Pratiques Conception de systèmes Interactifs (Ph. Truillet) septembre 2014 v. 1.7

Travaux Pratiques Conception de systèmes Interactifs (Ph. Truillet) septembre 2014 v. 1.7 http://www.irit.fr/~philippe.truillet Travaux Pratiques Conception de systèmes Interactifs (Ph. Truillet) septembre 2014 v. 1.7 Nota : ces TPs sont inspirés de ceux de Wendy MacKay, utilisés lors de l

Plus en détail

Systèmes d exploitation. Introduction. (Operating Systems) http://www.sir.blois.univ-tours.fr/ mirian/

Systèmes d exploitation. Introduction. (Operating Systems) http://www.sir.blois.univ-tours.fr/ mirian/ Systèmes d exploitation (Operating Systems) Introduction SITE : http://www.sir.blois.univ-tours.fr/ mirian/ Systèmes d exploitation - Mírian Halfeld-Ferrari p. 1/2 Qu est-ce qu un SE? Ensemble de logiciels

Plus en détail

Industrialisation des développements Spring dans Eclipse

Industrialisation des développements Spring dans Eclipse C Industrialisation des développements Spring dans Eclipse L objectif de cette annexe est de décrire comment mettre en œuvre une approche dirigée par les modèles afin d industrialiser les développements

Plus en détail

Diplôme : Licence Informatique

Diplôme : Licence Informatique Diplôme : Licence Informatique Développement d un module d authentification pour une application WEB Sous la direction de : Encadreur(s) Académiques Mme Sogoba Jacqueline KONATE Mr Adama COULIBALY Encadreur(s)

Plus en détail

ALEM: Un Modèle de Référence pour les Applications Web Adaptatif Educatif

ALEM: Un Modèle de Référence pour les Applications Web Adaptatif Educatif ALEM: Un Modèle de Référence pour les Applications Web Adaptatif Educatif Mohammed TADLAOUI 1, Azzedine CHIKH 2, Karim Bouamrane 1 1 Université d Oran, Algérie, 2 Université de King Saud, Royaume d'arabie

Plus en détail

Environnements de développement (intégrés)

Environnements de développement (intégrés) Environnements de développement (intégrés) Développement de greffons Patrick Labatut labatut@di.ens.fr http://www.di.ens.fr/~labatut/ Département d informatique École normale supérieure Centre d enseignement

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

Modbus 06/05/2013. Version 1.3

Modbus 06/05/2013. Version 1.3 06/05/2013 Version 1.3 Le protocole Modbus TCP, mode «Maître» Table des matières 1 Pré-requis... 3 2 Connecteur Modbus... 3 2.1 Ajout d un connecteur Modbus TCP... 3 2.2 Configuration d un connecteur Modbus

Plus en détail

Les patrons de conception décrivent des solutions standards pour répondre à des problèmes d'architecture et de conception des logiciels.

Les patrons de conception décrivent des solutions standards pour répondre à des problèmes d'architecture et de conception des logiciels. Design Pattern En génie Logiciel, un patron de conception (design pattern en anglais) est un concept destiné à résoudre les problèmes récurrents suivant le paradigme objet. En français on utilise aussi

Plus en détail

L INFORMATION GEOGRAPHIQUE

L INFORMATION GEOGRAPHIQUE Champs sur Marne ENSG/CERSIG Le 19-nove.-02 L INFORMATION GEOGRAPHIQUE Archivage Le Système d information géographique rassemble de l information afin de permettre son utilisation dans des applications

Plus en détail

MEGA TeamWork. Guide d utilisation

MEGA TeamWork. Guide d utilisation MEGA TeamWork Guide d utilisation MEGA 2009 SP4 1ère édition (juin 2010) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis et ne sauraient en aucune manière

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

Composition de Services Web

Composition de Services Web Composition de Services Web Dr. Djamel Benmerzoug Email : djamel.benmerzoug@univ-constantine2.dz Maitre de Conférences A, Département TLSI Faculté des NTIC Université Constantine 2 Abdelhamid Mehri 127

Plus en détail

Document de Spécifications Logiciel

Document de Spécifications Logiciel Document de Spécifications Logiciel FALLET Laurent JOUANNO Guillaume MALLET Grégory MARTEAU Sylvie MORISSET Samuel 6 juin 2003 Pour voir toutes les figures présentes dans ce document en une qualité optimum,

Plus en détail

Impact du choix du SGBD et de l architecture client-serveur pour garantir le service d un SGBD mis sous forte charge concurrente

Impact du choix du SGBD et de l architecture client-serveur pour garantir le service d un SGBD mis sous forte charge concurrente Impact du choix du SGBD et de l architecture client-serveur pour garantir le service d un SGBD mis sous forte charge Travail de diplôme réalisé en vue de l obtention du diplôme HES par : Muhammad Maqbool

Plus en détail

Compte-Rendu SDL. «Reprise de l application de gestion de listes de présences des alternants»

Compte-Rendu SDL. «Reprise de l application de gestion de listes de présences des alternants» Compte-Rendu SDL Auteurs : BOUTROUILLE Alexis BAILLEUL Pierre Tuteur : Ioan Marius Bilasco «Reprise de l application de gestion de listes de présences des alternants» Master MIAGE 1 Année 2012/2013 1 Remerciements

Plus en détail

AVATAR. Un profil SysML temps réel outillé

AVATAR. Un profil SysML temps réel outillé AVATAR Un profil SysML temps réel outillé Ludovic Apvrille, Pierre de Saqui-Sannes ludovic.apvrille@telecom-paristech.fr pdss@isae.fr SysML France, 6 décembre 2010 Agenda De TURTLE à AVATAR Le langage

Plus en détail

CONNECTIVITÉ. Options de connectivité de Microsoft Dynamics AX. Microsoft Dynamics AX. Livre blanc

CONNECTIVITÉ. Options de connectivité de Microsoft Dynamics AX. Microsoft Dynamics AX. Livre blanc CONNECTIVITÉ Microsoft Dynamics AX Options de connectivité de Microsoft Dynamics AX Livre blanc Ce document décrit les possibilités offertes par Microsoft Dynamics AX en terme de connectivité et de montée

Plus en détail

G. Lesauvage. Laboratoire d Informatique et du Traitement de l Information et des Systèmes

G. Lesauvage. Laboratoire d Informatique et du Traitement de l Information et des Systèmes Gestion dynamique des activités des chariots cavaliers sur un terminal portuaire à conteneurs en environnement incertain - approche par intelligence collective - G. Lesauvage Unité de Formation et de Recherche

Plus en détail