89 lines
5.4 KiB
Plaintext
89 lines
5.4 KiB
Plaintext
|
Les outils nécessaires à la fabrication du client ayant été définis, il est temps de concevoir sa structure logique.
|
||
|
|
Il me semble que, plutôt que de définir cette structure en rédigeant d'emblée des tickets (issues), il serait bien d'en discuter.
|
||
|
|
|
||
|
|
Que me dit mon expérience d'utilisateur ?
|
||
|
|
|
||
|
|
Tout d'abord, que le client va et vient entre deux principaux états:
|
||
|
|
- soit il sert à calculer (à "faire tourner") un modèle
|
||
|
|
- soit il sert à l'éditer (éditer ses états et/ou ses transitions) - NB un modèle est un automate.
|
||
|
|
|
||
|
|
Mais le client est aussi un outil de présentation (éventuellement d'apprentissage) car il est indispensable de passer par lui pour montrer l'exécution ou le résultat d'un calcul.
|
||
|
|
Pour autant, le client n'a pas vocation à fabriquer les images utilisées lors d'une présentation. Il serait seulement bon qu'il puisse faire défiler ces images en incluant ici ou là un lien (un bouton) et une vue de ce que fait le modèle. Cette fonctionnalité servirait grandement le présentateur en lui évitant des va et vient périlleux en cours d'exposé.
|
||
|
|
|
||
|
|
Il y a donc, dans la description la plus simple, trois états possibles du client: calcul (C), édition (E) et présentation (P).
|
||
|
|
|
||
|
|
Je vais, maintenant, nuancer un peu les choses et entrer dans le détail.
|
||
|
|
|
||
|
|
Pourquoi séparer calcul et édition ? Que faut-il impérativement interdire ? Que peut-on (ou doit-on) laisser libre ?
|
||
|
|
|
||
|
|
Il est évident que modifier les états et/ou les transitions d'un modèle en cours d'exécution est une atteinte à l'identité même du modèle. Le modèle d'arrivée n'est plus celui de départ. Aucune conclusion n'est plus possible sur ce que fait le premier.
|
||
|
|
|
||
|
|
Aucune ?... Hummm ?... Non. Non, bien sûr ! Et le domaine des modèles capables de s'auto-transformer est certainement bien plus riche que celui auquel je propose de nous limiter dans un premier temps. Mais rien de ce que nous allons faire n'excluera la possibilité de l'explorer ultérieurement.
|
||
|
|
|
||
|
|
Alors, dans le cas des modèles 'simples', l'utilisateur doit-il toujours attendre la fin d'un calcul pour éditer et la fin d'une édition pour calculer ? Ma réponse est: OUI !
|
||
|
|
Mais il peut, en attendant, éditer ce qui n'est pas utilisé par le calcul:
|
||
|
|
- une nouvelle règle qui ne fait pas partie du pool des règles 'actives'
|
||
|
|
- la structure d'un objet ou d'une classe d'objets, etc...
|
||
|
|
Ainsi, dès qu'il aura le résultat du calcul en cours, il pourra inclure ce qu'il vient d'éditer dans l'automate et relancer un nouveau calcul.
|
||
|
|
|
||
|
|
Il faut donc définir un état d'édition restreinte dans lequel, l'utilisateur peut continuer sa réflexion et son travail sans perturber le calcul en cours et un état d'édition libre durant lequel aucun calcul n'est possible.
|
||
|
|
|
||
|
|
Et du côté présentation ? Eh bien, on peut simplifier dans un premier temps: aucune édition, jamais.
|
||
|
|
|
||
|
|
Mais,... il est parfois bien convaincant, en cours de présentation, notamment des présentations méthodologiques ou destinées à promouvoir Gem-graph, de montrer comment se font les éditions et comment on élabore, pas à pas, un modèle. C'est ce qui met le mieux en valeur la puissance de l'outil.
|
||
|
|
Est-ce difficile à réaliser ? Oui, un peu, car il faut que le logiciel soit très stable à ces moments là. Il faut donc des restrictions plus fortes que dans le cas précédent.
|
||
|
|
|
||
|
|
Si je résume, J'ai décrit 7 états possibles du client.
|
||
|
|
Pour les nommer, je propose d'utiliser les lettres:
|
||
|
|
- C pour Calcul (pour éviter une confusion, dans les schémas, avec le 'E' de Exécution
|
||
|
|
- E pour Édition, et
|
||
|
|
- P pour Présentation
|
||
|
|
et d'associer à ces lettres, lorsque cela est pertinent, une deuxième lettre ou un chiffre:
|
||
|
|
- R pour Restreinte (c'est toujours l'édition qui est restreinte) ou
|
||
|
|
- F pour libre (Free)
|
||
|
|
- 0 pour arrêté (le calcul est prêt à être lancé ou a été interrompu)
|
||
|
|
- 1 pour actif: le calcul est en cours
|
||
|
|
|
||
|
|
Les 7 états possibles sont donc:
|
||
|
|
- C0 un modèle est chargé, prêt à être exécuté.
|
||
|
|
- C1 un modèle est en cours d'exécution. Il n'y a pas d'édition en parallèle.
|
||
|
|
- RE un modèle est en cours d'exécution et une édition restreinte est en cours, en parallèle.
|
||
|
|
- FE un modèle est chargé, en cours d'édition. Il ne peut être lancé tel quel.
|
||
|
|
- P0 une présentation est en cours. Un modèle est prêt à être montré si besoin. Il est à l'arrêt.
|
||
|
|
- P1 une présentation est en cours. Elle montre un modèle en cours d'exécution.
|
||
|
|
- PE une présentation est en cours. Elle montre un modèle en cours d'édition.
|
||
|
|
|
||
|
|
L'entrée (le démarrage de Gem-graph) se fait toujours vers C0
|
||
|
|
La sortie est possible à partir de n'importe quel état.
|
||
|
|
|
||
|
|
J'ai compté 15 transitions possibles. Soit 6 x 2 (réversibles) + 3 irréversibles.
|
||
|
|
|
||
|
|
Les 3 irréversibles:
|
||
|
|
C0 > P0
|
||
|
|
RE > C0
|
||
|
|
RE > FE
|
||
|
|
|
||
|
|
les 6 x 2 réversibles:
|
||
|
|
C0 <> C1
|
||
|
|
C0 <> FE
|
||
|
|
C1 <> RE
|
||
|
|
P0 <> P1
|
||
|
|
P1 <> PE
|
||
|
|
P0 <> PE
|
||
|
|
|
||
|
|
Avant d'aller plus loin, je crois qu'il faut que nous nous mettions d'accord sur ce graphe de départ (ou un autre). Ensuite, il faudra déterminer quelles vues peuvent être ouvertes à partir de chaque état. Mais si le graphe central est bien défini, ce sera 'relativement' facile.
|
||
|
|
|
||
|
|
-----
|
||
|
|
|
||
|
|
Dans la version 1.0.0, seuls 5 états sont implémentés: C0, C1, FE, P0 et P1
|
||
|
|
et 7 transitions seulement sont possibles: 3 x 2 (réversibles) + 1 irréversible.
|
||
|
|
|
||
|
|
L'irréversible:
|
||
|
|
C0 > P0
|
||
|
|
|
||
|
|
les 3 x 2 réversibles:
|
||
|
|
C0 <> C1
|
||
|
|
C0 <> FE
|
||
|
|
P0 <> P1
|
||
|
|
|