UI : cycle de vie d'un modèle et définition de l'automate du client gem-graph. #10

New Issue

Closed

opened 2023-10-16 15:05:02 +02:00 by neox · 0 comments

neox commented

2023-10-16 15:05:02 +02:00

Owner

Quel est le cycle de vie prévisible d'un d'un modèle gem-graph ?
Quels états du client gem-graph et transitions entre ces états peut-on prévoir ?

Cycle de vie d'un d'un modèle gem-graph.

L'utilisateur veut tester une hypothèse sur un système complexe qu'il observe.

Il définit un état initial de ce système, un état final, des objets et des interactions.

Le premier objectif est de voir si l'ensemble d'interactions défini produit bien l'état final prévu en partant de l'état initial.

Si cet objectif est atteint, de nouveaux objets et/ou de nouvelles interactions pourront être ajoutés à ce premier modèle et testés à leur tour.

Mais il se peut aussi que la fabrication du modèle remette en cause l'hypothèse initiale en montrant des phénomènes inattendus.

Dans tous les cas, l'attention du concepteur peut être tournée soit vers la fabrication du modèle soit vers sa validation (l'étude de sa capacité à rendre compte des phénomènes observés) et le client gem-graph sera configuré différemment dans les deux cas.

La fabrication d'un modèle est une succession d'essais / erreurs.

Pour réaliser les premiers essais, il suffit de définir un état initial et au moins une règle de transtion.

Deux types d'essais, au moins, peuvent être distingués selon leur durée:

des essais sont de courte durée suffisent à mettre en évidence une erreur reproductible ou une amélioration à réaliser rapidement.
des essais prolongés sont nécessaires pour tenter de repérer les erreur aléatoires.

Les erreurs aléatoires surviennent seulement à l'occasion de configurations rares et ne peuvent jamais être éliminées avec certitude. Le mieux qu'il soit possible de faire est d'observer longtemps le modèle avant d'en accroitre la complexité.

Ces erreurs sont difficiles à repérer et à reproduire.

Les outils indispensables à leur repérage sont:

l'observation sélective des objets et/ou des situations d'intérêt
les fonctions slow down, pas à pas et do/undo/redo
l'inhibition de règles ou de groupes de règles durant ces essais

Dans tous les cas, l'édition d'états et de règles doit être aussi rapide et efficace que possible pour ne pas détourner l'attention.

Ci dessous, première version de cette issue (à relire avant d'éliminer les redondances)

UI : trois types de sessions : créer, valider et étudier un modèle.

L'utilisateur qui développe un modèle peut se dire, à tout moment de son travail :

Je veux voir si mon modèle (tel état initial et de tel ensemble de règles) est stable.
Je veux juste que ce calcul soit effectué le plus rapidement (efficacement) possible : inutile de me renvoyer, pour l'instant, les copies des espaces locaux où aucune règle ne s'applique; je ne m'en servirai pas; je ne veux pas créer / éditer de nouvelle règle maintenant.

alors,

s'il n'a pas trouvé de règle qui s'applique, le worker n'a pas à faire ni à transmettre de copie de l'espace local; il peut simplement être terminé.

Si l'utilisateur se dit :

Je veux améliorer mon modèle en créant des règles pour les situations indéfinies c-à-d pour lesquelles il n'existe pas encore de règle,

alors,

s'il n'a pas trouvé de règle qui s'applique, le worker doit transmettre au superviseur (qui la transmettra au client qui la présentera à l'utilisateur, de préférence en mode "édition") une copie de l'espace local où il a travaillé avant d'être terminé.

Dans ce cas, le run peut être plus lent et de courte durée. Il a juste pour objectif de repérer certaines situations qu'il faut 'débloquer' (pour lesquelles il manque des règles)

Une fois ces règles éditées et ajoutées à l'arbre, l'utilisateur pourra souhaiter voir à nouveau si son modèle est stable.

Dans tous les cas, s'il a trouvé de règle qui s'applique, le worker doit effectuer l'ensemble des actions prescrites par cette règle puis renvoyer son identité (le [node_id] du dernier noeud-condition-feuille de la règle trouvée) avant d'être terminé.

Une session de validation a pour but d'obtenir un modèle stable d'un phénomène complexe.
Il faut avoir produit le modèle pour pouvoir l'étudier.

Une session d'étude ne s'intéresse plus aux performances du modèle ou à sa fiabilité.
(warning : les mots 'robustesse' ou 'fiabilité' peuvent être confusants)

Une session d'étude s'intéresse à la qualité du modèle confronté à la réalité :
Reproduit-il correctement ce qu'il est censé simuler ?
L'environnement fourni par le client sera différent : modules statistiques,...

