Analyse et Conception¶

Quand nous avons fait un état des lieux de l'existant en début de projet, nous nous sommes rendu compte qu'il n'y avait pas d'application pour afficher en temps réel les informations de vol du drone.

Ainsi, nous nous sommes réunis pour définir les fonctionnalités que l’IHM déporté devait comporter. Nous avons utilisé le langage de modélisation UML, car celui-ci nous a été enseigné lors de nos deux années dans l'enseignement supérieur.

UML est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires au bon développement d'un logiciel orienté objet. UML offre un standard de modélisation, pour représenter l'architecture logicielle. Ainsi, ce langage nous a paru une bonne solution pour bien démarrer le projet et pour que toute l'équipe puisse se comprendre.

Nous avons établi un diagramme d'activité pour savoir comment implémenter les fonctionnalités. Nous avons choisi de ce type de diagrammes d’activités, car ils permettent de modéliser un comportement tout en mettant l’accent sur les traitements. Ils sont donc particulièrement adaptés à la modélisation du cheminement de flots de contrôle (séquence, choix, itération, parallélisme) et de flots de données entre activités.

Ils permettent ainsi de représenter graphiquement le comportement d’une méthode ou le déroulement d’un cas d’utilisation.

Voici le diagramme d'activité de la réception de trame. La réception est la base de cette IHM, car c'est avec ceci que l'interface graphique reçoit les informations du drone.

Le reste de l'application est basé sur de la programmation événementielle pour réagir aux demandes de l'utilisateur (boutons appuyés...).

Nous avons mis en place un protocole réseau très simple de communication entre le simulateur et l'interface homme-machine. Après cette mise en commun, nous avons pu réaliser le code coté IHM du client UDP avec l'implémentation d'un parseur. Nous nous sommes vite rendu compte qu'il fallait découper l'application en plusieurs sous-tâches pour éviter de commencer certaines fonctionnalités et de se laisser déborder par le temps. Ainsi nous avons dressé un diagramme de classe pour permettre de découper en différentes classes selon ce qu'elles devaient faire pour une meilleure implémentation.

Il y a plusieurs zones qui comportent une ou plusieurs classes chacune qui ont été marquées. Ces zones ont permis une meilleure implémentation pour bien architecturer notre application.

Cette zone permet de recevoir une trame, de la parser et d'appeler les méthodes pour chaque type de trame reçue.

Horizon Artificiel¶

Cette zone s'occupe de dessiner l'assiette (altimètre, curseur, fond, angulaire …) mais aussi permet de recalculer la position de chaque élément lorsque l'assiette reçoit l'ordre de monter l'altimètre, ou d’incliner le fond, etc.
C'est cette zone qui rafraichit l'assiette 33 fois par seconde.

Graphique¶

Cette zone s'occupe de sauvegarder toutes les informations de vol du drone. Lorsque l'utilisateur clique sur un bouton de l'IHM, la Vue de la classe statistique est instanciée et permet de voir les 10 dernières informations de vol du drone (altitude, rotation X Y Z) mais aussi de tracer la courbe de l'altitude.

GPS¶

Cette unique classe permet soit d'interpoler des données en mètres en coordonnées GPS, soit d'utiliser directement des coordonnées GPS et ainsi afficher la carte dans l'IHM.

La classe principale de l'application se nomme IPV, elle est le centre de l'application, elle coordonne toutes les flux, mais aussi les interactions avec l'utilisateur.

Comme nous pouvons voir sur ce diagramme de classe, cette classe contient de nombreuses relations avec les différentes zones de l'application que l'on a précédemment définies.

Nous pouvons voir, qu'il possède un client UDP pour la communication réseau qui lui-même possède un IParseur.

IPV contient aussi une instance du canevas de l'assiette pour pouvoir dessiner dessus, elle possède aussi une instance de statistique pour dessiner la courbe de l'altitude et remplir les différents tableaux de vol du drone, une instance de la FORM pour rafraichir la location du drone avec une vue satellite de son environnement.

Ainsi toutes ces interactions ont permis d'avoir une classe qui va jouer le rôle du patron pour dire quelles actions doivent être exécutées lorsque celle-ci reçoit un message. Ainsi, imaginons que le parseur ait reçu une trame d'affichage GPS, il va envoyer un signal à IPV qui va le rediriger vers l'instance de FORM qui va savoir quoi en faire. Cette classe s'occupe donc de savoir quelles actions lancer lorsqu'une trame est émise, mais elle sert aussi d'interaction avec l'utilisateur. Ainsi lorsque ce dernier va cliquer sur un bouton par exemple le changement de couleur de l'assiette, c'est cette méthode qui va être appelée openColorWindow1() pour la couleur du ciel ou openColorWindow2() pour la terre, etc. Elle répond aux demandes de l'utilisateur.

Voici une capture d'écran de l'IHM dans sa version finale :