LOCODUINO
Parlons Arduino => Modélisation, Architectures logicielles et matérielles => Discussion démarrée par: Jean-Luc le avril 06, 2016, 03:06:56 pm
-
Bonjour,
Je voudrais présenter un Design Pattern, ou patron de conception : le Proxy, appliqué à un système en contrôle commande décentralisé en réseau.
En POO, les patrons de conception sont des architectures logicielles réutilisables dans de nombreux cas.
Un Proxy est une « classe qui se substitue à une autre classe » ce qui hors contexte ne veut pas dire grand chose. Prenons un exemple concret : un système de commande de réseau en DCC formé d'un Arduino gestionnaire central, d'un Arduino jouant le rôle de centrale DCC et d'Arduino pilotant des actionneurs d'aiguillage, d'autres Arduino gérant la détection de présence, etc.
Le gestionnaire central doit donc :
- envoyer des ordres aux trains (la locomotive qui le tracte) en communicant avec le calculateur DCC
- envoyer des ordres aux actionneurs d'aiguillages en envoyant des messages CAN
- recevoir la position des trains via des messages CAN
- recevoir la position des aiguillages via des messages CAN (en effet, la position effective ne correspond pas à l'ordre donné, du moins pas tout de suite)
Idéalement le gestionnaire central devrait pouvoir manipuler un train ou un aiguillage sans se soucier de la manière d'interagir, c'est la que le Proxy entre en scène.
Supposons que nous ayons une classe Train avec les méthodes fixeVitesse (fixe la vitesse du train) et position (retourne le canton où se situe le train). Le gestionnaire interagit avec les objets de cette classe, donnant, pour chacun d'entre eux, la vitesse à intervalles régulier et récupérant la position.
Supposons également que nous ayons une classe Aiguillage avec les méthodes positionneDroit et positionneDevie pour commander la position et une méthode position pour retourner la position de l'Aiguillage. De même le gestionnaire interagit avec les objets de cette classe.
Train::fixeVitesse effectue la communication avec l'Arduino DCC
La position retournée par Train::position est possiblement actualisée au gré de l'arrivée des messages CAN indiquant l'occupation des canton
Aiguillage::positionneDroit et Aiguillage::positionneDevie effectuent l'envoi d'un message CAN correspondant
La position retournée par Aiguillage::positionne est actualisée au gré de l'arrivée des messages CAN indiquant l'état des aiguillages.
Ces objets sont des proxy, ils agissent pour le compte d'objets distants mais donnent l'impression au gestionnaire central que ce sont de simples objets en mémoire.
À noté qu'ils permettent également, via le polymorphisme, de concevoir un gestionnaire indépendamment de la technologie DCC/Analogique sous jacente et indépendamment du type de carte utilisées sur le réseau.
-
En gros, c'est un concentrateur (un noeud) qui regroupe tous les échanges.
Il regroupe et mémorise les états (en sortie ou entrée) pour écrire ou lire périodiquement afin d'avoir une base à jour.
Avec, ne passe-t-on pas d'un mode asynchrone (commandes au fil du temps suivant la demande) à synchrone (à séquence régulière) ?
-
Dans l'exemple proposé c'est ça (mais ce n'est pas un concentrateur puisqu'il y a un proxy par train et un par aiguillage). Mais le proxy peut être employés différemment, par exemple on pourrait avoir une simple copie locale d'un objet C++ distant. La communication n'est pas non plus forcément synchronisée sur une horloge, elle peut être événementielle.
C'est surtout le fait de masquer les détails de l'interaction avec un ou plusieurs autres objets (distant, locaux, correspondant à des objets concrets ou pas) par un objet qui fait l'intermédiaire.
-
"Bizarrement", ça correspond exactement à ce que nombreuses personnes sont en train d'expérimenter. ;)
ça alors !! ;D ;D ;D
Mais c'est génial, ce truc !
On en a l'eau à la bouche.
-
Denis a raison ;)
J'ai bien un gestionnaire qui manipule tous les types d'objets du réseau (aiguilles, zones, trains, signaux, accessoires,...). Certaines méthodes des objets envoient des messages CAN à un carte actionneur (aiguilles, traction, ..). D'autres cartes détecteurs envoient des messages CAN d'événement (occupations, traction, boutons TCO,...). Certaines cartes sont donc actionneur ET
détecteur.
Les échanges de messages CAN réalisent en quelque sorte une synchronisation entre l'état des objets du gestionnaire central ( les proxys?) et les objets sur le réseau, dans les cartes.
Jusque là, je ne vois pas ce que ça change d'appeler ça "proxy" :o
-
C'est juste parce que ce que tu décris ce n'est pas un proxy :)
-
Ah, alors ça devient intéressant : hâte de lire la suite 8)