MàJ par récupération sur Clé USB et dans /mnt/hd/Chargement du pc portable
This commit is contained in:
olivier
249
G5a/Solutions/Robot/robo_corrige.htm
Normal file
249
G5a/Solutions/Robot/robo_corrige.htm
Normal file
@ -0,0 +1,249 @@
|
||||
<!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>
|
||||
Reference in New Issue
Block a user