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)