Bonjour,
J'ai modélisé un automate d'état que je construis avec la QStateMachine.
J'ai pris le parti de ne pas encapsuler le 'fonctionnel' dans les Etats (ie subclasser les QState), ou le moins possible.
J'ai donc une classe suivante :
J'ai dans le graphe des transitions sur signaux avec conditions :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9 Classe QMetier : QObject { Q_OBJECT QStateMachine machine QStates[] mes_etats Create() ; // Initialise le graphe de l'automate. .... }
J'ai suivi l'indication de l'aide en ligne : on surchage la méthode eventtest() dans la classe QSignalTransition.
Maintenant comment définir une transition interne associée à un signal ? J'en ai besoin car une transition réflexive provoque la sortie/entrée dans l'état et donc les actions associées, ce que je souhaite éviter.
Est-ce qu'il faut que je revois mon modèle pour me passer de ce mécanisme?
J'ai un petit automate avec seulement trois états, mais je voulais faire cet exercice car j'ai dans ce graphe plusieurs types de transitions/et définitions.
Force est de constater que ce n'est pas la panacée de les implémenter.
L'usage de la state machine me paraissait intéressant car j'avais un mécanisme réutilisable pour coder (un moteur, un graphe, des fonctions).
Mais je commence à trouver la QStateMachine pas encore mature par rapport à la norme SCXML / UML
Les premières idées qui me viennent sont :
Dans la classe QMetier définir une connexion signal/slot et dans ce slot vérifier l'actif en cours pour valider l'exécution.
SubClasser QState pour définir le slot et le connecter au signal de QMetier. Je me demande alors si l'émission du signal sera bien filtrée si l'état n'est pas actif. Que se passe-t-il aussi si une activité (une fonction) est en cours ? Le signal est-il perdu ou l'évènement associé empilé ? ...
Je sens que je vais basculer dans un mode d'essais.
Merci pour toute aide.
Partager