Conception détaillée

Chaque partie sera instanciée sur son propre thread ce qui évitera les problèmes de concurrence lors des parties.

Cependant, lors de la création et choix de lobby, de nombreux joueurs peuvent essayer de se connecter à la même partie au même moment.
Pour éviter les problèmes de concurrence possible à ce moment là, nous utiliserons des méthodes starvation-free

Cela permet d’éviter un blocage par mauvaise connexion et des comportements non souhaités dans les lobby.

Pour obtenir les meilleures performances possibles, nous implémenter des algorithmes performants utilisant des structures de données adaptées.

Les parties en elles même étant peu demandantes en termes de requêtes, dû au nombre limité d’actions possibles et de joueurs par partie, nous utiliserons l’outil wait/notify pour éviter une surutilisation des threads.

Cependant, il faut également mettre en place, en amont, un système filtrant les requêtes souhaitées pour ne pas réveiller un thread sans que ce soit nécessaire.

La mise en place d’Interfaces entre les composantes du logiciel permet de ne pas se soucier de leur implémentation. Ainsi, il est possible de changer rapidement de support pour le jeu en adaptant une composante du logiciel au support souhaité.

De même, les standardiser les formats de données par l’intermédiaire de classes abstraites et interfaces permet de garantir une plus grande compatibilité entre les composants.

L’aspect modulaire du projet, de par ses structures de données abstraites, permet de facilement adapter les implémentations à d’autres supports.

Cependant, pour éviter des transition difficiles entre les langages, nous utiliserons le moins possible les bibliothèques spécifiques à un langage.

Par souci de maintenabilité, nous avons défini une structure modulaire se basant sur une définition abstraite des composants.

Notre code suivra également des règles communes de nomenclature et syntaxe tout en étant commenté et documenté.

Enfin à chaque procédure sera associé une suite de texte permettant de vérifier son bon fonctionnement au fil des différentes versions du projet.

l’interface utilisateur doit être stable, efficace et cross plateforme. Nous avons donc choisi d’en faire une interface web. Cela permet l’utilisation de protocoles sécurisés et une stabilité de fonctionnement sur les divers supports des utilisateurs.

L’interaction avec le logiciel doit être simple, rapide et sécurisée. Notre interface logiciel utilise des données claires, structurées et documentées et fournit des méthodes pour les manipulées.

Nous avons choisi d’utiliser le websocket car il permet une sécurité accrue et des communications en temps réel.

Les composants logiciels peuvent interagir avec la base de données le feront par le biais de la JPA fourni par java.

Le projet est couplé à une suite de tests unitaires permettant de s’assurer du bon fonctionnement des différentes fonctions, méthodes et procédures.

Au vu des contraintes évoqués en amont, le projet sera implémenté selon le patron de conception facade. Chaque composant doit mettre à disposition une interface répondant aux critères communs. Les interactions entre les composants passent toutes par ces interfaces.

Le logiciel suit une architecture "layer" ou chaque composant ne connait et peut communiquer qu’avec ceux directement adjacent. Le fonctionnement profond de l’application est donc indépendant des couches supérieures et réciproquement.