Conception détaillée

1. Travail à réaliser

Objectif

Spécification détaillée des composants: leur structure (diagramme de classes de conception), ainsi que le comportement de chaque opération fournie par le composants. Le comportement peut-être décrit en utilisant les diagrammes d’activité, d’interaction, les machines d’état, ainsi que OCL.

Moyens

Appliquez les concepts vus en cours: design patterns, principes GRASP, bonnes pratiques, etc.

Conception detaillé de la partie Serveur

Classes de base : La classe Player représente chaque joueur. Elle conserve des informations comme l’ID, le nom, le prénom, l’email et le mot de passe. On peut sauvegarder ces informations avec la méthode save et les mettre à jour avec update.
La classe DataCase: sert à décrire une case dans le jeu. Elle contient des infos sur le joueur associé et le numéro de la case. Si on veut accéder à ces infos, on utilise les méthodes getPlayer et getCase.
Gestion de la Partie : La classe Partie gère une session spécifique du jeu. Elle a un ID unique, une liste de joueurs, et une liste de cases. Avec des méthodes comme partie, save, update, getCase, et getListePlayer, elle offre des moyens pour manipuler les données de la partie.
Contrôleur de Partie : Le controlleurPartie fonctionne comme un gestionnaire général. Il gère les parties disponibles, la liste d’attente des joueurs, et il peut démarrer un jeu. Des méthodes comme joinPartie, createPartie, getListePartie, et StartGame sont là pour gérer ces opérations.
Gestion du Jeu : La classe Game est une instance de jeu spécifique avec une partie associée et une liste de joueurs. Elle implémente l’interface Gestion_Game pour des actions spécifiques au jeu. Elle utilise aussi une classe Exception pour gérer des situations exceptionnelles liées au nombre de joueurs et à la recherche de joueurs.
Interface de Gestion du Jeu: L’interface Gestion_Game définit comment le jeu peut être géré. Elle a des méthodes pour lancer le dé, notifier un joueur, et envoyer une question. Éléments du Jeu :
La classe Question : représente une question avec un thème. Elle a des méthodes pour obtenir la question et vérifier sa validité.
La classe Gestion_de : s’occupe du dé du jeu. Elle a des méthodes pour obtenir un chiffre aléatoire entre 1 et 6.
Relations entre les Classes : Il y a des relations d’agrégation et d’association entre les classes. Par exemple, le controlleurPartie peut contenir plusieurs instances de Partie et Player. La classe Game utilise l’interface Gestion_Game et est associée à controlleurPartie. En résumé, ces classes et relations travaillent ensemble pour gérer les joueurs, les parties, et les différentes actions du jeu, fournissant une structure solide pour le côté serveur.

Conception detaillé de la partie client

Classes de base :
Identification: Classe abstraite servant de base pour les classes Login et SignIn. Elle contient des attributs communs pour l’identification des utilisateurs, tels que name et passWord.
Pions : Une autre classe abstraite qui sert de base pour Triangle et Camembert. Elle définit des attributs de base pour les pions, comme la couleur et le name.
PlateauInterface : Interface décrivant les méthodes et attributs essentiels d’un plateau de jeu. Les classes Plateau et Game se réfèrent à cette interface, indiquant qu’elles implémentent ou utilisent ses spécifications.
Case : Interface qui sert de base pour Depart, CaseN, et QG. Elle définit des attributs généraux pour différents types de cases sur un plateau de jeu, tels que la couleur et le name.
Gestion du Jeu : Dans le diagramme UML proposé, la classe Game apparaît comme la pièce maîtresse du système. Voici les raisons principales qui soutiennent cette affirmation: La classe Game est au cœur de la gestion de la logique du jeu. Elle est responsable de fonctions essentielles telles que l’initialisation du plateau (initPlateau), la gestion des réponses (sendResponse), le déplacement des pions camembert (deplacerCamembert), le positionnement des triangles sur les pions (putTriangleInCamembert), ainsi que l’affichage des questions (afficherQuestion). Ces méthodes indiquent clairement que Game dirige les principales opérations et le flux du jeu. La classe Game est en interaction étroite avec de nombreuses autres classes, illustrant son rôle intégrateur et centralisateur. Elle est directement liée à des classes telles que Camembert et Triangle, et interagit également avec le Plateau via l’interface PlateauInterface. Cette configuration souligne la position de Game comme un nœud de coordination entre divers composants du jeu.
Relations entre les Classes :
- Héritage : Login et SignIn héritent des propriétés de Identification, partageant ainsi des attributs communs tout en ayant leurs caractéristiques uniques.
- Agrégation : Game intègre les objets Camembert (6 instances) et Triangle (36 instances) en tant que composantes, mais ces objets peuvent exister indépendamment de Game. Plateau est composé d’une Depart, de 65 CaseN et de 6 QG, chacun pouvant exister séparément du Plateau.
- Implémentation d’Interface : Plateau implémente PlateauInterface, se conformant ainsi à ses spécifications. Game utilise également PlateauInterface, indiquant une interaction avec des objets conformes à cette interface.
- Association : QG est associé à Triangle et Category, indiquant une relation directe entre ces éléments. CaseN est lié à Category, suggérant une relation entre les types de cases et les catégories de questions.

