171 lines
8.3 KiB
Plaintext
171 lines
8.3 KiB
Plaintext
### 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)
|
|
|