Discussion :

[mb3575]

bon alors voilà, j'ai parcouru le net sans succès pour essayer de trouver un code objet simple, permettant de décrire une machine à état finis.

est ce que quelqu'un aurait çà dans une de ses bibliothèques en C++ ?

thanks

[zais_ethael]

Je vois vaguement l'allure que ça peut prendre, mais ça n'a jamais été fort difficile d'implémenter ça avec un simple algo.
En gros tu définis une énumération avec tes états, une variable contenant l'état actuel et tu boucles sur un switch pour lequel a été défini une action par état possible.

[JolyLoic]

Il y a plein de méthodes différentes de faire ce genre de choses, chacune avec ses propres avantages.

Ca peut être une énum décrivant les états, et un gros switch selon l'état courant changeant celui ci (solution la plus rapide à mettre en oeuvre dans les cas simples, mais la plus difficile à maintenir et faire évoluer).

Ca peut être une classe de base état, et une classe dérivée par état. Dans l'interface de cette classe de base sont définies les différentes fonctions de changement détat.

Ca peut être une représentation sous forme de graphe, chaque état étant un noeud.

Ca peut être plein d'autres choses.

[loufoque]

Il me semble qu'il y avait un projet pour ça dans boost.

[mb3575]

Thanks pour vos réponses. Effectivement j'aimerai éviter un gros switch général, qui est la méthode la plus simple à mettre en oeuvre. Le projet tournant sur un PC, et n'étant pas embarqué sur un chip, j'ai plus de libertés pour régler çà par de jolies classes.

Je cherchais donc quelque chose de facilement dérivable et réutilisable en objet.

Bon au final j'ai pondu deux types de MEF :
Le premier code essaie d'être exhaustif (aux erreurs de syntaxe et constructeurs prêt) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
class State
{
public :
	int State_ID;
	bool (*ptrFnToExecuteWhenEnteringState)();
}
 
 
class Transition
{
public :
	int StateToLeave;
	int StateToGo;
	bool (*ptrTestFunction) ();
	bool (*ptrExitFnIfTransitionOK)();
}
 
 
 
class GenericStateMachine
{
public :
	GenericStateMachine();
	~GenericStateMachine();
 
	int GetCurrentState();
	bool addState(int State_ID, bool (*ptrFnToExecuteWhenEnteringState)() );
	bool addTransition(int StateToLeave, int StateToGo, 
					   bool (*ptrTestFunction) (), bool (*ptrExitFnIfTransitionOK)() );
private:
    int CurrentState;
	std::vector<State> StateVector; 
	std::vector<Transition> TransitionVector;
 
 
}

et le second a pour avantage d'être plus "visuel", puisque le tableau de transition de chaque état est en statique dans le code, et donc consultable d'un seul coup d'oeil pour vérifier comment est construite la MEF :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
class StateMachine
{
public :
	GenericStateMachine();
	~GenericStateMachine();
 
	enum State (ID_State1, ID_State2, ID_State3);
 
	std::vector< std::vector<bool (*ptrFuncTransition)()> > Transition;
	// ou son équivalent en C : ( bool (*ptrFuncTransition) () ) Transition [Max_State][Max_Transition];
 
	int GetCurrentState();
 
private :
	int CurrentState;
 
 
}
 
GenericStateMachine::GenericStateMachine ()
{
 
	new Transition = {  // Transitions de l'état ID_State1
			{ptrFuncTransition11, ptrFuncTransition12, ptrFuncTransition13},
 
			// Transitions de l'état ID_State2
			{ptrFuncTransition21, ptrFuncTransition22, ptrFuncTransition23},
 
			// Transitions de l'état ID_State3
			{ptrFuncTransition31, ptrFuncTransition32, ptrFuncTransition33},
			}
	etc...
}

cette deuxième solution a l'avantage donc d'être "statique" et de fournir une vision d'ensemble rapidement.

Hé oui, venant du monde de l'embarqué, j'aime les choses statiques qui ne font pas exploser la mémoire ;oP On ne se refait pas.

vous en pensez quoi ? aux erreurs de déclaration prêt ?

Sinon Boost permet de traduire une MEF graphique en code directement c'est çà ? c'est gratuit ?


PS : Zais, çà y est l'invasion des lapins a commencé

[JolyLoic]

A mon avis, boost ne fourni rien de graphique pour ça. Par contre, c'est gratuit. Le truc sur les FSM est récent et pas encore officiellement accepté, je ne le connais pas.

Ce que j'ai trouvé intéressant en terme graphique en terme de retour sur investissement, c'est non pas générer le code à l'aide d'un graphique (coûteux), mais générer un graphique à l'aide du code, afin de valider celui ci. Comment générer ce graphique simplement ? A l'aide de graphviz, on génère un fichier texte qui décrit un graphe, et il génère le graphique correspondant (c'est gratuit).

[mb3575]

oui exact je connaissais graphviz.

je regarderais boost alors. la conception graphique ne m'est pas utile ppour l'instant sur le projet

[mb3575]

la partie graph de Boost est trop complexe pour mon problème finalement. J e n'ai pas besoin de code en fait qui respecte la théorie des graphes, mais seulement d'une petite machine à état

donc nope, boost ne m'aidera pas sur mon sujet. Mais je le garde sous le coude pour d'autres appli

[loufoque]

Pour ceux qui ne savent pas utiliser Google :
http://boost-sandbox.sourceforge.net...doc/index.html

[Alp]

J'avais codé quelque chose, après avoir lu un "tuto" montrant une utilisation efficace du design pattern Etat.
C'est à l'évidence quelque chose dont tu peux te servir dans ton projet.
Cela mettait en scène une utilisation fine des templates. Vois si tu peux pas proposer une 3eme solution à base de Design Pattern Etat et de Templates

[mb3575]

loufoque > utilisation de google ? là n'était pas la question....

Alp : thx. n'étant pas un habitué des design patterns, j'ai fignolé mon code pour faire deux types de FSM : une "dynamique" où l'on peut ajouter à chaque instant états et transitions, et une "statique" (codée en dur) qui a l'avantage de permettre de lire la FSM directement d'un seul coup d'oeil.

Le soft étant assez séquentiel, ce développement suffit dans un premier temps. Mais du coup je vais jeter un oeil aux design patterns pour d'autres fonctionalités du logiciel, et je regarderais si une modélisatoin par réseau de Pétri ne pourrait pas solutionner quelques problèmes à côté d'ailleurs tiens.

Thanks pour vos avis à tous.