Projet: Projet: Simulation de Robots Simulation de Robots

BARNAUD Marie-Lou I3A

BASTARD Anthony 2010/2011

Projet:

Projet:

Simulation de Robots

Simulation de Robots

Sommaire

I-Introduction II-Comparaison

III-Analyse

1- Les objectifs de l'application 2- Les structures de données

3- L'architecture 4- Les algorithmes

5- Les exceptions IV- Application

1- Vue générale 2- Structure de données

3- Nouveau jeu 4- La course 5- Affichage

V- Les tests unitaires et fonctionnels 1- Les fonctions de placement et de déplacement

2- Les fonctions d'affichage

3-Les fonctions d'initialisation et de validation de la grille 4- Tests fonctionnels

VI- Exploitation 1- Exemple d'exploitation

2- Constats

VII-Annexe

I- Introduction

Il peut nous arriver d'être spectateur d'une course-poursuite que ce soit dans la vie courante, dans des films ou dans des jeux. Le problème est qu'on ne comprend pas toujours comment cette course se déroule, ni quelles sont les chances (ou risques selon le point de vue) pour que l'un des deux protagonistes attrape l'autre ou réciproquement pour que l'autre réussisse à s'enfuir.

C'est pour cette raison que nous avons réalisé une application d'une simulation de courses- poursuites qui nous permettra d'en comprendre plus précisément le déroulement.

Les courses se passent dans une grille rectangulaire munie de cases et mettent en jeu deux robots: celui qui poursuit est nommé prédateur et celui qui s'enfuit proie. Chaque robot occupe une case et une seule. Il semble évident que si un des robots se déplace plus vite que l'autre, il gagne la course. Pour éviter cela, ils se déplacent à la même vitesse. Ainsi, une course est constituée de tours pendant lesquelles les robots avancent successivement d'une case au maximum.

En ce qui concerne les déplacements, ils se font seulement horizontalement et verticalement.

(Le déplacement vers une case située en diagonale est prohibé) et chaque robot possède un champ de vision qui lui permet de décider de façon autonome où il veut aller. D'ailleurs, le programme est lui aussi autonome puisque les courses se déroulent sans que l'utilisateur n'ait à intervenir.

Cette autonomie est dirigée par une unité de contrôle. Il existe également une unité de visualisation qui gère l'affichage de la course pour que l'utilisateur puisse observer la course et l'évolution des robots.

Mais, le programme a aussi été pensé pour l'utilisateur qui craindrait de n'être que spectateur.

Une unité de commande lui est réservée. Dans celle-ci, il choisit les paramètres de la course tels que le nombre de courses successives se déroulant dans une partie, le nombre de tours contenus au maximum dans chaque course et la vitesse d'un tour. En plus de cette unité, il peut choisir la taille de la grille c'est-à-dire sa longueur et sa largeur. Enfin, il doit également décider du champ de vision et des placements initiaux des robots. Il lui est même possible de placer des obstacles qui sont des cases dont les robots n'ont pas accès. Ces obstacles peuvent être utiles pour étudier le comportement des robots c'est-à-dire voir comment ils gèrent ces difficultés tout en essayant de gagner la course.

Une course est terminée lorsque le nombre de tours définis s'est écoulé ou lorsque le prédateur a attrapé la proie. Dans le premier cas, on considère que la proie a gagné la course, dans le second, le prédateur. Pour les utilisateurs encore insatisfaits, le déplacement automatique des robots peut être désactivé et ils peuvent jouer eux-mêmes.

Dans la suite de ce rapport, se trouve une comparaison des programmes déjà existants sur ce type de sujet ou s'en rapprochant. A cela, s'ajoute une analyse de l'application réalisée dans laquelle on trouve une description des structures de données, de l'architecture, les principaux algorithmes utilisés et les exceptions. Ensuite, nous expliquons comment l'application et les points décrits en analyse ont été implémentés en java. Des tests unitaires et fonctionnels viennent justifier le bon fonctionnement des principaux algorithmes et de l'application. Pour finir, nous exposons les résultats trouvés sur plusieurs courses qui nous indiquent les chances de gagner de chaque robot suivant différents paramètres.

II-Comparaison

Ce type de sujet, nous a fait penser à Pacman. En effet, dans ce jeu, nous trouvons une proie (Pacman), ainsi que des prédateurs (les fantômes) devant attraper la proie. Le but du jeu est que la proie attrape tous les pac-gommes placés dans la grille avant qu'un des prédateurs ne la rattrape.

Le pac-gomme est un aliment imaginaire symbolisé par un rond. Il est attrapé lorsque la proie et le pac-gomme se trouve sur la même case. Le tableau suivant montre les différences entre notre application et le jeu existant.

Paramètres Notre application Pacman

Nombre de prédateurs 1 3

Autonomie des robots Au choix La proie n'est jamais autonome

Grille Choisie par l'utilisateur 256 différentes Champ de vision Choisi par l'utilisateur Inexistant

Aliment Inexistant Pac-gommes (et fruits)

Vitesse Identique entre le proie et le prédateur.

Vitesse prédéfinie pour les prédateurs. Dépend de l'utilisateur pour la proie.

Victoire de la proie Tour maximal atteint Aliments tous attrapés

Ainsi, la grande différence entre notre application et Pacman est que la victoire de la proie dépend surtout de l'utilisateur dans Pacman alors que dans notre application, cette victoire est influencée par d'autres paramètres (Nombre de tours, champ de vision etc.). De plus, le jeu Pacman est « inégal » puisqu'il y a trois prédateurs pour une seule proie. Le jeu n'a pas été créé pour étudier la course poursuite entre deux robots, mais de permettre à l'utilisateur de faire gagner la proie par tous les moyens.

III- Analyse

1-Les objectifs de l'application

− Pouvoir présenter plusieurs grilles de taille et de disposition différentes contenant un prédateur, une proie et si souhaité, des obstacles.

