Parlons Arduino > Modélisation, Architectures logicielles et matérielles

Machine à états

<< < (3/5) > >>

Dominique:
Bonjour à tous,

J'avoue découvrir l'UML !
J'ai trouvé ce cours très intéressant sur les différentes phases de conception qui se termine sur une synthèse :

http://laurent-audibert.developpez.com/Cours-UML/?page=mise-en-oeuvre-uml

avec un schéma global joint.

L' application à notre domaine de Marc-Henri est très interessante.
J'en profite pour essayer de l'appliquer à la "mise en mouvement" de la modélisation de mon réseau.

A suivre ...

Merci de m'avoir conduit vers ce savoir  :D

Bien cordialement
Dominique

jac56:
Je suis heureux que cela vous semble utile.

C'est étonnant comme ce formalisme relativement simple fonctionne bien.
Le cœur de la modélisation suffit : graphe entre états qui décrit avec une précision diabolique quels événements (et eux seuls) permettent de 'transiter' d'un état à un autre, et avec quel effet.
Chaque 'case' du 'switch case' concerne un état. Le code à l'intérieur de chaque 'case' est, en général, une forêt d'if(); if (tel_événement == vrai) alors {}; seuls les événements permettant une transition sont représentés; les autres sont ignorés: l'état reste inchangé.

Personnellement, je ne saurais plus m'en passer pour aborder ce genre de problèmes.
J'ai découvert cette approche professionnellement, il y a bien longtemps (années 80...), alors que j'étais (bien jeune et)  en train de me noyer dans un problème de ce type abordé, par ignorance, sans une méthode suffisamment rigoureuse et efficace. C'était une analyse de signal assez complexe (du style: 'interprêter un électrocardiogramme', mais dans un domaine technique très industriel). Je m'en suis toujours souvenu, même si ensuite j'ai abandonné ce terrain de jeu. C'était l'époque bénie où les consultants des sociétés de service en informatique vous aidaient réellement à trouver rapidement des solutions très concrètes à vos soucis.

Dans quelques exemples traités pour le modélisme ferroviaire, sans l'usage de diagrammes états-transitions, je pense que je ne serais pas parvenu au but.
Exemple avec l'enchaînement d'opérations nécessaire pour régler les courses des aiguillages (4 points par aiguillage) de mon petit TCO. Il faut pouvoir revenir en arrière en cas d'erreur de manipulation, à tous les stades, tout en gérant minutieusement les messages à l'écran pour ne pas perdre le fil de là où l'on est (c'est très vite fait!), et en parvenant au résultat, in fine.
La combinatoire devient vite énorme. J'étais parti avec l'idée de laisser beaucoup trop de latitude à l'utilisateur, comme par exemple, lui laisser choisir le sens de parcours des points. Parfaitement superflu et surtout dangereux, car foisonnant. Les premières esquisses sur papier m'ont permis de voir qu'il fallait davantage canaliser l'opérateur, tout en ajoutant la faculté de retours-arrière, bien encadrés, et pas tous pressentis au départ. Et je pourrais multiplier les exemples dans le domaine Locoduino.

Il ne faut surtout pas alourdir la modélisation : sa légèreté fait sa force, car elle garantit la rapidité et l'exhaustivité de l'exploration du 'terrain'.

L' 'expérience de pensée' n'est pas difficile, et elle est, de toutes façons, incontournable.
Étant dans tel état, quel événement vais-je autoriser, et s'il arrive, vers quel état va-t-il me conduire?
Quel événement veux-je (dois-je) ignorer dans tel état?
Compte tenu des opérations à faire, pourrais-je raisonnablement atteindre l'état que je vise en un seule étape? Dois-je me ménager une étape intermédiaire, une voie de repli? etc...
Qu'est ce qui caractérise ce nouvel état atteint (en terme de variables d'état)?
Faute de graves déboires futurs, il est inévitable d'agiter toutes ces questions en amont du codage.
La démarche de pensée reste assez naturelle.

