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

TODO!

Interopérabilité

TODO!

Portabilité

TODO!

Sécurité

TODO!

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.

Maintenanbilité

TODO!

Maintenabilité

TODO!

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"

TODO!

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 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 :

  1. L’interface graphique.

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

  3. La communication entre les machines.

  4. La sécurité.