architecture update

architecture.md

@@ -1,23 +1,37 @@
 # Gem-graph Architecture
 
-* la partie dont l'exécution est rythmée par le calcul du modèle ('engine' ?) qui comprend:
+* Le [serveur](https://gitlab.os-k.eu/gem-graph-team/gem-graph-server) est la partie dont l'exécution est rythmée par le calcul du modèle:
 
-    - le centre qui calcule le modèle (see below)
+    - le scheduler
 
-    - les outils de détection et contrôle automatisables (supervisor ?)
+    - coordonne le calcul du modèle en initiant et terminant les threads de calcul et le superviseur
-          (état chaotique, boucle infinie, répartition déséquilibrée entre threads de calcul,...)
 
-* la partie dont l'exécution est rythmée par l'utilisateur ('interface' ?) qui comprend:
+    - les threads de calcul
+    - le superviseur
+
+        -  maintient l'historique et effectue les mesures
+
+        - utilise des outils de détection et contrôle automatisables
+
+        - 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,...)
+    - interface cli (command line interface) pour gérer le serveur sur la machine / à distance via le client
+
+        - les traductions, la gestion du vocabulaire
+
+
+* 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:
 
      - l'initiation / la terminaison / l'interface OS
 
      - les entrées / sorties / contrôles d'erreurs associés
 
-     - le déroulement du calcul et le contrôle temps réel
+     - le contrôle par l'utilisateur du déroulement du calcul (effectué par le serveur)
 
-        - automaton > user (quel est l'état du modèle ? comment fonctionne l'automate ?)
+        - interface serveur > user (quel est l'état du modèle ? comment fonctionne l'automate ?)
         
-        - user > automaton (stop, slow / speed, undo / redo, modify the nb of threads or the algorithm...)
+        - user > interface serveur (stop, slow / speed, undo / redo, modify the nb of threads or the algorithm...)
 
      - la gestion des vues (conformité à une view_type)
 
@@ -29,13 +43,11 @@
 
         - des arbres de règles
 
-     - les mesures des états du modèle et de son histoire
+     - interprétation des mesures des états du modèle et de son histoire
-
-     - les aides (au moins une par vue) et leur édition
 
      - les traductions, la gestion du vocabulaire
 
-     - des facilités (textes, vues, liens) vers :
+     - des aides/facilités/présentation (textes, vues, liens) vers :
 
         - le contexte théorique, la bibliographie
 
@@ -47,7 +59,7 @@
 
 ---
 
-Le centre de calcul (engine) est un automate qui effectue des transitions locales sur un état global
+Le centre de calcul (serveur) 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
 
@@ -55,8 +67,8 @@ Chaque transition locale est calculée indépendamment, en mode asynchrone, par
 
 Tous les threads de calcul appliquent les mêmes règles selon le même algorithme
 
-Un processus principal (apportioner ? allocater ?) initie et termine ces threads 
+Un processus principal (scheduler) initie et termine ces threads 
-                       (scheduler ne convient pas car la répartition est spatiale) 
+
 Il garantit la cohérence de l'état global et valide l'ensemble du calcul ou l'interrompt en cas d'erreur
 Il est seul à avoir accès à l'état global et à la liste des threads de calcul
 Il n'a pas accès aux règles de transition
@@ -89,54 +101,45 @@ Il exécute un cycle qui comporte deux étapes principales:
 
  - sinon arrêt de cette recherche en un temps fini
  
- - mesures / recueil des commandes / retour d'information
+ - stimule le superviseur qui effectue : mesures / recueil des commandes / retour d'information
  
+ - s'arrête s'il le superviseur renvoie une alerte d'intégrité
 
 ---
 
-
 chaque thread de calcul 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 un message d'erreur
+il retourne un nouvel état local ou lève une exception
 
 l'espace local est défini par un centre, une orientation et un rayon
 
 (il peut être approché par un carré, un hexagone, un cube, ou toute autre forme le contenant)
 
-le centre est une cellule contenant au moins une flèche (optimisation: elle pourrait ne pas en contenir)
+optimisation : le centre est une cellule contenant au moins une flèche
 
-
+L'algorithme de calcul de l'état local suit parallèlement un chemin partant du centre de l'espace local et un chemin allant de la racine de l'arbre des règles vers l'une des feuilles et il compare, à chaque itération: 
-l'algorithme de calcul de l'état local suit parallèlement un chemin partant du centre de l'espace local
-
-et un chemin allant de la racine de l'arbre des règles vers l'une des feuilles et il compare, à chaque itération, 
 
  - le nombre de flèches présentes dans chaque site
 
  - au nombre de flèches requis pour que la condition qui s'applique à ce site soit satisfaite
  (un parcours séquentiel ou aléatoire des règles est possible mais donnerait des résultats différents)
  
-ce chemin parcourt l'ensemble de tous les sites de toutes les cellules de l'espace local dans un ordre prédéfini
+Ce chemin parcourt l'ensemble de tous les sites de toutes les cellules de l'espace local dans un ordre prédéfini
 
-ce parcours est optimisé de façon à maximiser la probabilité d'intersection entre:
+Ce parcours est optimisé de façon à maximiser la probabilité d'intersection entre:
 
  - les sites occupés dans l'état local
 
  - les sites définis par les règles de transition
 
-pour pouvoir effectuer ce parcours, il faut que les coordonnées (locales) des conditions et des actions des règles
+Pour pouvoir effectuer ce parcours, il faut que les coordonnées (locales) des conditions et des actions des règles soient préalablement superposées aux coordonnées globales (calculées d'après l'origine et l'orientation) de l'espace local
 
-soient préalablement superposées aux coordonnées globales (calculées d'après l'origine et l'orientation) de l'espace local
+le parcours s'interrompt dès qu'une condition est fausse: ceci veut dire qu'aucune règle ne décrit cet espace local (to do: renvoyer à l'utilisateur un message : "pas de règle s'appliquant à cet espace local")
-
-le parcours s'interrompt dès qu'une condition est fausse: ceci veut dire qu'aucune règle ne décrit cet espace local (to do)
-
-sinon, il se termine lorque toutes les conditions d'une règle ont été satisfaites: 
-
-la région de l'espace global auquel cet espace local est superposé peut être modifié selon les indications de cette règle
 
+sinon, il se termine lorque toutes les conditions d'une règle ont été satisfaites: la région de l'espace global auquel cet espace local est superposé peut être modifié selon les indications de cette règle
 
 ---
 
-
 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
@@ -147,7 +150,6 @@ le nombre de calculs pouvant être effectués en parallèle dépend donc:
 
 ---
 
-le processus principal (apportioner) peut donc être un serveur pour les threads de calcul
+Le processus principal (scheduler) peut donc être un serveur pour les threads de calcul
-
-il doit également intercepter les demandes des utilisateurs et les déléguer a des threads ou processus dédiés
 
+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