Pour illustrer ces propos, voilà ce que ça peut donner :
http://www.forum-train.fr/forum/viewtopic.php?f=16&t=14445

Dominique y reconnaîtra la toile de fond de certains échanges que nous avons eu naguère.

Bien cordialement et à votre disposition sur tel ou tel sujet, dans la limite de ce que j'ai compris.

DDEFF:
Je vais vous paraître prétentieux, mais SGDD a été fait de tête, sans machine d'état (je ne savais même pas ce que c'était) et pratiquement sans notes.

Certes, je connais bien le sujet de la commande des trains depuis des années et, même si je pars d'un écran blanc, je sais où je vais.
Je pars d'un problème simple que je résous, puis je le mets dans une boucle pour qu'il s'applique à tout le réseau. Etc.

Par exemple, la commande des signaux se fait en seulement 100 lignes (Block.cpp, lignes 142 à 241) quelle que soit la taille du réseau.
J'ai 100 aiguilles et 155 cantons car j'ai pris un byte.
Mais si j'avais pris un interger, le programme n'aurait pas une ligne de plus.

Le vrai problème, c'est de définir le vrai canton suivant, qui dépend de la position des aiguilles.
C'est ça qui m'a obligé à  traiter des itinéraires.

Mon programme aurait certainement été meilleur avec une machine à états.
Mais c'est surtout la façon d'appréhender le problème au départ qui différencie deux programmes.

petitrain:
Bonjour à tous,
Je lis avec intérêt vos échanges, même si je ne comprends pas toujours tout. Je suis un menuisier à la retraite,
aimant bien les petits trains mais très limité en programmation et en anglais...
J'ai découvert la plateforme Arduino depuis quelques temps déjà et, comme tous les néophytes, on commence par recopier des petits programmes à droite et à gauche, émerveillé que cela marche...puis on a envie d'écrire ses propres sketches.... Par manque d'expérience et de méthode, on est souvent déçu et même découragé.
Aussi quand je vous ai lu, j'ai cherché du côté des machines à état, évoquées sur plusieurs sites. J'ai découvert que le Grafcet est une des méthodes d'approche pour écrire un programme clair et je suis tombé sur ce site:
http://www.electronics-micros.com/software-hardware/plclib-arduino/
Il propose une bibliothèque Arduino, très bien documentée pour transformer un Arduino  en un automate programmable (PLC). On nous explique que l'on peut facilement retranscrire un Grafcet , mais aussi écrire du code supplémentaire qui ne serai pas pris par la bibliothèque. Depuis quelques temps, j'écris des petits Grafcets que je transpose en code et ça marche!... La vision que l'on a du code à écrire s’éclaircit beaucoup et c'est un grand bonheur à concevoir. Allez faire un tour sur ce site, il me semble intéressant pour les petits trains.

Dominique:
Bonjour Petitrain,

Merci pour ce lien. Je viens de jeter un coup d'oeil et je suis un peu déçu car je trouve que c'est une manière de contourner le langage C et C++ de l'IDE Arduino en lui substituant un langage différent. En faisant le tour des pages, je trouve même que ce PLC est moins riche que ce que l'Arduino offre en standard, avec les multiples apports des développeurs et la richesse des bibliothèques disponibles.

Je ne veux pourtant pas décevoir car je suis passé rapidement sur le site. J'ai bien vu à la fin que c'est en cours de développement et que des extensions sont à venir.

Mais je trouve simplement dommage de s'éloigner du langage C et C++ de l' Arduino, dont on trouve facilement des tonnes de tutos, pour se lancer dans un nouveau langage : c'est une source de confusion.

Par contre les approches UML, pour l'analyse des situations à résoudre est un bon investissement. La programmation ensuite peut rester classique.

Mais j'ai peut-être mal compris ...

Cordialement
Et joyeux Noël

Navigation

[0] Index des messages

[#] Page suivante

[*] Page précédente