Conception détaillée

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.

Relations et interfaces des composants

Relation et interfaces côté Serveur

Relation et interfaces côté Client

Relation et interfaces des Cartes

Réponses aux exigences non-fonctionnelles

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

Concurrence

Côté client, il n’y a pas de problème de concurrence. Par contre, nous utilisons actuellement une seule instance Java avec des variables locales. En utilisant une base de donnée gérant les transactions il serait possible d’utiliser notre jeu avec plusieurs instances Java et permettre encore plus de joueurs.

Portabilité

L’application ayant êté créée grâce à ReactJS elle est utilisable sur tout appareil avec un navigateur web.

De plus, une technologie proche nommée React Native permettrait de compiler notre application jeu en application iOS/Android afin d’obtenir plus de performances. L’utilisation d’ElectronJS permettrait d’avoir une application native pour ordinateur

Finalement, l’utilisation du protocole WebSocket permettrait à toute application utilisant n’important quel framework pourrait utiliser notre serveur de jeu.

Performance

Comme expliqué auparavant, l’utilisation d’une base de données et de dérivés de ReactJS tels que React Native, nous pourrions améliorer la performance.

Sécurité

Des données utilisées côté serveur ne peuvent être envoyées au client, c’est pourquoi le patron de conception DTO (data transfer object) fut utilisé.

Ainsi les informations non nécessaires au client sont gardées côté serveur, une conversion inutile des classes avec des méthodes n’est pas faîte par le middleware. Mais surtout, les cartes des autres joueurs ne sont pas envoyées à tous les adversaires, celles-ci devant rester confidentielles.

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é

L’utilisation de procédés de développement faits pour le développement en équipe et grâce à une documentation poussée, nous sommes confiants en la maintenabilité de notre projet.

Nous avons détaillé dans la documentation Antora tous nos choix, notre architecture et nos composants. De plus tous nos diagrammes et encore plus notre code, possèdent des commentaires.

Finalement, nous avons utilisé ESLint pour l’application client afin de structurer au mieux et d’uniformiser notre code, tout en permettant de plus facilement repérer les erreurs. Nous avons aussi suivi grâce à nos IDE la syntaxe uniformisée Google Java Style Guide.

Relation et interfaces de tous les composants

Relation et interfaces côté Serveur

Relation et interfaces côté Client

Relation et interfaces des Cartes

Interface ou protocoles de communication

WebSocket

Patron de conception "A"

DTO (Data Transfer Protocol)
Injection de dépendances

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.

Autres choix de conception

Client

Pour les tests, nous avons décidé d’utiliser le framework Jest au lieu Jasmine, celui-ci étant plus utilisé et car nous sommes plus habitué à celui-ci.

Afin de compléter nos tests, nous avons décidé de présenter en fonctionnement nos composants et page grâce à Storybook. Ceci permettant aussi de faire des tests d’intégration plus poussés.

Finalement, il fut décidé de positionner les fichiers de test et stories (Storybook) auprès des composants, par praticité pour les retrouver et par convention en développement de framework single-page app.

Server

Pour la partie serveur, nous avons diviser le projet en 3 packages.

core qui contient toutes les classes generiques. Il sert a orchestrer tout el projet. Que ce soit techniquement mais aussi en terme de gameplay puisqu’il va contenir toutes les méthodes de jeu. Ce package contient aussi l’interface de game_server et de middleware afin de ne pas créer de dépendances cycliques
game_server qui contient toutes les méthodes relatives au serveur de jeu. Il a une dépendance au package middleware
middleware contient toutes les méthodes pour communiquer avec les ClientMiddleware. Le package middleware a une dépendance au package game_server.

Afin de partager des informations entre le serveur et les clients, nous avons utilisé des DTO. Nous avons choisi d’utiliser les DTO car ils nous permettent de choisir quels variables exposer et partager. En parallèle, nous utilisons un objet java qui contient ce DTO. Exemple :

Notre Player possède une liste de cartes qui sont sa main. Cette liste ne doit pas etre révélée aux autres joueurs, mais on veut tout de monde dire aux clients quel est le userName de notre joueur. Pour cela nous allons mettre le userName dans le DTO et dans notre objet java nous aurons un objet DTO correspondant a notre joueur, mais aussi sa liste de cartes. Ainsi lorsque nous devrons mettre à jour les clients par exemple, nous n’enverrons que les PlayerDTO.