Conception détaillée

Routes API

Lobby

Table 1. Routes API des lobbies
Nom Route Corps de la requête Réponse Description

Liste des lobbies

GET /lobbies?type={private | public}&creator={member_id}

Aucun

[{ lobby_id: <string>, name: <string>, maxPlayers: <number>, currentPlayers : <number>, hasPassword: <boolean>, creator: <member_id> }, …​]

Liste des lobbies actifs. On peut filtrer par type de lobby : public, sans mot de passe, ou privé, avec un mot de passe.

Récupérer un lobby

GET /lobbies/{lobby_id}

Aucun

{ lobby_id: <string>, name: <string>, maxPlayers: <number>, currentPlayers : <number>, hasPassword: <boolean>, creator: <member_id> }

Récupère les informations d’un lobby en particulier.

Créer un lobby

POST /lobby

{ name: <string>, maxPlayers: <int>, password: <string or null>, creator: <member_id> }

HTTP 201 Created

Crée un nouveau lobby et place l’utilisateur qui l’a créé dedans.

Supprimer un lobby

DELETE /lobby/{lobby_id}`

Aucun

HTTP 204 No-Content

Supprime un lobby. La suppression doit être faite par l’utilisateur qui a créé le lobby.

Rejoindre un lobby

POST /lobby/join`

Aucun

HTTP 200 Ok`

Un utilisateur rejoint un lobby.

Partie

Joueur

Authentification

Table 2. Routes API de l’authentification
Nom Route Corps de la requête Réponse Description

Connexion

POST /auth/login`

{ membername: <string>, password: <string>, email: <string> }

HTTP 200 Ok

Connexion au serveur avec ses identifiants.

Créer un compte

POST /auth/register

{ membername: <string>, password: <string>, email: <string> }

HTTP 201 Created { memberId: <member_id> }

Création d’un nouveau compte utilisateur. Le mot de passe doit être unique.

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.

Réponses aux exigences non-fonctionnelles

Expliquez dans cette section les répondes aux différentes exigences non-fonctionnelles spécifiées.

Concurrence

TODO!

Performance

Le jeu doit supporter un grand nombre de lobby en même temps ainsi qu’un grand nombre d’utilisateurs connecté en même temps.

Interopérabilité

TODO!

Portabilité

Compatible avec tous les navigateurs de recherche actuelle (Mozilla, Chrom, …​).

Sécurité

traçage des mises à jour des données dans le système, gestion de la confidentialité, gestion de l’intégrité des données, protection des données personnelles.

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.

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.

Maintenabilité

Possibilité de mise à jour, mise en valeur des erreurs, extensibilité, testabilité.

Interface utilisateur

TODO!

Interface logicielle

TODO!

Interface ou protocoles de communication

TODO!

Correction

TODO!

Patrons logiciels utilisés

Décrivez dans cette partie les patrons logiciels utilisés pour mettre en œuvre l’application.

Patron de conception "A"

Nous avons utilisé dans le cadre du projet, 2 patrons de conception afin d’améliorer la structure de notre code et l’appel à notre API.

Pour le premier patron de conception, nous allons faire en sorte d’utiliser une unique instance d’Axios ou nous allons en faire une injection de dépendence fonctionnant sur une branche spécifique de l’API. Cela permettra de rendre notre code beaucoup plus modulaire. Nous allons également travailler et traiter les demandes réussies ainsi que les échecs de ce dernier. Et en plus, standardiser les réponses des méthodes.

Généralisation de notre implémentation

Pour l’instant, nos méthodes get/post/put/…​ ressource sont toujours codé en dur dans notre code. Afin d’augmenter la rentabilité, nous voulons transmettre dynamiquement l’URL de la ressource.

Nous pourrions ajouter un deuxième paramètre dans notre classe. Mais il est plus pertinent de transformer notre fonction en fonction d’ordre supérieur (fonction qui renvoie fonction)

Il est maintenant possible de réutiliser notre méthode pour de nombreuses ressources tout en transmettant l’instance axios une seule fois. Cela nous permettra de plus de pouvoir tester efficacement notre API client.

Plugin Nuxt.ts

Afin de transmettre correctement l’instance axios dans Next.ts, nous pouvons faire appel aux plugins Next.ts. Les plugins nous seront très utiles, car en plus de pouvoir accéder partout dans le projet au composant axios, les plugins sont évalués avant de créer l’instance racine de Vue.

Patron architectural "B"

TODO!

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 cet environnement, ce qui nous permet d’avoir tout le même environnement de développement.

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

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

  1. L’interface graphique.

  2. La communication vers la base de données.

  3. La communication entre les machines.

  4. La sécurité.