Auteur Sujet: Projet partagé d'un gestionnaire de réseau  (Lu 441296 fois)

DDEFF

  • Hero Member
  • *****
  • Messages: 823
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #495 le: avril 08, 2025, 05:06:02 pm »
Bonjour,

J'étais en vacances la semaine dernière. Je repris hier et ça donne ça comme TCO.
Pour un réseau de 137 zones, 74 moteurs d'aiguille, 14 bretelles et 17 super appareils, 92 signaux, c'est assez sympa.

Le JSON fait 2627 lignes et il est complet. Il faut l'ouvrir avec Excel.

Le fichier Zones montre toutes les infos que le programme ne peut pas deviner.
Il y a beaucoup de champs en blanc car je n'ai pas rentré les infos de longueur, de vitesse, de gare et de zones de manœuvres.

Ce qui me fait plaisir, c'est que j'ai tout rentré sans aucun arrêt du programme (je faisais quand même de temps en temps des sauvegardes...), alors que je me suis planté, qu'il a fallu supprimer des zones, les recréer, la routine, quoi. ;D

Je mettrai le programme dans un prochain post. Il y a encore des choses que j'aimerais améliorer avant.

A suivre
Denis :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 387
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #496 le: avril 08, 2025, 05:07:20 pm »
Je vais vous présenter ici la démarche habituellement uitilisée par la programmation objet. Cette démarche est indépendante du langage utilise (C++,Processing(Java)).

Quand on programme en programmation objet, il faut commencer par identifier les objets possibles.

Prenons un de ces objets, généralement il y a plusieurs variantes possibles de cet objet, cela s’appelle du polymorphisme (la programmation objet c’est de l’encapsulation, de l’héritage et du polymorphisme).

Bien évidemment il n’est pas question de traiter les variantes avec des si/sinon (if/else) en programmation objet on procède completement différemment.

On commence par écrire une classe de base ayant le nom de l’objet, cette classe peut être une classe abstraite (on ne fait généralement pas d’instance de cette classe, mais cet aspect est secondaire), cette classe sera remplie par la suite en fonction des besoins (variables et fonctions (méthodes)).

Ensuite pour chaque variante on crée une sous-classe (il faut trouver un nom en rapport avec l’objet) qui hérite de la classe base, ou d’une autre sous-classe héritant directement ou indirectement de l’objet).

Voila le schéma général d’’écriture. Maintenant il fait remplir la classe et les sous-classes.

Prenons un exemple avec les signaux SNCF. Il faut réfléchir aux actions que l’on peut faire sur un signal, c’est la partie la plus difficile du processus ( et ce n’est pas lié au fait que l’on soit en programmation objet ), faut pas chercher de complications mais plutôt de la synthèse et ne pas chercher à trouver tout tout de suite. De façon synthétique un signal on peut l’ouvrir et le fermer (indépendamment de qui l’ouvre ou le ferme), cela fait deux actions pour l’instant.

On va coder ces deux actions sous forme de fonctions (méthodes) : void ouvrir() {…} et void fermer(){…}, c’est le signal qui saura ce qu’il faut faire.

Dans le programme objet utilisant ces signaux une variable de type signal sera typée Signal et non SignalCarre, Carré, Avertissement, … Pour que cela se passe bien( à la compilation ) il faut que la classe de base Signal contienne les deux fonctions (méthodes), mais sous une forme dégradée car la classe Signal ce n’est pas un vrai signal (on ne sait pas comment l’ouvrir ni le fermer) : void ouvrir() {} et void fermer() {}.

Ecrivons une variante, la plus simple CarreViolet. On a tout d’abord besoin d’une variable pour mémoriser le feu d’un signal, une énumération du genre : enum Feu={Vl,A,S,C,Cv,M,…}; convient très bien, mais dans quelle classe il faut la mettre, elle va servir pour tous les signaux, donc il faut la mettre dans la classe de base Signal.

Les deux fonctions (méthodes) peuvent donc s’écrires : void ouvrir() { feu=M; } et void fermer() { feu=Cv; } .

On a donc pour l’instant :

