Architecture du logiciel.

22 décembre 2013

Architecture, un bien grand mot !

Pourtant il convient assez bien car construire un logiciel c'est d'abord réfléchir au partage des tâches entre différents sous ensemble.

Sans quoi cela devient vite un grand bazard indéchiffrable et impossible à mettre au point comme à faire évoluer.

Nous avons vu la fonction d'affichage sur le panneau de la gare, cette fonction est en fait terminée, je l'ai localisée dans une fenêtre qui supporte les afficheurs mais qui supporte aussi d'un façon cachée, en fait dans un onglet, les listes des paramètres à afficher.

Ces listes sont issues des scripts que nous venons de voir, elles constituent le tri entre les départs et les arrivées, elles sont affichées directement sur le panneau d'affichage.

Cette fenêtre (Form au sens VB) supporte tous les éléments d'affichage ainsi que tout le code permettant de gérer l'affichage.

Même si cela semble important, c'est un élément relativement accessoire du logiciel et en terme d'architecture il est isolé.

Nous avons aussi vu la fonction de pilotage qui est la première brique fonctionnelle permettant de faire "bouger" des trains en mode manuel.

Reste à lier tout cela par un "Moteur" qui va lire le script et en déduire les commandes à appliquer sur les voies afin de réaliser l'animation. C'est là que ça devient intéressant !

Je vais donc avoir une fonction qui analyse les scripts, et :

Fait démarrer les trains.
Commande les annonces à envoyer.
Analyse la nécessité de ralentir en vue d'un arrêt.
Fait s'arrêter les trains (en gare ou au garage).

Cette fonction est ma fonction "Moteur".

A cette fonction s'ajoute la fonction qui calcule la commande des trains en fonction de la décision du "Moteur", cette dernière apporte en plus la protection entre convois qui se suivent.

Tout cela commence à s'emboiter correctement mais il n'est pas réaliste de croire pouvoir tester une telle usine à gaz sur le réseau réel. Aussi j'ai décidé d'ajouter une fonction "Simulation" qui va me permettre d'avancer dans le test du logiciel sans avoir le réseau réel.

Cette fonction va faire avancer les trains d'une façon virtuelle en fonction des commandes électriques émises par la fonction Moteur.

Nous aurons quelque chose comme ceci.

Sur l'image précédente on voit que le simulateur doit faire exactement ce que devrait faire le réseau, c'est à dire avancer les trains d'une façon réaliste en fonction de la commande électrique puis activer les capteurs en fonction de la position atteinte par les trains.

C'est pourquoi depuis le début j'ai prévu de connaitre la vitesse réelle des trains ainsi que la longueur réelle des cantons. Cela me permet de calculer l'avancement réel des trains ou du moins un avancement réaliste de nature à tester effectivement le logiciel.

Au final j'ai dans mon projet :

Form1 qui est la fenêtre affichage.
Moteur comme nous avons vu juste avant.
initMoteur, un module qui permet de mettre à part toutes les tables de description de la voies, des capteurs et des convois.
Pilot, la fenêtre de pilotage.
Script, la fenêtre d'édition des scripts.
Simu, la fonction de simulation discutée ci avant.
Son, un module à part pour gérer les sons.
Train, une petite fenêtre de présentation des différents convois disponibles.
Enfin "util" un foure tout de petits bouts de code utilitaires.