250 lines
6.4 KiB
HTML
250 lines
6.4 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
|
||
|
|
<meta http-equiv="Content-Language" content="fr">
|
||
|
|
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
||
|
|
<title>ROBOT-2</title>
|
||
|
|
|
||
|
|
|
||
|
|
</head>
|
||
|
|
|
||
|
|
|
||
|
|
<body>
|
||
|
|
|
||
|
|
<span style="font-family: Arial;">
|
||
|
|
<h1>La guerre des robots<br>
|
||
|
|
|
||
|
|
</h1>
|
||
|
|
|
||
|
|
<h2>Solution : </h2>
|
||
|
|
|
||
|
|
<h3>Diagramme de classes d'analyse</h3>
|
||
|
|
|
||
|
|
<p><img style="border: 0px solid ;" alt="DCA Robot" src="RoboA.jpg"></p>
|
||
|
|
|
||
|
|
Quelques remarques :
|
||
|
|
<br>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>On pourrait
|
||
|
|
regrouper en une
|
||
|
|
seule classe Equipe et Base puisqu'elles sont en relation 1--1 ; les
|
||
|
|
concepts étant différents, j'ai toutefois choisi
|
||
|
|
de les
|
||
|
|
séparer, cela permettrait une réutilisation plus
|
||
|
|
rapide
|
||
|
|
si on décidait qu'une équipe peut avoir plusieurs
|
||
|
|
bases</li>
|
||
|
|
|
||
|
|
<li><font face="Arial">La couleur est maintenant
|
||
|
|
un attribut de
|
||
|
|
l'équipe (cf énoncé)<br>
|
||
|
|
|
||
|
|
</font></li>
|
||
|
|
|
||
|
|
<li><font face="Arial">get_distancePerception est
|
||
|
|
abstraite dans
|
||
|
|
Robot et redéfinie dans les sous-classes car la distance de
|
||
|
|
perception n'est connue que ds ces sous-classes ; au contraire,
|
||
|
|
"percevoir" est concrète dans Robot car on peut y produire
|
||
|
|
tout
|
||
|
|
l'algorithme en faisant appel à getDistancePerception, elle
|
||
|
|
retourne un Vector d'Objets des objets perçus (Obstacles,
|
||
|
|
robots, bases)</font></li>
|
||
|
|
|
||
|
|
<li><font face="Arial">getCouleur est
|
||
|
|
concrète dans
|
||
|
|
"Robot" puisque son algorithme ne dépend pas des
|
||
|
|
sous-classes,
|
||
|
|
il ne dépend que de l'équipe ( =
|
||
|
|
getEquipe().getCouleur() ) ; en revanche, elle est abstraite
|
||
|
|
dans
|
||
|
|
Objet à cause de Obstacle<br>
|
||
|
|
|
||
|
|
</font></li>
|
||
|
|
|
||
|
|
<li><font face="Arial">Comme d'habitude, les
|
||
|
|
attributs communs
|
||
|
|
à toutes les instances d'une classe sont
|
||
|
|
préfixés c_ et static
|
||
|
|
(souligné) </font></li>
|
||
|
|
|
||
|
|
<li><font face="Arial">La classe Simulation est un
|
||
|
|
singleton car elle
|
||
|
|
n'a qu'une instance (le jeu en cours) et toutes ses
|
||
|
|
opérations
|
||
|
|
sont collectives<br>
|
||
|
|
|
||
|
|
</font></li>
|
||
|
|
|
||
|
|
<li><font face="Arial">recevoirTir est une
|
||
|
|
opération abstraite
|
||
|
|
de Objet qui est redéfinie dans tous les types d'objets
|
||
|
|
susceptibles de recevoir des tirs de foreuses ; son algorithme devra
|
||
|
|
détailler ce qui se passe alors (p.ex.
|
||
|
|
décrémenter
|
||
|
|
la solidité d'une valeur proportionnelle à la
|
||
|
|
puissance
|
||
|
|
du tir, mais on pourrait aussi complexifier le jeu en tirant
|
||
|
|
aléatoirement une avarie comme par ex. diminuer la distance
|
||
|
|
de
|
||
|
|
perception ou la charge max ). RQ : L'énoncé ne
|
||
|
|
dit rien
|
||
|
|
du tir sur une base : on pourrait la redéfinir en une
|
||
|
|
opération vide.</font></li>
|
||
|
|
|
||
|
|
<li><font face="Arial">"ajouter un nouveau robot"
|
||
|
|
donne naissance
|
||
|
|
à 2 méthodes différentes selon qu'il
|
||
|
|
s'agit d'une
|
||
|
|
foreuse ou d'un porteur (les paramètres sont
|
||
|
|
différents
|
||
|
|
aussi)</font></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<h3>Conception :</h3>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Faites le diagramme de conception, ajoutez une classe "IHM"
|
||
|
|
qui
|
||
|
|
servira d'interface entre l'utilisateur et le système</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p><font face="Arial">
|
||
|
|
Quelques remarques : </font></p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li><font face="Arial">Rappel : Dans un DCC les
|
||
|
|
relations sans
|
||
|
|
flèches sont des relations bi-orientées</font></li>
|
||
|
|
|
||
|
|
<li><font face="Arial">Alors qu'un diagramme
|
||
|
|
d'analyse
|
||
|
|
présente peu de variations possibles, il y a
|
||
|
|
souvent, au contraire, de nombreux choix de conception
|
||
|
|
possibles
|
||
|
|
avec des avantages et des inconvénients : Ici par exemple,
|
||
|
|
on
|
||
|
|
pourrait choisir de mettre un gestionnaire d'instances sur chaque type
|
||
|
|
d'objet : obstacle, équipe, chaque équipe
|
||
|
|
gérant
|
||
|
|
les instances de ses robots, ("Base" étant liée
|
||
|
|
à
|
||
|
|
"Équipe" en 1..1 elle n'a pas absolument besoin d'une
|
||
|
|
gestion
|
||
|
|
propre), ceci conduit à orienter les relations des
|
||
|
|
gestionnaires
|
||
|
|
vers leurs objets.</font></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p><img src="roboC_autre.jpg" border="0" height="437" width="915"></p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li><font face="Arial">Je n'ai pas retenu cette
|
||
|
|
solution, j'ai choisi
|
||
|
|
de faire de "Simulation" un super-gestionnaire d'instances de tous les
|
||
|
|
objets car c'est lui de toutes façons qui devra "donner vie"
|
||
|
|
à chaque objet en fonction de son type et qui devra
|
||
|
|
décider du type d'objet qui se trouve en (x,y) lors de la
|
||
|
|
perception par exemple (d'où le "getType" abstrait de
|
||
|
|
"Objet") <br>
|
||
|
|
|
||
|
|
</font></li>
|
||
|
|
|
||
|
|
<li><font face="Arial">Les relations sont
|
||
|
|
orientées dans le
|
||
|
|
sens strictement nécessaire pour une bonne
|
||
|
|
réutilisation
|
||
|
|
p.ex : orienter de Base vers Equipe et non l'inverse permet
|
||
|
|
d'évoluer facilement vers une solution "plusieurs bases par
|
||
|
|
équipe"<br>
|
||
|
|
|
||
|
|
</font></li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p><img src="RoboC.jpg" border="0" height="735" width="915"></p>
|
||
|
|
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Faites un diagramme de séquences (cf chapitre 4)
|
||
|
|
pour
|
||
|
|
chacune des requêtes suivantes :
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Recharger d'une quantité e les batteries du
|
||
|
|
robot
|
||
|
|
N°7 de l'équipe "rouge" </li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>NB : Les 3 paramètres de la requête
|
||
|
|
sont :
|
||
|
|
numéro et couleur du robot considéré
|
||
|
|
et
|
||
|
|
énergie à recharger mais sur le diagramme de
|
||
|
|
séquence, tous les paramètres apparaissent
|
||
|
|
toujours comme
|
||
|
|
"x" </p>
|
||
|
|
|
||
|
|
<p><img src="DSeq1.jpg" border="0" height="714" width="749"></p>
|
||
|
|
|
||
|
|
<p> </p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Quel est le type (foreuse ou porteur),
|
||
|
|
l'équipe et le
|
||
|
|
niveau d'énergie du robot situé en x,y ? (on
|
||
|
|
supposera
|
||
|
|
qu'il n'y en a qu'un)</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p><img src="DSeq2.jpg" border="0" height="794" width="707"></p>
|
||
|
|
|
||
|
|
<p> </p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
|
||
|
|
<li>Ajouter un nouveau robot à la
|
||
|
|
simulation (avec
|
||
|
|
ses paramètres de construction), on supposera qu'il s'agit
|
||
|
|
d'un
|
||
|
|
porteur</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p><img src="DSeq3.jpg" border="0" height="674" width="1082"></p>
|
||
|
|
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li>Afficher l'équipe gagnante : son nom, sa
|
||
|
|
couleur, sa
|
||
|
|
quantité de minerai et le nombre de foreuses qui y sont
|
||
|
|
rattachées</li>
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p><img src="DSeq4.jpg" border="0" height="794" width="790"></p>
|
||
|
|
|
||
|
|
<p> </p>
|
||
|
|
|
||
|
|
<p> </p>
|
||
|
|
|
||
|
|
<p> </p>
|
||
|
|
|
||
|
|
</span>
|
||
|
|
</body>
|
||
|
|
</html>
|