Fonctionnement¶

Voici un diagramme de séquence UML présentant de manière simplifiée le fonctionnement de l’IHM :
Figure 13 : Diagramme UML de séquence simplifié de l'IHM

Nous retrouvons les deux classes définies plus haut : la « MainWindow » et le « ClientTcp ». L’utilisateur et la « BorneWifi » sont considérés comme des acteurs externes à l’application. Donc, si nous suivons ce diagramme, l’utilisateur rentrera dans l’IHM l’adresse IP à laquelle il voudra se connecter. La « MainWindow » après que l’utilisateur ait cliqué sur le bouton connecter enverra l’adresse IP fournie et le port de connexion (par défaut 5000) au « ClientTcp ». A ce moment le client tentera une connexion à la borne Wifi et plusieurs scénarios sont possibles, en effet la borne wifi a peut-être déjà trop de clients, n’est pas visible ou accessible par l’application ou accepter la connexion. De ce fait le renvoi de l’information d’état par la borne est fictive, un système de retardateur annulera la connexion si la borne est invisible ou inaccessible.
Donc deux cas se dessinent. Soit la connexion est impossible, et le client enverra le message d’erreur à la fenêtre qui l’affichera. Soit la connexion est possible et un message de connexion apparaitra à l’écran. Le processus de connexion est automatisé et simplifié par l’utilisation du socket TCP fourni par la bibliothèque « QtNetwork », le renvoi du message de connexion au client n’existe pas dans le code mais doit être fait automatiquement puisque la connexion TCP est négocié entre le client et l’hôte mais il est mis dans un souci de cohérence. Une fois que la borne Wifi a reçu confirmation de la connexion, elle commencera à émettre ses données toutes les 10 mS. A chaque fois qu’une ligne sera émise par la borne wifi, le client la transmettra à la « MainWindow ». Celle-ci découpera la ligne en donnée, transformera les données qui doivent l’être (une double intégration pour, à partir d’accélérations, trouver des positions), puis dessinera ces données, en attachant à chaque courbe le point qui lui est destiné.
En effet, c’est un diagramme simplifié, car toutes les actions faites par l’application ne sont pas représentées : il y a une analyse de l’adresse IP quand l’utilisateur la rentre, pour contrôler sa forme grâce à un masque directement dans la fenêtre. De plus si les informations transmises ne sont pas bonnes : pas au bon nombre ou du bon type, la trame est détruite.
Il n’y a aucune attente active, en effet tous les envois de messages entre les différents éléments de l’application utilisent le système de Qt de signaux et de slots. Lorsqu’un élément a une information à envoyer ou recevoir, un signal est émis. Chaque signal est connecté à un ou plusieurs slots, qui se déclencheront et utiliseront les paramètres s’il y en a.

Voici une copie d’écran de l’application à l’ouverture :
En 1 nous trouvons la partie de connexion où l’utilisateur rentre l’IP à laquelle il veut se connecter, le bouton de connexion et l’état de la connexion ; en 2, les différents onglets créés et enfin en 3 une zone de dessin ou les courbes sont créées, un affichage des échelles et du zéro.

Dans cette partie nous avons montré quelles sont les solutions logicielles adoptées et les raisons de ces choix, comment les installer et les utiliser. Nous avons aussi montré quelle est l’architecture logicielle que nous avons choisie, comment les différentes classes communiquent entre elles, et quel est le chemin de l’information depuis la borne Wifi à l’affichage des courbes.

<- Conception logicielle -> Bilan Technique