Conception détaillée
1. 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.
2. Réponses aux exigences non-fonctionnelles
2.1. Concurrence
Il faut que le serveur puisse gérer plusieurs parties à la fois. Comme chaque partie est indépendante des autres, on n’a pas besoin de les synchroniser. Les parties seront disposées dans le serveur, et celui-ci utilisera des threads qui se partageront le travail des parties. Comme ça, on pourra gérer plusieurs parties en même temps sans problème.
2.2. Performance
Il est important que la performance soit de mise. Pour ce faire, une bonne gestion des threads, ainsi que limiter les fonctions gourmandes en énergie est primordial.
2.3. Interopérabilité
Étant donné que l’application est déployée sur le web, cela ne pose pas de problème d’interopérabilité, elle sera disponible sur n’importe quel browser.
2.4. Portabilité
L’application est portable, en effet, les interactions se font sur le navigateur web et et multiplate-forme, et le backend étant centralisé, cela ne pose pas de problème.
2.6. Maintenabilité
Le projet étant bien organisé, et suivant des conventions de nommage et de structure de code rigoureux permet une meilleure maintenabilité. Ainsi qu’une documentation complète et claire ce qui permet une meilleure compréhension du code.
2.7. Interface utilisateur
L’interface utilisateur est produite avec un framework de Javascript, Angular, rendant l’interface intuitive, interactive et attrayante.
2.8. Interface logicielle
La partie de code est présentée sous forme de components ce qui rend d’autant plus compréhensible et abordable son code source. Le code source suit les bonnes conventions de codage comme par exemple instancier des classes avec leur interface, et définir aux mieux possibles les interfaces.
2.9. Interface ou protocoles de communication
L’échange d’informations entre le serveur et la base de données s’appuie sur JDBC (Java Database Connectivity), une interface standard qui facilite la communication entre une application Java et un système de gestion de base de données.
Quant à la communication entre le serveur et les clients, elle se réalisera à travers le protocole de web socket RFC 6455. Ce protocole offre des échanges bidirectionnels en temps réel, ce qui le rend particulièrement adapté aux besoins du jeu.
3. Patrons logiciels utilisés
3.1. Patron de conception "A"
Nous opterons pour le modèle de conception Observer afin de faciliter la gestion des événements en temps réel entre le serveur et les clients. Les clients seront configurés pour observer les modifications d’état du serveur, particulièrement lors des tours de jeu, et seront informés en conséquence.
3.2. Patron architectural "B"
L’architecture physique retenue suivra le modèle client-serveur. Le contrôle de chaque entité est "event driven", entre ces derniers, il demeure séquentiel. Du fait que plusieurs entités peuvent être actives simultanément, le flux de contrôle global s’opère de manière concurrente.
4. Choix techniques - Distribution des processus
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 faits le choix d’utiliser comme environnement de travail l’IDE éclipse. Pour la raison que nous connaissions tout très bien cet 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 :
-
L’interface graphique.
-
La communication vers la base de données.
-
La communication entre les machines.
-
La sécurité.