2. Réponses aux exigences non-fonctionnelles

2.1. Interopérabilité

Les interfaces, comme PlateauInterface, peuvent faciliter l’interopérabilité. En définissant des contrats clairs, elles permettent à différentes implémentations de communiquer entre elles, pourvu qu’elles respectent ces contrats. Une architecture modulaire, comme celle suggérée par les différentes classes (Game, Triangle, Camembert, etc.), permet une plus grande flexibilité pour intégrer ou interagir avec d’autres systèmes. Chaque module peut être conçu pour interagir avec des composants externes tout en maintenant son indépendance. L’utilisation de formats de données standardisés (comme JSON, XML) et de protocoles de communication courants (HTTP, WebSockets) facilite l’échange d’informations avec d’autres applications.

2.2. Portabilité

Des éléments comme Identification et PlateauInterface fournissent une couche d’abstraction qui peut faciliter l’adaptation du système à différents environnements en modifiant simplement les implémentations spécifiques à la plateforme. La structure modulaire, comme illustrée dans le diagramme, aide à isoler les modifications nécessaires lors du transfert vers une nouvelle plateforme. Des modules clairement définis peuvent être adaptés ou remplacés indépendamment.

2.3. Sécurité

2.3.1. Exigence de sécurité

Notre système doit être sécurisé, même si nous ne manipulons pas des données sensibles. Pour cela nous devons vérifier l’identité de l’utilisateur.

Etant données que dans notre modelisation la gestion principal du jeu se fait dans la partie seveur, cela nous permet d’assurer la securité du système en limitant les actions au niveau client

2.3.2. Maintenabilité

Modularité : La structure en classes distinctes, chacune avec des responsabilités clairement définies (comme Game, Triangle, Camembert), facilite les modifications et les mises à jour dans une partie spécifique du système sans affecter les autres.
Réutilisation du Code : L’héritage (comme vu avec Login et SignIn héritant de Identification) permet la réutilisation du code, ce qui réduit la duplication et facilite la maintenance.
Principes SOLID : La conception preserve plusieurs principes SOLID (comme le Single Responsibility Principle et l’Open/Closed Principle), qui sont essentiels pour une bonne maintenabilité.
Cohérence et Clarté : Le diagramme montre une structure claire et cohérente, ce qui est crucial pour comprendre rapidement le système et effectuer des modifications. Dépendances Gérables : L’utilisation des interfaces (telles que PlateauInterface) peut aider à gérer les dépendances entre les classes, facilitant ainsi les modifications et les tests.

3. Patrons logiciels utilisés

3.1. Patron architectural "CLient"

Design patternsAbstract Factory
Factory
Design patterns Strategy
Builder
Composite
Decorator

4. Choix techniques - Distribution des processus

Explicitez les différents choix techniques et les réponses technologiques aux différentes contraintes que le système implique.

Pour cela nous allons donc vous présenter l’environnement général de développement puis énoncer les 4 contraintes que nous avons déterminées de notre logiciel.

Nous avons fais le choix d’utiliser comme environnement de travail l’IDE eclipse. Pour la raison que nous connaissons tous très bien cette environnement, ce qui nous permet d’avoir tous le même environnement de développement.

Également, cette IDE permet la gestion d’un projet maven ce qui nous sera parfaitement adapté.

Voici les 4 contraintes que nous avons déterminées :

L’interface graphique.
La communication vers la base de données.
La communication entre les machines.
La sécurité.