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 les 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. Spécification détaillée des composants
2.1. Serveur Trivial Pursuit
Le composant "Serveur Trivial Pursuit" est responsable de la gestion globale du jeu, y compris la création des objets de jeu, la gestion des connexions au serveur, la gestion des utilisateurs et des parties, ainsi que la logique de jeu pendant chaque tour.
2.2. Client Web
2.2.2. Comportement
startGame() : annonce au client que la partie commence play() : indique au client que c’est son tour hasColor() : demande au client si il a une couleur dans son camembert setCurrentPosition(position : Integer) : Indique au client sa nouvelle position
Toutes ces méthodes effectue un changement de l’interface, de manière réactive et "event driven".
3. Réponses aux exigences non-fonctionnelles
|
Expliquez dans cette section les réponses aux différentes exigences non-fonctionnelles spécifiées. |
3.1. Concurrence
Il faut pouvoir faire tourner plusieurs parties en même temps sur un même serveur. Pour cela, comme chaque partie est indépendante, il n’y aura pas de synchronisation à faire. Les parties seront simplement stockées, et le serveur utilisera un thread pool, une collection de thread se partageant les tâches liées aux parties, permettant une gestion simultanées de plusieurs parties.
3.2. Performance
3.3. Interopérabilité
Une interface client web assure l’interopérabilité car, le web étant une technologie omniprésente, les utilisateurs peuvent accéder au logiciel quelque soit leur matériel informatique, de manière uniforme. De même, l’utilisation de JDBC pour la communication avec la base de donnée permet une interopérabilité avec les systèmes de gestion de base de donnée.
3.4. Portabilité
Il n’y aura pas de problème de portabilité car le client est sur le web, et est donc multiplatforme par nature. Le serveur utilise java, qui est également portable. La base de donnée peut être moins portable, mais étant indépendante des autres composants et complétement gérée par le fournisseur du logiciel, ce problème est moindre.
3.5. Sécurité
3.5.1. 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.
3.6. Maintenabilité
Il faut au plus suivre les best practices rendant le code facile à lire et à tester pour rendre le code le plus maintenable que possible. Le fait de respecter les directives de codage Google permet déja de rendre le code plus simple à maintenir.
3.7. Interface utilisateur
L’interface utilisateur sera une interface web, conçue sur des principes d’accessibilité, par example sur les bases définie par le W3C dans son Introduction à l’accessibilité du web.
3.8. Interface logicielle
L’interface logicielle interne repose sur des interfaces java abstraite, limitant les dépendances à des abstractions. Cela permet des interactions bien définies, et une meilleure flexibilité pour l’implémentation et la maintenabilité. La communication entre les composants globaux se fait par le biais du réseau, par des protocoles décris dans la prochaine partie : Interface ou protocoles de communication.
3.9. Interface ou protocoles de communication
La communication entre le serveur et les clients se fera par le biais de web socket RFC 6455. Ce protocole permet des communications temps réelles simultané bidirectionnelles, bien adapté au jeu. De plus, nous utiliserons WSS, WebSocket Protocol over TLS pour assurer la sécurité des informations en transit.
La communication entre le serveur et la base de donnée repose sur JDBC ("Java Database Connectivity"), une interface standard et uniforme pour communiquer entre une application java et un système de gestion de base de données.
3.10. Correction
Pour limiter le comportement non voulu et les effets de bord, des tests unitaires doivent être mis en place, vérifiant le bon fonctionnement de chaque composant de manière isolée. Un processus de test d’intégration est aussi à mettre en place, pour tester le fonctionnement global du système
De plus, l’utilisation d’exception et un traitement rigoureux desdites exceptions pour limiter l’impact des erreurs qui peuvent apparaitre suite à des états inattendus du logiciel.
4. Patrons logiciels utilisés
| Décrivez dans cette partie les patrons logiciels utilisés pour mettre en œuvre l’application. |
5. 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 fait 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 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é.
Le choix pour l’interface graphique fut un client web, car cela permet la plus grande facilitée d’accès, sans que l’utilisateur ait besoin d’installer un logiciel dédié. Cela est aussi un bon choix, parce que c’est une industrie mature, avec beaucoup de personnes qualifiées pour créer une interface de bonne qualité.
La communication vers la base de donnée utilise "Java Database Connectivity", une methode standard pour communiquer entre une application Java et une Base de donnée. Ce choix est judicieux, car il offre une interface uniforme pour communiquer avec une base de données. Il est donc plus facile de déveloper sans connaissances spécifiques du système de gestion de base de données sous-jacent, cela améliore aussi la maintenabilité du code, ainsi que la portabilité en cas de changement de SGBD. Ce choix rend aussi le code plus stable, car il y a moins d’erreur possible qu’avec une implémentation ad-hoc, et des fonctions complexes comme les transactions ou les "connection pool", optimisant l’accès à la BDD.
La communication entre les machines utilise des web sockets, car ce protocole est bi directionnel, temps réel et persistant, ce qui est bien adapté au contexte d’un jeu. Cela garantit une meilleure réactivité et évite le surcout lié à des requêtes http fréquente.
La sécurité est assuré par un système d’authentification pour vérifier l’identité de l’utilisateur. Un système tel que OAuth, qui permet de déléguer l’authentification a un autre service, réduisant le risque de failles de sécurités dans notre application. Nous utiliserons aussi le protocole HTTPS pour sécuriser les connexions HTTP, ainsi que WSS pour sécuriser les connections via WebSocket