CAW1 2018 Projet de Samuel LEMAIRE et Bertrand DARBON

De Ensiwiki
Aller à : navigation, rechercher

RHome - projet WEB de Bertrand et Samuel

Réalisation d'un projet WEB permettant de consulter des informations liées à la domotique. L’interface utilisateur affiche des données de température humidité et consommation électrique sous forme de graphique.

Objectifs

Le but est de permettre à un utilisateur identifier de visualiser les données de température, humidité, consommation électrique etc... de sa maison via une interface WEB. Il peut ainsi vérifier que tout est normal chez lui et peut également envoyer des ordres à sa maison comme modifier la température, couper le courant.

Le but est de créer une application permettant d'ajouter facilement de nouveaux indicateurs et de nouvelles commandes.

Modélisation

Cas d'usage

L'application RHome est prévu pour les cas d'utilisation suivants :

Les utilisateurs de l'application sont  : les visiteurs (non connectés), les administrateurs ainsi que les utilisateur de base de l'application. Les visiteurs peuvent seulement s'identifier. Une fois identifiés les utilisateurs ne peuvent que consulter leurs indicateurs domotiques, et exécuter des actions simples comme éteindre le courant, ou verrouiller leur maison. Les administrateurs ont accès à la page d'administration qui permet de créer ou modifier des utilisateurs. Ils peuvent également rajouter des indicateurs à l’interface de chaque utilisateur.


UseCase.jpg

Scenarii d'usages

Le diagramme ci dessous représente le scénario d'ajout d'un utilisateur. Ce scénario est très semblable à l'ajout d'un nouveau device (au nom des méthodes près. Il ne nous a donc pas semblé intéressant de surcharger la page pour celui-ci.

Ajout d'un utilisateur.jpg

Modèle de données

Le modèle de donnée derrière RHome est très simple : voici son diagramme UML.


Class.jpg

Architecture

L'application Rhome s'organise de la façon suivante : Le serveur back qui permet la communication avec les différents raspberryPI qui collectent les données, gère les connexions à la base de données et formalise les données pour le front. Le front qui gère l'interface avec les utilisateurs, et qui affiche es données en provenance du back. la base de données Mongo DB qui permet le stockage à long terme des informations domotiques hébergées par l'application, et qui permet également l'identification des utilisateurs. Le web service simulant un raspeberryPI. Il y a une instance du web service pour chaque device émulé et chacun est capable d'envoyer des données au back.

Choix techniques

Consignes d'installation

Pour installer le webservice il faut préalablement installer le package express (npm install express). Pour installer le back et le run il faut préalablement installer les packages express, serve-icon, morgan, cookie-parser, body parser, mongoose et debug.

Web-service

Le web-service utilisé par l'application est une application distante (sur un rasberry pi par exemple) renvoyant toutes les données collectées au moment de l'appel. Le but est de récolter ces données à intervalles réguliers pour alimenter la base de données de l'application.

Pour les besoins de l'exercice, le web-service utilisé est un simple web-service en local simulant une collecte de données et l'envoie de celles-ci.

Il existe donc un web-service pour chaque raspberry pi/client utilisant l'application.

L'application distante est accessible via des routes HTTP. On y accède donc en envoyant des requêtes GET sur l'URL <service IP>:3000/dataCollect. Le web service répond à la requête en renvoyant un objet JSON à l'appelant. L'objet est ensuite traité par le serveur Back de l'application.

Gestion des rôles

Dans l'application RHome il y à trois rôles distincts. Les rôles sont différentiés au moment de la connexion. Un couple identifiant mot de passe correspond à une connexion à l'application et le rôle en est déduis grâce à la base de données.

visiteur

Le visiteur est l'utilisateur qui ne s'est pas encore connecté via l'interface de connexion. L'accès à la consultation et à la gestion des indicateurs domotique lui est impossible.

administrateur

L'administrateur est un utilisateur identifié correspondant au rôle administrateur. Il a pour but de gérer les accès à l'application, en créant et supprimant des comptes utilisateurs ; ainsi que l'accès aux devices, en créant de nouveaux devices et en les associant ou en les dissociant des clients de l'application.

client

Les utilisateurs identifié clients de RHome, n'ont accès qu'a la page de consultation de leurs données. Ils peuvent sur cette page consulter l'évolution de leur consommation électrique, de la température et de l'humidité de leur maison, et peuvent également opérer des actions à distance comme couper le courant, verrouiller la maison .. etc..

API

Ci dessous une description de l'API que nous avons fait :

API RHome
PATH GET POST PUT DELETE
/api/devices/:device/data/:type Récupération des données du type voulu pour le device spécifié
/api/users/devices Récupération de la la liste des device pour l'utilisateur séléctionné
/api/devices Renvoie la liste de tous les devices Permet d'insérer un nouveau device dans la base de données.
/api/users Renvoie la liste de tous les utilisateurs Permet d'insérer un nouvel utilisateur dans la base de données.
/api/logout Permet à l'utilisateur de se déconnecter
/api/login Permet à l'utilisateur de se connecter
/api/users/:username Permet à l'administrateur d'ajouter un device à la liste de device de l'utilisateur "username"

screen cast

le screen cast visible via le lien suivant vous permet d'avoir un aperçut de l'utilisation de RHome. https://drive.google.com/file/d/1GcdMLTz6r2T40kh9FGAc7zzLBBqZZC1x/view

jeux de test

Les scénarios de test pour valider les développements du back et du web-service ont été réalisés grâce à cucumber. Pour cela il faut installer cucumber comme suit : npm install cucumber --save-dev

Chacun des trois projets git possède son propre jeu de test. Les scenarii sont décrits dans les dossier features/ et features/step_definition/ . Ces scenarii permettent de valider le bon fonctionnement du projet auquel ils appartiennent.


web-service

Pour le web-service, nous testons que les données générées soient conforment avec ce que le serveur Back attend. Nous testons également que le web-service se lance bien et écoute sur le bon port.

back-end

Pour le back-end, nous testons les connections, insertions et valeurs de retour en base de données. Nous testons également la connexion au web-service. ainsi que les différentes routes misent en place pour le front-end.