Chapitre 3. Application de la méthodologie et modélisation du système
Introduction
Ce chapitre présente dans un premier temps les participants à cette étude et les différentes stratégies de collecte de données utilisées, puis revient sur l’application de l’approche méthodologique choisie, avant de partir de la modélisation du système proposé grâce aux diagrammes UML pour obtenir le modèle de données à implémenter.
Participants à l’étude
La réalisation du projet de cette étude est l’effet de la participation de deux catégories d’acteurs en constante collaboration. D’une part, une équipe de maîtrise d’œuvre. Cette première équipe chargée de conception et de réalisation du système, est composée de l’étudiant auteur de ce document ayant joué le rôle d’analyste et concepteur du système ; d’un encadreur Chef des travaux qui a suivi de près l’évolution du projet en donnant, à chaque fois, des directives de rédaction ; et d’un directeur Professeur Docteur qui a validé le travail. D’autre part, une équipe de maitrise d’ouvrage. Cette seconde équipe jouant le rôle du client de ce projet et répondant en tant qu’Université Catholique de Bukavu dans son domaine de l’élevage bovin, est composée de l’Administrateur général de l’Université Catholique de Bukavu qui a autorisé que ces recherches soient menées dans son cadre, et de son Préposé à l’élevage qui a fourni toutes les informations nécessaires à la réalisation de ce projet.
Stratégies de collecte des données
Les données ayant servi à la réalisation de ce travail ont été collectées à travers les techniques classiques de la documentation et de l’interview. Le guide d’entretien présenté en annexe reprend toutes les questions posées au client pour mieux exprimer ses besoins et attentes, et ainsi élaborer le cahier des charges.
Application de la méthodologie
Interpolation
En considérant que x0 est le temps initial en nombre d’années en 2006, soit x0=0, f (x0) est le capital initial en nombre de vaches, soit f (x0) =5 ; x1 est le nombre d’années écoulées entre 2006 et 2010, soit x1=4, et f (x1) le nombre de vaches en 2010, soit f (x1) = 10 ; x2 est le nombre d’années écoulées entre 2006 et 2015, soit x2=9, et f (x2) le nombre de vaches en 2015, soit f (x2) = 20 ; et x3 est le nombre d’années écoulées entre 2006 et 2020, soit x3=14, et f (x3) le nombre de vaches en 2020, soit f (x3)=45, on obtient le tableau 3.1 portant des cordonnés de l’évolution de la taille du troupeau en fonction des années.
Tableau 3.1. Evolution de la taille du troupeau
| xi | x0 = 0 | x1 = 4 | x2 = 9 | x3 = 14 |
| f (xi) | f (x0) = 5 | f (x1) =10 | f (x2) = 20 | f (x3) = 45 |
Et par application des différences divisées ou rapports d’accroissement sur les cordonnées reprises dans le tableau 3.1, il se déduit que la production bovine à l’Université Catholique de Bukavu, croit suivant le polynôme d’interpolation de Newton ci-après :
Équation 3.1. Polynôme d’interpolation de la taille du troupeau.
𝑓(𝑥) =
5𝑥3 − 51𝑥2 + 474𝑥 + 1400
280
, 0 ≤ 𝑥 < ∞
Taille du troupeau
200
150
100
50
0
2006
2010
2015
2020
2030
Ainsi, en projetant cette production sur dix ans à venir, soit x=24, si toutes les conditions restent inchangées, il résultera un capital d’approximativement 188 têtes à l’horizon 2030 comme illustré par le graphique 3.1.
Graphique 3.1. Évolution de la taille du troupeau en fonction des années.
Processus unifié rationnel et modélisation
Le modèle conçu pour obtenir le système à implémenter dans cette étude est composé de six diagrammes UML, notamment le diagramme de cas d’utilisation avec description de chaque cas d’utilisation ; les digrammes d’activité pour les cas d’utilisation clés, le diagramme de classes ; le diagramme d’états-transitions pour des classes qui présentent des traitements complexes ; le diagramme de composants et le diagramme de déploiement. Il faut aussi noter que le système dont il est question de modéliser dans cette étude étant complexe, les règles de l’art obligent qu’il soit subdivisé en trois modules principaux, à savoir le module de gestion des utilisateurs, le module de gestion des ressources bovines et le module de géolocalisation et gestion des alertes. Par ricochet, le diagramme de cas d’utilisation est divisé respectivement en ces trois sous-systèmes.
Diagrammes de cas d’utilisation
Pour un diagramme de cas d’utilisation, on appelle cas d’utilisation, une fonctionnalité complète offerte par le système. On appelle acteur, une personne ou un système matériel ou logiciel qui initie un cas d’utilisation du système modélisé. Il est donc possible d’avoir des relations d’héritage (ou d’extension) et d’inclusion entre les cas d’utilisation, et des relations de généralisation entre les acteurs [47]. Un cas d’utilisation hérite d’un autre cas d’utilisation si le premier explique le dernier par extension. Un cas d’utilisation inclut un autre cas d’utilisation si le premier ne peut être exécuté avant que l’autre ne soit préalablement et entièrement exécuté. Un acteur généralise un autre si le premier hérite de tous les cas d’utilisation du second en plus d’avoir ses cas d’utilisation spécifiques [48].
Pour le module de gestion des utilisateurs, le diagramme de cas d’utilisation illustré à la figure 3.1 comprend trois acteurs réalisant chacun un ou plusieurs cas d’utilisation qui le concernent. Le premier acteur est l’Administrateur général qui gère tous les utilisateurs du système. Par gérer les utilisateurs il faut comprendre l’ajout des utilisateurs dans la base de données, l’édition de leurs profils, la visualisation et la suppression de ceux-ci. Le deuxième acteur et le troisième sont respectivement le Préposé à l’élevage et le fermier. Ces acteurs peuvent chacun voir et éditer son profil. Cependant pour réaliser l’un ou l’autre cas d’utilisation de ce module les acteurs doivent préalablement s’authentifier au système.
Figure 3.1. Diagramme de cas d’utilisation : Gestion des utilisateurs.
Pour le module de gestion des ressources bovines, le diagramme de cas d’utilisation illustré à la figure
3.2 comprend également trois acteurs réalisant chacun un ou plusieurs cas d’utilisation qui le concernent. Ces acteurs sont l’Administrateur général qui généralise le Préposé à l’élevage, et le fermier. Alors que le fermier, dans ce module, ne peut que voir les statistiques en tableau de bord, l’administrateur général et le préposé à l’élevage, en plus de voir les statistiques de l’élevage en tableau de bord, ils gèrent les fermes, les vaches, les productions bovines, les disparitions de vaches et les systèmes embarqués. Mais pour cela, tous les acteurs doivent s’authentifier préalablement au système.
Figure 3.2. Diagramme de cas d’utilisation : Gestion des ressources bovines.
Pour le module de géolocalisation et gestion des alertes, le diagramme de cas d’utilisation illustré à la figure 3.3 comprend quatre acteurs dont un acteur mécanique et trois acteurs humains réalisant chacun un ou plusieurs cas d’utilisation qui le concernent. L’acteur mécanique est le système embarqué. Cet acteur envoie la position de la vache sur la mappe de Google intégrée dans le système et lance les alertes dans la base de données. Les trois acteurs humains dont l’Administrateur général, le Préposé à l’élevage et le fermier consultent la mappe et visualisent les alertes, ici encore ils doivent préalablement s’authentifier au système.
Figure 3.3. Diagramme de cas d’utilisation : Géolocalisation et gestion des alertes.
Description des cas d’utilisation
Le tableau 3.2 décrit tous les cas d’utilisation du système proposé en précisant pour chacun les acteurs qui l’initient ainsi que l’enchaînement principal d’activités et des scenarii.
Tableau 3.2. Description des cas d’utilisation.
| Cas d’utilisation | Acteurs | Enchaînement d’activités |
| S’authentifier | Administrateur général ; Préposé à l’élevage ; et Fermier. | L’acteur clique sur le bouton «se connecter». Le système affiche le formulaire d’authentification. L’utilisateur saisit ses paramètres d’authentification. Le système vérifie les paramètres saisis. S’ils sont corrects, le système ouvre le module correspondant aux droits d’accès de l’utilisateur. Sinon, le système renvoie un message d’erreur et demande à l’utilisateur de les saisir à nouveau. |
| Gérer les utilisateurs | – Administrateur général. | L’authentification de l’acteur a réussi. L’acteur clique sur le bouton «Ajouter» ou «Modifier» ou «supprimer» l’utilisateur. Par défaut, la liste des utilisateurs est affichée dès l’ouverture du module de gestion des utilisateurs. Le système affiche le formulaire demandé. L’acteur rentre les informations de l’utilisateur concerné. Le système vérifie les informations rentées et demande à l’acteur de confirmer son action. Si les informations sont correctes, le système ajoute ou modifie ou supprime l’utilisateur concerné. Sinon, il renvoie un message d’erreur. |
| Editer profil utilisateur | Administrateur général ; Préposé à l’élevage ; et Fermier. | L’authentification de l’acteur a réussi. L’acteur clique sur le bouton «Modifier les paramètres». Le système affiche le formulaire demandé avec les paramètres précédents. L’acteur saisit ses nouveaux paramètres et clique sur le bouton «Enregistrer». Le système vérifie les paramètres saisis. S’ils sont corrects, le système enregistre les modifications dans la base des données. Sinon, le système renvoie un message d’erreur «Paramètres incorrects» et demande à l’utilisateur de les saisir à nouveau. |
| Gérer les fermes | – Administrateur général | L’authentification de l’acteur a réussi. L’acteur clique sur le panneau «Fermes» puis sur le bouton «Ajouter» ou «Modifier» ou «supprimer» la ferme. Par défaut, la liste des fermes est affichée dès l’ouverture du panneau «Fermes». Le système affiche le formulaire demandé. L’acteur rentre les informations concernant la ferme. Le système vérifie ces informations et demande à l’acteur de confirmer son action. Si elles sont correctes, le système ajoute ou modifie ou supprime la ferme dans |
| la base de données. Sinon, le système renvoie un message d’erreur. | ||
| Gérer les vaches | Administrateur général ; Préposé à l’élevage. | L’authentification de l’acteur a réussi. L’acteur clique sur le panneau «Vaches» puis sur le bouton «Ajouter» ou «Modifier» ou sur le bouton «supprimer» la vache. Par défaut, la liste des vaches est affichée dès l’ouverture du panneau «Vaches». Le système affiche le formulaire demandé. L’acteur rentre les informations concernant la vache. Le système vérifie les informations saisies et demande à l’acteur de confirmer son action. Si elles sont correctes, le système ajoute ou modifie la vache dans/de la base de données. Sinon, il renvoie un message d’erreur. |
| Gérer les productions | Administrateur général ; Préposé à l’élevage. | L’authentification de l’acteur a réussi. L’acteur clique sur le panneau «Productions» puis sur le bouton «Ajouter» ou «Modifier» ou «supprimer». Par défaut, la liste des productions est affichée dès l’ouverture du panneau «Productions». Le système affiche le formulaire demandé. L’acteur rentre les informations concernant la production. Le système vérifie les informations saisies. Si elles sont correctes, il ajoute, modifie ou supprime la production dans/de la base de données et notifie l’acteur. Sinon, il renvoie un message d’erreur. |
| Gérer les disparitions | Administrateur général ; Préposé à l’élevage. | L’authentification de l’acteur a réussi. L’acteur clique sur le panneau «Disparitions» puis sur le bouton «Ajouter» ou «Modifier» ou «supprimer» la disparition. Par défaut, la liste des disparitions est affichée dès l’ouverture du panneau «Disparitions «. Le système affiche le formulaire demandé. L’acteur rentre les informations concernant la disparition. Le système vérifie les informations saisies. Si elles sont correctes, il ajoute, modifie ou supprime la |
| disparition dans/de la base de données et notifie l’acteur. Sinon, il renvoie un message d’erreur. | ||
| Gérer les systèmes embarqués | Administrateur général ; Préposé à l’élevage. | L’authentification de l’acteur a réussi. L’acteur clique sur le panneau «Systèmes embarqués» puis sur le bouton «Ajouter» ou «Modifier» ou «supprimer» le système embarqué. Par défaut, la liste des systèmes embarqués est affichée dès l’ouverture du panneau » Systèmes embarqués». Le système affiche le formulaire demandé. L’acteur rentre les informations concernant la disparition. Le système vérifie les informations saisies. Si elles sont correctes, il ajoute, modifie ou supprime la disparition dans/de la base de données et notifie l’acteur. Sinon, il renvoie un message d’erreur. |
| Voir les statistiques | Administrateur général ; Préposé à l’élevage ; et Fermier | L’authentification de l’acteur a réussi. L’acteur clique sur le menu «Tableau de bord». Le système affiche trois graphiques exprimant respectivement le nombre des vaches en fonction des fermes, les productions laitières en litres en fonction des années d’exercice, ainsi que les disparitions bovines en fonction des causes qui les provoquent. |
| Envoyer la géolocalisation | Système embarqué | La synchronisation du module GPS avec le satellite a réussi. Le module GPS prélève la position en la longitude et la latitude de la vache. Le NodeMCU traite ces signaux. Le module Wi-Fi envoie les valeurs de ces signaux vers la mappe intégrée dans l’application. |
| Lancer l’alerte | Système embarqué | Les capteurs DHT11 et NB023 mesurent la température et le rythme cardiaque de la vache. Le NodeMCU traite et analyse ces signaux. Le module Wi-Fi envoie les valeurs de ces signaux au serveur d’application. |
| Le serveur teste ces valeurs. Si elles sont en dehors de l’intervalle requis alors L’alerte est envoyée à la base de données. | ||
| Consulter la mappe | Administrateur général ; Préposé à l’élevage ; et Fermier. | L’authentification de l’acteur a réussi ; L’acteur clique sur le bouton «localisation». Le système affiche la mappe avec la géolocalisation respective de chaque vache. |
| Voir les alertes | Administrateur général ; Préposé à l’élevage ; et Fermier. | L’authentification de l’acteur a réussi ; L’acteur clique sur le bouton «Alertes». Le système affiche la page des alertes lancées par les systèmes embarqués. |
Diagrammes d’activités
L’activité première que doit réaliser un acteur humain pour utiliser le système proposé dans cette étude est de s’authentifier. L’enchaînement logique des actions à faire avec des scénarii possibles pour s’authentifier au système est présenté au diagramme d’activité de la figure 3.4.
Figure 3.4. Diagramme d’activité pour s’authentifier
La suite d’actions réalisées par un système embarqué pour transmettre la géolocalisation de la vache sur au serveur est illustrée à la figure 3.5.
Figure 3.5. Diagramme d’activité pour envoyer la géolocalisation.
Pour envoyer une alerte sur les troubles sanitaires de la vache à la base de données, le diagramme d’activité s’illustre à la figure 3.6.
Figure 3.6. Diagramme d’activité pour envoyer l’alerte.
Le diagramme d’activité pour qu’un acteur humain visualise la géolocalisation des vaches sur la mappe se présente à la figure 3.7.
Figure 3.7. Diagramme d’activité pour consulter la mappe.
Pour visualiser les alertes sur les troubles sanitaires émises par le système embarqué, l’enchaînement d’actions est illustré par le diagramme d’activité de la figure 3.8.
Figure 3.8. Diagramme d’activité pour voir les alertes.
Diagramme de classes
Dans un diagramme de classes, une classe décrit de façon abstraite, un ensemble d’objets partageant les mêmes propriétés et les mêmes comportements. Les propriétés d’une classe sont les attributs que peuvent avoir les objets de cette classe et les associations qui lient les objets entre eux, tandis que les comportements désignent les méthodes ou les opérations que ces objets peuvent subir [47].
Le diagramme de classes conçu pour obtenir le modèle de données à implémenter dans ce projet et présenté à la figure 3.9, est organisé en dix classes qui sont en association, et pour chaque classe, un constructeur, qui est une méthode servant d’initialisation des attributs de la classe, est créé avec le même nom que celui de la classe qui le porte.
La classe Ferme enregistre les attributs et méthodes relatifs à une ferme des vaches. Ces attributs sont le numéro de la ferme (attribut numFerme) qui est du type entier et unique à chaque ferme, le nom de la ferme (attribut nom) qui est du type chaine de caractères, la date de création de la ferme (attribut dateCreation) qui est du type date, l’adresse de la ferme (attribut adresse) qui est une chaîne de caractères, et le périmètre que couvre la ferme (attribut perimetre). Trois méthodes sont aussi exécutées dans cette classe, la méthode Ferme() qui est son constructeur, la méthode calculNbVaches() qui renvoie le nombre de vaches se trouvant dans la ferme, et la méthode calculNblitres qui renvoi le nombre de litres de lait produits par la ferme.
La classe Fermier regorge les attributs et méthodes relatifs à un fermier qui est affecté à une ferme donnée. Ces attributs sont le numéro du fermier (numFermier) qui est identifiant unique à chaque fermier et du type entier, le nom du fermier (attribut nom) qui est du type chaîne de caractères, son numéro de téléphone (attribut telephone) qui est une chaîne de caractères, sa date de naissance (attribut dateNaissance) et la référence de la ferme à laquelle il est affecté (l’attribut ferme) qui est du type objet de la classe Ferme. Elle contient également la méthode Fermier() qui joue de constructeur.
La classe Vache enregistre tous les attributs relatifs à une vache, tels sont le code de la vache (attribut codeVache) qui est une chaîne de caractères, sa date de naissance (attribut dateNaissance) qui est du type date, son sexe (attribut sexe) qui est une chaîne de caractères, ainsi que la référence de la ferme dans laquelle elle se trouve (attribut ferme) qui est du type objet de la classe Ferme. Elle contient aussi la méthode Vache() qui lui sert de constructeur.
La classe Production regorge les attributs relatifs à une production laitière. Ces attributs sont le numéro de production (numProduction) qui est du type entier, sa date (date) qui est du type date, la quantité produite en litres (quantite) qui est du type double, et la référence de la ferme dont elle provient (ferme) du type objet de la classe Ferme. Elle exécute également la méthode Production() qui lui sert de constructeur.
La classe Disparition renferme les attributs relatifs à une disparition bovine, c’est-à-dire le numéro de la disparition (attribut numDisparition) qui est du type entier, la date de disparition (attribut date) qui est du type date, la cause de la disparition (attribut cause) qui est du type chaîne de caractères, et la référence de la vache qui a disparu (attribut vache) qui est du type objet de la classe Vache. Elle exécute aussi la méthode Disparition() qui lui sert de constructeur.
La classe Capteur enregistre les attributs tels que le code du capteur (attribut codeCapteur) qui est du type chaîne de caractères, et le type de capteur qui est également du type chaine de caractères. La méthode Capteur() qu’elle exécute est son constructeur.
La classe Microcontrôleur contient les attributs tels que le code du microcontrôleur (attribut codeControleur) qui est du type chaîne de caractères, et sa famille (attribut famille) qui est du type chaine de caractères. La méthode Microcontroleur() qu’elle exécute lui sert de constructeur.
La classe Système embarqué comprend les propriétés relatives à un système embarqué. Ces propriétés sont les attributs tels que le numéro du système embarqué (numSysteme) qui est du type entier, la référence de la vache à laquelle il est associé qui est du type objet de la classe Vache, ainsi que les relations comme la collection des capteurs et la collection des microcontrôleurs qui l’agrègent. La méthode SystemeEmbarque() qu’elle exécute lui sert de constructeur.
La classe Alerte comprend le numéro de l’alerte (attribut numAlerte) qui est du type entier, l’instant auquel l’alerte a été lancée (attribut instant) qui est du type date, le contenu de l’alerte (attribut contenu) qui est du type chaîne de caractères, et la référence du système embarqué qui l’a lancée (attribut système) qui est du type objet de la classe Système embarqué.
Figure 3.9. Diagramme de classes du système proposé.
Diagramme d’états-transition
Dans un diagramme d’états-transition, un état désigne une situation stable et durable dans laquelle peut se trouver un objet de la classe que l’on cherche à connaître et à gérer. Une transition exprime, pour un objet, le passage d’un état à un autre, l’événement étant le stimulus qui la provoque [47].
Le diagramme d’états-transition conçu dans ce modèle concerne les objets de la classe Système embarqué. En effet, ces objets présentent un traitement complexe le long de tout leur cycle de vie et les différents états qu’il peuvent prendre méritent une attention particulière.
Ainsi, un système embarqué, ici composé des capteurs et du microcontrôleur, peut prendre, dès sa conception jusqu’à sa destruction, deux grands états, il peut être opérationnel ou non opérationnel. Pendant qu’il est opérationnel, sept états sont possibles, ces états sont donc imbriqués dans l’état composite «opérationnel». D’abord, il peut être allumé ou éteint. Une fois allumé, les différents composants entrent en synchronisation. Si la synchronisation a réussi, le système est dit synchronisé et les différents capteurs commencent les actions de détection des paramètres. Les valeurs détectées sont ensuite testées, le dispositif entre alors en état de test des valeurs. Si le test résulte les valeurs anormales, le système entre en état d’envoi d’alerte puis retarde la détection de cinq secondes.
La figure 3.10 illustre le diagramme d’états-transition pour un objet de la classe Système embarqué.
Figure 3.10. Diagramme d’états-transition d’un système embarqué.
Diagramme de composants
Le logiciel développé dans cette étude comprend deux principaux composants, le frontend tournant du côté client, et le backend tournant du côté serveur. Ces deux composants sont interfacés par la librairie axios.js qui joue d’API. Les contenus échangés entre ces deux composants, grâce aux méthodes POST et GET de la librairie axios.js qui permettent respectivement d’envoyer et de capturer les données et les services, sont codés et décodés en objets JSON4. Ainsi, le frontend est composé des composants VUE et des pages HTML, tandis que le backend comprend la base de données de l’application avec toutes ses tables et des fichiers PHP interagissant avec cette base de données.
La figure 3.11 illustre tous les composants du logiciel développé, la manière dont ils sont interfacés, les interfaces offertes et les interfaces requises des uns et des autres.
Figure 3.11. Diagramme de composants du système proposé.
4 La notation d’objet JavaScript ou en anglais JavaScript Object Notation (JSON) est un langage de sérialisation des données au format léger textuel pour les échanger et les rendre lisibles par l’utilisateur [58].
Diagramme de déploiement
L’environnement matériel et réseau d’exécution du système proposé dans cette étude et la façon dont ses différents composants sont installés, sont décrits par le diagramme de déploiement illustré à la figure 3.12. De ce diagramme il ressort que le code source de l’application est hébergé dans un serveur d’application et la base de données de l’application est logée dans un serveur de base de données. Les différents utilisateurs accèdent aux pages de l’application à travers les navigateurs web installés dans leurs postes de travail. L’ordinateur de l’Administrateur général, l’ordinateur du Préposé à l’élevage et le téléphone du fermier sont donc des instances du nœud Poste de travail utilisateur.
Figure 3.12. Diagramme de déploiement de la solution proposée.
Bilan du chapitre
L’application de l’approche méthodologique présentée dans ce chapitre, et spécialement les différents diagrammes UML conçus ont permis de modéliser les quatre plus une (4+1) vues du système à implémenter dans cette étude. Les quatre vues du système modélisées ici sont respectivement exprimées par le diagramme de classes qui traduit la vue logique, le diagramme d’états-transition qui traduit la vue de processus, le diagramme de composants qui traduit la vue de composants, et le diagramme de déploiement qui traduit la vue de déploiement. Ces différents diagrammes sont tous axés sur les besoins des utilisateurs exprimés ici par le diagramme de cas d’utilisation. L’application de la méthode expérimentale et de la méthode comparative est clairement indiquée dans la discussion des résultats au chapitre suivant, tandis que celle de la méthode de points de fonction est indiquée dans la section dédiée à l’estimation de coût du projet.
