Conception détaillée
1. 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.
2. Composants et leurs structures internes:
2.1. Composant 1 : PlayerServer
2.1.1. Classes et Methodes :
Classe GestionnaireDeConnexion:
implémente une partie des opérations définies dans GameDesk
Ses méthodes:
-
connect: Gère l’authentification et l’établissement de la connexion des joueurs. -
fermerConnexion`: Permet de déconnecter un joueur du système. Cette classe est responsable de la gestion de tous les aspects liés à la connexion des joueurs, garantissant que les connexions sont établies, maintenues et terminées de manière sécurisée et efficace.
Classe GestionnaireDePartie: Essentielle pour orchestrer les différentes parties du jeu, de la création au suivi de leur progression. Elle gère également certaines opérations de GameDesk liées à la gestion des parties :
Ses méthodes:
-
joinGame, joinSpecialGame: Gère l’inscription des joueurs aux parties normales ou spéciales. -
getGameStatus: Renvoie le statut d’une partie en cours. -
startRound: Initie un nouveau tour dans une partie. -
createGame: Crée une nouvelle partie avec un nombre défini de joueurs.
2.1.3. Comportement des opérations fournies:
-
createGame:
Explication du Diagramme :
La méthode commence par recevoir le paramètre numberOfPlayers. Il verifie pour déterminer si le nombre de joueurs est valide . Si le nombre de joueurs est valide, il passe à la création d’un nouveau jeu sinon la méthode retourne une erreur ou un identifiant de jeu vide.
Le jeu est initialisé avec le nombre spécifié de joueurs . Un identifiant unique pour le jeu est généré et retourné comme résultat de la méthode.
-
connect:
Explication de la machine d’état :
-
Etat Déconnecté : L’état initial du joueur.
-
Transition de Déconnecté à En Attente d’Authentification : lorsqu’un joueur tente de se connecter en utilisant la méthode connect.
-
En Attente d’Authentification: Quand les informations de connexion du joueur sont vérifiées.
-
Transition de En Attente d’Authentification à Connecté : si les informations de connexion sont validées.
-
Connecté : le joueur est connecté.
-
Transition de Connecté à Déconnecté : lorsque le joueur se déconnecte.
-
JoinGame:
-
Explication du diagramme d’activité :
Au début , une réception des identifiants gameID et userID est faite . Ensuite une vérification de l’existence du jeu spécifié par gameID.
Si le jeu existe, vérification de l’existence de l’utilisateur spécifié par userID. Si l’utilisateur existe, vérification pour s’assurer que l’utilisateur n’est pas déjà dans le jeu. Si l’utilisateur n’est pas déjà dans le jeu, il est ajouté, et la fonction retourne true.
Dans tous les autres cas, la fonction retourne false.
-
getGameStatus:
Explication du diagramme d’intéraction :
1- Un utilisateur ou un autre composant du système demande le statut d’un jeu en appelant getGameStatus(gameID) sur le GestionnaireDePartie.
2- Le GestionnaireDePartie reçoit la demande et interroge ensuite le Jeu spécifique à l’aide de la méthode getStatus(gameID).
3- Le Jeu répond au GestionnaireDePartie avec le statut du jeu.
4-Le GestionnaireDePartie transmet ensuite ce statut à l’utilisateur.
-
joinSpecialGame:
Explication de la machine d’état :
-
AttenteDeJoueurs : L’état initial du jeu.
-
Transition de AttenteDeJoueurs à EnCours : lorsqu’un joueur rejoint le jeu et qu’il y a de la place disponible.
-
EnCours : la partie en cours
-
Transition de EnCours à Complet : lorsque le dernier joueur nécessaire rejoint, et toutes les places sont prises.
-
Complet : toutes les places sont prises.
-
Transition de EnCours à AttenteDeJoueurs: si un joueur quitte le jeu, ouvrant des places.
-
Transition de AttenteDeJoueurs à l’état final : si le jeu est annulé
-
startRound:
-
Explication du diagramme d’intéraction :
1- Un joueur ou un autre composant du système demande à démarrer un nouveau tour en appelant startRound(userID) sur le GestionnaireDePartie.
2- Le GestionnaireDePartie reçoit la demande et demande ensuite au Jeu de lancer un nouveau tour.
3- Le Jeu répond que le nouveau tour est initialisé.
4- Le GestionnaireDePartie envoie ensuite une notification de début de tour à chaque joueur participant.
5-Chaque joueur envoie un accusé de réception de la notification.
6-Finalement, le GestionnaireDePartie retourne le statut du nouveau tour au joueur qui a initié la demande.
2.2. Composant 2 : InitializerGameServer
2.2.1. Classes et Méthodes
-
Classe
InitialiseurDeJeu: Implémente des opérations deGameManagement. -
Méthodes:
-
registerPlayer: Enregistre un nouveau joueur. -
createBoard: Crée le plateau de jeu. -
startGame: Démarre une nouvelle partie. -
endGame: Termine la partie en cours.
-
-
Classe
GestionnaireDePartie: Implémente des opérations deGameDesk. -
Méthodes:
-
joinGame: Gère l’inscription des joueurs aux parties. -
getGameStatus: Fournit le statut actuel d’une partie.
-
2.2.3. Comportement des opérations fournies:
-
createGame:
Explication du Diagramme :
-
Recevoir les données du joueur : on commence par la réception des données d’inscription du joueur:le nom d’utilisateur et le mot de passe.
-
Vérification des Données Valides : on vérifie si les données fournies sont valides: la longueur et le format du nom d’utilisateur et du mot de passe. Si les données ne sont pas valides, le joueur est informé que l’inscription a échoué et le processus se termine.
-
Contrôle de l’Unicité du Nom d’Utilisateur : Si les données sont valides, le système vérifie ensuite si le nom d’utilisateur est déjà utilisé dans le système.
-
Création du Compte : Si le nom d’utilisateur est disponible, le compte du joueur est crée. Cette étape implique l’enregistrement des données du joueur dans la base de données ou le système de gestion des utilisateurs.
-
Envoi de la Confirmation : Après la création réussie du compte, une confirmation est envoyée au joueur. la confirmation peut etre sous forme d’un message de succès ou même d’un email de vérification.
-
Notification de Nom d’Utilisateur Pris :Si le nom d’utilisateur est déjà pris, le système informe le joueur que le nom d’utilisateur choisi n’est pas disponible. Le joueur peut alors essayer avec un autre nom d’utilisateur.
-
Fin du Processus :A ce stade , le processus d’inscription est soit complet, soit le joueur doit réessayer avec des données différentes
-
createBoard:
-
Explication du Diagramme :
-
Début du Processus : Initialisation d’une nouvelle partie.
-
Initialisation du Plateau : préparation du plateau de jeu: définition de la taille du plateau, l’initialisation des cases, la mise en place des éléments spécifiques au jeu.
-
Placement des Éléments de Jeu : Le plateau est rempli avec les éléments nécessaires : pions, jetons, ou d’autres objets de jeu.
-
Vérification de l’Intégrité du Plateau : Une vérification est effectuée pour s’assurer que le plateau est correctement configuré et prêt pour le jeu : les positions de départ, la disponibilité des éléments nécessaires, etc.
-
Confirmation de Création : Une fois le plateau correctement configuré, une confirmation est générée, indiquant que le plateau est prêt à être utilisé.
-
StartGame:
-
Explication du Diagramme :
-
début : startGame() est invoquée, généralement par un joueur ou automatiquement lorsque toutes les conditions de démarrage sont remplies.
-
Vérification des Conditions de Jeu : Le système vérifie si toutes les conditions nécessaires pour démarrer le jeu sont réunies : nombre de joueurs, configuration du jeu, etc.
-
Initialisation des Éléments de Jeu : Si les conditions sont remplies, le jeu initialise tous ses éléments nécessaires: la réinitialisation des scores, la mise en place des joueurs sur le plateau, etc.
-
Notification des joueurs : Les joueurs sont notifiés que le jeu commence.
-
Début du Jeu : Le jeu démarre marquant le début de la partie.
-
StartGame:
-
Explication du Diagramme :
-
Début : endGame() est invoquée pour terminer la partie en cours.
-
Finalisation de la Partie : Le jeu effectue les actions nécessaires pour finaliser la partie: calcule et enregistre les scores finaux.
-
Notification des Joueurs : Les joueurs sont notifiés de la fin de la partie et des résultats finaux.
-
Nettoyage et Réinitialisation : Le jeu effectue les opérations de nettoyage nécessaires : réinitialisation de l’état du jeu / la libération des ressources.
-
Préparation pour une Nouvelle Partie ou Fermeture : Le système se prépare soit pour démarrer une nouvelle partie, soit pour se fermer si c’est la fin de la session de jeu.
-
JoinGame:
-
Explication du Diagramme :
-
Joueur Demande à Rejoindre : Un joueur ,ou client envoie une demande pour rejoindre une partie spécifique, identifiée par gameID.
-
Vérification par le Gestionnaire de Partie : GestionnaireDePartieInit reçoit la demande et vérifie l’existence et le statut de la partie spécifiée.
-
Vérification de l’État du Joueur : Le système vérifie également si le joueur est éligible pour rejoindre la partie , par exemple s’il pas déjà dans une autre partie.
-
Ajout du Joueur à la Partie : Si les vérifications sont réussies, le joueur est ajouté à la partie
-
Confirmation au Joueur : Le joueur reçoit une confirmation de son ajout à la partie.
-
GetGameStatus:
-
Explication du Diagramme :
-
Réception de la Demande : getGameStatus(gameID) est invoquée, typiquement par un joueur ou un composant du système, avec l’identifiant gameID de la partie concernée.
-
Vérification de l’Existence de la Partie : Le système vérifie si la partie avec l’identifiant gameID existe.
-
Récupération du Statut de la Partie : Si la partie existe, le système récupère le statut actuel de cette partie.
-
Retour du Statut : Le statut de la partie est retourné à l’entité qui a appelé la méthode.
-
Gestion des Erreurs : Si la partie n’existe pas, une erreur ou un message indiquant que la partie n’a pas été trouvée est généré.
2.3. Composant 3 : BoardServer
2.3.1. Classes et Méthodes
-
Classe
GestionnaireDePlateau: Gère l’ensemble des opérations relatives au plateau. -
Méthodes:
-
createGameBoard(numberOfPlayers: int): Crée le plateau de jeu -
initializePlayerPawn(playerIDs: String[]): Initialise les pions des joueurs. -
movePlayer(playerID: String, steps: int): Déplace un joueur sur le plateau. -
createCamembert(): Crée les éléments camembert. -
resetBoard(): Réinitialise le plateau de jeu. -
displayGameBoard(gameID: String): Affiche le plateau de jeu.
-
-
Classe
GestionnaireDeCartes: Gère les cartes de questions et de réponses. -
Méthodes:
-
createCard(category: String): Crée une carte de jeu. -
generateQuestions(): Génère les questions du jeu. -
generateAnswers(): Génère les réponses du jeu
-
2.3.3. Comportement des opérations fournies:
-
createCard:
Explication du Diagramme :
-
Réception des Paramètres : createCard(category: String) est invoquée avec le paramètre category, qui spécifie la catégorie de la carte à créer.
-
Création de la Carte : En fonction de la catégorie, une nouvelle carte est créée .
-
Vérification et Validation : Le système effectue une vérification pour s’assurer que la carte est correctement formatée et répond aux critères du jeu.
-
Enregistrement de la Carte : Une fois validée, la carte est enregistrée dans le système, prête à être utilisée dans le jeu.
-
Retour de la Carte : La méthode retourne l’objet Card créé.
-
generateQuestions:
-
Explication du Diagramme :
-
Début : generateQuestions() est activée pour la création de nouvelles questions.
-
Sélection ou Création des Questions : Selon la logique du jeu, le système sélectionne des questions à partir d’une base de données et les crée en fonction de règles définies.
-
Vérification des Questions : Chaque question générée est vérifiée pour s’assurer qu’elle est conforme aux normes du jeu : diffucltés , clarté..
-
Enregistrement des Questions : Les questions vérifiées sont ensuite enregistrées dans le système, prêtes à être utilisées dans le jeu.
-
Confirmation : Une fois toutes les questions générées et enregistrées, la réussite du processus est confirmée .
-
generateAnswers:
-
Explication du Diagramme :
-
Début : generateAnswers() est activée pour la création de nouvelles réponses.
-
Création des Réponses :génération des réponses adaptées aux questions existantes.
-
Vérification des Réponses : Chaque réponse est vérifiée pour s’assurer qu’elle est correcte, pertinente et conforme aux standards du jeu.
-
Enregistrement des Réponses : Les réponses vérifiées sont ensuite enregistrées dans le système, prêtes à être associées aux questions correspondantes dans le jeu.
-
Confirmation de la Génération : Une fois toutes les réponses générées et enregistrées, la méthode confirme la réussite du processus.
-
createGameBoard:
-
Explication du Diagramme :
le processus commence par la réception du nombre de joueurs. Il vérifie si ce nombre est valide. Si oui, le plateau est initialisé et les pièces ou jetons nécessaires sont placés. Ensuite, une vérification finale est effectuée pour s’assurer que le plateau est correctement configuré. Si cette vérification est réussie, une confirmation indiquant que le plateau est prêt est retournée. En cas d’échec de cette vérification ou si le nombre de joueurs n’est pas valide, une erreur est retournée.
-
initializePlayerPawn:
Explication du Diagramme :
-
Réception des Identifiants des Joueurs : on commence par la réception d’une liste d’identifiants de joueurs.
-
Initialisation d’un Index de Joueur : Avant de commencer à placer les pions, un index est initialisé pour suivre la position actuelle dans la liste des identifiants de joueurs.
-
Placement des Pions sur le Plateau : on entre dans une boucle où pour chaque joueur , son pion est placé sur la position de départ appropriée sur le plateau.
-
Incémentation de l’Index : Après le placement du pion d’un joueur, l’index est incrémenté pour passer au joueur suivant dans la liste.
-
Vérification :on verifie que les pions de tous les joueurs sont placés sur le plateau.
-
Vérification du Placement Correct : on vérifie si le placement est correct et complet.
-
Retour du Résultat : Si tous les pions sont correctement placés, la méthode retourne une confirmation de réussite. Si un problème est survenu lors du placement , par exemple un identifiant invalide la méthode retourne une erreur.
-
movePlayer:
-
Explication du Diagramme :
-
Joueur Demande à Se Déplacer : Un joueur envoie une demande pour se déplacer sur le plateau.
-
Réception de la Demande par le Gestionnaire de Plateau : GestionnaireDePlateau reçoit la demande de déplacement.
-
Vérification de la Position Actuelle du Joueur: Le gestionnaire de plateau vérifie la position actuelle du joueur sur le plateau.
-
Calcul du Nouveau Placement : Basé sur le nombre de pas, le gestionnaire calcule la nouvelle position du joueur.
-
Déplacement du Pion : Le pion du joueur est déplacé vers la nouvelle position sur le plateau.
-
Vérification et Confirmation : Après le déplacement, une vérification est effectuée pour s’assurer que le déplacement est valide selon les règles du jeu. Si valide, une confirmation est envoyée au joueur.
-
Gestion des Règles de Jeu : Si le déplacement implique des règles supplémentaires comme obtenir une carte question, ces actions sont traitées.
-
createCamembert:
-
Explication du Diagramme :
-
début : l’initiation de la création des camemberts.
-
Boucle sur les Catégories : Le système entre dans une boucle où il crée un camembert pour chaque catégorie de questions dans le jeu.
-
Pour chaque catégorie, un camembert est créé.
-
Une couleur unique est attribuée à chaque camembert, correspondant à sa catégorie.
-
-
Passage à la Catégorie Suivante : Après le traitement d’une catégorie, on passe à la catégorie suivante jusqu’à ce que toutes les catégories soient traitées.
-
Vérification des Camemberts : Une fois tous les camemberts créés, le système vérifie si chaque pièce est correctement associée à sa catégorie et à sa couleur.
-
Résultat du Processus : Si la vérification est réussie et que tous les camemberts sont corrects, ils sont enregistrés dans le système. Le processus retourne une collection des camemberts créés. En cas d’erreur, comme une mauvaise association de couleur ou de catégorie, un signal d’erreur est généré.
-
resetBoard:
-
Explication du Diagramme :
-
Début : on commence par l’activation de la méthode resetBoard() pour réinitialiser le plateau.
-
Nettoyage du Plateau : Toutes les pièces et jetons du jeu précédent sont retirés, laissant le plateau vide et prêt pour une nouvelle configuration.
-
Réinitialisation des États : Les variables du jeu ou tout état spécifique sont remis à leurs valeurs initiales, effaçant ainsi toute trace du jeu précédent.
-
Vérification : Le système vérifie si le plateau est correctement réinitialisé et prêt pour une nouvelle partie.
-
Fin : Si la réinitialisation est réussie, une confirmation indiquant que le plateau est prêt pour un nouveau jeu est retournée. Si la réinitialisation échoue, un message d’erreur est généré.
-
displayGameBoard:
-
Explication du Diagramme :
-
Récupération de l’État du Plateau : L’état actuel du plateau est récupéré en utilisant le gameID fourni.
-
Vérification de la Validité : Le système vérifie si l’état du plateau est récupérable et valide.
-
Formatage pour l’Affichage : Si l’état est valide, il est formaté pour être affiché.
-
Fin: Si le formatage est réussi, le plateau formaté est retourné pour l’affichage. En cas d’échec du formatage ou de la récupération, un message d’erreur est retourné.
2.4. Composant 4: GameServer
2.4.1. Classes et Méthodes
-
Classe
GestionnaireDeJeu: Responsable de la gestion générale de la partie. -
Méthodes:
-
startGame(), endGame(), isGameFinished(), announceWinner(): Gèrent le démarrage, la fin du jeu, la vérification de la fin du jeu et l’annonce du vainqueur -
addQuestion(question: Question), addAnswer(answer: Answer): Gèrent les questions et les réponses..
-
-
Classe
ControlleurDeTour: Responsable de la gestion de chaque tour de jeu. -
Méthodes:
-
playRound(playerID: String), getQuestionForPlayer(playerID:String), answerQuestions(playerID: String, answers: String): Gèrent le déroulement d’un tour, la récupération des questions et la gestion des réponses. -
movePlayerOnBoard(playerID: String, diceResult: int): Gère le mouvement des joueurs sur le plateau.
-
2.4.3. Comportement des opérations fournies:
-
StartGame:
Explication du Diagramme :
-
Début du Processus : Démarrage du jeu.
-
Initialisation des Composants du Jeu : Les éléments essentiels du jeu comme le plateau, les joueurs et les pièces sont initialisés.
-
Configuration des États Initiaux : Les variables de jeu telles que les scores et les positions des joueurs sont configurées.
-
Notification aux Joueurs : Une étape est incluse pour notifier tous les joueurs que le jeu a commencé.
-
Vérification et Résultat : Une vérification est effectuée pour s’assurer que toutes les initialisations nécessaires ont été réussies . En fonction du résultat de cette vérification, une confirmation ou un message d’erreur est retourné.
-
EndGame:
-
Explication du Diagramme :
-
Utilisateur → Game: endGame() : L’interaction commence avec l’utilisateur appelant la méthode endGame() sur l’objet "Jeu".
-
* → Score: calculerScoreFinal()* : Le jeu demande alors à l’objet "Score" de calculer le score final.
-
Score -→ Game: scoreFinal : Le score final est retourné au jeu.
-
Game → UI: afficherScore(scoreFinal): Le jeu envoie ensuite le score final à l’interface utilisateur pour l’afficher.
-
Game → Game: terminerJeu() : Fin du jeu
-
AddQuestion:
-
Explication du Diagramme :
-
Réception de l’Objet Question : GameServer reçoit une nouvelle question destinée à être ajoutée au jeu.
-
Validation de la Question : Avant d’intégrer la question dans le jeu, le serveur procède à sa validation.
-
Stockage de la Question : Si la question passe la validation, elle est ensuite ajoutée au pool de questions du jeu. Ce pool représente l’ensemble des questions disponibles pour être posées aux joueurs durant les parties.
-
Mise à Jour de l’État du Jeu : Après l’ajout de la question, l’état du jeu est mis à jour pour inclure cette nouvelle information.
-
Fin / résultat : En cas de succès, le serveur retourne une confirmation, indiquant que la question a été correctement ajoutée au jeu. Si la validation échoue ,par exemple, si la question est mal formulée, le serveur retourne un message d’erreur.
-
AddAswer:
-
Explication du Diagramme
-
Réception de l’Objet Réponse : GameServer reçoit une réponse à une question spécifique du jeu , qui peut être liée à l’une des différentes catégories de questions .
-
Validation de la Réponse : Avant d’ajouter la réponse au jeu, le serveur effectue une validation pour s’assurer que le format de la réponse est correct et qu’elle correspond bien à la question associée.
-
Stockage de la Réponse : Si la réponse est validée, elle est ensuite stockée dans le pool de réponses du jeu. Ce pool est une collection des réponses disponibles utilisées dans le jeu pour évaluer les réponses des joueurs.
-
Mise à Jour de l’État du Jeu : Après l’ajout de la réponse, l’état du jeu est mis à jour pour refléter cette nouvelle information. Cela implique la mise à jour des données utilisées pour poser des questions aux joueurs lors des tours suivants.
-
Fin : Si l’ajout de la réponse est réussi, le serveur retourne une confirmation, indiquant que la réponse a été correctement ajoutée au jeu. Si la réponse n’est pas validée (par exemple, si elle ne correspond pas à la question ou si le format est incorrect), un message d’erreur est retourné.
-
isGameFinished:
-
Explication du Diagramme :
-
Début du Processus : l’objectif est de déterminer si la partie est terminée.
-
Évaluation des Conditions de Fin de Jeu : on peut verifier si toutes les questions ont été répondues ou si un joueur a atteint une condition de victoire spécifique au jeu .
-
Détermination de l’État de Fin de Jeu : le jeu détermine si les conditions pour considérer la partie comme terminée sont remplies.
-
Retour d’un Valeur Booléenne : La méthode retourne une valeur booléenne indiquant si la partie est terminée ou non.
-
annouceWinner:
-
Explication du Diagramme :
-
Détermination du Gagnant : l’objectif est de determiner le gagant .
-
Récupération des Scores des Joueurs : on interroge la base de données des joueurs pour obtenir les scores de tous les joueurs.
-
Calcul du Score le Plus Élevé : on calcule quel joueur a le score le plus élevé.
-
Retour de l’ID du Gagnant : L’ID du joueur avec le score le plus élevé est retourné au serveur.
-
Récupération des Détails du Gagnant : Le serveur demande à la base de données des joueurs les détails du gagnant.
-
Annonce du Gagnant : Le serveur annonce le gagnant .
-
playRound:
-
Explication du Diagramme :
-
Début du Tour : démarrage du tour d’un joueur spécifique.
-
Détermination de la Position : on determine la position actuelle du joueur sur le plateau de jeu est déterminée.
-
Poser une Question : Une question est posée au joueur, probablement basée sur la catégorie de sa position actuelle sur le plateau.
-
Évaluation de la Réponse :
-
Si la réponse du joueur est correcte, son score est mis à jour.
-
Si la réponse est incorrecte, des conséquences comme perdre des points sont appliquées.
-
-
Vérification de la Condition de Victoire : Le jeu vérifie si le joueur a atteint une condition de victoire comme remplir son camembert avec tous les triangles de couleur.
-
Fin du Tour ou Préparation de la Fin du Jeu : Si le joueur a atteint la condition de victoire, le processus pour terminer le jeu . Sinon, le jeu se prépare à passer au tour suivant.
-
getQuestionForPlayer:
-
Explication du Diagramme :
-
Réception de l’ID du Joueur : Le serveur de jeu reçoit l’identifiant du joueur.
-
Détermination de la Catégorie du Joueur : Le serveur détermine la position actuelle ou la catégorie du joueur en fonction de son playerID. cela pourrait identifier la catégorie de question associée à la position du joueur sur le plateau de jeu.
-
Sélection d’une Question Appropriée : Une question appropriée est sélectionnée depuis le pool de questions du jeu, basée sur la catégorie du joueur. Le jeu doit choisir une question qui n’a pas encore été posée à ce joueur et qui est pertinente pour sa catégorie actuelle.
-
Retour de la Question Sélectionnée : La question choisie est ensuite renvoyée au joueur. Cela signifie que le joueur reçoit la question à laquelle il doit répondre lors de son tour.
-
answerQuestions:
-
Explication du Diagramme :
-
Soumission de la Réponse : Le joueur soumet sa réponse à travers le ContrôleurDeTour.
-
Récupération de la Question : Le contrôleur demande la question correspondante depuis le pool de questions pour évaluer la réponse.
-
Évaluation de la Réponse : Le système d’évaluation détermine si la réponse est correcte ou incorrecte.
-
Mise à Jour du Score ou Pénalité : Si la réponse est correcte, le score du joueur est mis à jour. Sinon, une pénalité est appliquée au joueur par exemple rester sur place ou de perdre des points.
-
Retour au Joueur : Le joueur reçoit le résultat de son action : succès ou échec de la réponse.
-
movePlayerOnBoard:
-
Explication du Diagramme :
-
Réception des Informations : recevoir l’identifiant du joueur et le résultat du dé.
-
Calcul de la Nouvelle Position : La position actuelle du joueur est déterminée, et la nouvelle position est calculée en fonction du résultat du dé.
-
Déplacement du Joueur : Si la nouvelle position est valide, le joueur est déplacé à cette position sur le plateau.
-
Gestion des Cases Spéciales :
-
Si le joueur atterrit sur une case spéciale, l’effet de cette case est appliqué : avancer ou reculer de plusieurs cases
-
Si ce n’est pas une case spéciale, le jeu continue normalement.
-
-
Gestion du Dépassement : Si la nouvelle position dépasse les limites du plateau, une gestion spécifique est appliquée par exemple le joueur peut être amené à commencer un nouveau tour sur le plateau.
-
Vérification des Conditions de Victoire : Le jeu vérifie si ce déplacement a mené à une condition de victoire comme remplir son camembert de toutes les couleurs dans le jeu.
2.5. Composant 5: CardServer
2.5.1. Classes et Méthodes
-
Classe
GestionnnaireDeCarte: implémente cardInterface -
Méthodes:
-
getCard(cardID: String), getCardByCategory(category: String), getCardsByCategory(category: String, numberOfCards: int): Fournissent des cartes selon l’ID, la catégorie ou en nombre spécifié. -
getQuestionsByCategory(category: Theme), getUnaskedQuestions(), getCorrectAnswersByQuestionID(questionID: String): Gèrent les questions et les réponses par catégorie.
-
-
Classe
GestionnaireDeReponses: implémente l’interface CardInterface -
Méthodes:
-
checkAnswer(questionID: String, userAnswer: String), isCorrectAnswer(questionID: String, userAnswer: String): Vérifient si les réponses données par les joueurs sont correctes. -
markQuestionAsAsked(questionID: String): Marque une question comme ayant été posée.
-
2.5.3. Comportement des opérations fournies:
-
getCard:
Explication du Diagramme :
-
Demande de Carte : CardServer demande une carte spécifique à la classe GestionnaireDeCartes en utilisant l’identifiant de la carte .
-
Récupération de la Carte : Le GestionnaireDeCartes interroge la base de données des cartes pour trouver la carte demandée.
-
Retour de la Carte : Une fois la carte trouvée, les données de la carte sont renvoyées au GestionnaireDeCartes, qui à son tour les renvoie au serveur de cartes.
-
getQuestionsByCategory:
-
Explication du Diagramme :
-
Demande de Questions par Catégorie : CardServer demande des questions d’une catégorie spécifique à la classe GestionnaireDeCartes.
-
Récupération des Questions : Le GestionnaireDeCartes interroge la base de données des questions pour trouver toutes les questions correspondant à la catégorie demandée.
-
Retour de la Liste de Questions : Les questions trouvées sont renvoyées au GestionnaireDeCartes, qui les transmet ensuite au serveur de cartes.
-
getUnaskedQuestion:
-
Explication du Diagramme :
-
Demande de Questions Non Posées : CardServer fait une requête au GestionnaireDeCartes pour obtenir une liste de questions qui n’ont pas encore été posées.
-
Récupération des Questions Non Posées : Le GestionnaireDeCartes consulte la base de données des questions pour récupérer toutes les questions non posées disponibles.
-
Retour de la Liste de Questions : Les questions non posées sont renvoyées au GestionnaireDeCartes, qui les transmet ensuite au serveur de cartes.
-
getCardByCategory:
-
Explication du Diagramme :
-
Demande de Carte par Catégorie : CardServer demande au GestionnaireDeCartes de récupérer une carte basée sur une catégorie spécifique.
-
Récupération de la Carte : Le GestionnaireDeCartes interroge la base de données des cartes pour trouver une carte qui correspond à la catégorie demandée.
-
Retour de la Carte : La carte récupérée est ensuite renvoyée au serveur de cartes.
-
getCardsByCategory:
-
Explication du Diagramme :
-
Demande de Cartes par Catégorie : CardServer demande au GestionnaireDeCartes de récupérer plusieurs cartes d’une catégorie spécifique, en spécifiant également le nombre de cartes souhaité.
-
Récupération des Cartes : Le GestionnaireDeCartes interroge la base de données des cartes pour trouver un ensemble de cartes qui correspond à la catégorie et au nombre demandés.
-
Retour de la Liste de Cartes : Les cartes récupérées sont ensuite renvoyées au serveur de cartes.
-
CheckAnswer:
-
Explication du Diagramme :
-
Demande de Vérification de Réponse : CardServer envoie une requête au GestionnaireDeReponses pour vérifier l’exactitude de la réponse d’un joueur, en fournissant l’ID de la question et la réponse du joueur.
-
Récupération de la Réponse Correcte : Le GestionnaireDeReponses consulte la base de données des questions pour obtenir la réponse correcte correspondant à questionID.
-
Comparaison des Réponses : Si la réponse de l’utilisateur correspond à la réponse correcte récupérée, le gestionnaire renvoie true, indiquant que la réponse est correcte. Sinon, le gestionnaire renvoie false, indiquant que la réponse est incorrecte.
-
isCorrectAnswer:
-
Explication du Diagramme :
-
Demande de Vérification de Réponse : CardServer envoie une requête au GestionnaireDeReponses pour vérifier si la réponse d’un joueur à une question spécifique est correcte.
-
Récupération de la Réponse Correcte : Le gestionnaire demande à la base de données des questions la réponse correcte pour la question spécifiée.
-
Comparaison et Résultat: Si la réponse du joueur correspond à la réponse correcte, le gestionnaire renvoie true, indiquant que la réponse est correcte. Sinon, le gestionnaire renvoie false, indiquant que la réponse est incorrecte.
-
markQuestionAsAsked:
-
Explication du Diagramme :
-
Demande de Marquage de Question : CardServer envoie une requête au GestionnaireDeReponses pour marquer une question spécifique comme ayant été posée.
-
Marquage de la Question : Le gestionnaire demande à la base de données des questions de marquer la question spécifiée comme posée.
-
Confirmation du Marquage : Après la mise à jour, la base de données confirme que la question a été marquée comme posée.
-
Retour de la Confirmation : Le gestionnaire renvoie une confirmation au serveur, indiquant que l’opération a été réalisée avec succès.
3. Réponses aux exigences non-fonctionnelles
3.1. Concurrence
Attente : Le système doit être capable de gérer plusieurs joueurs simultanément, en assurant une exécution concurrente des actions sans compromettre l’intégrité du jeu.
Réponse : Le composant GameServer (Composant 4) gère la gestion du jeu en temps réel, y compris la réception et le traitement des actions des joueurs à chaque tour. Avec ces interfaces GameManagement et GamPlay, elle optimise ses performances en Concurrence pour gérér un flux de joueurs. Les interactions définies ques doivent respecter chaque action garantie le parallélisme de chaque utilisateur.
3.2. Performance
Attente : Le système doit fournir des performances satisfaisantes en termes de temps de réponse pour garantir une expérience de jeu fluide.
Réponse : Pour garantir une bonne performance, les différents composants qui doivent stocker des informations, doivent le moins stocker d’informations volumineux pour ne pas ralentir le système. C’est pour cela que nous avons optimisé le stockage des données, notamment le rôle du composant CardServer (Composant 5).
3.3. Interopérabilité
Attente : Le système doit être compatible et interopérable avec différentes plateformes.
Réponse : Les interfaces fournies par GameDesk, GameManagement, et GamePlay sont conçues pour assurer l’interopérabilité entre les composants du système.
Ces interfaces définissent clairement les opérations et les flux de données nécessaires pour la communication entre les différents composants de plus nous pouvons remarquer
qu’ils ne comportent pas de pré-requis spécifiques à une plateforme en particulier.
3.4. Portabilité
Attente : Le système doit être portable sur différentes plateformes sans compromettre la sécurité ni les fonctionnalités du jeu.
Réponse : Les composants du système sont conçus pour être portables sur différentes plateformes. Le composant PlayerServer (Composant 1) gère l’authentification, il assure la portabilité du système sur différents environnements. Les interfaces définies pour les composants spécifient les opérations nécessaires, garantissant une portabilité optimale sur différentes plateformes.
3.5. Sécurité
3.5.1. Exigence de sécurité
Attente : 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.
Réponse : N’ayant pas à nous occuper de l’authentification de l’utilisateur nous admettons que le système s’occupant de cela est correct et lui-même sécurisé. Nous admettons également que, quelle que soit la plateforme utilisée (web, logiciel, application) le service d’authentification sera le même pour tous.
3.5.2. Maintenabilité
Attente : Le système doit être maintenable, permettant des mises à jour, des corrections de bugs, et des améliorations futures avec une efficacité minimale.
Réponse : Chaque composant est conçu de manière indépendante, permettant des mises à jour spécifiques sans affecter l’ensemble du système. De plus, l’utilisation d’interfaces claires facilite l’ajout de nouvelles fonctionnalités ou la correction de défauts sans perturber les autres parties du système pour ne pas créer une défaillance générale.
3.7. Interface logicielle
Attente : Les interfaces logicielles doivent être bien documentées, faciles à comprendre, et suivre des conventions de codage cohérentes.
Réponse : La spécification des composants, avec ses interfaces bien définies telles que GameDesk, GameManagement, et GamePlay, garantit
une documentation claire des interfaces logicielles.
4. Choix techniques - Distribution des processus
4.1. Environnement de travail en général
L’environnement de travail pour le développement du logiciel Trivial Pursuit se conforme à des exigences non-fonctionnelles bien déterminées. Le système est structuré de manière distribuée, et adopte une architecture client-serveur utilisant les WebSockets pour les échanges de données. Le langage de programmation Java (version 11) est utilisé pour le serveur, tandis que le client est développé en TypeScript (version 4) avec le framework Angular (version ≥ 16.0).
4.2. Choix techniques
4.2.1. Composants techniques attendus
-
Serveur de jeu → JAVA avec Spring Boot
-
Client web → TypeScript avec Angular
-
Base de données → utilisation de JDBC pour interroger le SGBD
4.2.2. Contraintes
Vis-à-vis des composants :
-
Le composant
PlayerServerdoit garantir la sécurité des connexions des joueurs, surtout lorsqu’il s’agit de gérer des comptes utilisateurs. -
Tous les composants doivent intéragir de manière cohérente pour ne pas créer des erreurs lors du déroulement du jeu (reprises aux exigences non-fonctionnelles).
Vis-à-vis des exigences fonctionnelles :
-
L’interface graphique
-
Base de données : La communication vers la base de données.
Vis-à-vis des exigences non-fonctionnelles :
-
La sécurité
-
Navigateur : Le client web doit être compatible avec différents navigateurs (Firefox, Chrome, Edge, …)
-
Elasticité : Le système doit être capable de gérer un grand nombre de connexions simultanées et sans latence.
4.3. Distribution des processus :
La distribution des processus se réfère à la manière dont les différents composants et modules d’un système logiciel sont répartis sur des nœuds physiques ou logiques pour garantir une performance du système.
4.3.1. Distribution des processus dans Trivial Pursuit
-
Le processus pour le client web s’exécute sur la partie Navigateur.
-
Le processus serveur de jeu s’exécute sur la partie TrivialServer.
-
Le processus base de données s’exécute sur la partie Database.
-
La communication entre le client et le serveur utilise des WebSockets.