Aide/Validation Diagramme de classes

Bonjour à tous,

Dans le cadre d'un projet à réaliser au cours de mes études, je dois créer deux applications en C++ avec un autre étudiant.
Pour nous obliger à passer par une phase de modélisation et à utiliser des concepts fondamentaux de la POO tels que l'héritage et le polymorphisme, nous devons partir d'un modèle objet générique pour ensuite le décliner en deux applications similaires.

Nous avons donc choisi de développer deux jeux de plateaux : le jeu de dames et le jeu d'othello, en se basant sur un modèle objet général de "jeux de plateau".
Nous allons inclure, pour chacune des deux applications :
- la possibilité de jouer contre une IA (algo min-max avec élagage alpha beta), dès la première version
- une interface graphique fenêtrée, dans une seconde version (dans un premier temps, l'interface sera textuelle)
Nous ajouterons éventuellement (ce n'est pas une priorité) la possibilité de jouer en réseau (local ou non).
Nous aimerions donc que ce modèle soit :
- générique
- efficace
- dotée d'une IHM facilement remplaçable (utilisation du patron de conception MVC => passer d'une version textuelle à une version graphique en remplaçant uniquement la vue)
- facilement maintenable, réutilisable, évolutif (facilité d'ajout de nouvelles fonctionnalités au programme tels que le jeu en réseau, la sauvegarde de partie…)

Nous sommes en train de concevoir le diagramme de classes de ce modèle objet générique de jeux de plateau.
Nous aimerions avoir votre avis sur le modèle actuel et nous avons plusieurs questions à vous poser.
En effet, nous éprouvons une certaine difficulté à concevoir ce modèle…

Voici ce que nous avons fait pour l'instant :
Pièce jointe 173006


Nous allons vous expliquer le modèle et les choix que nous avons fait au niveau de la conception.
N'hésitez pas à les commenter, les valider ou les infirmer.
C'est la première fois que nous faisons un projet avec une phase de conception aussi poussée, alors il est très probable que tout soit à refaire, soyez gentil avec nous s'il vous plait :-).

Tout d'abord au niveau du modèle:

- Une classe plateau qui représente le plateau du jeu, de taille nbLignes*nbColonnes.
Il dispose d'une méthode permettant de savoir si une coordonnée est valide (i.e., contenu dans les bornes du plateau).

- Ce plateau est constitué de cases, ayant une position sur plateau et une couleur.
Sur une case peut éventuellement être posée une pièce.
On peut donc savoir si une case est libre.

- Une pièce est un élément du jeu que l'on peut poser sur le plateau (aux dames : pions, dames. À l'othello : un seul type de pièce).
Une pièce est éventuellement posée sur une case, on peut la déplacer sur une case.
Elle appartient éventuellement à un joueur.
Avec une pièce, on peut faire un certains nombres de coups (par exemple, au tout début du jeu de dames on n'a que des pions et certains de ces pions peuvent être déplacés sur deux cases. À mesure que le jeu évolue, des possibilités telles que la prise de pions ou la "rafle" de pions deviennent possibles. En fin de partie, on se retrouve souvent avec des dames qui, elles, peuvent se déplacer sur un nombre plus important de cases. À l'othello, pour les pièces n'étant pas posées sur le plateau, on peut les poser sur un certains nombre de case alors que celles qui sont posées sur le plateau ne sont pas déplacables).
On peut donc mettre à jour les coups de la pièce (et cela se fait de manière abstraite : cela dépend entièrement du jeu auquel on joue).

- Un coup serait donc composé d'une pièce de départ et d'une suite de cases (cas particulier de la rafle aux dames où la pièce se déplace sur plusieurs cases avant d'atteindre sa position finale).
Une variable statique serait ici présente pour connaitre la valeur de l’enchaînement maximum de cases pour un coup (aux dames, on ne peut jouer que les rafles maximales : nécessité de connaitre la valeur de cette rafle maximale et de supprimer les coups dont le nombre de cases est inférieur à cette variable).

- Un joueur a un certains nombres de pièces.
Il possède une couleur propre à lui-même et ses pièces sont affichés comme étant de cette couleur.
Il peut être Humain ou artificiel.
Il peut jouer un coup.

- Une classe Jeu représente un état du jeu à l'instant t.
C'est une "photographie" de la partie.
À un tour fixé (la variable nbToursJoue), nous avons à dispositions des pièces, des joueurs, un plateau.
Nous avons aussi une liste de coups autorisés pour passer à l'état suivant du jeu, que nous pouvons générer en examinant les coups de chaque pièces.
À partir du nombre de joueurs présent et du nombre de tours joué, on peut facilement en déduire le joueur ayant le trait.
Avec un coup, on peut générer un nouveau jeu correspondant à l'état suivant.
De manière abstraite, on peut connaitre les pièces du jeu dont il est nécessaire de mettre à jour les coups (aux dames, il faut regarder toutes les pièces du plateau. À l'othello, il suffit de considérer une seule pièce : un des pièces qui n'est pas posée sur le plateau).
On peut savoir si l'état du jeu est nul, si le jeu est terminé (i.e. si quelqu'un a gagné la partie).

- Enfin, la classe IA permet de connaitre le meilleur coup jouable depuis une position du jeu donnée (grace à l'algorithme min-max).
Cet algorithme est le même pour tous les jeux deux joueurs à somme nulle.
Toutefois, il est nécessaire d'être capable d'évaluer une position de jeu, et cela se fait de manière abstraite.

On arrive au patron MVC :

- Une classe controleur qui a un jeu, une vue et éventuellement une IA.
Elle initialise le jeu de manière abstraite (les attributs du jeu dépendent complétement du jeu joué), mais globalement la partie se déroule de la même manière pour tous les jeux (on joue au jeu de manière concrete, grace à des méthodes abstraites).

- Une classe vue qui peut afficher le menu du jeu, lire le mode de jeu (avec ou sans IA), afficher le jeu, récupérer les coups joué. Tout cela de manière purement abstraite car cela dépend entierement du jeu joué.


Voici maintenant une liste de questions que nous avons :
- Niveau association/composition sur le diagramme, est-ce que tout colle avec ce que l'on vient de dire ?
- Nous comptons inclure la gestion des exceptions, que préconisez-vous ?
- Au niveau du patron MVC, est-ce que ce que nous avons fait nous permettra de changer très facilement l'IHM ? Y'a-t-il des choses à modifier dans notre modèle objet pour garantir cela ? Nous avons entendu parler du "pattern observer" pour le MVC, à quoi sert-il et comment le mettre en place ?
- Est-ce que l'algorithme min-max sera efficace avec ce modèle ? Nous aimerions pouvoir avoir quelque chose de très efficace pour gagner en profondeur dans la recherche min-max et ainsi rendre l'IA plus poussée. C'est plus de l'algo, mais bon : quelles heuristiques recommenderiez-vous au niveau de l'évaluation du jeu pour avoir une IA puissante ?

Si vous avez pris le temps de lire tout cela et que vous comptez nous répondre, nous vous remercions infiniment de prendre de tout ce temps pour nous.
Il nous est très difficile de concevoir un bon modèle, et tout conseil nous serait d'une grande aide.