− Observer dans cette grille, la simulation d'une ou plusieurs courses poursuites entre des robots.

− Afficher les résultats de cette ou ces courses.

2- Les structures de données.

Nous présentons, ici, les structures de données principales se trouvant dans notre application.

Pour chaque structure, nous exposons dans un premier paragraphe les fonctionnalités de bases c'est-à-dire celles qui sont indispensables pour la mise en place et le déroulement d'une course.

Dans un second paragraphe, nous décrivons d'autres fonctionnalités qui nous paraissent importantes, mais moins essentielles. On peut considérer que les premières sont celles qui nous étaient demandées et les secondes, celles que nous avons rajoutées.

a- La grille

La grille possède une longueur et une largeur, deux valeurs que l'on peut récupérer ou modifier (si on veut changer la taille de notre grille par exemple). Sur cette grille, nous pouvons ajouter ou au contraire enlever des éléments (des obstacles, des robots). De plus, nous savons si une case est vide ou occupée ou encore nous pouvons récupérer l'élément se trouvant dans une case quelconque.

Étant données toutes ses fonctionnalités, la grille est représentée par un tableau dans lequel on peut savoir le nombre d'éléments s'y trouvant. Enfin, lorsqu'il crée sa grille, l'utilisateur a aussi accès à des grilles prédéfinies c'est-à-dire des grilles enregistrées à l'avance dans le programme.

b- Les robots

Un robot a des coordonnées : l'abscisse, l'ordonnée et le numéro de la case qu'il occupe sur la grille, qui peuvent être modifiés puisque le robot se déplace sur la grille. Le déplacement se fait sur des cases adjacentes horizontalement et verticalement et le robot ne peut en aucun cas sortir de la grille. Il possède aussi un champ de vision choisi par l'utilisateur qui correspond au nombre de cases visibles autour de lui. (Schéma 1) En outre, il sait si la proie est attrapée et donc peut dire s'il a gagné ou perdu selon s'il est le prédateur ou la proie. On précise aussi que le robot « voit » à travers les obstacles.

Schéma 1: Champ de vision

Avant une course, le champ de vision n'est pas pris en compte et le robot sait si le prédateur peut attraper la proie. En effet, si, par exemple, la proie est protégée par des obstacles et que le prédateur n'a aucun moyen de passer, le prédateur ne peut pas atteindre la proie et celle-ci gagnera à chaque fois. (Schéma 2) En ce qui concerne le déplacement des robots, il est fait en principe de façon automatique mais l'utilisateur peut contrôler le robot s'il le souhaite.

Schéma 2: Le prédateur ne peut pas gagner.

c- Les obstacles

Comme les robots, ils ont des coordonnées. Le nombre total d'obstacles dans la grille est également connu.

Nous avons choisi d'en faire une structure à part entière et de ne pas les intégrer directement à la grille car nous pensons qu'il est possible de mettre en place des obstacles originaux comme par exemple des obstacles qui disparaîtraient tous les trois tours. Ceci n'a pas été développé dans notre application, mais cette structure permet de rendre les obstacles indépendants de la grille et de ne pas être obligé de modifier l'architecture de l'ensemble pour créer une extension à nos obstacles.

d- Les éléments de la grille

Les robots et les obstacles sont tous deux des éléments de la grille. Ils ont en commun le fait qu'ils occupent une case et qu'ils possèdent des coordonnées et qu'on peut les placer sur la grille.

Pour éviter d'écrire deux fois la même chose pour les deux structures, nous en créons une nouvelle. Par héritage, nous faisons ensuite en sorte que les robots et les obstacles possèdent les propriétés des éléments de la grille.

e- L'unité de visualisation

C'est elle qui s'occupe de la façon dont l'ensemble sera représenté pour l'utilisateur. Elle gère donc l'affichage de la grille que ce soit avec ou sans élément. On précise que l'affichage est actualisé comme par exemple lors du déplacement des robots. C'est aussi elle qui prend en charge la représentation des éléments, cette dernière pouvant être modifiée.

Elle affiche également le champ de vision des robots.

f- L'unité de contrôle

L'unité de contrôle dirige la course. Ainsi, elle lance la course, peut l'arrêter partiellement c'est-à-dire faire une pause et la reprendre par la suite ou alors l'arrêter totalement auquel cas la grille et les éléments sont initialisés. C'est elle qui gère le nombre de course, le nombre de tours de chaque course et la vitesse d'un tour. (Vitesse à laquelle avance les robots à chaque tour en déplacement automatique). Elle s'occupe également des statistiques comme par exemple: la moyenne des tours au bout desquels le prédateur a attrapé la proie, le nombre de courses gagnées par le prédateur et le nombre de courses gagnées par la proie.

Dans notre application, on précise que pendant la course, la vitesse d'un tour est modifiable.

g- L'unité de commande

Elle contrôle les initialisations. Elle s'occupe des valeurs données par l'utilisateur comme par exemple, le nombre de courses, le nombre de tours par course et la vitesse d'un tour.

Selon les choix de l'utilisateur, elle sait aussi quel robot débute la course et si les robots se déplacent de façon automatique ou grâce à l'utilisateur.

3- L'architecture

Pour réaliser une telle application, nous utilisons un langage orienté objet. Ainsi nous avons utilisé plusieurs classes et interfaces liées entre elles. Nous présentons sous le schéma suivant un diagramme d'héritage, d'implémentation et de composition entre les éléments créés. Les interfaces sont représentées par un rectangle jaune, les classes par un rectangle bleu clair, les flèches violettes sont les flèches d'implémentation (les classes implémentent des interfaces), les flèches rouges caractérisent la composition (une classe est composée d'une autre classe) et les flèches bleues foncées représentent l'héritage (une classe fille hérite d'une autre classe).

Schéma 3: Architecture

