From 05ece0ef2f7038d6c5938100b71d037b35d7b922 Mon Sep 17 00:00:00 2001 From: Jean Sirmai Date: Wed, 14 Apr 2021 06:09:34 +0000 Subject: [PATCH] Delete serveur' --- Analyse 'client/serveur' | 170 --------------------------------------- 1 file changed, 170 deletions(-) delete mode 100644 Analyse 'client/serveur' diff --git a/Analyse 'client/serveur' b/Analyse 'client/serveur' deleted file mode 100644 index 22735c6..0000000 --- a/Analyse 'client/serveur' +++ /dev/null @@ -1,170 +0,0 @@ -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) -