Ministère de l'Education Nationale

Université de Montpellier II

Rapport de Projet Informatique FMIN200 Du Master informatique 1ere année

Editeur d’agents à base de machines à états finis

Etudiants : Garbin Grégory Bedel-Navarro Grégory Mirasoa Ranaivo

Encadrant : Ferber Jacques

VisualKit

1

Remerciements

Nous tenons à remercier M. Ferber pour l'aide et les explications qu'il nous

a données tout au long du projet. Sa patience et son implication nous a permis de le mener à bien.

VisualKit

2

Sommaire

1. Introduction........................................................................................................ 3 2. Présentation ....................................................................................................... 4 3. Objectifs.............................................................................................................. 4 4. Cahier des charges .......................................................................................... 5 5. Organisation du travail..................................................................................... 6 5.1. Diagramme de Gant .................................................................................... 6 5.2. Répartition des tâches.................................................................................. 7 5.3. Outils de développement............................................................................ 9

6. Etude de l'existant ........................................................................................... 10 6.1. SEdit ............................................................................................................... 10 6.2. Warbot .......................................................................................................... 10 6.3. Automaton ................................................................................................... 11

7. Conception...................................................................................................... 12 7.1. La structure ................................................................................................... 12 7.2. Les états ........................................................................................................ 12 7.3. Les liaisons..................................................................................................... 13 7.4. Les transitions................................................................................................ 13 7.5. La compilation ............................................................................................. 18

8. Développement.............................................................................................. 21 8.1. Structure de données ................................................................................. 21 8.2. Structure de VisualKit .................................................................................. 22 8.3. Les Transitions ............................................................................................... 24 8.4. Les Actions .................................................................................................... 27 8.5. Le Formalisme de Visualkit ......................................................................... 28 8.6. La sauvegarde du diagramme................................................................. 30

9. Mode d’emploi................................................................................................ 33 9.1. Installation..................................................................................................... 33 9.2. Utilisation ....................................................................................................... 33

10. Conclusion et perspectives ........................................................................... 35 11. Annexes ............................................................................................................ 36 11.1. Diagramme UML de la structure de VisualKit...................................... 36 11.2. Formalisme de VisualKit........................................................................... 37 11.3. Sauvegarde du modèle ......................................................................... 38 11.4. Sauvegarde de SEdit............................................................................... 39

VisualKit

3

1. Introduction

MadKit est une plateforme de développement multi-agent. Elle contient

plusieurs plate-formes de développement, dont notamment Warbot, un logiciel de simulation de combat. Le but est d'implémenter (en Java ou en Python) le comportement d'une équipe d'agents pour qu'elle détruise ses adversaires. Ces agents fonctionnent avec un système de perceptions. Ils ont tous une vision locale de leur environnment mais, peuvent communiquer avec d'autres agents Warbot.

A l'heure actuelle, il faut coder le comportement de ces agents. Le but de ce projet est donc de créer une interface permettant de générer le code de ce type d'agent, tout en gérant les fonctionnalités qu'ils possèdent (perception, communication). Le code créé doit être structuré comme une machine à état fini (état-transition).

Il faut donc associer à cette interface un formalisme graphique reprenant ce principe.

VisualKit

4

2. Présentation

MadKit est une plateforme multi agent codée en Java, et fait sur le

modèle d'organisation Agent/Groupe/Rôle (AGR : les agents ont des rôles et forment des groupes).

Il contient une plateforme spécifique (TurtleKit) pour la programmation de machine à états finis (FSM). Ce genre d'agent évolue en passant d'un état à un autre, selon des conditions.

Grâce à MadKit, on peut réaliser des logiciels tels que Warbot. C'est une simulation de combat entre robots dans laquelle il faut « coder » le comportement du robot pour que son équipe puisse remporter le combat. Ce type d'agent n'a qu'une perception locale de son environnement (pas d'accès à l'état global) mais communique directement avec les autres agents. Ce genre d'agent évolue donc directement en fonction de la perception de son environnement, et non en fonction de conditions diverses comme les machines à états finis.

Son comportement dépend directement de l'environnement qu'il perçoit (sous forme de signaux).

Le logiciel fonctionne en mode distribué de manière transparente à partir d'une architecture "peer to peer" sans nécessiter de serveur dédié. Cela sert à faire communiquer des agents à distance sans avoir à se préoccuper des problèmes de communication qui sont gérés par la plate-forme.

MadKit contient aussi SEdit, qui est un logiciel permettant de créer des formalismes graphiques

3. Objectifs

Notre but est d'ajouter une fonctionnalité à MadKit permettant d'éditer et

de créer des agents à partir d'un formalisme graphique que nous devons définir. Il s'agit donc de créer un compilateur de modèles graphique en code utilisable sous MadKit (Python ou Java).

