typos and small adjustments

trivial-doc/modules/development/pages/conception.adoc

@@ -5,10 +5,10 @@
 // ainsi que de décrire comment vous répondez aux différentes exigences non-fonctionnelles.
 
 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.
+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.
+Appliquez les concepts vus en cours : design patterns , principes GRASP, bonnes pratiques, etc.
 
 
 
@@ -59,7 +59,7 @@ 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".
+Toutes ces méthodes effectue un changement de l'interface, de manière réactive et "event driven".
 
 
 === Base de données
@@ -85,18 +85,19 @@ Expliquez dans cette section les réponses aux différentes exigences non-foncti
 === Concurrence
 
 Il faut pouvoir faire tourner plusieurs parties en même temps sur un même serveur.
-Pour cela, le serveur a simplement une liste des parties en cours, on pourrait imaginer un thread par partie.
+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.
 
 === Performance
 
 ==== Performance serveur
-Pour assurer que les utilisateurs ai un retour rapide de leurs action il faut de bonnes performances serveur.
+Pour assurer que les utilisateurs aient un retour rapide de leurs actions, il faut de bonnes performances serveur.
 
-Il faut limiter au maximum la complexité des opérations. On pourra imaginer utiliser des outils de profiling pour s'assurer de bonnes performances.
+Il faut limiter au maximum la complexité des opérations. On utilisera des outils de profiling pour s'assurer de bonnes performances.
+De plus il faut pou
 
 ==== Performance client
 
-Le client web doit pouvoir s’exécuter sur un ordinateur personnel doté de 4 Go de RAM. Il faut donc limiter la complexitée du client pour le rendre performant sur ce type de machines.
+Le client web doit pouvoir s’exécuter sur un ordinateur personnel doté de 4 Go de RAM. Il faut donc limiter la complexité du client pour le rendre performant sur ce type de machines.
 
 === Interopérabilité
 
@@ -113,24 +114,24 @@ Le serveur utilise java, qui est également portable. La base de donnée peut ê
 
 ==== 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.
+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é
+=== 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.
 
 
 === 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 https://www.w3.org/WAI/fundamentals/accessibility-intro/fr[Introduction à l'accessibilité du web].
+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 https://www.w3.org/WAI/fundamentals/accessibility-intro/fr[Introduction à l'accessibilité du web].
 
 === Interface logicielle
 
-L'interface logicielle interne repose sur des interfaces java abstraite, limitant les dépendances a 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,Interface ou protocoles de communication >>.
+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,Interface ou protocoles de communication>>.
 
 === Interface ou protocoles de communication
 
@@ -157,7 +158,7 @@ Le Trivial Pursuit le patron de conception d'Observer, car c'est bien un systèm
 
 === Patron architectural
 
-L'architecture physique sera celle d'un système client(s) serveur. Le flot de contrôle de chaque partie est "event-driven", et entre ses évènements, il est séquentiel. Comme plusieurs parties peuvent être en cours en même temps, le flot de contrôle général est Concurrent.
+L'architecture physique sera celle d'un système client(s) serveur. Le flot de contrôle de chaque partie est "event driven", et entre ses évènements, il est séquentiel. Comme plusieurs parties peuvent être en cours en même temps, le flot de contrôle général est Concurrent.
 
 
 == Choix techniques - Distribution des processus
@@ -167,10 +168,10 @@ L'architecture physique sera celle d'un système client(s) serveur. Le flot de c
 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.
+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.
+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é.
 
@@ -185,6 +186,6 @@ Le choix pour l'interface graphique fut un client web, car cela permet la plus g
 
 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. Sela garantie une meilleure réactivité et évite le surcout lié à des requêtes http fréquente.
+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  https://oauth.net/2/[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