Quel est le cycle de vie prévisible d'un d'un modèle gem-graph ? Quels états du client gem-graph et transitions entre ces états peut-on prévoir ? Cycle de vie d'un d'un modèle gem-graph. L'utilisateur veut tester une hypothèse sur un système complexe qu'il observe. Il définit un état initial de ce système, un état final, des objets et des interactions. Le premier objectif est de voir si l'ensemble d'interactions défini produit bien l'état final prévu en partant de l'état initial. Si cet objectif est atteint, de nouveaux objets et/ou de nouvelles interactions pourront être ajoutés à ce premier modèle et testés à leur tour. Mais il se peut aussi que la fabrication du modèle remette en cause l'hypothèse initiale en montrant des phénomènes inattendus. Dans tous les cas, l'attention du concepteur peut être tournée soit vers la fabrication du modèle soit vers sa validation (l'étude de sa capacité à rendre compte des phénomènes observés) et le client gem-graph sera configuré différemment dans les deux cas. --- La fabrication d'un modèle est une succession d'essais / erreurs. Pour réaliser les premiers essais, il suffit de définir un état initial et au moins une règle de transtion. Deux types d'essais, au moins, peuvent être distingués selon leur durée: - des essais sont de courte durée suffisent à mettre en évidence une erreur reproductible ou une amélioration à réaliser rapidement. - des essais prolongés sont nécessaires pour tenter de repérer les erreur aléatoires. --- Les erreurs aléatoires surviennent seulement à l'occasion de configurations rares et ne peuvent jamais être éliminées avec certitude. Le mieux qu'il soit possible de faire est d'observer longtemps le modèle avant d'en accroitre la complexité. Ces erreurs sont difficiles à repérer et à reproduire. Les outils indispensables à leur repérage sont: - l'observation sélective des objets et/ou des situations d'intérêt - les fonctions slow down, pas à pas et do/undo/redo - l'inhibition de règles ou de groupes de règles durant ces essais Dans tous les cas, l'édition d'états et de règles doit être aussi rapide et efficace que possible pour ne pas détourner l'attention. --- --- Ci dessous, première version de cette issue (à relire avant d'éliminer les redondances) --- UI : trois types de sessions : créer, valider et étudier un modèle. L'utilisateur qui développe un modèle peut se dire, à tout moment de son travail : - *Je veux voir si mon modèle (tel état initial et de tel ensemble de règles) est stable. Je veux juste que ce calcul soit effectué le plus rapidement (efficacement) possible : inutile de me renvoyer, pour l'instant, les copies des espaces locaux où aucune règle ne s'applique; je ne m'en servirai pas; je ne veux pas créer / éditer de nouvelle règle maintenant.* alors, s'il n'a pas trouvé de règle qui s'applique, le worker n'a pas à faire ni à transmettre de copie de l'espace local; il peut simplement être terminé. --- Si l'utilisateur se dit : - *Je veux améliorer mon modèle en créant des règles pour les situations indéfinies c-à-d pour lesquelles il n'existe pas encore de règle*, alors, s'il n'a pas trouvé de règle qui s'applique, le worker doit transmettre au superviseur (qui la transmettra au client qui la présentera à l'utilisateur, de préférence en mode "édition") une copie de l'espace local où il a travaillé avant d'être terminé. Dans ce cas, le run peut être plus lent et de courte durée. Il a juste pour objectif de repérer certaines situations qu'il faut 'débloquer' (pour lesquelles il manque des règles) Une fois ces règles éditées et ajoutées à l'arbre, l'utilisateur pourra souhaiter voir à nouveau si son modèle est stable. --- Dans tous les cas, s'il a trouvé de règle qui s'applique, le worker doit effectuer l'ensemble des actions prescrites par cette règle puis renvoyer son identité (le [node_id] du dernier noeud-condition-feuille de la règle trouvée) avant d'être terminé. --- Une session de validation a pour but d'obtenir un modèle stable d'un phénomène complexe. Il faut avoir produit le modèle pour pouvoir l'étudier. Une session d'étude ne s'intéresse plus aux performances du modèle ou à sa fiabilité. (warning : les mots 'robustesse' ou 'fiabilité' peuvent être confusants) Une session d'étude s'intéresse à la qualité du modèle confronté à la réalité : Reproduit-il correctement ce qu'il est censé simuler ? L'environnement fourni par le client sera différent : modules statistiques,...

neox added the

Rejeté

label 2023-10-16 15:05:02 +02:00

neox closed this issue

2023-10-16 15:05:02 +02:00

No Label

BUG

Contrôle

Graphics/3D