La guerre des robots

Solution : 

Diagramme de classes d'analyse

• 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
• La couleur est maintenant un attribut de l'équipe (cf énoncé)
  
• 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)
• 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
  
• Comme d'habitude, les attributs communs à toutes les instances d'une classe sont préfixés  c_ et static (souligné) 
• La classe Simulation est un singleton car elle n'a qu'une instance (le jeu en cours) et toutes ses opérations sont collectives
  
• 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.
• "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)

Conception :

• Faites le diagramme de conception, ajoutez une classe "IHM" qui servira d'interface entre l'utilisateur et le système

Quelques remarques : 

• Rappel : Dans un DCC les relations sans flèches sont des relations bi-orientées
• 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.

• 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")
  
• 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"
  

• Faites un diagramme de séquences (cf chapitre 4) pour chacune des requêtes suivantes :
  • Recharger d'une quantité e les batteries du robot N°7 de l'équipe "rouge"

  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" 

  

   

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

  

   

  • Ajouter un nouveau robot à  la simulation (avec ses paramètres de construction), on supposera qu'il s'agit d'un porteur

  

   
• Afficher l'équipe gagnante : son nom, sa couleur, sa quantité de minerai et le nombre de foreuses qui y sont rattachées