Nous précisons qu'Ucm correspond à l'unité de commande, Uc à l'unité de contrôle et Uvl à l'unité de visualisation.

Chaque interface implémente la classe qui lui correspond: la classe « Ucm » implémente l'interface « Ucm », la classe « Grille » implémente l'interface « Grille » etc. Ainsi, chaque classe aura les fonctionnalités définies dans l'interface qu'elle implémente.

En ce qui concerne l'héritage, les robots et les obstacles sont des éléments contenus dans la grille, par conséquent, les classes (respectivement interfaces) « Robot » et « Obstacles » héritent des caractéristiques de la classe (respectivement interface) « ElementGrille » De même, les prédateurs et les proies sont tous deux des robots, donc les classes « Proie » et « Predateur » héritent de la classe « Robot ».

Passons maintenant à la composition. Celle-ci a été plus difficile à mettre en place et il est possible que d'autres classes implémentant les mêmes interfaces aient des liens de composition différents. Expliquons nos choix. Dans l'unité de commande, l'utilisateur doit avoir des robots dans ses paramètres afin de choisir, qui, des deux robots (proie ou prédateur) commence la course.

Pour cette raison, la classe « Ucm » est composée de la classe « Robot ».

Ensuite, l'unité de visualisation doit afficher la course poursuite. Pour que cet affichage soit possible, elle doit savoir sur quelle grille a lieu la course. La classe « Uvl » est donc composée de la classe « Grille ». Une fois la grille créée, il faut que les éléments se trouvant sur la grille soient eux-aussi représentés. Ainsi, lorsqu'ils sont placés sur la grille, ils doivent prévenir l'unité de visualisation pour qu'elle les représente. De même, les robots doivent prévenir qu'il faut réactualiser leurs représentations lorsqu'ils se déplacent. Donc, l'unité de représentation doit faire partie des paramètres de l'élément de la grille. Donc, la classe « ElementGrille » est composée de la classe « Uvl ». Enfin, l'unité de contrôle, qui gère le déroulement des courses, doit s'occuper du déplacement des robots sur la grille. Il doit donc savoir sur quelle grille s'effectue la course et connaître les deux robots en pleine poursuite. Ces éléments faisant partie des paramètres de l'unité de contrôle, on peut en conclure que la classe « Uc » doit être composée de la classe « Robot » et de la classe « Grille ».

4-Les algorithmes

Nous présentons dans cette partie les algorithmes les plus élaborés.

a- Le déplacement automatique des robots

• Situation 1: Les deux robots ne se voient pas.

Le prédateur et la proie se déplacent de la même façon: Ils vont sur une case au hasard en évitant les obstacles, de sortir de la grille et de retourner sur la case où ils étaient le tour précédent

.Schéma 4: Déplacement du robot (lorsqu'il ne voit pas l'autre)

• Situation 2: Ils se voient et il existe un chemin pour se rejoindre dans le champ de vision.