Classe Signal {
   enum Feu={Vl,A,S,C,Cv,M,…};
   void ouvrir() {}
   void fermer() {}
}

Classe CareViolet hérite de Signal {
   void ouvrir() { feu=M; }
   void fermer() { feu=Cv; }
}

Bien évidemment il manque les autres variantes de signaux.

Voila la démarche standard de la programmation objet, c’est généralement toujours la même démarche.

Je vous laisse digérer cette démarche, et me poser toutes les questions nécessaires..

Cordialement

Pierre59

DDEFF

  • Hero Member
  • *****
  • Messages: 823
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #497 le: avril 08, 2025, 05:52:07 pm »
Merci Pierre.

Ce post arrive pile au bon moment : je vais pouvoir commencer le gestionnaire sur de bonnes bases.  ;)
Et quand j'aurais bien compris, je reviendrai sur le JSON.

Commençons par le signal. On a une classe Signal () {} qui a deux méthodes ouvrir () {} et fermer () {}.
Effectivement, "ouvrir un signal" n'est pas assez précis, mais il faut que la méthode existe dans l'objet Signal dont on va hériter, quitte à être vide.

"Ouvrir un signal" a deux fonctions : allumer les LED qui vont bien sur le signal et agir sur l'état du train correspondant.
J'imagine qu' "Ouvrir" fait partir le train et "Fermer" l'arrête ?
Mais on peut aussi ouvrir un ralentissement ? Ou ouvrir un avertissement ?

Je pense que oui, par référence aux signaux mécaniques.

J'imagine qu'il faut un objet Cible() {} pour indiquer comment traduire "C" en positions de LED à allumer ?

Denis  :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 387
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #498 le: avril 08, 2025, 05:58:43 pm »
Tu vas déja beaucoup trop vite, on se concentre sur le gestionnaire, le reste viendra après.

pierre

Pierre59

  • Sr. Member
  • ****
  • Messages: 387
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #499 le: avril 09, 2025, 07:30:07 am »

J’ai fait une erreur avec le carré violet, j’ai oublié de déclarer la variable feu, cette variable va servir pour tous les signaux donc il faut la mettre dans la classe de base Signal :

Classe Signal {
   enum Feu={Vl,A,S,C,Cv,M,…};
   Feu feu;
   void ouvrir() {}
   void fermer() {}
}

Classe CareViolet hérite de Signal {
   void ouvrir() { feu=M; }
   void fermer() { feu=Cv; }
}

Pierre

DDEFF

  • Hero Member
  • *****
  • Messages: 823
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #500 le: avril 09, 2025, 03:07:56 pm »
Bonjour,

Avant de me lancer dans les lignes de programme, je vais faire un cahier des charges de ce que je veux faire comme gestionnaire.

Le conducteur du train part avec sa Feuille de Route qui lui donne un but et des gares de passage (entre autres). Il y a aussi les horaires sur lesquels je ferai l’impasse.

Il faut donc un objet "Feuilles de route" qui engrange toutes les feuilles de routes actives à un moment donné.

Dans les gares, il faudra des itinéraires. Objet "Itineraire"

A noter qu’on ne choisit pas tous les itinéraires de toutes les gares entre le départ et le but avant le départ (comme je faisais dans mon ancien gestionnaire).

J’ai attendu suffisamment longtemps dans ma vie devant les panneaux d’affichage pour savoir que les itinéraires se décident "au dernier moment".

Un itinéraire est d'abord enregistré : on mémorise la voie d'entrée et la voie de sortie dans toutes les gares traversées. Quand le train sera à proximité de la gare, c'est là qu'on pourra lancer la recherche d'itinéraire pour cette gare, ce qui donnera la voie choisie dans la gare, à ce moment.

Il y a un classement des priorités des trains.

Train de voyageurs rapide (Express) ou lent (Omnibus)
Train de marchandises rapide (Régime Accéléré) ou lent (Régime Ordinaire).
On a EX > OM > RA > RO à la SNCF.
A noter qu'en Amérique, les trains de marchandise sont prioritaires sur les trains de voyageurs.

