Les bâtiments Intelligents d’élevage: Besoins et attentes
Chapitre 4 – Analyse & Conception du système
I. Introduction
Après avoir exprimé l’objectif de notre travail ainsi que les solutions technologiques les plus adaptées à nos besoins dans le chapitre précédent.
Nous pouvons maintenant passer à la phase conception et modélisation du système qui représente une activité clé dans le processus de développement de notre projet de fin d’études. En effet, elle formalise et détaille ce qui a été ébauché au cours de préliminaire, et permet de dégager l’étude fonctionnelle du système.
Elle permet ainsi d’obtenir une idée sur ce que va réaliser le système en termes de métier (comportement du système).
Tout au long de ce chapitre, nous commençons par définir les besoins fonctionnels et Techniques de la solution que nous allons proposer, ainsi que son architecture. Par la suite, nous passons vers la modélisation et Conception du notre application à travers les différents diagrammes (diagramme de classe, cas d’utilisation, séquence et de composant).
Enfin, nous clôturons ce chapitre par présenter une conception hardware de différent composant électronique à travers les schémas de chaque branchement.
II. Spécification des besoins des éleveurs
1. Besoins Fonctionnels
Pour assurer les différents besoins et attentes des éleveurs, notre système devra être intelligent et extensible permettant de superviser et contrôler les bâtiments d’élevage, et cela avec différents niveaux d’accès.
Notre système comprendra trois (03) fonctionnalités principales que nous allons présenter ci-dessous de façon plus détaillée afin d’être plus clairs.
1.1 La Supervision
Notre système doit permettre à l’utilisateur de suivre en temps réel l’état des bâtiments d’élevage de volaille et de la volaille elle-même, en offrant à l’utilisateur la possibilité :
- * de montrer l’historique des états passés.
- * d’accès à distance (à travers Internet).
1.2 Gestion Des Lieux
Dans ce contexte, notre système offre la possibilité de gérer les différents équipements et dispositifs (extracteur d’air, régulateur de température, lampes…) de manière automatique, semi-automatique ou de manière manuelle.
1.3 Gestion Des Alertes
Les différents capteurs et actionneurs installés dans les bâtiments d’élevage permettent au système d’avoir des informations sur les paramètres d’environnement (Ammoniac, l’humidité, la chaleur, …) et ceci de manière continue.
Ce dernier pourra analyser des données envoyées et lance l’alerte dans les cas anormaux (chaleur anormale… ) , et dans ces cas notre système réagira de façon automatique et autonome en effectuant une liste d’actions préconfigurées pour remettre les paramètres environnement à ses bonnes valeurs tout en envoyant des notifications aux utilisateurs (via SMS, Appel etc..) qui pourront eux même intervenir.
2. Les besoins Techniques
Les besoins Techniques concernent les contraintes à prendre en considération pour mettre en place une solution adéquate aux attentes des utilisateurs.
Les principaux besoins Techniques que notre application doit nécessairement assurer, ce résument dans les points suivants :
* Gestion des utilisateurs et droits d’accès : On distingue principalement deux types d’utilisateurs : “Dirigeant” et «Employé” pour notre système dont le premier permet de gérer les différents employés, ainsi que les différents bâtiments d’élevages de plus que l’autre.
* La sécurité : l’application devra être hautement sécurisée, les informations ne devront pas être accessibles à tout le monde, c’est-à-dire que le site web est accessible par un identifiant et un mot de passe attribué à une personne physique.
* L’interface : avoir une application qui respecte les principes des interfaces Homme/Machine (IHM) tels que l’ergonomie et la fiabilité.
* La portabilité et compatibilité: Notre application doit être portable sur tous les environnements logiciels (Windows, Mac OS, Linux), d’où compatible avec les autres services développés ou qui vont être développés.
III. Démarche de modélisation
Chaque application et chaque système avant d’être réalisé doit passer par une étape de conception en utilisant un langage de modélisation afin de représenter ses modèles.
Cette étape permet de décrire les fonctionnalités du système, son comportement et tout le détail nécessaire pour la réalisation de ce système et son déroulement.
1. Choix du modèle de conception
Dans le cas de notre projet, on a choisi l’approche objet pour la conception de l’application, en raison de ses nombreux avantages, tels que [45]:
– Le système développé est plus facile à maintenir du fait que les objets sont indépendants. Ils peuvent être modifiés. Mais, le fait de modifier l’implémentation d’un objet ou de lui ajouter des services ne doit pas affecter les autres objets du système (Contrairement à l’approche fonctionnelle).
– Les objets sont considérés comme des composants réutilisables appropriés vu leur indépendance. On peut alors développer des conceptions à l’aide des objets créés dans une autre conception.
– Pour certaines classes du système, il existe une correspondance claire entre les entités du monde réel (tels que les composants matériels) et les objets du système qui le contrôlent ce qui permet d’améliorer la compréhension de la conception.
Pour La Modélisation de notre application, on a choisi le langage UML (Unified Modeling Language) qui permet de modéliser un problème de façon standard… (Vous trouverez tous les détails d’UML sur ce lien) [46].
V. Conception
Après avoir définit les fonctionnalités du notre système, il est indispensable de passer par la suite vers la conception qui s’intéresse à comment ces fonctionnalités seront implémentées et représente ainsi une ébauche de l’activité de développement.
La conception passe par deux étapes : la conception software et la conception des composants électroniques (hardware).
1. La conception software
Concerne une vision descriptive des éléments de la conception de la partie logiciel : sous systèmes (composants), classes et interfaces.
Dans ce qui suit nous allons décrire les éléments de la conception de notre système (cas d’utilisation, diagramme de classes et diagrammes de séquence) et cela en utilisant les outils de UML.
1.1 Identification les acteurs du système
Un acteur est une entité externe qui agit sur le système (Utilisateur , dispositif matériel, autre système, etc.) et qui peut consulter et/ou modifier l’état du système. Pour des fins de sécurité nous définissons deux catégories des acteurs:
* Directeur
Est le responsable des différents bâtiments d’élevages (Peut être le propriétaire). Il a toutes les fonctionnalités de système telles que :
La Supervision, Gestion des Lieux, Gestion des Alertes ainsi que la possibilité de créer un nouveau compte d’employé et de gérer les différents bâtiments d’élevages (Ajouter, Modifier, Supprimer).
* Employé
Assure la supervision des différents bâtiments, comme il peut accéder à des autres fonctionnalités du système (piloter les équipements, envoyer un message d’alerte et Consulter l’historique).
1.2 Diagramme de cas d’utilisation
Un cas d’utilisation permet de décrire l’interaction entre les acteurs (utilisateurs du cas) et le système, tel que chaque cas correspond à une fonction métier du système, selon le point de vue d’un de ses acteurs [47].
Nous présentons ci-dessous, les différents diagrammes de cas d’utilisation de notre système, qui donnent une vision globale et simple du comportement fonctionnel de ce dernier.
1.2.1 Diagramme de cas d’utilisation Globale
Figure 23 diagramme de cas d’utilisation global
Maintenant nous allons détailler ce diagramme général en détaillant les cas d’utilisations générales de notre système, commençant par le 1er cas d’utilisation qui est la gestion des lieux.
1.2.2 Diagramme de cas d’utilisation « Gestion des lieux »
Figure 24 : diagramme de cas d’utilisation «Gestion des lieux»
1.2.3 Diagramme de cas d’utilisation « Gestion des Alertes »
Figure 25: diagramme de cas d’utilisation » Gestion des Alertes »
1.2.4 Diagramme de cas d’utilisation « Consulter l’historique »
Figure 26:Diagramme de cas d’utilisation «Consulter l’historique»
1.2.5 Diagramme de cas d’utilisation « Gérer les bâtiments d’élevage »
Figure 27 Diagramme de cas d’utilisation «Gérer les bâtiments d’élevage»
1.3 Diagramme de classes
Le diagramme de classes décrit les types des objets qui composent un système et les différents types de relations statiques qui existent entre eux.
Le diagramme de classes fait abstraction du comportement du système. Les classes qui composent notre système sont :
Figure 28 Diagramme des classes
La représentation détaillée (les attributs et les fonctions) de chaque classe est décrite dans les figures suivantes :
1.3.1 Classe Centre d’alerte
C’est la class responsable d’envoi et de la réception des diverses Messages d’Alerte.
Figure 29: Classe Centre d’alerte
SendMsg (): permet d’envoyer un Message d’Alerte. Call () : permet de passer un appelle téléphonique.
ReceiveMsg () : permet de recevoir un Message envoyé par le Responsable au système.
1.3.2 Classe Equipement
C’est la class qui permet d’interagir entre la carte ESP32 (Actionneur) et le système, aussi le pilotage des équipements de bâtiment d’élevage.
Figure 30: Class Equipement
ActiveEqui (): permet d’activer l’équipement. DesactiseEqui (): permet de désactiver l’équipement.
GetData () : permet de recevoir les données envoyer par le system.
GetStatut () : permet de récupérer le statut d’un équipement électrique. SendStatut () : permet d’envoyer le statut d’un équipement au system (ON/OFF).
1.3.3 Classe capteur
C’est la class qui permet d’interagir entre la carte ESP32 (Capteur) et le système, aussi la réception des différents valeurs des paramètres climatiques.
Figure 31 Classe capteur
GetData () : permet de recevoir les données envoyer par le system. SendData () : permet d’envoyer les données au système.
1.3.4 Classe évènement
C’est la classe qui permet de lie chaque information envoyer par la carte ESP32 (capteur) avec la date d’acquisition.
Figure 32 Classe évènement
1.3.5 Classe SmartFarm
C’est la classe principale de notre system, elle se compose d’un à plusieurs bâtiments d’élevage et permet de faire toutes les contrôles et les actions.
Figure 33 Class SmartFarm
Notifier () : permet d’envoyer une notification à l’utilisateur. Farm_Auto (): permet d’activer ou désactiver le Mode Automatique.
1.3.6 Classe Bâtiment
La class qui représente un bâtiment d’élevage de poulet de chair, elle se compose d’un ensemble des Dispositif (capteurs et équipements).
Figure 34 Classe Bâtiment
1.4 Diagrammes de séquence
Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs et le système selon un ordre chronologique.
Dans ce qui suit, nous présenterons quelques diagrammes de séquences illustrant les interactions entre les acteurs et notre système.
1.4.1 Diagramme de séquence « Superviser l’état des bâtiments d’élevages »
Figure 35 Diagramme de séquence «Superviser l’état des bâtiments d’élevages»
Le Scénario
Après l’authentification, L’utilisateur (Employé ou Directeur) demande au système de Superviser l’état des bâtiments. Une fois l’interface demandée est affichée, il sélectionne le Bâtiment qu’il désire superviser.
A son tour le système envoi un requête au serveur BD afin de déterminer l’état actuel de Bâtiment sélectionné, puis l’afficher.
Ce procédé est exécuté chaque deux secondes après que l’utilisateur sélectionne le bâtiment, c’est pourquoi nous avons utilisé l’opérateur «loop».
1.4.2 Diagramme de séquence « Gestion des lieux »
Figure 36 Diagramme de séquence « Gestion des lieux »
Le Scénario
Apres l’authentification avec succès et l’affichage de l’interface demandée, Trois scénarios peuvent se présenter :
* Visualiser l’état des équipements:
L’utilisateur n’aura besoin que de sélectionner le bâtiment qu’il veut, puis valide la demande. A son tour le système transfert la demande au serveur BD afin déterminer l’état actuel des équipements, puis les afficher.
* Activation Désactiver Mode Automatique:
Rendre le système autonome est la fonctionnalité la plus importante de notre projet. L’utilisateur n’aura besoin que de lancer l’activation de mode automatique, Le système à leur tour communique avec le serveur BD afin de déterminer les paramètres nécessaires, puis affiche un message de confirmation à l’utilisateur (Pour désactiver le mode, L’utilisateur suit les même étapes).
* Pilotage Manuel des équipements :
L’utilisateur commence par la sélection de Bâtiment puis il identifie l’équipement et l’action désiré. Ensuite le système a son tour envoi une requête au serveur BD. Le serveur BD transfère l’action vers la carte ESP32 qui va commander cet équipement soit en l’allumant ou en l’éteignant.
1.4.3 Diagramme de séquence « Scénario d’Alarme »
Figure 37 Diagramme de séquence «Scénario d’Alarme»
Le Scénario
Dès que les différents capteurs détectent un phénomène anormal (chaleur anormale, gaz toxique…), Le système interprète l’évènement et déclenche une alarme en affichant un message d’alerte aux différents utilisateurs de notre application web avec la possibilité d’envoyer un SMS, Appel…aux responsables dans les cas grave.
En même temps, il allume l’équipement Approprié afin de remettre le paramètre environnemental à sa bonne valeur avant qu’il ne soit trop tard.
1.4.4 Diagramme de séquence « Consulter l’historique »
Figure 38 Diagramme de séquence «Consulter l’historique»
Le Scénario
Apres l’authentification, tous les employés ont la possibilité de consulter l’historique, ils doivent d’abord sélectionner le paramètre d’environnement.
A son tour le système envoi un requête au serveur BD afin de déterminer l’historique de paramètre sélectionné.
1.4.5 Diagramme de séquence « gérer les bâtiments d’élevage »
Figure 39 Diagramme de séquence «gérer les bâtiments d’élevage»
Le Scénario
Après authentification, le directeur effectue une demande de gestion d’un bâtiment d’élevage. Le système affiche alors la page correspondante. Trois scénarios peuvent se présenter : Ajout d’un bâtiment, Suppression d’un bâtiment ou Modification d’un bâtiment.
* Ajouter un bâtiment:
Après l’affichage de la page en passant en mode «Créer Bâtiment», le directeur ensuit saisit les informations de bâtiment qu’il veut ajouter, puis valide l’opération.
* Modifier bâtiment:
Le directeur sélectionne le bâtiment concerné par la modification et effectue la demande de modification. Le système affiche alors dans le formulaire les informations de bâtiment sélectionné, dans lequel le directeur saisit les modifications et les valide.
* Suppression d’un bâtiment :
Le directeur sélectionne le bâtiment concerné par la suppression. Le système à son tour affiche la page correspondante, une fois qu’il est affichée, le directeur supprimer et valide l’action
NB : En ce qui concerne la gestion des employés, on suivra les mêmes étapes que dans la gestion des bâtiments d’élevage, pour ajouter, modifier ou supprimer un employé.
