Définir une transition interne dans un état et une transition avec condition

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 :

Code:

---

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 dans le graphe des transitions sur signaux avec conditions :
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 :calim2: ?

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.

Bonjour

Tu ne nous épargnes pas :aie: Tu peux nous donner un peu plus ce que tu a déjà fait et pas seulement ce que tu veux faire ? Le code de create(), des QState, des QSignalTransition, des diagrammes si tu en as, etc.

Pour le problème de transition réflexive, à priori, ça n'arrivera que si tu connectes un signal d'un objet à une QSignalTransition, lui même connecté à l'objet. Bref, tu n'auras ce problème que si tu codes ton graph pour avoir ce problème

Hors sujet :
- Les nom commençant par Q + majuscule sont utilisés habituellement pour les classes Qt. A éviter
- Idem pour QStates (et c'est dangereux de donner un nom pour une classe enfant aussi proche du nom du parent)
- Utilises QVector (ou vector) pour mes_etats plutôt qu'un tableau

Merci pour ta réponse.

Citation:

---

Envoyé par gbdivers

Bonjour
Tu ne nous épargnes pas :aie: Tu peux nous donner un peu plus ce que tu a déjà fait et pas seulement ce que tu veux faire ? Le code de create(), des QState, des QSignalTransition, des diagrammes si tu en as, etc.

---

C du code 'pro' mais je vais poster une situation similaire

Citation:

---

Envoyé par gbdivers

Pour le problème de transition réflexive, à priori, ça n'arrivera que si tu connectes un signal d'un objet à une QSignalTransition, lui même connecté à l'objet. Bref, tu n'auras ce problème que si tu codes ton graph pour avoir ce problème

---

Si tu entends que le QsignalTransition ne peut être utilisé pour une transition interne on est d'accord.

Hors sujet :

Citation:

---

Envoyé par gbdivers

- Les nom commençant par Q + majuscule sont utilisés habituellement pour les classes Qt. A éviter

---

J'ai peux être pas été assez précis, d'ou cette remarque.

Citation:

---

Envoyé par gbdivers

- Idem pour QStates (et c'est dangereux de donner un nom pour une classe enfant aussi proche du nom du parent)

---

Les QStates appartiennent au framework Qt.

Citation:

---

Envoyé par gbdivers

- Utilises QVector (ou vector) pour mes_etats plutôt qu'un tableau

---

[/QUOTE]
Je suis contre l'usage systématique des objets, mais je suis ouvert à la conversion lorsque c'est justifié. Comme QVector encapsule le parcours de la liste, pourquoi pas.

Citation:

---

Envoyé par bizulk

Maintenant comment définir une transition interne associée à un signal ?

---

C'est à dire ?

Citation:

---

Force est de constater que ce n'est pas la panacée de les implémenter.

---

Perso, je n'ai pas trouvé aussi difficile de les utiliser. Au contraire.

Citation:

---

Mais je commence à trouver la QStateMachine pas encore mature par rapport à la norme SCXML / UML

---

Normalement les QState sont basé sur la norme SCXML. Il y avait un projet qui permettais d'utiliser un fichier SCXML pour initialiser la state machine.
http://labs.qt.nokia.com/2009/08/10/...ine-framework/

Citation:

---

SubClasser QState pour définir le slot et le connecter au signal de QMetier.

---

Ce de QState ne te suffit pas?

Citation:

---

Je me demande alors si l'émission du signal sera bien filtrée si l'état n'est pas actif.

---

Comment cela?

Citation:

---

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é ? ...

---

Normalement ca passe par l'eventloop de Qt donc cela s'empile.

En générale je fait :
* connect sur un QState sur les signaux entered() et exited ()
* sous classe QAbstractTransition et je poste des events à moi dans la statemachine.
* Pour hériter de QSignalTransition, regarde la doc : http://qt.developpez.com/doc/latest/...ransition.html

Ca dépend de ce que tu veux faire.

Pour exécuter des tâches lors d'une transition, j'utilise maintenant une lambda dans un std::function. Mais ca dépend du compilateur que tu utilise (VC2100 et gccc 4.5 et sup)

Bonjour,

Les transitions internes sont décrites ici :
cours uml

Mes premiers essais ont été concluants mais je n'avais pas essayé l'implémentation de ces mécanismes.

L'utilisation du fichier scxml est encore à l'état expérimental, bien que cela prouve déjà la compatibilité.

"SubClasser QState ..." : je cherche un moyen de créer une transition interne.

Citation:

---

* connect sur un QState sur les signaux entered() et exited ()

---

Idem.

Citation:

---

* sous classe QAbstractTransition et je poste des events à moi dans la statemachine.

---

Si je fais cela je risque d'exécuter le code associé à entry/ & exit/ or c'est ce que je cherche à éviter.

Citation:

---

Envoyé par bizulk

Si je fais cela je risque d'exécuter le code associé à entry/ & exit/ or c'est ce que je cherche à éviter.

---

Faut mieux faire l'un ou l'autre mais pas les deux. Ca dépend de ce que tu veux faire.
J'avoue je n'ai pas compris ce qui te pose problème.

http://qt.developpez.com/doc/latest/...rgetstate-prop

Citation:

---

If a transition has no target state, the transition may still be triggered, but this will not cause the state machine's configuration to change (i.e. the current state will not be exited and re-entered).

---

Cela répond il à ta question ?

Merci c'est une ligne que j'avais zappée,
En fait c'est comme une patte flottante ... :lol:
Je vais tester ainsi :
Je code un QsignalStransition sans état cible,
Sur le signal triggered () j'écris une trace (mais ça devrait fonctionner d'après la
description).

J'enverrai un code source pour le résultat.

Bon malheureusement une transition sans état cible, ça ne fonctionne pas,
J'ai une assertion qui m'indique que la transition n'a pas été crée.
Ci-joint le code, de test (vite fait ;))