Le modèle graphique sera dans un premier temps un FSM (Finite State Machine simple et à pile) que l'on appliquera à Warbot, un sous-système développé en MadKit. Dans un second temps nous généraliserons notre approche pour pouvoir prendre en compte d'autres architectures: subsomption, satisfaction, dirigée par les événements, etc…

Nous devons donc faire en sorte que notre compilateur puisse être facilement extensible pour pouvoir gérer des environnements (donc des agents) autre que ceux basés sur le modèle FSM.

Dans le système proposé, Il doit pouvoir être possible de modifier des agents créés à partir du formalisme graphiques que nous allons définit, c'est-à-dire passer d'un code généré au diagramme correspondant et vice-versa.

VisualKit

5

4. Cahier des charges

Deux parties sont distinctes, une partie graphique utilisant SEdit, une autre partie correspondant à la compilation du code d’un agent. Voici les étapes du cahier des charges :

- Définition des langages ou formalismes graphiques (machine à état fini, architecture de subsumption, architecture à base d'événements, etc..). Nous nous sommes inspiré d'une part des langages existants sous MadKit et d'autres part des architectures d'agents existantes dans le domaine. Ce formalisme est décrit en langage XML. Ce que ce langage est le plus abstrait possible pour pouvoir être appliqué à tout types d’agents.

- Définition de l’interface graphique grâce à SEdit. Cette interface génére un fichier .sed qui contiendra toute la description d’un agent. Cette description est construite à partir du langage graphique défini. Ce fichier sera du XML.

- Compilation des descriptions en code python. C’est ce code qui

sera exécuté par madkit.

- Modification de la description d’un agent. A partir d’un fichier python ou java par la suite, il faudra effectuer le processus inverse, c'est-à-dire pouvoir le modifier via l’interface de SEdit.

- Donner la possibilité à l’utilisateur d’ajouter des procédures à un

agent. Sachant que ces procédures sont en python ou en java ensuite, donc à ne pas les compiler.

- Ajout à la génération de code la possibilité de générer du Java. En

plus du python il faudra générer du Java, il faudra recompiler le code générer.

VisualKit

6

5. Organisation du travail

5.1. Diagramme de Gant

VisualKit

7

5.2. Répartition des tâches

Ce projet comporte deux parties distinctes, une partie graphique, une

autre partie compilation. La charge de travail de la partie graphique est beaucoup plus importante que la partie compilation. Nous avons décidé que deux personnes l’implémenteraient, et que la troisième personne du groupe implémentera la partie compilation.

5.2.1. Partie graphique

Grégory Garbin et Grégory Bedel-Navarro ont implémenté cette partie. Voici les tâches de cette partie :

- Création du formalise : en binôme. Le formalisme étant la base d’un plugin de Madkit, cette tâche devait être absolument effectuée à deux, pour avoir une base commune pour la suite.

- Implémentations des transitions : Grégory Garbin.

- Implémentation des opérateurs de condition : Grégory Garbin Cela comprend les opérateurs sur les variables globales et les opérateurs sur des percepts.

- Implémentation des variables locales : Grégory Garbin. Des variables locales à la transition peuvent être créées, elles correspondent à un type de percept.

- Implémentation des actions des transitions : Grégory Bedel-Navarro.

- Implémentation des variables globales : Grégory Bedel-Navarro.

Les variables globales sont accessibles par toutes les transitions. - Implémentation des états : Grégory Bedel-Navarro. - Implémentation des liaisons : Grégory Bedel-Navarro.

- Chargement et sauvegarde du modèle : Grégory Bedel-Navarro.

VisualKit

8

5.2.2. Partie compilation

La partie compilation est implémentée dans la majeure partie par

Mirasoa Ranaivo.

- Comprendre la structure du code d’un agent python fonctionnant sur Madkit : Mirasoa Ranaivo.

- Programmer par soit même un agent ayant un comportement qui

respecte le principe des machines à états finis : Mirasoa Ranaivo.

- Comprendre et manipuler un fichier XML : utilisation de l’API JDom de java : Mirasoa Ranaivo.

- Ecrire la méthode compile() pour chaque type d’objet (état,

transition, condition, action…) : Grégory Garbin, Mirasoa Ranaivo.

- Ecrire la classe permettant de générer le code source d’un agent python : Mirasoa Ranaivo.

VisualKit

9

5.3. Outils de développement

Etant donné que la plateforme MadKit est codée en Java, nous avons

réalisé notre plugin dans ce langage. Les agents générés sont compilés en python, et exécutés par le biais de Warbot, grâce à son interpréteur python. Le formalisme permettant la sauvegarde et le chargement de nos fichiers est basé sur le langage XML.

Nous avons utilisé le logiciel de développement Eclipse pour réaliser nos classes Java. Mais elles doivent être compilées dans MadKit, en utilisant le « Plugin Designer ».

VisualKit

10

6. Etude de l'existant

6.1. SEdit

Ce plugin fonctionne essentiellement à base de formalisme. Un formalisme est un fichier xml qui contient plusieurs informations

permettant la création d'une fenetre SEdit. Ces informations sont pour la plupart des classes java, préalablement compilées et ajoutées à la librairie MadKit.

6.2. Warbot

Warbot est donc un plugin de MadKit. Ce formalisme permet l'exécution d'agents Warbot. A l'heure actuelle, il faut coder le comportement de ces agents, soit en python, soit en java. Avec notre plugin, la réalisation de ces agents pourra se réaliser de façon graphique, grâce à un diagramme.

VisualKit

11

6.3. Automaton

Il y a plusieurs formalismes dans SEdit permettant la représentation d'un

agent en tant que automate en tant que diagramme état-transition. Celui qui s'en rapproche le plus est Automaton.

Ce formalisme contient deux types d'élément : − les états et les transitions (qui sont assimilés à des noeuds). − Les flèches, elles font le lien entre un état et une transition. Nous avons donc décidé de se baser sur ce formalisme pour pouvoir créer celui de VisualKit. Les états du formalisme seront ceux des agents, et les transitions seront les conditions et actions réalisées si les conditions sont vérifiées. Les états et les transitions seront reliés par les flèches.

VisualKit

12

7. Conception

7.1. La structure

Visualkit est basé sur la notion de machine à états finis, de ce fait sa

structure est composée de nœuds états et transitions, mais elle contient aussi une liste des variables globales que l’utilisateur pourra utiliser lors de la définition des transitions et des actions. Tous les nœuds ont des liaisons entre eux stockées aussi dans la structure.

Nous avons alors créer des classes correspondantes à chaque élément.

7.2. Les états

Un état est un noeud de la structure. Une classe implémente cet élément

de la structure. Définir simplement un état n’est pas suffisant. Un agent doit avoir un état

de départ obligatoirement, c’est pour cette raison que nous avons différencié deux types d’états, un état de départ et les autres. Le changement d’état s’effectuera par une transition si sa condition est vérifiée.

VisualKit

13

7.3. Les liaisons

Chaque liaison entre états et transitions est définie par une classe dédiée.

Une liaison est composée par une origine, une destination. Or un agent peut vérifier plusieurs conditions mais il ne peut être dans plusieurs états en même temps. De ce fait nous avons du créer une priorité sur la liaison état transition. Les conditions seront donc testées suivant cet ordre.

Par convention nous avons défini que la transition de défaut aura la priorité 0. Seules les priorités des liaisons états transitions sont prisent en compte.

7.4. Les transitions

Les transitions correspondent aux conditions et aux actions qui permettent

de passer d'un état à un autre. Une transition, c'est donc une condition et une liste d'actions.

7.4.1. Les conditions

Une condition est un test (<, >, = =), donc soit le résultat d'une opération de test, soit le résultat d'une opération logique sur des conditions. Par conséquent, ces derniers héritent de la classe « condition ». Une telle architecture facilite la maintenance et le développement du logiciel. D'une part, il est très facile d'ajouter ou d'enlever des opérations de type test ou logique. On pourrait implémenter facilement le « ou exclusif » si on en ressent la nécessité. Il suffit de créer une classe que l'on nommerait par exemple « XOR » qui hériterait d’un opérateur logique. Il ne resterait qu'à implémenter le code de la compilation dans le langage souhaité et le tour est joué. Le diagramme de classe ci-dessous illustre ce principe.

VisualKit

14

Comme l'indique le schéma ci-dessus, « condition » est une classe abstraite. Ses seules instances sont soit des opérateurs de test soit des opérateur logiques. Ces classes doivent implémenter la méthode permettant de compiler le python qui générera le code correspondant à leur test.

VisualKit

15

a. Les opérateurs logiques

Un opérateur logique est, en quelque sorte, un arbre n-aire de conditions. C'est-à-dire que c'est un arbre qui contient soit des opérations de test, soit des opérateurs logiques. Grâce à cette structure, il est possible de représenter facilement des conditions logiques simples ou composées :

b. Les opérateurs de test Il y a plusieurs types de tests réalisables dans Warbot : − Sur les attributs. − Sur les percepts. − Sur la liste de percepts.

Comme ces opérations sont effectuées différemment selon le type. Il a fallu traiter de façon différente ces trois cas. Les tests sur les attributs concernent les variables de l'agent (comme l'énergie, la direction...), elles correspondent à un test « normal ».

