Discussion :

[Mayeu]

Bonsoir à tous

J'ai un petit programme à réaliser qui devras pouvoir envoyer et recevoir des informations par le port série.
Avant d'attaquer le code pur et dur, je me suis demandé comment les différents "modules" pourraient interagir entre eux, et j'ai dégagé "l'architecture" suivante :

- En premier lieu mon programme posséderas une interface graphique. Cette interface posséderas des boutons d'ordre, et un affichage de texte, qui afficheras l'état du logiciel/transmission de l'ordre (exemple : clic sur le bouton "avancer", on voit apparaître "Ordre avancer envoyé", réception d'un accusé après l'envoie d'un ordre "L'ordre machin à été effectué...). Le tout seras codé en suivant le Modèle Vue Contrôleur.

- Vient ensuite la lecture et l'écriture série, et la j'ai pensé réaliser 2 thread, un d'envoi (qui se charge d'envoyer les ordres, rééméttre un ordre si l'envoie à foiré etc...), et un thread de réception, qui attendras la réception d'info par le port série et se chargeras de leurs traitements.

Que pensez vous d'une telle architecture ? Vous parez t'elle lourde, optimisable ?

Merci de me donnez vos opinion

Mayeu

[gifffftane]

Cela dépend de ton protocole sur la liaison série, mais c'est pas forcément top de faire deux threads pour l'écriture et la lecture.

L'approche en couches de je ne sais plus quelle spécif (il y en 7, de mémoire) (pas 7 mémoires, 7 couches) est plus pratique. Mais ça dépend si c'est un protocole à l'arrache ou un protocole qui mérite le nom de protocole, si le dialogue est synchrone/asynchrone, etc. Et de toutes façons c'est pas obligatoire de les faire toutes les couches, c'est juste l'idée couche qui est bonne.

Et puis pense aux tests.

[Mayeu]

Alors la communication se fait en asynchrone, car le receveur des ordres ne peu pas à la fois émettre et recevoir, donc dans tout les cas seul un sens seras utilisé à la fois, pour le protocole c'est plus ou moins du "alarach" avec des ordres de taille constante (32bits, 8bits identifiant l'émetteur, 8bits d'ordre, et 16bits pour le CRC16).

Quand au double thread, en y reréfléchissant c'est en effet pas forcement le top à mon avis... Mais la je suis en train de me plonger dans la doc du package RXTX, voir comment il préconise la chose.

[vic]

Avec RXTX tu obtiens 2 flux d'entrée/sortie, donc utiliser 2 threads pour les gérer me semble tout à fait adapté. Par exemple utiliser le thread principal pour l'envoi, et un autre thread pour recevoir les messages.

Ensuite pour ce qui est du design pattern, comme l'a dit gifffftane ce qui est important c'est de bien découper ton appli en couches de traitement, de données, de présentation. Savoir si tu utilises un MVC en bonne et due forme ou pas est secondaire.