Conception détaillée
Routes API
Lobby
Nom | Route | Corps de la requête | Réponse | Description |
---|---|---|---|---|
Liste des lobbies |
|
Aucun |
|
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 |
|
Aucun |
|
Récupère les informations d’un lobby en particulier. |
Créer un lobby |
|
|
|
Crée un nouveau lobby et place l’utilisateur qui l’a créé dedans. |
Supprimer un lobby |
|
Aucun |
|
Supprime un lobby. La suppression doit être faite par l’utilisateur qui a créé le lobby. |
Rejoindre un lobby |
|
Aucun |
|
Un utilisateur rejoint un lobby. |
Authentification
Nom | Route | Corps de la requête | Réponse | Description |
---|---|---|---|---|
Connexion |
|
|
|
Connexion au serveur avec ses identifiants. |
Créer un compte |
|
|
|
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. |
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.
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.
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.
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 :
-
L’interface graphique.
-
La communication vers la base de données.
-
La communication entre les machines.
-
La sécurité.