note : pour faire avancer le test, j'ai simplement utilisé un timer. Noter aussi que je lance la statemachine après l'initialisation de la boucle principale par ce biais.

Voici le code que j'utilise

Code:

---

1 2 3 4 5 6 7 8 9

// Transition sans état cible, trig lors de l'émission de oneSignal par l'objet signalSender QAbstractTransition* tr = new QSignalTransition(signalSender, SIGNAL(oneSignal()));   // Ajout de la transition à un état state1->addTransition(tr);   // On peut alors connecter le signal triggered de la transition à ce qu'on veut connect(tr, SIGNAL(triggered()), anotherObject, SLOT(oneSlot()));

---

Bonjour,

Tu as raison ça fonctionne ! :lol:
C'est dingue, je viens de remarquer que la signature de

Code:

---

QSignalTransition QState::addTransition()

---

ne définit par de cible NULL par défaut, ...

Bon le code fonctionne dans ce cas, je le poste pour la posterité :lol:
Je mets ce fil comme résolu, merci à vous.

Si je comprend bien,
lorsque l'on utilise une transition sans état finale, la statemachine applique le teste de la transition mais reste dans l’état courant sans en sortir et y re entrer?

Et faite je pensais que l'on devais toujours donner un etat finale et pour rester dans un même état, je donnais cette état en état finale

Code:

---

state->addTransition(new QSignalTransition (... , ... state));

---

Et normalement il sort de l'état pour y revenir.

Oui c'est bien cela, si tu donnes l'état final, il sort et re-rentre mais si tu ne le donnes pas, il teste la transition sans sortir ni re-rentrer mais en restant quand même dans le même état forcément.

Citation:

---

Envoyé par ness522

Oui c'est bien cela, si tu donnes l'état final, il sort et re-rentre mais si tu ne le donnes pas, il teste la transition sans sortir ni re-rentrer mais en restant quand même dans le même état forcément.

---

Intéressant.
:merci:

Plutôt que "état final" on devrait parler "d'état cible".
Dans un modèle une telle transition est une transition interne,
Elle est représentée dans l'état au même titre que entry/ & exit/, qui sont eux aussi des transitions internes.
Lorsqu'une telle transition est exécutée, les évenements entry et exit ne sont pas générés, à contrario d'une transition réflexive.

Dans Qt, cela prend forme avec un objet QAbstractTransition sans état cible.

Exemple d'application :
Demande de saisie d'entrée de stock.
On crée l'état 'saisie' avec :

Code:

---

1 2 3

entry / afficher et initialiser formulaire exit / maj base de données touche F1 / Afficher Aide Saisie

---

'touche F1'/ est une transition interne associé à l'évènement 'pression sur la touche F1'. Sur cet évènement il ne faut surtout pas sortir de l'état et mettre à jour la base de données, d'ou ce choix.