Gem-graph/Analyse 'client/serveur'

171 lines
8.3 KiB
Plaintext
Raw Normal View History

2021-04-14 08:06:39 +02:00
gem-graph: architecture client / serveur
serveur: 3 modules principaux:
- CLI (= interface administrateur)
- Requests manager
- Scheduler
Requests manager: reçoit les demandes des utilisateurs (via un terminal ou une interface graphique)
et les répartit vers des modules spécialisés:
- account creation
- begin / end a session (login, authorizations, preferences, locale, language)
- preferences (read / write file or use default)
- load / save a model (read / write model file, init [Paramètres du calcul], init measures)
- control (using a control view or a terminal)
- run / stop, slow / speed, do / undo / redo
- modification [Paramètres du calcul]
- choix des vues, de la présentation des données (forme, fréquence, alarmes)
- résultats
- raw data,
- états,
- transitions,
- fonctionnement de l'automate
- analyse (outils / AI)
- aides
- édition
- états (global, local, sélection selon objet, situation)
- règles
- arbre des règles (regroupements selon un "point de vue" utilisateur)
- facilities, support (littérature, liens, correspondants, outils de présentation,...)
Views provider: reçoit de [Requests manager] une demande spécialisée:
(ex: user identification, begin / end session, run control, résults, data analysis tools, )
(éditions (state, rules, rules tree), help, facilities, support, preferences choice)
- cherche la vue adaptée dans [Views list]
- si possible, cherche dans un fichier les preferences utilisateurs
- si possible, cherche une traduction (default sinon) [Translations]
- si possible, cherche
* des résultats dans [Tables historiques], [espace graphique],
* des paramètres du modèle [arbre des règles], [paramètres du calcul]
- transmet l'ensemble au client
Translations:
Views list:
Superviseur:
- integrity control
- data assessement
- compression
Raw data: l'utilisateur demande l'accès aux données brutes
Mesures: chacune des mesures et des calculs de ce module est effectué avec une fréquence propre
(de une par cycle à une tous les 10^n cycles)
ces fréquences sont fixées par chaque utilisateur dans [Paramètres du calcul]
des arbitrages sont à prévoir en cas de conflit:
* certaines sessions sont destinées à identifier une règle ou un état
qui cause un comportement défectueux; ce comportement est reproductible.
* d'autres à vérifier la validité / conformité d'un modèle dans la durée
- Trois types de mesures:
* paramètres de fonctionnement de l'automate (ex: profil d'utilisation des règles)
* cohérence d'un modèle (jusqu'à ce que l'automate produise un résultat attendu)
* mesures utiles à l'interprétation d'un modèle:
l'automate produit le résultat attendu;
les mesures ont pour but de montrer la pertinence du modèle.
- reçoit de Scheduler des informations sur le nombre de cycles et leurs résultats:
(succès, échec, erreur)
- mesure le temps système et calcule la durée d'exécution du cycle à chaque réception
- reçoit de chaque thread de calcul le résultat de son calcul (succès, échec, erreur)
et, le cas échéant, le n° de la règle qui s'est appliquée.
- peut lire l'[espace graphique]
- met à jour les [Tables historiques]: opérations, objets simples, objets complexes.
d'après l'application des règles
ces mesures sont à confronter aux mesures réalisées à partir de l'[espace graphique]
- parcours systématique de la totalité de l'[espace graphique]
+ comparaison aux [Types du modèle] (lecture seule)
> objectif: dénombrement des objets de chaque type contenus dans l'[espace graphique]
- comparaison du nombre d'objets théoriquement produits par application des règles
au nombre d'objets effectivement présents dans l'[espace graphique]
+ reconnaissance d'éventuels objets non répertoriés, d'états cahotiques, etc... (méta-règles).
Cette mesure est coûteuse en temps de calcul mais elle permet de dépister les cas
où une règle s'applique à une situation pour laquelle elle n'avait pas été conçue.
Paramètres du calcul:
- fréquences des mesures
- inhibition d'une partie des règles
Tables historiques:
- opérations réalisée (transformations / transports / mouvements)
- objets de chaque type simple présents dans l'[espace graphique]
nombre calculé d'après l'application des règles
- nombres d' objets complexes créés / détruits
les objets complexes (ex: compartiment) sont prédéfinis dans [Types du modèle]
Types du modèle:
- liste les objets décrits par les règles (qui peuvent être présents dans l'[espace graphique])
- liste des objets composés ou topologiquement complexes prédéfinis (ex: compartiments)
- liste les transformations / transports / mouvements potentiels (décrits par les règles)
Scheduler: une boucle sans fin comportant 4 étapes:
- écoute CLI et Users Interface (qui peuvent interrompre le calcul ou en modifier la vitesse)
- transmet au module Mesures des informations:
nombre de cycles et résultat de chacun (succès, échec, erreur)
- cherche si un calcul local peut être entrepris (en un temps fini)
- cherche si un calcul local peut être achevé (en un temps fini)
* pour savoir si un calcul local peut être entrepris:
- lit [arrows list] <> tire une flèche au hasard
- lit [espace de préemption] <> l'espace où ce trouve cette flèche peut-il être calculé ?
- si oui, alors:
- tenter de le préempter (lit / écrit) (périphérique versus volumétrique ?)
- si la préemption a réussi, alors créer un thread de calcul à cet endroit
(lit / écrit dans la [liste des threads])
* pour savoir si un calcul local peut être achevé:
- lit la [liste des threads] <> un thread a-t-il fini son calcul (et écrit ses données) ?
- si oui, alors:
- le sortir de la [liste des threads] (écriture)
- lever la préemption (écriture dans l'[espace de préemption])
Thread de calcul:
- initialisé avec adresse + orientation dans l'[espace graphique]
- boucle for qui suit le même trajet dans cet espace et dans l'[arbre des règles]
et compare, à chaque étape, l'état de l'espace à la condition de l'arbre correspondante
si la condition est satisfaite (l'état de l'espace est conforme à la règle)
alors continuer le chemin
sinon return (aucune règle ne s'applique)
les choses sont un peu plus compliquées à cause des 'branches neutres':
si la règle ne pose pas de condition sur un état de l'espace rencontré,
alors, plusieurs règles pourraient convenir: il faut aller voir au delà et revenir;
les variables nécessaires pour mener à bien ces explorations sont toutes locales.
- en cas de succès,
* écrit les opérations prescrites par la règle dans l'[espace graphique]
* écrit les additions / délétions dans [arrows list]
* indique à Mesures le n° de la règle qui s'applique
- dans tous les cas (succès, échec, erreur), indique à Mesures le résultat du cycle.
l'[arbre des règles] est seulement lu.
espace graphique
arbre des règles
arrows list
* Users interface agit sur les paramètres du calcul:
- on / off, vitesse,
- fréquence des mesures, (transmis au module Mesures)
- fréquence de transmission des résultats (transmis au module Superviseur)