Le prédateur essaye de se rapprocher de la proie. S'il n'y a pas d'obstacles, le déplacement se fait aisément, le prédateur se déplaçant en direction de la proie. Lorsqu'il y a des obstacles, le prédateur calcule le chemin le plus court pour se rapprocher de la proie en fonction des cases dont il a accès (c'est-à-dire les cases visibles dans son champ de vision).

Pour ce faire, les cases du champ de vision sont numérotées (Schéma 5), puis le prédateur se déplace sur une des cases à côté d'elle au plus faible numéro.

En ce qui concerne la proie. Elle essaye de s'éloigner le plus possible du prédateur. S'il y a des obstacles, elle évalue la case, la plus éloignée du prédateur et essaye de s'en approcher.

Pour ce faire, les cases du champ de vision sont également numérotées, (Schéma 5) et la proie se déplace sur une des cases à côté d'elle au plus fort numéro.

Schéma 5: Champ de vision numéroté

Sur le schéma si le robot bleu est le prédateur, il se déplacera sur la case au numéro 5 (entouré en rouge) pour se rapprocher de la proie. Si le robot bleu est la proie, elle se déplacera sur une des cases au numéro 7 (entouré en cyan) pour s'éloigner du prédateur et essayera d'aller vers la case 10 (case la plus éloignée du prédateur)

• Situation 3: Ils se voient, mais il n'existe pas de chemin visible pour atteindre l'autre robot.

Les robots se déplacent de la même façon que lors de la situation 1 car ils ne savent pas quoi faire. En effet, le prédateur ne peut pas attraper la proie car il ne sait pas quel chemin emprunter.

De même, la proie ne sait pas forcément quelle case est la plus éloignée du prédateur vu que celui-ci ne peut déjà pas l'attraper.

Ces trois situations sont les principales que nous pouvons trouver. Cependant, il peut exister d'autres situations qui sont également traitées par l'algorithme mais que nous ne présentons pas ici.

Schéma 6: Différence entre la situation 2 et 3.

b- Le déroulement d'une course.

Voici le diagramme des traitements du déroulement d'une course.

Diagramme des traitements de déroulement d'une course C'est l'unité de contrôle qui gère cet algorithme. Voici le déroulement.

Une fois la course lancée le robot 1 joue. Lorsque celui-ci a fini de se déplacer, il y a un petit temps d'attente (entre 500ms et 2 secondes) qui correspond à la moitié de la vitesse d'un tour après lequel le second robot joue. Quand celui-ci s'est déplacé, le nombre de tours est incrémenté et c'est de nouveau au robot 1 de jouer (toujours à la même vitesse), la boucle continue tant que le nombre de tours n'est pas fini ou que le prédateur n'a pas attrapé la proie. Entre temps, la course peut être arrêtée momentanément par l'utilisateur ou totalement (non mis sur le diagramme) auquel cas la boucle arrête de tourner.

Lorsque la boucle se termine (et donc que la proie est attrapée ou que le nombre de tours est terminé) on considère que la course est finie et les statistiques sont calculées. Ensuite, les éléments sont remis à leur place, prêts pour une nouvelle course.

c- Vérification que la prédateur peut attraper la proie

Avant une course, l'application vérifie que le prédateur peut attraper la proie. Pour se faire, la fonction débute à la case où se trouve un robot. Elle avance ensuite sur les cases adjacentes (horizontalement et verticalement)

→ Si la case est vide, la fonction lui donne un numéro et continue sur les cases d'après.

→ Si la case contient un obstacle ou un numéro, la fonction ne fait rien.

Ce système continue tant que la fonction n'arrive pas sur la case où se trouve l'autre robot ou que la fonction a encore des cases à observer.

A la fin, si la fonction est arrivée sur la case de l'autre robot le prédateur peut attraper la proie, sinon il ne peut pas.

5- Les exceptions

Comme dans toute application, il existe de nombreux cas qui provoquent des erreurs. Pour les contrer, nous avons donc mis en place des exceptions. Voici les principales.

Exception si une case est pleine: Comme une case ne peut contenir qu'un seul élément, il faut penser au cas où l'utilisateur essayerait de rajouter un élément alors que la case est déjà remplie.

Exception si une case est vide: Si au contraire, l'utilisateur essaye de supprimer un élément de la grille alors que la case en question est vide, il faut le prévenir que c'est impossible.

Erreur de taille: Si l'utilisateur essaye de rentrer un élément sur une case qui n'existe pas (exemple une case dont la longueur est 12 alors que la longueur de la grille est 10), le programme doit être en mesure de dire que cette action est impossible.

Erreur de type: Cette exception est présente pour éviter de rentrer n'importe quoi dans la grille c'est-à-dire autre chose que des robots ou des obstacles.

Erreur sur le nombre de course, le nombre de tours, la vitesse: Toutes ces valeurs sont limitées et ne doivent pas non plus être négatives. Il faut une exception pour chacune de ces valeurs pour éviter que l'utilisateur fasse n'importe quoi.

Il existe d'autres exceptions, nous n'avons donné ici que les principales.

IV-Application

1-Vue générale

Application: Vue générale

En 1, nous avons la grille qui contient des obstacles et les deux robots. Cet affichage est géré par l'unité de visualisation.

En 2, nous avons une icône qui ouvre une autre fenêtre (plus exactement une boite de dialogue) dans laquelle on peut paramétrer une nouvelle partie: nouvelle grille, changer le placement, les initialisations...

En 3, nous avons la gestion de la course, la première icône lance la course, la seconde l'arrête momentanément et la troisième l'arrête totalement. Ceci est géré par l'unité de contrôle.

En 4, on remarque des cases de couleurs différentes: elles correspondent aux champs de vision des robots. Ceci est également dirigé par l'unité de visualisation

En 5, on indique quel robot est le prédateur et quel robot est la proie.

En 6, nous avons les paramètres d'une partie. Elles ont été initialisées par l'unité de commande et sont utilisées lors d'une partie par l'unité de contrôle. On précise que la vitesse est modifiable.

En 7, nous avons les statistiques d'une course qui sont calculées par l'unité de contrôle.

En 8, sont indiquées les touches sur lesquelles appuie l'utilisateur lorsque les robots se déplacent manuellement.

2- Structures de données

Récapitulatif des principaux attributs et fonctions des structures de données qui ont été implantés en java. On précise que toutes les fonctions d'une interface sont présentes dans la classe qui l'implémente. L'architecture vue précédemment a aussi été gardée.

a-La grille

b- Les éléments de la grille

c- Les robots

d-Prédateur et proie.

e- Unité de commande

f- Unité de contrôle

g- Unité de visualisation

3- Nouveau jeu

Voici les étapes pour établir une nouvelle partie:

Diagramme des traitements: nouvelle partie

Nous allons préciser ce cheminement, en indiquant comment ceci a été implémenté en java.

Lorsqu'on ouvre la boite de dialogue pour créer une nouvelle partie, les paramètres présentés sont ceux de la course en cours.

a- Choix de la grille:

Pour des grilles personnalisées, nous choisissons les paramètres de la grille (en 2): la longueur, la largeur et les couleurs. En cliquant sur « OK », la grille choisie apparaît en 1. En cliquant sur «Par défaut», la grille retrouve les paramètres de la grille actuellement affichée en 1.

Programmation:

La longueur et la largeur sont des propriétés de la grille. Lors du clic sur «OK», une fonction créant une nouvelle grille avec la nouvelle longueur et la nouvelle largeur est appelée.

Les couleurs sont gérées par l'unité de visualisation. Lors du clic sur «OK», une fonction modifiant ces deux couleurs est appelée.

De plus, une fonction d'affichage de cette unité est aussi sollicitée: elle actualise la grille en 1 avec ses nouveaux paramètres.

En cliquant sur le bouton « Grille prédéfinie », nous avons le choix entre six grilles. Pour en choisir une, il suffit de cliquer sur le bouton

« OK » se trouvant en dessous de la grille de notre choix.

Programmation:

Les grilles prédéfinies sont des grilles qui ont été préalablement enregistrées dans des fichiers (un fichier pour chaque grille) et qui sont ouverts et utilisés dans l'application.

De la même façon, il est possible de sauvegarder une grille dans un fichier en cliquant sur

« Fichier » (en haut à gauche).

b- Choix du robot

L'image correspond ici au choix du prédateur, mais il est identique pour celui de la proie. Dans tous les cas, nous choisissons d'abord l'image du robot (en 1). On précise que chaque robot doit avoir une image différente. (Ceci est géré par l'application). L'image choisie apparaît en 3. Enfin nous choisissons le champ de vision du robot en 2.

Programmation:

Le champ de vision fait partie des paramètres du robot, ainsi, une fonction le modifiant est appelée lorsqu'on le change en 2.