Puisqu'on parle d'itinéraires, on ne peut pas accéder à un appareil de voie donné directement.
Pas de boutons pour changer la position d'un appareil de voie sur le TCO, ni de clic sur un écran.
On doit passer par un itinéraire.

Quand l'itinéraire se forme, il modifie la position des appareils de voie (si c'est possible) et interdit aux itinéraires incompatibles de se former (c'est l'enclenchement).

Comme il y a souvent plusieurs itinéraires possibles entre un point A et un point B, il faut trouver une façon de les prioriser pour qu'un seul itinéraire soit proposé, celui qui a la plus forte priorité. Sachant aussi qu'un itinéraire d'un express passe avant celui d'un omnibus, même si l'omnibus est arrivé avant. De plus, un express passe prioritairement sur l'itinéraire le plus direct.

La priorisation ne peut pas être l'itinéraire le plus court, sinon un omnibus peut bloquer la gare. D'où le poids des appareils de voie dans le fichier "Zones"

Une fois les appareils de voie en position, on peut décider de l'affichage des feux puisqu'ils tiennent compte de la position des appareils de voie et des occupations des trains.

Une fois que les feux sont affichés, on peut lancer les trains, les faire ralentir et s'arrêter puisqu'ils obéissent aux feux.

Et on recommence au début en regardant si de nouveaux itinéraires sont possibles après le déplacement des trains.

Denis  :P
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 387
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #501 le: avril 09, 2025, 03:17:59 pm »

Décider de la circulation des trains, de leurs horaires, des priorités, de ou ils partent et ou ils vont, … c’est de la régulation (il y a des régulateurs pour cela a la SNCF), ce n’est pas du rôle du gestionnaire.

Pierre

DDEFF

  • Hero Member
  • *****
  • Messages: 823
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #502 le: avril 09, 2025, 03:24:57 pm »
Alors j'ai un problème. Il fait quoi, le gestionnaire ?

Denis
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 387
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #503 le: avril 09, 2025, 03:28:31 pm »

Le noyau du gestionnaire assure la sécurité, donc les enclenchements.

Pierre

DDEFF

  • Hero Member
  • *****
  • Messages: 823
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #504 le: avril 09, 2025, 03:37:18 pm »
Peux-tu être plus précis ? Quelques exemples ?

Denis
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 387
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #505 le: avril 09, 2025, 04:05:35 pm »

Le noyau du gestionnaire gère l’état des aiguilles, des zones, des autorisations, des signaux, des itinéraires, …
Il prends en compte les changement d’état des éléments, par exemple occupation/libération des zones.
Il accepte des demandes d’itinéraires qu’il peut établir, mais dans le respect des enclenchements, avec la manoeuvre des aiguilles et l’affichage des feux des signaux.
Et certainement encore d’autres tâches.

Pierre

DDEFF

  • Hero Member
  • *****
  • Messages: 823
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #506 le: avril 09, 2025, 04:33:01 pm »
On a donc le régulateur qui est, en quelque sorte, une "surcouche" du gestionnaire, lequel gère uniquement la sécurité et dit si telle opération est réalisable ou non.
Ai-je bien saisi ?

Denis
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 387
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #507 le: avril 09, 2025, 04:42:16 pm »
Oui

Pierre

DDEFF

  • Hero Member
  • *****
  • Messages: 823
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #508 le: avril 09, 2025, 04:54:47 pm »
Il faut déjà faire la liste de tous les objets dont on aura besoin.

Et, "accessoirement", il faut lire le fichier JSON pour affecter les bonnes informations aux bons objets.
La façon dont j'ai généré le JSON montre clairement que je n'ai pas utilisé les fonctions JSON de Processing parce que je ne les ai pas vraiment comprises.  ::)

Denis
"Ce n'est pas le puits qui est trop profond, c'est ta corde qui est trop courte" (proverbe chinois)

Pierre59

  • Sr. Member
  • ****
  • Messages: 387
    • Voir le profil
Re : Projet partagé d'un gestionnaire de réseau
« Réponse #509 le: avril 09, 2025, 05:12:54 pm »
Mon but initial était de t'habituer à la programmation vraie objet.

Mais pourqois pas aller aussi dans ce que tu propose.

Pierre