Spécification des composants

Découpage de la solution en composants (ou sous-systèmes) et spécification des interfaces fournies et requises par ces composants

Utilisez des diagrammes d’interaction (séquence, communication) pour décrire l’échange de messages entre les composants pour en déduire leurs interfaces.

Vue globale côté serveur

Notre solution se divise en 8 composants. Chaque composant gère une partie indépendante du système.

Auth : gestion de l’authentification et la création d’un compte pour un utilisateur.
Member : utilisateur enregistré sur le logiciel.
Friend : gestion des amis. Permet aux joueurs de faire des demandes d’ami, d’inviter d’autres joueurs dans leurs parties.
Player : gestion des joueurs, c’est-à-dire des membres dans un lobby et dans une partie.
Lobby : gestion de la création d’une partie et des parties en attente de pouvoir commencer.
Game : gestion d’une partie en elle-même, avec le déroulement des tours, les conditions de victoire, la distribution des cartes, le gain en ressources, en or, en points de victoires, en jeton Conflit.
Card : gestion des cartes, du deck d’une partie.
Wonder : gestion des merveilles, de leurs faces.

Figure 1. Diagramme de composants

Lobby

Le composant Lobby gère les zones d’attente pour le démarrage d’une partie, les lobbies.

Connexion d’un joueur à un lobby

Figure 2. Diagramme de séquence de la connexion d’un joueur à un lobby

Côté serveur

Figure 3. Diagramme de classe des interfaces du composant Lobby côté serveur

Côté serveur, les requêtes HTTP sont gérées par LobbyController.

L’ensemble des lobbies sont gérés par LobbyService, qui assure la persistance des données via LobbyRepository. Ce dernier réalise les requêtes avec la base de données.

Lobby représente un lobby créé par LobbyFactory, ce dernier étant appelé par LobbyService.

La communication WebSocket se fait par l’intermédiaire de LobbyGateway.

Côté client

Figure 4. Diagramme des pages côté client

Du côté de la webapp, le composant lobby regroupe 3 pages qui gèrent la partie lobby.

La page Lobbies a la responsabilité d’afficher la liste des lobbies avec les informations essentielles : places restantes, nombre de joueurs requis, nom de la partie, présence ou non d’un mot de passe.

Depuis Lobbies, on accède à LobbyCreation pour créer et configurer une nouvelle partie.

Lorsqu’un joueur est connecté à un lobby, la page Lobby affiche qui sont les autres joueurs, permet aux joueurs de choisir leur merveille si cette option a été activée lors de la configuration de la partie. Le joueur peut se mettre prêt. La partie se lance lorsque tous les joueurs sont prêts.

Partie

Le composant Game gère les parties en cours.

Déroulement d’une partie

Figure 5. Diagramme de séquence du déroulement d’une partie

Côté serveur

Figure 6. Diagramme de classe des interfaces du composant Game côté serveur

GameGateway gère les événements WebSockets. GameManager gère toutes les parties en cours. GameFactory crée les nouvelles parties. Les parties sont représentées par Game.

Côté client

Une seule interface est responsable de l’affichage de la partie en cours du côté de l’application web, il s’agit de Game.

Cette page doit afficher en temps réel l’état des merveilles de tous les joueurs et leur permettre de jouer. Des animations identifiables indiquent les actions que prennent les joueurs.

Pour éviter la triche, l’application web n’évaluera pas elle-même la faisabilité d’une action au cours de la partie. Ce sera la responsabilité du serveur.

Membre

Le composant Membre représente un utilisateur enregistré.

Côté serveur

Côté client

L’application web affiche les informations de l’utilisateur connecté dans le header des interfaces. Elle offre une interface pour se créer un compte et s’authentifier.

Joueur

Le composant Joueur gère les joueurs dans un lobby puis dans une partie.

Côté serveur

Deux types de joueurs sont différenciés : le joueur dans un lobby et celui dans une partie.

Côté client

Durant le déroulement d’une partie, l’application web affiche les informations d’un joueur en temps réel. Dans un lobby, seul le statut d’un joueur (prêt ou non), son nom et la merveille choisie est affiché.

Authentification

Le composant Auth gère la création d’un compte et l’authentification des utilisateurs.

Connexion au serveur

Côté serveur

Côté client

Carte

Le composant Card gère la récupération des cartes dans la base de données et la composition des decks pour la distribution aux joueurs.

Côté serveur

Figure 7. Diagramme de classe des interfaces du composant Card côté serveur

Les cartes seront directement inclues dans la base de données. Ce composant a pour responsabilité de récupérer les cartes dans la base de données, de les mapper en objets Card et de créer des decks de cartes à distribuer aux joueurs.

Côté client

L’application web est responsable de l’affichage des informations des cartes. Un composant web dédié effectuera cette tâche.

Merveille

Le composant Wonder gère la récupération des merveilles dans la base de données et la distribution des paquets de cartes pour chaque âge.

Côté serveur

Figure 8. Diagramme de classe des interfaces du composant Wonder côté serveur

Les merveilles seront directement inclues dans la base de données.

Côté client

L’application web est responsable de l’affichage des informations de la merveille. Un composant web dédié effectuera cette tâche.

Amis

Ce composant gère le système d’amitié : la possiblité pour un utilisateur de demandé en ami un autre joueur, d’accepter des invations, d’envoyer des invitations à rejoindre une partie.

Ce composant n’est pas indispensable pour le fonctionnement du jeu. Sa spécification est remise à une version ultérieure du logiciel.