Parlons Arduino > Modélisation, Architectures logicielles et matérielles
Modélisation logicielle d'un réseau - le système de Denis
DDEFF:
Bonjour,
Je vais commencer par un état des forces en présence. L'ordre n'a aucune importance.
- Pierre59 (Pierre) a fait un article http://www.locoduino.org/spip.php?article154
On a là une programmation à base d'objets et utilisation intensive des héritages qui permet une description d'un réseau, côté aiguilles, zones, ...
- Pierre a fait un autre article http://www.locoduino.org/spip.php?article167 qui, cette fois traite des signaux.
Toujours des objets et des héritages qui permettent la gestion complète de la partie signaux.
- Jean-Luc a, lui, porté son attention sur la gestion des itinéraires http://forum.locoduino.org/index.php?topic=167.0 en partant de ma gare et en étendant à tout un réseau. Là encore, les objets et les héritages et un résultat impressionnant.
- Et, évidemment, toujours de Jean-Luc, les articles sur les gares cachées :
http://www.locoduino.org/spip.php?article155
http://www.locoduino.org/spip.php?article156
http://www.locoduino.org/spip.php?article157
- Pour mémoire, je fais un peu pâle figure avec SGDD qui est bien à base d'objets, mais où je n'avais pas compris la notion d'héritage. Et d'autres choses, d'ailleurs. :P
Pourtant, toutes ces méthodes (y compris la mienne) souffrent d'une tare originelle : il faut "mettre les mains dans le cambouis" et décrire le réseau "en dur", directement dans le programme. :o
Cela est, certes, bien expliqué dans les articles cités, mais, à chaque fois, il s'agit d'une méthode de description nouvelle.
On part d'un objet originel, avec des fonctionnalités parfaitement adaptées à l'objectif à atteindre.
Et d'héritage en héritage, on arrive à ce qu'on voulait. Par des méthodes tout à fait géniales, d'ailleurs.
A moins que je n'aie pas compris, il faut décrire plusieurs fois le réseau en fonction des résultats à atteindre. Ce qui est dommage. :(
D'autre part, cette description se fait directement dans le programme, ce qui n'est pas évident. :(
Ce qu'il faudrait c'est "un anneau pour les gouverner tous", selon la formule consacrée.
Je ne suis certes pas Sauron (c'est le méchant 8)) et je n'y arriverais pas tout seul. Mais je pense avoir une piste.
Je suis parti sur autre chose : un TCO sur écran, gratuit et sans fils.
J'ai fait une première version, en mode objet, mais sans héritages. Et, donc, très dure à développer.
Pierre a eu pitié de moi et m'a fourni une solution presque "clés en mains", avec le bon objet de départ et les héritages nécessaires. Et là, j'ai (enfin !) compris comment ça marchait. Un grand merci.
Il était temps qu'on me "décolle la pulpe du fond"… ;)
La V2 était donc nettement plus facile à développer, beaucoup plus souple et ceux qui ont vu le résultat ont l'air d'avoir apprécié.
Ces deux versions étaient compatibles avec SGDD. On pouvait suivre le déplacement d'un train géré par un Arduino DUE sur l'écran de l'ordinateur, PC ou Mac.
Et je développe en ce moment la V3 qui ne sera plus compatible SGDD pour plusieurs raisons :
1°) programmation SGDD lourde et "datée"
2°) j'ai voulu adjoindre à l'éditeur de TCO un embryon d'exploitation de réseau
Donc, avec mon éditeur de TCO, je fais (forcément) une description du réseau, à minima graphique.
L'intérêt d'un éditeur étant qu'on ne va pas écrire directement dans le programme. Cela résout l'un des problèmes cités.
Mais on peut plus !
Je suis en train de développer la V3 pour qu'à la fin on ait une matrice qui décrit tous les liens des cantons/aiguilles. Une description littérale, cette fois, du réseau et des connections des éléments entre eux. Description automatique, uniquement générée à partir des éléments graphiques de mon éditeur.
Il me reste à trouver le moyen que cette description soit compatible avec tous les objets dont on aura besoin pour la gestion du réseau.
Dit autrement, je cherche à ce que toutes les instanciations des classes soient paramétrées et qu'elles aillent chercher ces paramètres dans cette matrice. ???
Évidemment, pour l'instant, cette matrice sera sommaire, mais susceptibles d'évolution pour intégrer de nouveaux objets pour gérer le réseau.
Mais c'est une autre histoire…
Dominique:
Bravo Denis,
J'approuve ta recherche de ce but qui est la configuration graphique interactive du réseau, stade ultime et évidemment compliqué.
Ce serait pouvoir se passer, enfin, d'un logiciel du commerce pour lequel il faut quand même passer du temps à son apprentissage.
Je réagis juste un peu sur ce que tu affirmes qu'il faut décrire plusieurs fois le réseau avec les 3 propositions de gestionnaire dont Locoduino à probablement l'exclusivité : je montre bien dans le fil du Forum consacré à la solution de Pierre que le réseau est décrit, pour les zones et aiguilles, dans une seule série de méthodes particulières du type "zone suivante paire et impaire" et une autre pour les signaux. C'est facile à organiser dans le code, avec les onglets, pour le rendre fiable et clair.
J'ai hâte de lire la suite
Amicalement
Dominique
DDEFF:
Tout d'abord, les méthodes proposées par Pierre, Jean-Luc (et même UAD de Thierry) sont tout à fait géniales.
Pour moi, ça ne fait aucun doute et j'aimerais bien les utiliser.
Elles sont même (assez) simples d'emploi pour celui qui a une bonne maîtrise des objets avec tout ce que ça implique. OK. ;)
Ma problématique, c'est que les instanciations sont littéralement dans le programme. :(
Je vais donner un cas hyper simple : un rond avec 3 cantons.
Quand mon programme de TCO sera fini, j'aurais une matrice block[3], calculée sans intervention autre que dessiner à l'écran :
precedent, courant, suivant
3 1 2
1 2 3
2 3 1
Ce que je veux, c'est que c'est que toute la partie d'instanciation "suivant pair" et "suivant impair" n'aient pas à être écrite dans le programme. Pas littéralement.
Pour décrire le réseau, une instanciation du genre :
--- Code: ---for (int i = 0; i < 3; i++) {
suivant_pair[i] = block[i].suivant();
suivant_impair[i] = block[i].precedent();
}
--- Fin du code ---
Ce que j'ai écrit n'a aucun sens et n'est pas syntaxiquement correct. Mais j'espère qu'on y saisit l'idée.
Je n'ai aucune notion de la vraie syntaxe, ni même si c'est possible. :o
Dominique:
Je suis un peu comme toi Denis, certain qu'il existe des outils pour convertir le résultat d'une IHM graphique en programme, soit en passant par un traducteur de tableau (ça peut s'appeler un compilateur), soit en générant du code à partir de Macros paramètrées à partir du tableau ou de l'IHM directement. Il doit bien y avoir d'autres méthodes encore.
C'est ce que font JMRI, RocRail et TrainControler.
Les 2 premiers sont en open source donc on peut regarder dans leur code comment il font (tâche certainement très fastidieuse) !
Attention, en réalisant l'IHM interactive que tu veux faire, il est probable qu'il faille avoir une idée précise de la conversion en code qui doit suivre.
Mais nos experts sauront mieux que moi t'expliquer ...
Sujet très intressant ::)
DDEFF:
Pour info, j'avais des zones "floues" dans TCO V1 et V2, spécialement dans la numérotation des cantons.
"Flou", en informatique, c'est être assis sur une bombe à retardement...
J'ai repris complètement cette partie qui est maintenant fiable. Mais quel boulot! :P
Et comme je passe d'un TCO purement graphique à un TCO qui prépare un gestionnaire, il était fondamental que la numérotation des cantons soit fiable...
Les infos liées aux cantons et aiguilles ont considérablement évolué. Et, là aussi, je veux qu'elles soient adaptées à tous les programmes à venir.
Toujours l'unicité.
Et, donc, ça avance. ;D
Navigation
[#] Page suivante
Utiliser la version classique