gem-graph/gem-graph-client
gem-graph
/
gem-graph-client
3
0
Fork 0
Code Issues 14 Pull Requests Projects Releases Activity
gem-graph-client/WIP: rédaction cahier des c...

741 lines
37 KiB
Plaintext
Raw Blame History

2022-06-03 10h00
_____________________________________________________________
| |
| 740 lines 5015 mots 29314 car 37682 octets |
|____________________________________________________________|
Le client est la partie dont l'exécution est rythmée par l'utilisateur.
Il peut fonctionner en mode "client seul" ou en mode "client / serveur".
Certaines de ses fonctionnalités sont communes aux deux modes.
Quel que soit le mode, édition et exécution doivent être disjointes (sessions indépendantes)
En mode "client seul", le client travaille indépendemment du serveur.
Il opère sur des modèles locaux:
Ses fonctions sont:
- lectures/écritures de ces modèles dans une base de données locale
- édition/vérification/validation (règles de transition/états/arbres de règles)
- exécutions locales
- sans optimisation ni recherche de performances
- sous contrainte de compatibilité avec les spécifications du serveur
- additions de modèles
Fonctionnalités communes aux modes "client seul" et "client / serveur"
- visualisation des données
- traductions, gestion du vocabulaire
- outils de mesure
- états du modèle,
- histoire, - validité des règles,
- performances
- aides à l'interprétation
- édition d'aides
- le contexte théorique, la bibliographie
- principes / justifications / limites du modèle
- outils de présentation (textes, vues, liens)
- modèles, interprétations
- licence, droits, auteurs, informations pratiques
En mode "client / serveur", le client travaille connecté au serveur.
Il peut
- proposer au serveur des modèles locaux ou
- opèrer sur des modèles de la base de données du serveur.
Ses fonctions sont:
- les entrées / sorties / contrôles d'erreurs associés
- demande / initialisation / terminaison du calcul (dialogues client/serveur)
- le contrôle par l'utilisateur du déroulement du calcul effectué par le serveur
- interface serveur > user (quel est l'état du modèle ? comment fonctionne l'automate ?)
- user > interface serveur (stop, slow / speed, undo / redo, modify the nb of threads or the algorithm...)
- la gestion des vues (conformité à une view_type)
Contraintes communes au client et au serveur
recherche de performance.
Le nombre de calculs pouvant être effectués en parallèle dépend :
- du rapport entre l'étendue de l'espace local et celui de l'espace global
- du temps de parcours moyen des règles, 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.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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)
--------------------------------
https://git.a-lec.org/gem-graph/gem-graph/-/blob/master/Cahier%20des%20charges%20client
deux modes de communication:
-. commandes en ligne via un terminal et 'raw data' (données non formatées) ou
-. interface graphique
Note : l'interface ligne de commande doit intercepter les demandes des utilisateurs et les déléguer a des threads ou processus dédiés
deux types de sessions:
-. fabrication (repérage et correction des erreurs) ou
-. interprétation (quelle part de la réalité ce modèle ce modèle représente-t-il ?)
liste des vues et des fonctions auxquelles elles donnent accès:
-. run
-. run, stop
-. speed, slow
-. pas à pas: montre l'état local et la règle sélectionnée, avant et après application
-. do, undo, redo (en continu +/- rapide ou pas à pas)
-. état global
-. défilement,
-. zoom,
-. sélection (objets, tags,...),
-. filtres apparence (links, tiles),
-. recherches
-. état local
-. extraction de l'état global,
-. filtres apparence (links, tiles),
-. édition,
-. copie (en vue d'une édition d'une règle)
-. règles
-. images état local (avant, après),
-. identité (nom, chemin),
-. listes (avec filtres, tris) (conditions, actions, commentaires)
-. texte complet (format XML, texte,...)
-. vignettes (lien vers la règle)
-. activation / inhibition
-. mesures d'activité
-. tracking
-. édition de règles
-. à partir d'une copie d'un état local,
-. à partir de structures extraites de bases de données
-. de novo
-. étude du domaine d'application de la règle (essais d'application à d'autres situations)
-. activité des règles ('rules account')
-. filtres (sélection de groupes de règles àpartir d'arbres utilisateurs)
-. liens vers les vignettes,
-. activation / inhibition
-. mesures d'activité
-. tracking
-. transformations
-. activation / inhibition,
-. mesures d'activité
-. tracking
-. arbre des conditions
-. complet,
-. condensé (les noeuds sans bifurcations sont supprimés),
-. édition manuelle ?
-. filtre branches neutres,
-. activation / inhibition,
-. mesures d'activité
-. tracking
-. liens vers les vignettes
-. arbres utilisateurs
-. édition
-. mesures d'activité
-. tracking
-. liens vers les vignettes
-. histoire
-. concentrations,
-. transformations,...
-. filtres objets, ensembles d'objets, transformations,...
-. durées de vie des objets ('lifespans')
-. filtres objets, ensembles d'objets
-. espace de phases
-. axes objets / axes transformations / mixtes ?
-. corrélations
-. entre objets, transformations, les deux ?
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Fichiers de profils et de sessions
Chaque utilisateur de gem-graph peut travailler sur différents modèles gem-graph et peut, ou non, faire appel aux serveurs gem-graph.
Dans chaque situation, il peut avoir ses propres préférences (langage, apparences, aides, contexte, correspondants, etc...).
Une session gem-graph est une exécution (une instance) du client gem-graph.
Une session est, le plus souvent, exécutée à propos d'un modèle.
Durant cette session, l'utilisateur peut ou non être connecté à un serveur gem-graph.
Les données gem-graph sont donc de différents types (et stockées dans différents fichiers) selon qu'elles sont relatives à :
Un utilisateur. Celui-ci peut vouloir éditer ses préférences-client sans travailler sur un modèle. A chaque utilisateur est associé un fichier préférences-client.
Un utilisateur travaillant sur un modèle. A chaque paire modèle-client est associée un fichier session.
Un utilisateur établissant une connexion avec un serveur. Chaque utilisateur est identifié dans une base de données utilisateurs et modèles accédée uniquement par les serveurs.
Un serveur travaillant (à la demande d'un client) sur un modèle. A chaque modèle vu par un serveur est associé un fichier modèle.
Un administrateur de serveur (fichier journal, base de données utilisateurs et modèles, base de données serveurs)
Une session gem-graph commence donc par la lecture d'un fichier préférences-client et se termine par son enregistrement.
Il existe autant de fichiers préférences-client que de clients.
Si l'utilisateur veut travailler sur un modèle, il doit charger ou créer un fichier session. Ce fichier décrit un modèle vu par un client.
Il existe autant de fichiers session-modèle-client que de paires (tuples) utilisateur-modèle.
En fin de session, les modifications du modèle sont enregistrées dans ce fichier session-modèle-client.
Si l'utilisateur veut faire tourner un modèle sur un serveur, il doit d'abord demander un accès à un serveur.
Cet accès utilise des données de la base de données utilisateurs et modèles.
Il doit, après s'être identifié, choisir le modèle qu'il veut faire tourner.
Il peut s'agir d'un modèle déjà répertorié dans la base de données, d'un modèle modifié ou d'un nouveau modèle.
Tout modèle, quel que soit son statut, est enregistré dans la base de données utilisateurs et modèles.
Opérations traitées par un client gem-graph:
édition d'un modèle en cours
comparaisons, fusion de modèles (complètes ou partielles), recombinaisons...
-----------------------------------
Accès aux données : le cas des modèles ayant un espace global dont la taille est invariante.
Pour représenter un espace de taille fixe dans le client, un tableau de tous les sites dans toutes les cellules faciliterait les accès.
Un module en C (avec get / set) permettrait d'optimiser (dans un second temps) ce cas particulier mais fréquent.
----------------------------------
UI : détection des erreurs reproductibles et aléatoires lors de la fabrication d'un modèle.
Ces deux types d'erreurs sont repérables par des techniques différentes faisant appel à des outils parfois communs, parfois différents.
Cette issue a pour but de lister ces outils afin de faciliter le design du client.
Il va probablement falloir un sous-groupe Gem-graph-lab spécialisé dans le dépistage des erreurs reproductibles et disposant d'un moteur monothread (lent mais indépendant) pour traiter des demandes incompatibles avec les performances demandées au serveur (voir les issues serveur #25, #26 et #27, trop contraignantes pour le serveur).
Le serveur devrait être dédié aux calculs haute performance nécessaires à la recherche d'erreurs aléatoires puis à l'étude des résultats des modèles (leur confrontation à la réalité).
Voir aussi liste des outils dans le cahier des charges : https://git.a-lec.org/gem-graph/gem-graph/-/blob/38e5c855e90d08fa5c6bddba7de5f7e4151b5149/Cahier%20des%20charges
Les erreurs reproductibles (systématiques) sont facilement repérables car elles bloquent rapidement l'exécution du modèle en générant un état cahotique ou, au minimum, non conforme à des critères facilement définissables. Ces critères peuvent porter sur la structure de l'état global (présence ou absence de tel type d'objet ou variation du nombre d'objets de tel type au dela d'un seuil, etc....) ou sur la fréquence d'exécution d'un règle ou d'un groupe de règles.
Ces erreurs peuvent (liste non limitative) :
bloquer complètement l'exécution d'une règle
survenir à chaque exécution d'une règle
survenir toujours dans la même situation ou en présence du même objet
effectuer une modification facilement identifiable
...
Elles surviennent fréquemment lors de la création des modèles.
Elles sont facilement identifiées et corrigées avec des outils simples :
do/undo/redo
slow down/speed up
pas à pas à une localisation aléatoire
pas à pas à une localisation choisie
retour à l'état du modèle précédant la dernière modification
tracage et/ou inhibition sélective de règles ou groupes de règles
édition de nouvelles règles à partir de copies d'états locaux non reconnus
...
A ce niveau de complexité, l'édition est maladroite. Il faut accepter de procéder par essais / erreurs, c'est-à-dire, en gros, de 'pousser à la rencontre les uns des autres' les objets et les règles nouvellement créés, d'observer en détail ce qui se passe et de rééditer jusqu'à obtenir ce que l'on veut.
Les erreurs aléatoires sont difficiles à repérer car :
elles ne bloquent pas l'exécution du modèle
elles provoquent un effet imprévu et qui survient rarement
elles peuvent être indirectes (l'effet imprévu est lui-même causé par un autre effet imprévu)
Garantir qu'aucune erreur aléatoire n'est présente au sein du modèle est impossible.
Les outils les plus utiles pour les repérer sont (liste non limitative) :
Les confrontations prédictions / bilans (nombre d'objets, de situations, de transitions) (resp. meta-x)
la surveillance de l'évolution (vues 'histoire du modèle', histogrammes nombres d'objets, exécutions de règles)
les statistiques globales ou avec focus sur un object, une situation ou une règle
l'inhibition sélective de règles ou groupes de règles
la suppression transitoire d'objets ou de groupes d'objets
la soustraction d'une partie du modèle ou sa divison en branches si elle est possible
...
----------------------------
Traduction Internationalisation
----------------------------
UI : deux types exclusifs de sessions : exécution / édition (d'un modèle)
L'exécution et l'édition d'un modèle sont des opérations exclusives. Un modèle ne peut ni être édité pendant une exécution ni être exécuté pendant une édition.
Ce principe de fonctionnement pourra être remis en cause si la création de modèles capables de s'auto-éditer est envisagée, mais, d'ici là, il doit guider la première phase de développement. (nov 2021)
----------------------------
UI : deux types d'arbres des règles : par conditions et par fonctions
Les arbres des règles par conditions sont essentiellement destinés au serveur. Ils sont au coeur de la représentation des transitions dans le modèle XML.
Les arbres des règles par fonctions sont essentiellement destinés à l'utilisateur. Chaque utilisateur peut avoir le sien et en avoir plusieurs s'il le souhaite.
Un arbre des règles par fonctions peut servir à inhiber temporairement une règle ou un groupe de règles.
--------------------------
UI : permettre l'affichage d'une règle spécifique
Affichage 'complet' :
graphe 'avant' (état local avant application de la règle)
graphe 'après' (état local après application de la règle)
liste des conditions
liste des actions
Vignette : les deux graphes sous une forme 'miniature' pour faciliter les comparaisons entre règles
--------------------------
UI : afficher l'arbre de conditions
Il y a plusieurs arbres des conditions possibles.
Les arbres qui intéresseront le plus les utilisateurs seront ceux qui leurs permettront d'organiser les règles à leur convenance. voir issue : afficher l'arbre de l'utilisateur
Le plus simple de ces arbres est celui qui réunit les conditions de toutes les règles en suivant un chemin en spirale qui parcourt systématiquement tous les sites de toutes les unités de l'espace en partant de l'origine.
Ces arbres peuvent être créés suivant d'autres parcours de l'espace des règles. Par exemple, un parcours aléatoire des sites, ou commençant à mi-profondeur, ou dans une zone de densité particulière des conditions, pourrait s'avérer plus rentable que le parcours en spirale...
Toutes ces possibilités donneront des résultats variables d'un modèle à un autre et devront parfois être évaluées et comparées.
--------------------------
UI : afficher les objets des modèles
L'utilisateur a besoin :
d'une liste ou d'un arbre lui permettant d'accéder à tous les objets de son modèle
d'une (au moins) image de l'objet sur lequel il veut travailler (+ liste 'texte' des flèches)
de liens vers les autre objets-modèles qui représentent le même objet-réel
et vers le meta-objet
Même si les meta-objets sont initialement 'fabriqués à la main', il faut les prévoir (leur prévoir une place = des noms, des liens d'accès)
Il faudra les manipuler pour comprendre quelles sont les fonctions à automatiser.
--------------------------
UI : afficher les état des modèles
--------------------------
UI : graphes pour les états des modèles et le suivi/monitoring de la modélisation
--------------------------
Graphics : afficher les états des modèles
--------------------------
Réseau : communiquer avec le serveurs
--------------------------
Parsing/chargement de modèle
identity
(model identity)
parameters id="..." date="..." author="..."
(simulation & space parameters)
objects id="..." date="..." author="..."
(each object is a list of arrows)
savestates id="..." date="..." author="..."
(each savestates is a list of arrows)
conditions id="..." date="..." author="..."
(a list of conditions)
(each condition associates x, y, z, site, weight, node_id, parent)
transitions
(a list of transitions)
(each transition has a parent)
(each transition is a list of arrows)
--------------------------
UI : création d'une GUI
Fonctionnalités prévues
Deux modes de visualisation exclusifs : édition / contrôle
Plusieurs types de session :
+ évaluation de gem-graph
+ fabrication d'un modèle (pas à pas)
+ tests qualité
+ observation
+ analyse résultats
+ présentation
... (voir les issues liées)
--------------------------
Cycle de vie d'un modèle et définition de l'automate du client gem-graph.
Création d'un modèle.
essais de courte durée pour mettre en évidence les erreurs reproductibles.
les outils :
Renvoyer au client des copies des états locaux auxquels aucune règle ne s'adapte.
Tracer une règle (obtenir des informations chaque fois qu'elle est appliquée).
Déclencher une seule transition en un point choisi de l'espace global.
...
Mise au point
essais prolongés adaptés au repérage des erreurs aléatoires.
...
Confrontation à la réalité
Lorsque le modèle produit des résultats suffisament reproductibles.
Un sous-groupe Gem-graph-lab disposant d'un moteur monothread localisé dans le client (peu performant mais indépendant) devrait être spécialisé dans le dépistage des erreurs reproductibles.
Certaines fonctionnalités, indispensables à ce travail, sont, en effet, incompatibles avec le fonctionnement du moteur du serveur.
Ex (voir les issues serveur #25, #26 et #27 - liste non limitative) :
Le serveur devrait être dédié aux calculs haute performance et longue durée nécessaires à la recherche d'erreurs aléatoires puis à l'étude de l'adéquation du modèle (confronté à la réalité).
--------------------------
Représentation probabiliste des volumes.
A chaque case d'un espace peut être associée une probabilité de présence d'un volume.
Cette technique permettrait d'associer aux volumes des contours 'flous' et pourrait faciliter leurs déplacements et la représentation de leurs interactions.
Le 'remplissage' des objets par 'de la présence' permettrait de représenter des ondes de densité: ces ondes seraient générées sur un bord et, lorsqu'elles atteidraient un bord opposé, elles le déplaceraient. Un seul mécanisme représenterait ainsi les mouvements de tous les objets, quelle que soit leur forme.
--------------------------
Le client gem-graph devrait fournir des outils facilitant l'édition de meta-situations.
Le concepteur d'un modèle peut souhaiter représenter (dessiner) une même 'situation-réelle' de différentes façons selon les positions ou les états des objets en situation (en interaction).
Il peut souhaiter également éditer des liens entre ces différents représentations et, éventuellement, y ajouter d'autres informations.
L'ensemble des informations concernant une même 'situation-réelle' constitue une meta-situation.
Le client gem-graph devrait fournir des outils facilitant l'édition de meta-situations.
Si, par exemple, le concepteur du modèle fait l'hypothèse que l'évolution d'une situation (réelle) est connue de façon certaine, il est inutile de simuler l'évolution de cette situation de façon détaillée. Il faut qu'il puisse simplifier cette étape. L'objectif du modèle est ailleurs.
Il est donc utile, dans ce cas, de pouvoir identifier toutes les configurations (toutes les 'situation-dessinées') qui représentent cette 'situation-réelle' et de leur appliquer la même meta-transition.
Cette fonctionnalité suppose la possibilité de créer et d'éditer des meta-situations.
Elle diffère de l'édition de meta-objets parce qu'une meta-situation associe nécessairement plusieurs objets ou meta-objets.
A la date de création de cette issue (nov 2021), cette technique n'a jamais été testée.
--------------------------
Réfléchir aux choix des conventions nécessaires à l'écriture des modèles. Préparer l'internationalisation.
Des conventions sont nécessaires pour pouvoir écrire des modèles de gem-graph.
Par exemple:
Les directions de l'espace seront-elles énumérés dans l'ordre x, -x, y, -y, z, -z, etc... ou dans le sens trigonométrique ou dans le sens horaire ?
Faut-il encourager ou 'déprécier' l'usage des noms des points cardinaux, des mots 'gauche', 'droite' ?
Le sens de lecture, etc...
Des décisions, conformes aux habitudes de chacun, qui peuvent sembler parfaitement adaptées et logiques à un moment du développement peuvent devenir contre-productives ultérieurement...
Pour mémoire, cette sonde qui s'est écrasée sur Mars parceque deux équipes utilisaient - pour des raisons culturelles - des unités de longueur différentes (pieds vs. mètres) et qu'il semblait évident à chacune que tout le monde faisait comme elle.
Des décisions indispensables - peu nombreuses - ont déjà été prises. De futurs utilisateurs ou contributeurs pourraient demander qu'elles soient répertoriées et justifiées.
Le but est d'être le plus simple et le plus compréhensible possible dans le plus grand nombre de contextes possible.
--------------------------
Le client gem-graph devrait fournir des outils d'extraction de graphes non géométriques et de dessins.
Des graphes non géométriques pourraient être 'extraits' de chaque état d'un gem-graph.
Ces graphes s'intéresseraient seulement aux propriétés non géométriques des gem-graphs, oubliant les propriétés liées à leurs coordonnées spatiales.
Il pourrait être utile de les comparer, de les classer et d'étudier leurs propriétés mathématiques.
Le client gem-graph devrait fournir - sous forme de modules - des outils d'extraction de tels graphes à partir de gem-graphs.
Des dessins (sans graphe associé) pourraient être 'extraits' de chaque état d'un gem-graph.
Les annotations, qui ne représentent pas les objets eux-mêmes ni les situations, seraient alors supprimées ou converties.
--------------------------
Une organisation modulaire des clients gem-graph simplifierait le traitement des clients particuliers.
Des interfaces gem-graph spécialisées devraient être créés pour traiter les modèles de certains systèmes complexes particuliers.
Liste (non exhaustive) de communautés d'utilisateurs potentiels:
biologie cellulaire,
biologie du développement,
écologie,
géographie,
climatologie,
économie,
urbanisme,
...
Une organisation modulaire du logiciel permettrait de développer séparément les interfaces dédiées à des utilisateurs particuliers (ex: accès à certaines banques de données, références, contexte,...) qui présenteraient peu d'intérêt pou les autres.
Une bibliothèque de modules spécialisés devrait être organisée.
--------------------------
Le client gem-graph devrait fournir des outils facilitant l'édition de meta-transitions.
Le concepteur d'un modèle peut souhaiter représenter (dessiner) un même 'objet-réel' de différentes façons selon les situations ou suivant les transitions qui s'appliquent à cet objet.
L'ensemble des informations concernant un même 'objet-réel' constitue un meta-objet.
Le concepteur peut souhaiter définir une même transition sur tout ou partie des objets (graphes connexes) d'un ou de plusieurs meta-objet(s).
Un ensemble des transitions concernant un même 'objet-réel' ou meta-objet constitue une meta-transition.
Le client gem-graph devrait fournir des outils facilitant l'édition de meta-transitions.
L'utilisation d'outils utilisant des représentations vectorielles des meta-objets devrait être encouragée lorsqu'elle est possible.
L'identification d'objets et de situations par un ensemble de conditions est une technique de 'pattern recognition' qui pourrait être optimisée par des méthodes développées en IA.
A la date de création de cette issue (nov 2021), cette technique n'a jamais été testée.
--------------------------
Le client gem-graph devrait fournir des outils facilitant l'édition de meta-objets.
Le concepteur d'un modèle peut souhaiter représenter (dessiner) un même 'objet-réel' de différentes façons selon les situations ou suivant les transitions qui s'appliquent à cet objet.
Il peut donc considérer plusieurs 'objets-dessinés' (graphes connexes) comme des représentations d'un même 'objet-réel'.
Il peut souhaiter également éditer des liens entre ces différents représentations et, éventuellement, y ajouter d'autres informations.
L'ensemble des informations concernant un même 'objet-réel' constitue un meta-objet.
Le client gem-graph devrait fournir des outils facilitant l'édition de meta-objets.
La représentation vectorielle, partielle ou complète, des objets devrait être encouragée lorsqu'elle est possible.
A la date de création de cette issue (nov 2021), cette technique n'a jamais été testée.
--------------------------
Chaque modèle gem-graph devrait pouvoir être couplé à des modèles décrivant des ondes.
Certains phénomènes participant à des phénomènes complexes sont décrits de façon optimale par des équations continues représentant des ondes.
Chaque modèle gem-graph devrait pouvoir être couplé à de tels modèles.
Ce couplage suppose remplies toutes les conditions suivantes:
superposition des espaces et des temps des deux modèles
lecture des valeurs d'une variable d'intérêt du modèle décrivant les ondes par le modèle gem-graph au moyen de conditions spécifiques prenant en compte l'orientation, la section efficace, l'énergie, la phase,...
écriture dans le modèle continu des modifications effectuées par le modèle gem-graph au moyen d'une action ('assignment') spécifique
A la date de création de cette issue, cette technique n'a jamais été testée.
--------------------------
Chaque modèle gem-graph devrait pouvoir être couplé à des modèles décrivant des flux.
Certains phénomènes participant à des phénomènes complexes sont décrits de façon optimale par des équations continues représentant des flux.
Ces modèles utilisent des gradients de variables intensives (ex: pression, température, densité,...) pour décrire les états et calculer leurs évolutions.
Chaque modèle gem-graph devrait pouvoir être couplé à de tels modèles.
L'idée d'un couplage entre modèles de nature différente a déjà été proposée. (ref 1)
Ce couplage suppose remplies au moins toutes les conditions suivantes:
superposition des espaces et des temps des deux modèles
lecture des valeurs d'une variable d'intérêt du modèle continu par le modèle gem-graph au moyen d'une condition spécifique
écriture dans le modèle continu des modifications effectuées par le modèle gem-graph au moyen d'une action ('assignment') spécifique
A la date de création de cette issue (nov 2021), cette technique n'a jamais été testée.
--------------------------
Le client gem-graph devrait fournir des outils facilitant l'addition de modèles.
L'addition de modèles est une propriété importante de gem-graph.
Elle permet à des concepteurs ayant produit indépendamment des modèles partiels d'un même phénomènes global de vérifier la compatibilité de leurs modèles.
Pour additionner deux modèles, il faut additionner
(1) leurs états
(2) leurs transitions
Le client gem-graph devrait fournir des outils facilitant ces opérations.
Définir des normes de compatibilité faciliterait l'addition de modèles.
--------------------------
https://git.a-lec.org/gem-graph/gem-graph/-/blob/master/Analyse%20client-serveurs
### 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])
-----------------
https://git.a-lec.org/gem-graph/gem-graph/-/blob/master/architecture.md
Gem-graph Architecture
Le serveur est la partie dont l'exécution est rythmée par le calcul du modèle.
(Le client est la partie dont l'exécution est rythmée par l'utilisateur)
Le serveur comporte:
- 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 superviseur 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
----------------------------
--------------------------
--------------------------
Reference in New Issue View Git Blame Copy Permalink