Les variables que l'on teste sont des « variables globales » de l'agent qui sont définies dans son code au niveau de Warbot (comme par exemple l'énergie), ou bien définies dans de notre plugin, par le biais de l'interface de création de variables.

VisualKit

16

Pour les percepts, il faut approcher le problème de façon différente. Mais tout d'abord qu'est-ce qu'un percept ? Il s'agit d'un objet qui se trouve dans le champ de détection d'un agent,

Dans l'exemple ci-dessus, il y a un hamburger dans la liste des percepts de

l'agent. Donc pour tester un percept, il faut récupérer la liste des percepts et les tester un à un. On doit donc avoir une approche différente que pour les attributs.

Pour commencer, il faut préciser ce que l'on veut tester sur ce percept, c'est a dire quel champ de l'objet percept va-t-on tester. Ensuite il est nécessaire de stocker ce percept pour pouvoir effectuer des actions sur celui-ci. Il nous a donc semblé judicieux de créer une classe pour les variables locales qui correspond à la partie gauche d'une opération de test.

Cette classe permet de stocker les types de variables que l'on veut tester et facilite un peu plus la compilation de ces derniers, en particulier pour les tests sur les percepts. Une opération de test est donc maintenant composée de deux attributs : − partieGauche, c'est l'instance de percept. Elle contient le champ que l'on

veut tester, et le nom de variables à lui donner. − PartieDroite, la valeur à tester sur partieGauche.

On peut vouloir tester certaines choses sur une liste de percept. Par exemple, l'agent pourrait avoir un comportement particulier s'il y a trop d'ennemi dans son percept. Ou encore aller récupérer la nourriture la plus proche.

Pour les listes de percepts, le principe est à peu près le même que précédemment. C'est-à-dire qu'il faudra que le code de l'agent stocke la liste de percepts dans une variable pour pouvoir effectuer les tests. Ce sera la plupart du temps un filtre sur la liste des percepts.

Par contre, les opérations qui permettent ces tests ne sont pas implémentées dans un agent Warbot. Les sources que l'on compilera devront contenir les fonctions de tests sur les listes de percepts appelées dans l'interface.

VisualKit

17

7.4.2. Les actions :

Les actions sont les fonctions de l’agent exécutées lors de la validation d’une condition d’une transition. Ces actions sont des attributs d’une transition, cette dernière est stockée dans la structure.

Chaque fonction est une classe héritant de la classe abstraite contenant les informations communes à toutes les actions. Cela permet d’une part de définir très facilement son code compilé en langage python par exemple, d’autre part d’ajouter simplement des fonctions supplémentaires.

Nous avons aussi donné la possibilité à l’utilisateur d’implémenter l’action. Cette implémentation n’est jamais modifiée, ou vérifiée par Visualkit. L’utilisateur devra donc entrer le code directement à partir de l’interface.

VisualKit

18

7.5. La compilation

7.5.1. Objectifs

La partie compilation est une partie majeure de notre projet. L’interface

SEdit présentée à l’utilisateur est assez ergonomique. Pour définir le comportement d’un agent, l’utilisateur utilise des nœuds

représentant soit des états soit des transitions, et des flèches reliant les nœuds. Sur un nœud état, représentant le concept dans lequel l’agent est confronté à un moment donné, nous pouvons spécifier le nom de l’état. Sur un nœud transition, représentant le passage d’un état à l’autre, nous pouvons définir des conditions modérant le passage à un nouvel état, mais aussi des actions à effectuer que nous appelons actions de transitions.

Notre but est de générer le code source de l’agent dont le comportement est défini par l’utilisateur à travers l’interface SEdit. Ainsi la phase de programmation réelle de l’agent sera transparente au niveau utilisateur.

Le travail de compilation que nous effectuons revient à exploiter le

maximum d’information recueilli par l’interface SEdit.

VisualKit

19

7.5.2. Solutions proposées

a. Une première approche : le fichier Sed

Nous rappelons qu’à l’enregistrement de l’application, c'est-à-dire après

que l’utilisateur ait défini les comportements de son agent, SEdit génère un fichier de type Sed. Nous rappelons également que comme tout fichier XML, le fichier Sed est structuré par des balises englobant d’autres balises. Dans ces balises, nous avons la possibilité de stocker les informations que nous voulons concernant les nœuds et les transitions manipuler par l’utilisateur.

Comme JDOM, une API du langage Java, nous permet de manipuler des donnés XML, une première idée a été d’exploiter ce fichier afin de générer le code source de l’agent.

b. Une deuxième approche : les classes d’objets

Nous avons créé plusieurs classes pour représenter nos objets (nœud,

transition, condition, action…). Ces classes contiennent des attributs et des méthodes permettant de gérer entièrement les informations de chaque nœud créé par l’utilisateur.

Un nœud « état » est représenté par la classe VkState et un nœud « transition » par la classe VKTransition. L’ensemble des nœuds créés est géré par une classe VKStructure et est stocké dans un vecteur de nœuds.

Une méthode compile() créée dans chaque classe d’objet nous génère le code python de l’objet en question. C'est-à-dire le code python associé soit à un état, une transition, une condition ou une action.

VisualKit

20

Cette solution est la plus adaptée à notre problème car non seulement c’est plus pratique pour la partie programmation mais aussi cela respecte le cas de réutilisation par rapport à la manipulation du fichier Sed. L’idée principale de cette approche est donc de parcourir le vecteur de nœuds, récupérer le code de chaque objets par la méthode compile() et de les organiser afin d’avoir un code source complet d’un agent.

7.5.3. Organisation de la compilation

Dans le but de faciliter la compilation, nous devions trouver une solution

afin de généraliser le plus possible le code source associé à un agent python toujours en respectant le principe des machines à états finis.

a. Code source d’un agent python

On peut diviser conceptuellement le code d’un agent python en trois parties distinctes. Considérons la première partie étant composée de l’entête commun à tout agent python et de quelques fonctions nécessaires à la création d’un agent comme activate() et end().

Considérons une deuxième partie pour la définition de nos propres fonctions. Et consacrons la troisième partie à la définition de la fonction DoIt() dans laquelle tout le comportement de l’agent est défini.

En suivant ce concept, nous avons donc non seulement à compiler toute la deuxième partie pour la définition des fonctions dont on aura besoin, mais aussi de compiler la fonction DoIt() et y définir des comportements à base de machines à états finis.

b. Méthodes adoptées

Nous avons défini une classe de manière générique dans le code source

de l’agent pour représenter l’agent lui-même. Cette classe est générique dans le sens où sa compilation s’adapte à tout type d’agent et à tout type de variables que nous devons définir à l’intérieur. En créant un attribut « selfState », dans cette classe, désignant l’état courant de l’agent, la définition de la fonction DoIt() va se résumer à faire appel à la méthode « goState() », lequel se contente d’activer l’état courant de l’agent. Il nous reste donc à compiler, dans la deuxième partie du code de l’agent, les définitions des états étant composées de transitions, c'est-à-dire un ensemble de conditions et d’actions.

En conséquence des conditions, chaque état modifie ensuite l’état courant de l’agent en faisant appel à la méthode « setState » de l’agent.

VisualKit

21

8. Développement

8.1. Structure de données

Nous avons créé une classe mère Global qui permet l’implémentation des variables globales. L’utilisateur peut en ajouter autant qu’il veut, les transitions peuvent accéder aux variables via la structure.

Pour les conditions sur les percepts, la création de variables locales aux transitions est indispensable, nous avons donc créé une classe Local héritant de Global.

Pour pouvoir représenter l'arborescence d'une opération logique plus facilement, nous avons implémenté un arbre n-aires. C'est une classe générique. Elle contient un contenu, la liste des noeuds suivants (les fils) et son noeud père. Chaque noeud est un Arbre.

Nous avons implémenté aussi plusieurs méthodes permettant une gestion plus facile de l'arbre.

VisualKit

22

8.2. Structure de VisualKit

Voici les principales classes qui composent VisualKit. Vous trouverez en annexe le diagramme complet.

Toutes les classes de la structure de VisualKit ont une classe d’interface graphique dite « UI » permettant l’interaction avec l’utilisateur.

VkState implémente un état d’agent. Il est définit par ses attributs qui sont son nom et sont type (départ, autre). IL possède une fonction permettant son exportation en XML. Une autre fonction que possède cette classe est celle qui permet la génération de l’état en python. A noter aussi la présence d’une fonction « definition » qui est en rapport avec le formalisme, nous traiterons cette partie plus loin dans ce rapport.

VKTransition implémente les transitions. Elle est donc composée d’une classe Condition et d’une liste d’actions. Nous avons ajouté aussi des attributs XML permettant l’exportation de la condition et des actions en XML. Elle possède par ailleur une fonction d’exportation de la transition en XML. Il est donc très facile d’implémenter un nouveau format d’exportation.

VisualKit

23

Les deux classes VkState et VkTransition héritent de la classe SNode via SimpelState et SimpleTransition, toutes les trois incluses dans SEdit.

VkLink implémente les liaisons qu’il y a entre les états et les transitions. Elle est composée d’un attribut caractérisant la priorité de la liaison. Cette priorité est affectée soit manuellement soit automatiquement grâce aux fonctions contenu dans la classe, elle hérite de SimpleStateTransitionLink héritant de SArrow, toutes deux incluses dans SEdit.

VkStructure implémente la structure du formalisme, elle contient les variables globales décrites plus haut dans ce rapport, mais aussi la liste des actions qui seront utiles pour la transition.

De plus, elle contient tous les nœuds états et transitions mais aussi les liens entre eux. De ce fait nous avons pu implémenter des fonctions permettant l’exportation en XML des tous ces elements, par exemple « statesToXML », ce qui conduira à la sauvegarde du model par la fonction « saveModel ». Il existe aussi du fait d’une sauvegarde, le chargement du model grâce à la fonction « loadModel » qui construira les élement grace aux fonctions qui leurs sont dédiées, par exemple « XMLToState ».

VisualKit

24

8.3. Les Transitions

8.3.1. Les opérateurs de test

Comme on a vu précédemment, ils regroupent les opérateurs de comparaison binaires. C'est la classe ConditionBinaire qui les représente. Elle regroupe les tests sur les attributs (ConditionBinaire), les percepts (ConditionPercepts), et les listes de percepts (ConditionListPercepts). Elle est composée : − d'une instance de « Global », partieGauche. C'est ce que l'on veut tester. − D'un opérateur (String), c'est l'opérateur de test. − D'une partieDroite(String), c'est la valeur qu'on veut tester sur la partie

gauche.

Ces trois types de test possèdent leur propre interface (respectivement ConditionBinaireUI, ConditionPerceptsUI, ConditionListPerceptsUI).

a. Les attributs Ce type de test ne se fait que sur des variables globales propres à un

agent Warbot, ou ajouter avec l'interface. Voilà l'interface pour ce type de test :

VisualKit

25

b. Les percepts

Comme on l'a vu plus haut, un percept est élément que l'agent à dans son champ de « vision ». Ce type de ConditionBinaire ne s'applique pas à ses attributs, mais à un percept. Pour représenter ces conditions, il fallait que « partieGauche » ne soit pas seulement une variable globale, mais locale. Elle correspond à un élément des percepts de l'état courant. On peut tester dessus différentes choses tel que le type, sa « team »...Chaque fois qu'une nouvelle variable locales est défini dans une condition, elle est ajoutée à la liste des variables locales de la transition.

c. Les listes de percepts

On peut tout aussi bien effectuer des tests sur des listes de percepts, et vouloir effectuer une action sur cette liste. Dans ce cas, le type de variables de la « partieGauche » est dans tous les cas une liste de percepts. L'utilisateur n'a donc pas besoin de choisir le champ de test.

VisualKit

26

8.3.2. Les opérateurs logiques Ce sont les classes filles de opérateurLogique. Elle est composée d'un arbre de condition, qui représente l'ensemble des paramètres de l'opérateur logique. OperateurLogiqueUI est l'interface qui lui est associé. Nous avons implémenté deux opérateurs logiques n-aires, le «And» et le «Or».

L'opération associé à cette interface :

team = y And groupName = X And ( state = E2 Or energie < 54)

VisualKit

27

8.4. Les Actions

Les différentes classes d’actions telles que Move, MoveTo ou LaunchRoket héritent toutes d’une classe mère abstraite TransactionAction. Les informations communes à toutes les actions sont stockées dans cette dernière, à savoir le nom de l’action, le nombre de paramètre et un vecteur dans lequel nous allons garder les paramètres de l’action.

En effet, une action prend comme paramètre des variables locales de la transition qui lui est associée. Ces paramètres peuvent être plusieurs, alors pour ne pas limiter le nombre de paramètre en mettant directement les paramètres dans le constructeur de chaque action, l’attribut vecteur d’action est bien une bonne solution pour stocker nos paramètres.

Ce vecteur sera parcouru lors de la compilation afin de bien paramétrer les fonctions python. La classe TransationAction contient aussi une méthode abstraite compilerPython() qui sera redéfini dans chaque classe d’actions. Effectivement, à chaque classe d’actions correspond différents codes en python.

VisualKit

28

8.5. Le Formalisme de Visualkit

Le formalisme est la définition des nœuds de l’application sous SEdit. Tous

les nœuds sont connectés par un élément de liaison. Un formalisme SEdit est un fichier formaté XML. Sous Visualkit nous avons deux types de nœuds, les états et les transitions.

Pour créer son propre formalisme, il faut indiquer dans le fichier les classes d’implémentation de la structure, des nœuds, des liaisons. Grâce au formalisme, nous pouvons définir très simplement des actions sur des nœuds, sur des liaisons mais aussi sur la structure.

Pour définir la structure du formalisme, il faut indiquer la classe d’implémentation dans l’attribut « class » de la balise « formalisme » :

Ensuite il faut définir les types de nœuds ainsi que leur classes d’implémentation :

L’ajout d’un type de nœud et pris en charge par SEdit. Un bouton est créé pour chaque type de nœud. Il faut juste renseigner l’icône du bouton :

Lors de la création d’un nœud, l’instance de la classe de la structure ajoute une nouvelle instance de la classe définissant le nœud, SEdit ensuite dessine l’élément suivant les instructions de cette dernière.

Nous pouvons ajouter une action sur un noeud de SEdit, lors d’un clic droit sur l’élément graphique, un menu est affiché. Pour ajouter une action dans le menu il suffit de l’indiquer dans la description du noeud une balise de ce format :

Dans cet exemple, on ajoute une action « Définition ». Quand cette action est choisie par l’utilisateur, la fonction java « definition » de l’instance du nœud est appelée.

La définition des types de liaisons c’effectue de la même manière que les nœuds :

Ajout d’une balise liaisons :

VisualKit

29

Ajout d’un type de liaison en définissant sa classe d’implémentation :

Changement de l’icône du bouton d’ajout:

Enfin nous pouvons définir des actions sur la structure du formalisme :

Un bouton est créé automatiquement, lors de son activation il appelle la fonction java de la classe de la structure. Voici le résultat du formalisme de VisualKit :

VisualKit

30

8.6. La sauvegarde du diagramme

SEdit possède un mode de sauvegarde de diagrammes, mais il ne peut

que sauvegarder les noeuds avec des attributs de type chaîne de caractères. Or tous les nœuds de Visualkit sont composés d’autres types d’attributs tels que des listes. Il nous était impossible de modifier le ce mode, car les autres formalismes de SEdit ne pourraient plus être sauvegardés. De ces faits la sauvegarde d’un diagramme Visualkit s’effectue en deux étapes, la sauvegarde du modèle, et la sauvegarde du diagramme avec SEdit, donc deux fichiers distincts sont créés. Ces fichiers sont au format XML permettant une facilité de lecture et d’écriture.

Les actions de sauvegarde et chargement du modèle sont implémentées dans la structure. Chaque élément de l’architecture possède sa fonction de traduction en XML, « toXML() » utilisée lors de la sauvegarde, et « XMLTo… » pour le chargement. Les pointillés correspondent au nom de l’élément par exemple « XMLToStates() ».

8.6.1. Sauvegarde du modèle

La racine du fichier de sauvegarde est une balise :

Cette balise contient tout d’abord les variables globales :

Chaque variable globale sera traduite en une balise, qui contiendra tous

les attributs la caractérisant, nom, droits, type :

A la suite des variables globales il y a les états contenus dans la balise :

Chaque état sera sauvegardé dans ce format :

Ensuite il y a la sauvegarde des transitions contenues dans la balise: Chaque transition est définie grâce à cette balise contenant son identifiant :

VisualKit

31

La transition contiendra tout d’abord la condition, et ensuite l’action. Une condition sur les variables globales sera définie, en premier lieu par son opérateur puis ses paramètres :

Remarquez que l’opérateur à un type, il contient la classe à implémenter. Pour les percepts la classe sera bien sûr différente :

Pour une condition sur les percepts, il faut définir une variable locale, elle sera traduite dans un format contenant le type de percept et la variable locale associée :

Enfin les actions de cette transition seront continues dans une balise:

L’action contiendra le nom de la fonction à effectuer et si c est le cas le paramètre quelle doit avoir :

L’utilisateur peut définir manuellement l’action, dans ce cas nous aurons une balise qui contiendra le code de l’action :

Vous trouverez un exemple complet en annexe.

VisualKit

32

8.6.2. Sauvegarde de SEdit

La première balise définie la structure :

Cette balise contiendra toutes les informations que SEdit peut sauvegarder, donc les nœuds les liaisons et les attributs de type chaîne de caractères. Un attribut très important est le chemin du fichier de sauvegarde du modèle :

Les nœuds sont contenus dans une balise :

Chaque nœud possède un type, dans notre cas état ou transition, un id

permettant de faire le lien avec le modèle et enfin un label, par exemple pour un état :

Le noeud contient des informations graphiques permettant son dessin sous SEdit:

Enfin ses attributs tels que le type d’état (départ, autre) et son nom :

Après les nœuds nous trouvons les liaisons qui sont contenues dans la balise :

Chaque liaison est definie par son origine (from) sa destination (to) et son id :

Elle possède aussi des informations graphiques:

Enfin son ordre de priorité :

Vous pouvez consulter un exemple entier dans l’annexe.

VisualKit

33

9. Mode d’emploi

9.1. Installation

Suivre les étapes d’installation :

− Mettre le dossier VisualKit dans madkit\plugins − Mettre le fichier jdom.jar dans madkit\lib − Mettre le fichier VisualKit.fml dans madkit\lib\formalisms − Mettre le fichier desktop.ini dans madkit\bin − Lancez MadKit − Double-cliquer sur 'Plugin Designer' − Sélectionner le plugin VisualKit − Cliquer sur 'Validate' puis sur 'Build − Lancez VisualKit par le menu MadKit

9.2. Utilisation

Définissez les états et les liens :

VisualKit

34

Définissez vos conditions et vos actions

VisualKit

35

10. Conclusion et perspectives

Nous avons réussi à créer un formalisme adapté à la création d’agent à états finis pour Warbot. Il permet de gérer les conditions aussi bien sur les attributs que sur les percepts.

Mais, il est possible d'approfondir ce projet. Tout d'abord en y ajoutant la notion de réflexe. Ce serait en quelque sorte une transition qui primerait sur toute les autres quand toutes ses conditions sont réunies.

Il serait possible aussi d'ajouter la gestion des messages. Cela serait sûrement lié à la notion de réflexe : un agent retournerait à la base s'il reçoit un message le prévenant d'une attaque sur celle-ci.

Pour finir, on pourrait aussi compiler les agents non seulement en python, mais aussi en Java.

Au final, grâce à ce projet nous avons découvert la plate-forme MadKit et nous avons approfondi nos connaissances sur la programmation agent.

VisualKit

36

11. Annexes

11.1. Diagramme UML de la structure de VisualKit

VisualKit

37

11.2. Formalisme de VisualKit

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE formalism SYSTEM "sedit-formalism.dtd"> <formalism name="vk" description=""

class="madkit.VisualKit.VkStructure"> <formalism-info> <author>Gregory Bedel-Navarro</author> <author>Gregory Garbin</author> </formalism-info> <node-types>

<node-desc name="state" class="madkit.VisualKit.VkState"> <icon url="images/place1.gif"/> <action description="Definition"> <java-method name="definition" /> </action> </node-desc>

<node-desc name="transition" class="madkit.VisualKit.VKTransition"> <icon url="images/transition2.gif"/> <graphic-element class="SEdit.Graphics.GRectangle"> <property name="width">10</property> <property name="height">40</property>

</graphic-element> <action description="Definition"> <java-method name="definition"/> </action> </node-desc> </node-types>

<arrow-types> <arrow-desc name="link" class="madkit.VisualKit.VkLink"> <icon url="images/stdarrow.gif"/> <graphic-element > <property name="displaylabel">true</property> </graphic-element>

<action description="Definir Priorite"> <java-method name="definition"/> </action> <action description="Definir Priorite Automatiquement"> <java-method name="autoPriority"/> </action>

</arrow-desc> </arrow-types> <action description="Globals"> <icon url="images/editor24.gif"/> <java-method name="showGlobals"/> </action>

<action description="Save the Model"> <icon url="images/stop.gif"/> <java-method name="showModelFileChooser"/> </action> <action description="Python Compilation">

<incon url="images/editor.gif /> <java-method name="compiler" /> </action> </formalism>

VisualKit

38

11.3. Sauvegarde du modèle

<?xml version="1.0" encoding="UTF-8"?> <structure> <globals> <global name="energie" droits="r" type="static" /> <global name="heading" droits="w" type="static" /> <global name="team" droits="w" type="static" /> <global name="groupName" droits="w" type="static" /> <global name="homeBaseX" droits="w" type="user" /> <global name="homeBaseY" droits="w" type="user" /> <global name="state" droits="w" type="user" /> <global name="atHome" droits="w" type="user" /> <global name="wait" droits="w" type="user" /> </globals> <states /> <transitions> <transistion id="N0"> <AND> <parametre> <inferieur type="class madkit.VisualKit.PerceptsInferieur"> <parametre type="Team">Var0</parametre> <parametre>0</parametre> </inferieur> </parametre> </AND> <actions> <action class="moveTo" param="Var0" /> </actions> </transistion> </transitions> </structure>

VisualKit

39

11.4. Sauvegarde de SEdit

<?xml version="1.0" encoding="UTF-8"?> <structure name="example" type="vk"> <nodes> <node id="N0" label="Etat1" type="state"> <graphic x="130" y="140"> <property name="height">40</property> <property name="width">40</property> </graphic> <property name="type">start</property> <property name="statename">Etat1</property> </node> <node id="N1" label="Etat2" type="state"> <graphic x="393" y="152"> <property name="height">40</property> <property name="width">40</property> </graphic> <property name="type">other</property> <property name="statename">Etat2</property> </node> <node id="N2" type="transition"> <graphic x="274" y="215"/> </node> <node id="N3" type="transition"> <graphic x="281" y="74"/> </node> </nodes> <arrows> <arrow from="N0" id="A0" label="0" to="N2" type="link"> <graphic x="214" y="197"/> <property name="priorityindex">0</property> </arrow> <arrow from="N2" id="A1" label="0" to="N1" type="link"> <graphic x="346" y="203"/> <property name="priorityindex">0</property> </arrow> <arrow from="N1" id="A2" label="0" to="N3" type="link"> <graphic x="349" y="133"/> <property name="priorityindex">0</property> </arrow> <arrow from="N3" id="A3" label="0" to="N0" type="link"> <graphic x="218" y="127"/> <property name="priorityindex">0</property> </arrow> </arrows> <property name="gridsize">10</property> <property name="displaygrid">false</property> <property name="pathmodel">C:\Documents and Settings\user\test.mdl</property> <property name="snaptogrid">false</property> </structure>