UTCoupe

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Architecture logicielle 2017 ======

(cette page est un transfert du [[https://github.com/utcoupe/coupe17/wiki|wiki coupe 17 sur Github]]

===== Généralités =====

L'architecture est centrée autour d'un serveur. Sans serveur, aucun module ne peut fonctionner correctement (ils ne sont prévus que pour se connecter à un serveur).

Chaque module respecte une règle et c'est la même pour tous :

  do one thing and do it well

Ainsi, ils auront souvent des entrées et des sorties.

{{https://raw.githubusercontent.com/utcoupe/coupe17/wiki_images/archi1.png}}


La plupart des modules sont connectés à des dispositifs physiques (Arduinos, Hokuyos). Un autre cas similaire est la communication avec un programme bas niveau écrit en C/C++ (Pathfinding).
Dans les deux cas, on considère que la communication est bas niveau (Serial, child process) et donc qu'elle peut se faire directement. C'est le seul cas autorisé, et cette communication est fortement liée aux rôles de ces modules. Bien entendu de la logique sera en place pour permettre une abstraction : la communication avec les autres modules doit être "haut niveau".

{{https://raw.githubusercontent.com/utcoupe/coupe17/wiki_images/archi2.png}}

Pour faire communiquer deux modules entre eux, il est obligatoire de passer par le serveur.
{{https://raw.githubusercontent.com/utcoupe/coupe17/wiki_images/archi3.png}}

===== UTCoupe =====


Toutes ces règles donnent l'architecture actuelle. Chaque module est détaillé dans sa page dédiée du wiki.

{{https://raw.githubusercontent.com/utcoupe/coupe17/wiki_images/archi4.png}}

===== Justification =====


L'organisation en module permet de travailler séparément sur des aspects différents du projet. Comme chaque module a son rôle bien défini, les autres peuvent se baser dessus avant même que celui-ci soit fonctionnel. Les modules peuvent également être améliorés en toute indépendance. Ils produiront ainsi des sorties de meilleure qualité.

L'architecture matérielle est complètement indépendante de l'architecture logicielle. Ainsi, peu importe qui instancie tel ou tel module, si il est identifié sur le serveur comme étant de type X, il sera considéré comme un module de type X et recevra donc les ordres associés (cf. la page Serveur pour plus d'informations).
Il y a plusieurs avantages à cela : on peut exécuter tous les modules sur son PC sans dispositif physique. Ils sont alors en "mode simulation" par détection automatique de non présence du dispositif physique. On peut également imaginer rejouer des données, par exemple pour l'Hokuyo. On enregistre une fois les données, puis il nous suffit de créer un module qui simule le fonctionnement du module Hokuyo en rejouant les données ! Les autres modules n'y verront que du feu. 🔥

Ainsi, voilà à quoi ressemble l'architecture lorsque qu'aucun dispositif technique n'est connecté à l'ordinateur :

{{https://raw.githubusercontent.com/utcoupe/coupe17/wiki_images/archi5.png}}

On remarque que l'IA et le Webclient sont inchangés : ils ne sont pas au courant qu'ils communiquent avec des clients fake... C'est le but !
UTCoupe

Outils d'utilisateurs

Outils du Site

Outils de la Page
