08. Architecture Schémas
Nous disposons d'un Frontend, d'un Backend et d'une base de données. Le frontend possède les pages accessibles par les utilisateurs qui remplisse des champs et ces derniers sont envoyés au backend qui lui traite et analyse les données pour ensuite les envoyés à la db.
Nous avons utilisé MongoDB, de ce fait, nous utilisons des collections regroupant des gros concepts comme par exemple Objectifs, Users, Ville, donnees et sessions.
La collection Objectifs regroupent les objectifs disponible aux utilisateurs, la collection Users regroupe les différents utilisateurs de notre applications, la collection ville regroupe l'ensemble des communes belges afin de permettre la personnalisation de leur localitée aux utilisateurs, la collections données possèdent l'ensemble des données du raspberry et la collections sessions contient les données de sessions d'un utilisateur.
Elle regit les cookies utilisateurs
Chaque objets dans ces tables possèdent un "model" dédiée qui regroupe toutes les données de celui-ci. Par exemple, un objectif contient son id, une description, un type et un nom.
En travaillant avec un model, chaque objectif possèdera les même champs devant être remplis afin d'effectuer des sauvegardes sur la base de données.
Dans l'API, nous disposons de plusieurs routes (objectif, users, villes) ces dernières sont utilisées quand ce qu'on demande se réfère à un de ces concepts, par exemple si je demande tous les objectifs ma requête passe par la route objectifs.
Voici ci joint le dossier contenant toute les routes de notre projet : ici
L'utilisation de MongoDB, fonctionnant avec des documents, nous propose une flexibilitée folle dans l'évolutions de notre projet. En cas de nouvelle fonctionnalitée, nous pourrons sans aucun soucis ajouter une collection dans laquelle un nouveau modèle de données y sera enregistré
Nous utilisons également un raspberry PI utilisé comme montre connectée. Sur ce dernier, nous avons placer des capteurs par l'intermédiaire d'un breadboard. Une analyse a été faite sur les tensions necessaire afin d'alimenter les capteurs.
Nous avons cependant perdu cette analyse papier.
Ci dessous, une photo de la réalisation de cette analyse :
Afin d'accéder au contenu des données des capteurs, le raspberry écrit sur une clé USB les données afin de pouvoir les interpreter en frontend.
Ainsi, les données sont accéssible de manière lisible sur le frontend, permettant d'avoir nos informations de santée sur l'application.
Les données interprétées sont dans un fichier data.csv contenant les données sous le format suivant :
| Date | Heure | Latitude | Longitude | Vitesse | Altitude | Frequence cardique | nombre de pas |
|---|---|---|---|---|---|---|---|
| X | X | X | X | X | X | X | X |
| Y | Y | Y | Y | Y | Y | Y | Y |
| Z | Z | Z | Z | Z | Z | Z | Z |
Grâce à un interpréteur de fichiers, nous pouvons naviguer au sein de notre système afin d'ouvrir ce fichier data.csv en question.
L'avantage de cette méthode est que si un utilisateur ne possédant pas notre montre désire essayer notre application, il lui suffit d'avoir une fichier similaire au notre afin de pouvoir accéder aux traitement de ses données.
N'ayant pas une base de données relationnelle, nous utilisons des collections et des modèles lié à notre base de données MongoDB.
Les modèles de ces derniers sont disponible ici ainsi que ces collections suivantes :
-
objectifs : contient tous les objectifs liés à notre projet
-
users : contient tous les utilisateurs liés à notre projet
-
villes : contient toutes les villes liés à notre projet
-
sessions : collection nécessaire pour les cookies
-
données : contient les données des capteurs du raspberry