L'image du robot est un paramètre de l'unité de visualisation. C'est donc une fonction faisant partie de cette unité qui est utilisée lorsqu'on modifie l'image du robot.

Remarque: Nous avons voulu représenter les robots sous forme d'image, c'est un choix. Mais nous aurions pu les représenter sous forme de texte: « Prédateur rouge », « Petite proie » etc.

Aussi, c'est l'unité de visualisation qui gère l'affichage des robots pour être sûr qu'il soit représenté de la même façon: (Pas un sous forme de texte et l'autre sous forme d'image).

c- Placement des éléments

Nous avons placé des éléments sur la grille 1: les robots et les obstacles.

Pour ce faire: nous choisissons dans la JComboBox (en 2) ce que nous voulons placer. Une fois choisi, soit nous cliquons sur la case de la grille (1) sur laquelle nous souhaitons le positionner, soit nous rentrons les coordonnées de la case (en 3).

En ce qui concerne les obstacles, on peut soit en ajouter, soit en supprimer.

Ainsi, lorsqu'on choisit de les placer le cadre 4 apparaît.

Le point 5 est important, si nous souhaitons rechanger un paramètre de la grille, tous les placements seront annulés et il faudra recommencer. Ceci évite, par exemple qu'un élément se retrouve hors de la grille si l'utilisateur décide de rétrécir sa taille.

Programmation:

Lors de l'ajout d'un élément sur la grille nous faisons appel:

− A la fonction de la classe grille qui place l'élément sur la case voulue. (si la case est vide)

− A la fonction de la classe éléments de la grille qui actualise les coordonnées de l'élément.

− A la fonction d'affichage de l'unité de visualisation, qui affiche l'élément sur la grille sur la case choisie.

S'il s'agit d'un robot:

− S'il était sur une autre case, l'élément est supprimé de la case où il était précédemment.

(Fonction de la grille) S'il s'agit d'un obstacle:

− Une fonction de la classe Obstacles actualise le nombre d'obstacles sur la grille. (en 4) Lors de la suppression d'un obstacle, les mêmes fonctions sont appelées mis à part celle ajoutant un élément qui est remplacée par la fonction de suppression d'un élément.

d- Autres paramètres:

L'utilisateur entre ici tous les paramètres nécessaires à la partie:

nombre de course, de tours,la vitesse, qui commence et le type de déplacement. Il clique sur «OK» une fois ses choix effectués.

Programmation: Il s'agit de l'initialisation des paramètres donc c'est l'unité de commande qui s'en charge.

Lors du clic sur « OK », chaque paramètre est modifié à l'aide d'une fonction se trouvant dans la classe de l'unité de commande.

e-Validation

Si l'utilisateur décide finalement de ne pas créer de nouvelle partie, il peut cliquer sur « Annuler » qui le renvoie à la fenêtre principale.

Lorsque l'utilisateur a choisi tous les paramètres dont il a besoin pour faire une course, il clique sur « OK ». Si tous les paramètres sont valides, la boite de dialogue se ferme et la fenêtre principale contient tous les éléments de la nouvelle partie. (La nouvelle grille est affichée, les éléments placés, les nouveaux paramètres modifiés). La validité des paramètres sera précisée dans la phase de test.

4- La course.

Le déroulement d'une course se fait essentiellement par l'algorithme de gestion d'une course de l'unité de contrôle. Celui-ci a déjà été décrit précédemment.

