Échecs en JavaFX

Présentation du projet (Juin 2024)
Nous avions un projet collaboratif universitaire (une SAÉ) où nous devions reproduire une capture d'écran du site web Chess.com en JavaFX. Nous avons travaillé à quatre sur ce projet: Youssef E., Maxime A., Baptiste A. et moi-même. Nous n'avions pas à reproduire le fonctionnement complet du jeu d'échecs, mais uniquement les déplacements et quelques autres fonctionnalités (tournoi, jouer contre un ordinateur faisant des coups aléatoires...) Dans le cadre de ce projet, nous devions respecter certaines contraintes, telles que:
- Proposer un code commenté, versionné, et documenté;
- Implémentation du modèle MVC;
- Proposer des diagrammes d'analyse et de conception;
- Proposer des tests;
- Mettre en place les bonnes pratiques en matière d'ergonomie.
Le code était abondamment commenté en utilisant des commentaires Javadoc, versionné avec Git (et GitHub), documenté avec un README et la documentation Javadoc générée, et testé avec JUnit. La convention MVC a été respectée, avec une séparation entre modèles, vues et contrôleurs, qui étaient chacuns dans un package distinct. Nous avons également réalisé des diagrammes d'analyse et de conception, et nous avons fait des recherches bibliographiques quant à l'ergonomie. Vous trouverez dans la galerie des images du projet.
Ce projet m'a apporté une expérience en matière de développement Java et JavaFX, de collaboration, de documentation, de tests unitaires, de versionnage, et de respect des bonnes pratiques de développement. J'ai également pu approfondir mes connaissances en architecture logicielle.
Modèle MVC et architecture du code
Le modèle MVC pour Modèle, Vue, Contrôleur est un modèle d'architecture logicielle destiné aux interfaces graphiques. Il se décompose donc en trois parties:
- Le modèle, qui contient les données et les méthodes pour les manipuler;
- La vue, qui affiche les données et les contrôles;
- Le contrôleur, qui gère les interactions entre le modèle et la vue.
Modèles
Les modèles se trouvaient dans le package model. Le package des contrôleurs, controller, est un sous-package du parent de model. Parmi les modèles, il existe 8 classes et une interface.
- La classe Piece est une classe abstraite, avec des méthodes publiques communes à toutes ses classes filles, et des méthodes abstraites que chaque classe fille implémente;
- Les classes filles de Piece (Cavalier, Pion, Fou, Roi, Reine et Tour) sont toutes des pièces qui implémentent, pour les besoins de la pièce qu’ils représentent, les méthodes abstraites à leur manière (qui sont donc publiques ici);
- L’interface Collision définit l’utilisation de la fonction booléenne collision qui permet de trouver une collision dans le déplacement d’une tour ou d’une reine;
- La classe Plateau est un singleton : elle définit l’échiquier du jeu d’échecs, et n’est instanciée qu’une fois. Ainsi, n’importe quelle classe la modifiant, la modifiera pour tous ses autres usages.
Vues
Les vues se trouvaient dans les resources, dans le package view. Nous avons utilisé du FXML pour la fenêtre principale, ainsi que du CSS pour davantage styliser la fenêtre.
Contrôleurs
Main, PlateauChess, PlateauChessController et PieceManager sont des contrôleurs. Ce sont toutes des classes publiques. La classe Main ne contient qu’un appel à PlateauChess. PlateauChess initialise les paramètres de démarrage de l’application JavaFX. PlateauChessController est le contrôleur lié au FXML situé dans le dossier des vues, et contient des méthodes pour initialiser l’affichage. PlateauChessController possède des propriétés qui ne sont pas affichées sur le diagramme :
- une instance de PieceManager,
- un entier TILE_SIZE (75 pixels) qui correspond à la taille d’une case,
- un entier BOARD_SIZE qui correspond à la taille de l’échiquier (8, car c’est un 8x8).
PieceManager génère, à partir de l’échiquier de la classe Plateau, une matrice de pièces, chacune des objets de classes filles de Piece. Sa propriété typesPieces enregistre dans une matrice de paires de String le type de pièce en première position, et la couleur en second.
Commentaires et Javadoc
Le code était abondamment commenté, avec des commentaires Javadoc pour les classes, les méthodes et les propriétés. Les tags Javadoc sont très fréquents, comme le montrent les exemples ci dessous:
Javadoc
Grâce à l'utilisation de Javadoc, nous avons pu générer une documentation HTML de notre code.
Versionnage et branches avec Git
Nous avons utilisé Git pour versionner notre code. Nous avons utilisé des branches pour travailler sur des fonctionnalités spécifiques, et nous avons fusionné ces branches avec la branche principale, main, lorsque les fonctionnalités étaient avancées et fonctionnelles. Pour ce projet, nous avons utilisé GitHub pour stocker notre code. Dans ce projet, j'ai réalisé 56 commits qui ont "terminé" dans le main.
Tests unitaires avec JUnit
De nombreux tests unitaires ont été réalisés pour ce projet par mes soins. Ceux-ci ont été réalisés avec JUnit, un framework de tests unitaires pour le langage de programmation Java. Ils étaient commentés, et ont permis de vérifier le bon fonctionnement de certaines méthodes de nos classes. Ceux-ci étaient, selon la convention utilisée par Maven, dans un dossier spécifique "test", puis dans des packages correspondants aux packages testés, c'est-à-dire model et controller. Par exemple, la classe de test ci-dessous teste la classe Reine et s'appelle donc ReineTest.
Galerie


Visuel final










