Clean-up server architecture

architecture.md

@@ -4,16 +4,16 @@
 
    - l'interface cli (command line interface) qui gère le serveur sur la machine où il est exécuté, ou à distance via le client (prévoir les traductions, la gestion du vocabulaire)
 
-   - le scheduler qui coordonne le calcul du modèle en initiant et terminant le superviseur et les threads de calcul
+   - le [scheduler](server/scheduler.md) qui coordonne le calcul du modèle en initiant et terminant le superviseur et les threads de calcul
 
-   - le superviseur qui: 
+   - le [superviseur](server/supervisor.md) qui:
 
       - maintient l'historique et effectue des mesures
 
       - effectue un test d'intégrité et renvoie son résultat au scheduler
          (pour détecter des états chaotiques, boucles infinies, répartitions déséquilibrées entre threads de calcul,...)
       
-   - les threads de calcul
+   - les [threads de calcul](server/worker_thread.md)
 
 - Le [client](https://gitlab.os-k.eu/gem-graph-team/gem-graph-client) est la partie dont l'exécution est rythmée par l'utilisateur:
 
@@ -53,11 +53,7 @@
 
 ---
 
-
-
----
-
-le nombre de calculs pouvant être effectués en parallèle dépend donc:
+Le nombre de calculs pouvant être effectués en parallèle dépend donc:
 
  - du rapport entre l'étendue de l'espace local et celui de l'espace global
 
@@ -65,8 +61,4 @@ le nombre de calculs pouvant être effectués en parallèle dépend donc:
  (si l'on néglige les opérations d'initiation et de terminaison des threads de calcul 
  et les opérations de communication de la boucle principale avec son environnement)
 
----
-
-Le processus principal (scheduler) peut donc être un serveur pour les threads de calcul
-
-L'interface ligne de commande doit également intercepter les demandes des utilisateurs et les déléguer a des threads ou processus dédiés
+Note : l'interface ligne de commande doit également intercepter les demandes des utilisateurs et les déléguer a des threads ou processus dédiés

server/scheduler.md

@@ -1,3 +1,5 @@
+# Scheduler
+
 Le centre de calcul (scheduler) est un automate qui effectue des transitions locales sur un état global
 
 Les modifications successives de cet état global décrivent sa trajectoire dans son espace de phase

server/supervisor.md

@@ -0,0 +1 @@
+# TODO

server/worker_thread.md

@@ -1,3 +1,5 @@
+# Worker Thread
+
 Chaque thread de calcul (worker thread) applique à un état local différent les mêmes règles de transition selon le même algorithme
 
 il retourne un nouvel état local ou lève une exception