L'implémentation en java de cet algorithme a nécessité la présence d'un Timer. (qui correspond à la vitesse d'un tour) Il évite que les déplacements se fassent trop vite ce qui empêcherait l'utilisateur de suivre le déroulement de la course.

En ce qui concerne le déplacement des robots, l'algorithme de déplacement décrit précédemment a, lui aussi, été implémenté. Il a fallu penser, en plus, à actualiser l'affichage de la grille à chaque déplacement pour que l'utilisateur puisse voir le déroulement de la course.

On précise que si on clique sur une case pendant la course, l'application nous dit si cette case est vide ou occupée. De plus, l'enchainement des courses est automatique, l'utilisateur n'a pas besoin de relancer la course suivante.

5- Affichage

Lorsque le déplacement est automatique, la grille s'affiche normalement sur la fenêtre principale c'est-à-dire que l'utilisateur voit la grille avec tous les robots et les obstacles qu'il a placés. Le champ de vision des robots est également affiché.

Cependant, quand le déplacement est manuel, la grille ne s'affiche que partiellement.

L'utilisateur ne voit pas tous les obstacles qu'il a placés et, parfois, il ne voit pas les deux robots.

Ceci n'est pas dû à un dysfonctionnement. En effet, si les deux robots sont déplacés manuellement, l'application affiche dans la grille de la fenêtre principale seulement le robot qui est en train de jouer et ce qu'il « voit » dans son champ de vision, celui-ci étant lui aussi affiché. Toutes les autres cases semblent vides ou, du moins, rien n'y est affiché. Mais, elles ne sont pas vides, c'est juste l'application qui les cache. Par exemple, un obstacle apparaitra lorsqu'il sera dans le champ de vision du robot qui jouera. De même, ce même obstacle disparaîtra s'il ne fait plus parti du champ de vision du robot en train de jouer.

Lorsqu'un robot est déplacé manuellement et l'autre automatiquement, seul le robot se déplaçant manuellement est affiché. L'autre reste invisible même quand c'est à lui de jouer. Cela permet de mettre l'utilisateur dans les vraies conditions de jeu. Il ne voit que ce que le robot « voit ».

De plus, lors de la course, la grille est actualisée. Ainsi, en déplacement automatique,

l'utilisateur voit le déplacement fait par les robots et il peut suivre la course. Si les deux robots sont manuels, ils s'affichent chacun leur tour. Leur déplacement est également pris en compte. Quand un des deux robots est manuel et l'autre automatique, l'utilisateur ne voit que le déplacement du robot étant déplacé manuellement. Le déplacement de l'autre robot, bien qu'il se produise, reste inconnu et ne s'affiche pas.

Programmation:

Tout ceci est dirigé par l'unité de visualisation. Au départ, une fonction affiche la grille seule:

elle ne contient aucun élément. Ensuite, si le déplacement est automatique, toutes les cases de la grille sont testées: si une case contient un élément celui-ci est affiché, sinon elle reste vide.

En déplacement manuel, les cases du champ de vision du robot en train de jouer sont calculées, puis, elles sont testées.

Lors de l'actualisation: en déplacement automatique, seules les deux cases où a évolué le robot sont modifiées (celle où il était avant de se déplacer et celle où il est après son déplacement). Le champ de vision est lui aussi réactualisé pour être affiché.

Lorsque les deux robots sont déplacés manuellement, la grille entière est réactualisée: le robot qui a fini de jouer disparaît, lui et son champ de vision. Pendant ce temps, l'autre robot apparaît, ainsi que son champ de vision (et les éléments faisant partie de son champ de vision).

Lorsqu'un seul des robots est automatique, les éléments des cases de son ancien champ de vision disparaissent, son nouveau champ de vision est calculé et les éléments en faisant parti sont affichés.

V- Les tests unitaires et fonctionnels:

En ce qui concerne les données, si cela n'est pas précisé la taille de la grille est de longueur 10 et de largeur 12 (abrégé en Taille 10/12), le nombre de course est initialisé à 1, le nombre de tour à 25, la vitesse à 500 et le déplacement est fait automatiquement. Les robots ont un champ de vision de 1. Nous présentons ici les fonctions principales de l'application, mais nous précisons que toutes les fonctions ont été testées.

1- Les fonctions de placement et déplacement

a- Position initiale

Données: Pour tester la validité de cette méthode, nous avons choisi de l'évaluer sur plusieurs grilles de différentes tailles: Taille: 3/3, Taille 10/12, Taille 20/20, Taille 3/20, Taille 20/3. Pour chaque grille, les éléments ont été testés sur toutes les cases (à peu près) notamment les bords. A chaque fois, les deux robots étaient positionnés et plusieurs obstacles (allant de 2 à 100 selon les grilles) étaient également placés.

Description: Nous avons vérifié que nous pouvons placer des éléments sur la grille. Les tests ont notamment vérifié que chaque élément (prédateur, proie, obstacle) peut aller sur n'importe quelle case vide, mais que nous ne pouvons pas placer deux éléments sur une seule case. De plus, nous avons vérifié que la fonction supprimant les obstacles de la grille ne peut pas supprimer les robots.

Résultat: Chaque élément peut aller sur n'importe quelle case vide. L'application envoie un message lorsque l'utilisateur essaye de placer un élément sur une case déjà occupée. Elle envoie également un message d'erreur si nous essayons de supprimer un robot au lieu d'un obstacle.

b- Repositionnement

Données: Le repositionnement des robots a été fait sur des grilles de tailles 10/12, 15/15 et 3/20.

Les robots ont été placés sur 10 cases de chaque grille en testant plusieurs cas: un robot sur le bord, un robot au centre, les deux au centre, les deux sur les bords, les deux robots éloignés l'un de l'autre ou, au contraire, rapprochés. Les robots avaient un champ de vision allant de 1 à 5 (lorsque c'était possible). Le nombre d'obstacles variait de 2 à 50. Les tests ont été effectués pour des déplacements automatiques et manuels. Nous précisons également que le repositionnement a été fait au cours de la course (course arrêtée prématurément) ou à la fin de course.

Description: A la fin d'une course, les robots sont replacés sur la case qu'ils occupent avant la course. En plus de s'assurer du bon fonctionnement de cette méthode, les tests ont vérifié qu'il n'y a pas de problème dans le cas où un robot occupe à la fin de la course la position initiale de l'autre robot.

Résultat: A l'appel de la méthode, les robots retournent, dans toutes les situations, sur la case qu'ils occupent au début de la course.

c- Déplacement si l'autre robot n'est pas vu.

Données: Les tests se sont effectués principalement sur la grille n°1(en annexe), la grille n°2 et sur une grille sans obstacle. Les robots ont été placés sur plus de 20 cases de ces grilles. Nous avons surtout cherché à « coincer » les robots en les plaçant sur des cases avoisinant un ou plusieurs obstacles.

Description: On rappelle que ce déplacement se fait au hasard, tout en évitant les répétitions. Une répétition étant le déplacement sur la case où il était au tour précédent.

Nous avons créé une fonction pour compter les cases disponibles et une autre évitant les répétitions. Nous avons donc testé plusieurs fois ces fonctions pour vérifier que le robot ne se déplace pas sur les obstacles, ne sort pas de la grille et évite de faire des répétitions. Nous avons dû évaluer également deux cas spéciaux: le premier déplacement où la répétition n'est pas prise en compte (comme il s'agit du premier déplacement il n'y a pas de tour précédent) et le cas où le robot se trouve dans une impasse et doit faire demi-tour pour avancer. Dans ce cas-là, la répétition n'est également pas prise en compte sinon le robot ne peut plus se déplacer.

Résultat: Les robots avancent comme prévu dans toutes les situations. Le seul bémol étant qu'ils « stagnent » parfois sur une petite portion de la grille au lieu de la parcourir entièrement. Cela est dû à la fonction aléatoire et au fait qu'ils ne retiennent que la case où il était le tour précédent et pas celles des autres tours.

d- Déplacement du prédateur lorsqu'il voit la proie.

Données: Cette méthode a été testée principalement sur la grille n°2 (en annexe). Le champ de vision pour chaque robot allait de 3 à 7.

Description: Le prédateur choisit le chemin le plus court pour aller vers la proie.

Pour cela, il a fallu vérifier qu'il prend bien le chemin le plus court pour aller vers la proie en évitant les obstacles et sans sortir de la grille. Cependant, il a fallu tester un autre cas, celui où le prédateur voit la proie, mais où il n'existe pas de chemin pour l'attraper d'après son champ de vision. Dans ce cas, le prédateur se déplace comme s'il ne voyait pas la proie.

Résultat: Le prédateur se déplace correctement. On précise que pour vérifier les résultats une fonction dessinant la grille calculant le chemin le plus court a été créée. Elle nous a permis de vérifier que le chemin emprunté par le prédateur pour atteindre la proie est le plus court à chaque fois.

e- Déplacement de la proie lorsqu'elle voit le prédateur.

Données: Cette méthode a été également testée sur la grille n°2 avec un champ de vision pour chaque robot allant de 3 à 7.

Description: La proie essaye de s'écarter le plus du prédateur. Pour cela, nous avons dû vérifier sur plusieurs grilles qu'elle s'enfuit bien et qu'elle ne sort pas de la grille ou ne va pas sur des cases occupées par des obstacles. Nous avons noté un cas à part, celui où le prédateur ne peut pas attraper la proie. Dans ce cas, la proie se déplace comme si elle ne voyait pas le prédateur.

Résultat: La proie se déplace correctement et s'enfuit comme il le faut quand elle le peut. Quand elle est coincée par le prédateur et ne peut pas s'enfuir, elle se déplace sur seulement deux ou trois cases alternativement.

f- Déplacement manuel

Données: Cette méthode a été testée sur la grille n°1 et une grille sans obstacle.

Description: L'utilisateur doit contrôler son robot. Nous avons donc vérifié que le lancement de la course de façon automatique est impossible. Réciproquement, en fonctionnement automatique, les robots ne peuvent pas être déplacés par l'utilisateur. De plus, chaque robot avançant l'un après

l'autre, nous avons fait attention de ne pas pouvoir déplacer deux fois de suite le même robot.

Enfin, nous avons testé le cas où l'utilisateur voudrait aller sur un obstacle ou sortir de la grille.

Dans ce cas, le déplacement ne se fait pas. Notons que tant que le déplacement n'est pas valide, c'est toujours au même robot de jouer.

Résultat: Tout fonctionne correctement. L'application envoie un message d'erreur lorsque l'utilisateur veut faire un déplacement automatique alors qu'il est manuel et réciproquement. Pour les autres cas, l'application les gère mais ne laisse pas de message.

2 - Les fonctions d'affichage.

Pour chaque fonction d'affichage les données sont les suivantes: Les grilles testées sont de tailles 3/3, 10/12, 15/15, 20/20, 3/20, 20/3. Nous avons testé également plusieurs couleurs de bords et de fond (rouge, bleu, violet, orange etc.). En ce qui concerne les éléments de la grille, les robots ont été placés au hasard ainsi que 5 à 20 obstacles. Le champ de vision des robots variaient entre 1 et 5 (lorsque c'était possible). L'affichage a été vérifié en déplacement automatique et manuel.

a- L'affichage de la grille.

Description: En changeant la couleur et la taille de la grille, puis en rajoutant des obstacles et les robots, nous avons vérifié qu'elle s'affiche comme prévu. Nous avons aussi vérifié que la couleur des bords d'une case ne peut pas être la même que celle du fond (sinon la délimitation des cases ne pourrait pas se faire). Si certains robots sont contrôlés manuellement, la grille apparaît partiellement.

Résultat: Dans chaque cas l'affichage s'est fait comme souhaité. En changeant plusieurs fois entre manuel et automatique, l'application alternait entre affichage total et affichage partiel sans problème. De plus, si l'utilisateur essaye de mettre la même couleur pour le fond et pour les bords un message d'erreur apparaît.

b- Le champ de vision.

Description: Nous avons vérifié que le champ de vision apparaissait comme prévu. Nous avons porté une attention particulière à son affichage lorsque les robots sont contrôlés manuellement, puisque celui-ci doit être affiché seulement pour le robot prêt à se déplacer.

Résultat: Il n'y a pas eu de souci d'affichage pour le champ de vision. En automatique, on note que lorsque les champs de vision des deux robots se rencontrent, la partie partagée par les deux champs change de couleur.

c- Les éléments.

Données (en plus): Toutes les images des robots ont été testées.

Description: Nous avons d'abord vérifié que chaque élément s'affichait correctement sur la grille quelle que soit sa position. Nous avons ensuite évalué le cas particulier de l'affichage lors du contrôle manuel en vérifiant que seuls les éléments se trouvant dans le champ de vision du robot

prêt à se déplacer était affiché. En ce qui concerne la représentation des deux robots, nous avons fait attention de ne pas pouvoir choisir la même image pour ne pas les confondre.

Résultat: Les éléments s'affichent quand il faut sur la grille. En ce qui concerne la représentation des robots, un message d'erreur est lancé si on essaye de choisir la même image pour les deux robots.

3- Les fonctions d'initialisation et de validation de la grille.

a- Initialisation

Données: Nous avons testé des chiffres de 0 à 26 pour les courses, de 0 à 76 pour les tours, de 0 à 1501 pour la vitesse et également des chiffres négatifs.

Description: Nous avons vérifié que la grille créée est valide pour faire une course. Ainsi le nombre de courses, de tours et la vitesse ne doivent pas être négatifs par exemple. Il est aussi indispensable que le prédateur puisse attraper la proie.

Résultat: Seules les valeurs valides ont été gardées par les différentes fonctions. Si une des valeurs n'est pas valide, (inférieure ou supérieure au nombre minimal ou maximal) une exception est lancée. Par exemple, mettre 5 courses initialise le nombre de course à 5, mais mettre 0 course lance une exception et le nombre de course est par défaut mis à 1.

b- Validation

Données: Nous avons testé plusieurs cas dans lesquelles on plaçait les deux robots de façon à ce qu'ils ne puissent pas s'attraper ou l'un à côté de l'autre auquel cas le prédateur a forcément gagné.

Ces tests ont été essayés principalement dans la grille n°3(en annexe)

Description: Nous avons vérifié ici, que la fonction de validation était correcte. Ainsi si le prédateur ne peut pas attraper la proie, la course ne peut pas être validée et il en est de même si la proie est déjà attrapée.

Résultat: Dans chaque cas, la fonction s'effectue correctement. La grille est validée si les deux robots peuvent se rejoindre et que le prédateur n'a pas déjà gagné. Dans le cas inverse, un message d'erreur apparaît.

4- Tests fonctionnels

a- Nouvelle partie

Nous avons suivi les étapes qui ont été décrites dans la partie IV (Développement).

Nous avons d'abord choisi une grille en essayant de choisir la même couleur pour les bords et pour le fond: un message d'erreur est apparu.

Nous avons choisi ensuite nos robots en essayant de prendre la même image pour les deux robots: un message d'erreur est apparu. Nous avons donc pris une image différente.

Nous avons essayé de valider la grille sans avoir placé les robots: un message d'erreur est apparu. Nous avons donc placé les robots et quelques obstacles. Après le placement nous avons

essayé de valider: un message d'erreur est apparu nous informant que les paramètres de la course n'étaient pas définis.

En ce qui concerne les paramètres, nous avons essayé de mettre 0 pour le nombre de course: un message d'erreur est apparu. De même, des messages d'erreurs sont apparus en essayant de mettre 725 aux nombre de tours et -22 pour la vitesse. Une fois tous les paramètres remplis correctement, nous avons validé la course. La partie a été validée et la grille s'est affichée dans la fenêtre principale. De même le nombre de course, de tours et la vitesse se sont affichés dans les paramètres de la fenêtre principale.

b- Nouvelle course

Sur une grille quelconque (celle créé par le test précédent par exemple) nous avons lancé une course. On précise que le déplacement est automatique. Nous avons donc pu voir que tout s'enchaînait correctement, que les robots avançaient l'un après l'autre et que le nombre de tours était bien incrémenté à chaque fois. En augmentant la vitesse lors de la course, les robots accéléraient, en la diminuant, ils ralentissaient. Si on stoppait la course, les robots s'arrêtaient et reprenaient si on la relançait. Enfin, si on tentait de jouer manuellement alors que le déplacement est automatique un message d'erreur apparaissait.

VI- Exploitation

1- Exemple d'exploitation

Essai n°1:

Grille 10/12. Prédateur placé en 3/3. Proie placée en 7/8. Champ de vision des deux robots: 2. Nombre d'obstacles: 12 (Placés aléatoirement). Nombre de courses: 3. Nombre de tours:

25. Vitesse: 500. Déplacement: automatique.

Résultat: Prédateur: 1 victoire et Proie: 2 . Tours moyen: 21.

Explication: Le champ de vision est assez petit par rapport à la grille et le prédateur met longtemps avant de trouver la proie.

Essai n°2:

Grille 10/10. Prédateur placé en 7/4. Proie placée en 6/7. Champ de vision des deux robots: 5. Nombre d'obstacles: 20 (Placés aléatoirement). Nombre de courses: 5. Nombre de tours:

35. Vitesse: 500. Déplacement: automatique.

Résultat: Prédateur: 5 victoires et Proie: 0. Tour moyen 7.

Explication: Les deux robots se voient dès le début de la course. Ils effectuent à quelques exceptions près toujours le même déplacement (la proie essaye au maximum d'éviter le prédateur et le prédateur calcule le chemin le plus court pour attraper la proie). Ainsi le déplacement des robots évolue peu et c'est toujours le même robot qui gagne (ici le prédateur, mais dans une autre grille il est possible que ce soit la proie.)

Essai n°3:

Grille 7/9. Prédateur placé en 3/ 4. Proie placée en 6/8. Champ de vision des deux

robots: 2. Nombre d'obstacles: 10 (Placés aléatoirement). Nombre de courses: 3. Nombre de tours:

15. Vitesse: 500. Déplacement: automatique.

Résultat: Prédateur 2 victoires. Proie 1. Tour moyen: 9

Explication: Tous les paramètres sont à peu près réglés pour que le prédateur et la proie puissent gagner chacun à leur tour. Aucun paramètre n'avantage un des robots. Ce qui explique ce résultat.

2- Constats

En plus des exemples précédents, nous avons testé l'application sur de nombreuses grilles, avec des robots aux champs de vision différents, en déplacement automatique et manuel, sur des courses plus ou moins longues. Pour les différents constats qui suivent nous nous sommes basés sur les statistiques trouvées (nombre de courses gagnées par chaque robot et tours moyens)

Constat n°1: Plus la grille est grande, plus le champ de vision doit être grand pour que le prédateur ait une chance d'attraper le prédateur. La plupart du temps, le tour moyen augmente quand la taille de la grille augmente.

Constat n°2: Si les deux robots n'ont pas le même champ de vision, c'est généralement le robot au plus grand champ de vision qui gagne.

Constat n°3: Plus les robots sont éloignés l'un de l'autre, plus il est difficile pour le prédateur d'attraper la proie. (Tour moyen élevé). La proie gagne aussi plus souvent.

Constat n°4: Si les deux robots se voient au départ de la course, c'est généralement toujours le même robot qui gagne.

Constat n°5: Plus il y a d'obstacles dans la grille, moins le prédateur gagne. Généralement, le tour moyen augmente lorsqu'on rajoute des obstacles.

Constat n°6: Plus il y a de tours dans la course, plus le prédateur gagne.

VII-Annexe

Grille n°1

Grille n°2

Grille n°3