Développement D'une Application Android Pour L'acquisition Et Le Traitement de Données Biomédicales À Partir D'une Smartwatch

ÉCOLE NATIONALE D’INGÉNIEURS DE TUNIS
Département des Technologies de l’Information et de la

communication
Génie Informatique
Sujet : Développement d’une

plateforme mobile pour
l’acquisition de données
biomédicales à partir
d’une smartwatch
Elaboré par :
Ibn abdallah Fida
Chakroun Rania
Encadré par :
Mme .Meherzi Soumaya
Mr .Ben lamine Khaled
Année universitaire : 2022/2023

Rapport de projet de fin d’année 2A INFO
Remerciements
Nous désirons exprimer nos sincères remerciements à Madame Soumaya Meherzi
et Monsieur Khaled Ben Lamine, nos encadrants, pour leur soutien inébranlable,
leurs conseils avisés, leur patience et leur engagement tout au long de notre projet.
Leurs précieux commentaires et encouragements ont grandement contribué à notre
succès dans cette mission.
Nous aimerions également exprimer notre profonde gratitude envers tous les
membres du jury pour leur temps, leur expertise et leur soutien dans l’évaluation
de notre projet.
Enfin, nous souhaitons adresser nos chaleureux remerciements à toutes les personnes
qui nous ont soutenus dans la réalisation de ce projet.
1
Table des matières
Introduction 1
1 Étude préliminaire 2
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Ètude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 L’IoT dans la télésurveillance médicale 5

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Définition de l’internet des objets . . . . . . . . . . . . . . . . . . . 5
2.2.1 Architecture de l’internet des objets . . . . . . . . . . . . . . 5
2.2.2 Les capteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Protocole de communication . . . . . . . . . . . . . . . . . . 7
2.3 l’Internet des objets dans le domaine de la santé . . . . . . . . . . . 7
2.4 Intégration de l’IOT dans la solution proposée . . . . . . . . . . . . 8
2.4.1 Firebase Cloud Messaging (FCM) . . . . . . . . . . . . . . . 8
2.4.2 Protocole MQTT . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.3 Protocole MQTT dans la plateforme ThingSpeak . . . . . . 10
2.4.4 L’architecture de SayFR . . . . . . . . . . . . . . . . . . . . 11
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Application de la SmartWatch 14
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Spécification et analyse des besoins . . . . . . . . . . . . . . . . . . 15
3.3.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . 15
3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . 19
2
3.4.2 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Application mobile 32
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Spécification et analyse des besoins . . . . . . . . . . . . . . . . . . 33
4.3.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . 34
4.4 Réalisation de l’application . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . 36
4.4.2 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3
Table des figures
1.1 Logo SayFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Architecture de l’internet des objets[1] . . . . . . . . . . . . . . . . 6

2.2 Capteurs de smartwatch Galaxy 4 . . . . . . . . . . . . . . . . . . . 7
2.3 Architecture de protocole MQTT[4] . . . . . . . . . . . . . . . . . . 10
2.4 Architecture de SayFR . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Architecture physique du projet . . . . . . . . . . . . . . . . . . . . 12
2.6 Diagramme de classe de SayFR . . . . . . . . . . . . . . . . . . . . 13
3.1 Vue d’ensemble de l’application de smartwatch . . . . . . . . . . . . 14

3.2 Le diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . 16
3.3 Diagramme de séquence pour le cas d’utilisation «Faire un compte» 17
3.4 Diagramme de séquence pour le cas d’utilisation «Envoyer notification» 18
3.5 Diagramme de séquence pour le cas d’utilisation «Envoyer les don-
nées biomédicales d’un patient» . . . . . . . . . . . . . . . . . . . . 18
3.6 Table «Patients» . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7 interface de création de compte . . . . . . . . . . . . . . . . . . . . 21
3.8 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . 22
3.9 Interface des choix de patient . . . . . . . . . . . . . . . . . . . . . 22
3.10 Interface d’envoie d’une notification en urgence . . . . . . . . . . . 23
3.11 Notification d’urgence . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.12 Interface de liste des signals . . . . . . . . . . . . . . . . . . . . . . 24
3.13 Interface d’envoie por le signal du rythme cardiaque . . . . . . . . . 24
3.14 Interface d’envoie por le signal ECG . . . . . . . . . . . . . . . . . . 25
3.15 Interface d’envoie por le signal PPG . . . . . . . . . . . . . . . . . . 25
3.16 Visualisation des données du signal du rythme cardiaque . . . . . . 26
3.17 Visualisation des données du signal ECG . . . . . . . . . . . . . . . 26
3.18 Visualisation des données du signal PPG . . . . . . . . . . . . . . . 27
3.19 Utilisation des données . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.20 Création d’un client . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.21 Connexion au canal . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4
3.22 Visualisation du signal de fréquence cardiaque . . . . . . . . . . . . 30
3.23 Visualisation de chaque signal de fréquence cardiaque . . . . . . . . 30
4.1 Vue d’ensemble de l’application mobile . . . . . . . . . . . . . . . . 33

4.2 Diagramme cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Diagramme de séquence pour le cas d’utilisation «Ajouter patient» 35
4.4 Diagramme de séquence pour le cas d’utilisation «Supprimer patient» 36
4.5 Table «Docteurs» . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6 Interface de création de compte . . . . . . . . . . . . . . . . . . . . 38
4.7 S’authentifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.14 profil du docteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.8 Ajouter patient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.9 Liste des patients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.10 Gestion des patients . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.11 Modifier patient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.12 Supprimer patient . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.13 Interface de modification du profil . . . . . . . . . . . . . . . . . . . 41
Introduction
Les plateformes mobiles sont devenues un élément clé de la santé connectée car
elles permettent de collecter et de gérer efficacement les données médicales générées
par des dispositifs portables tels que les montres connectées. En effet, ces dispositifs
peuvent fournir des données précises et en temps réel sur différents paramètres de
santé, notamment la fréquence cardiaque, la pression artérielle, les scores ECG et
PPG, ainsi que d’autres données qui peuvent être utilisées pour surveiller l’état de
santé d’un individu.
L’avantage de ces données est qu’elles peuvent être facilement partagées avec les
professionnels de la santé, ce qui permet une prise en charge plus personnalisée et
efficace des patients. Les plateformes mobiles permettent également de stocker les
données médicales des patients de manière centralisée, ce qui peut faciliter l’accès
aux données et la coordination entre différents professionnels de la santé.
Notre projet vise à développer une plateforme reliant une application sur une
montre connectée Galaxy Watch 4 à une application sur un téléphone pour acquérir
des données brutes provenant de différents capteurs tels que le capteur du signal
photoplethysmography (PPG) et le capteur du signal electrocardiography (ECG).
Afin de réaliser ce projet, nous avons utilisé le SDK Samsung Privileged Health qui
n’est pas en accès libre et nécessite une demande auprès de Samsung pour y avoir
accès.
Le rapport comprend quatre chapitres. Le premier chapitre aborde l’état de

l’art et l’étude théorique de notre projet. Le deuxième chapitre est consacré aux
concepts fondamentaux et l’implémentation de plateforme Iot dans le domaine de
la télésurveillance médicale. Le troisième chapitre se concentre sur la conception et
la réalisation de l’application pour la smartwatch, et le quatrième chapitre traite la
conception et la réalisation de l’application mobile.
1
Chapitre 1
Étude préliminaire
1.1 Introduction
Dans un premier lieu,cette partie est consacrée à mettre le projet dans son
cadre général en présentant le sujet. En seconde lieu, nous introduisons une étude
de l’existant afin d’obtenir des résultats assez riches et solides basant sur les
insuffisances des solutions existantes.
1.2 Présentation du projet

La branche de la télémédecine appelée télésurveillance médicale ou healthcare
monitoring connaît une croissance rapide grâce à la technologie IoT.
Son objectif est de surveiller à distance l’état de santé des patients atteints de ma-
ladies chroniques à risque élevé en utilisant des capteurs biomédicaux non-invasifs
connectés à Internet.
Ces capteurs permettent de mesurer en continu des indicateurs biologiques et de
les envoyer en temps-réel à l’équipe médicale. Bien que les montres connectées
soient devenues populaires pour la collecte de données biomédicales, il est crucial
d’avoir des applications fiables pour collecter et traiter ces données, permettant
des décisions éclairées sur la santé.
C’est là que notre projet SayFR intervient, en fournissant une plateforme pra-
tique et efficace pour collecter et traiter les données biomédicales des montres
connectées. Cette plateforme fournit également une interface intuitive pour visuali-
ser les données et envoyer des messages d’urgence et des alertes pour contacter le
médecin.
Le nom SayFR est inspiré de "safer" en anglais, soulignant l’objectif de rendre
les patients plus sains et plus sûrs, et est également inspiré des prénoms de ses
2
créateurs, Fida et Rania (FR).

En résumé, notre plateforme répond aux besoins humains en permettant aux utili-
sateurs de collecter des données de manière plus efficace et exploitable.
Figure 1.1 – Logo SayFR
1.3 Objectifs du projet

L’objectif principal de ce projet est del’acquisition et le traitement de données
biomédicales à partir d’une smartwatch. Plus précisément, les objectifs spécifiques
sont :
— Collecter de manière fiable et précise des données biomédicales telles que
la fréquence cardiaque, la pression artérielle, la saturation en oxygène, les
niveaux de stress,... à partir d’une smartwatch.
— Traiter et analyser les données collectées pour obtenir des informations
pertinentes sur la santé de l’utilisateur, telles que l’évolution de ses indicateurs
de santé, ses habitudes de sommeil, etc.
— Concevoir une interface utilisateur ergonomique et intuitive pour permettre
à l’utilisateur d’accéder facilement à ses données de santé, de les visualiser et
de les comprendre.
En somme, SayFR est une solution complète pour le suivi de la santé, qui bénéficie
aussi bien aux utilisateurs qu’aux professionnels de la santé.
1.4 Ètude de l’existant

Dans le but d’obtenir des résultats riches et fiables, nous faisons des recherches
approfondies sur les solutions existantes avant de développer le projet. En effet,
l’analyse ainsi que la collecte des données biomédicales à partir des smartwatch
est devenue un sujet d’intérêt croissant au cours de ces dernières années.Tant de
solutions ont été développées citant comme exemples :
3
Critère WaDa ROAMM Raproto SayFR
SE Android Tizen Tizen Android

Langage de programmation – – C Java
Interface utilisateur encombrée encombrée bien organisée clairement organisée
Compatibilité avec d’autre SE — — OUI OUI
Table 1.1 – Comparaison des applications.
— WaDa : une application autonome pour smartwatch avec systéme d’exploita-

tion Android qui a pour objectif la collecte de données à partir d’une montre.
Bien que la smartwatch WaDa et l’application de bureau soient disponibles
gratuitement à des fins de recherche et d’enseignement, elles ne sont pas open
source et ne peuvent donc pas être adaptées à des tâches spécifiques[11].
— ROAMM : une application de smartwatch sous Tizen comme systéme d’ex-
ploitation pour l’évaluation en ligne et le suivi de la mobilité. Bien que ce
cadre n’est pas open-source, le code peut être demandé dans des circonstances
limitées[11].
— Raproto : une plateforme open-source extensible pour le prototypage rapide
de dispositifs médicaux portables. Le système Raproto est composé d’une
application smartwatch, d’un protocole de communication et d’un serveur
pour la collecte et le stockage des données[11].
1.5 Conclusion
En conclusion, ce chapitre a présenté notre projet SayFR. Nous avons énoncé
nos objectifs spécifiques pour le développement de l’application, notamment la
collecte fiable et précise de données biomédicales, le traitement et l’analyse de ces
données, la conception d’une interface utilisateur ergonomique.
4
Chapitre 2
L’IoT dans la télésurveillance

médicale
2.1 Introduction
Dans ce chapitre, nous présentons les concepts fondamentaux liés au développe-
ment de la solution proposée. Plus précisément, nous nous intéressons à l’utilisation
de la technologie de l’internet des objets dans le domaine de la surveillance médicale
à distance.
2.2 Définition de l’internet des objets

L’internet des objets (IOT) représentent l’interconnexion entre Internet et les
objets, les positions et les environnements physiques. Ces objets sont tous des objets
quotidiens, et ces objets sont attribués aux nombres. Nous parlons de Web 3.0.
La technologie IoT permet des choses ou de l’équipement Les ordinateurs agissent
intelligemment et prennent de bonnes décisions collaboratives pour certaines appli-
cations. Il peut être identifié et des systèmes de capture de données, tels que la
température externe ou la fréquence cardiaque, ou le système de transmission de
données qui fournit des applications intelligentes ou l’interface de l’application[1].
2.2.1 Architecture de l’internet des objets

L’écosystème IoT est assez complexe, car il intègre plusieurs technologies et
domaines de compétences. Un système IoT englobe, généralement, à la fois du
hardware, des protocoles de communication, du software, du cloud et du mobile.
Ainsi, un projet IoT nécessite d’avoir une équipe pluridisciplinaire[2].
5
On peut décomposer un système IoT en 4 fonctionnalités distinctes comme le

montre la figure ci-dessous
Figure 2.1 – Architecture de l’internet des objets[1]
2.2.2 Les capteurs

La collecte des données dans le domaine de l’IoT est essentielle pour obtenir
des informations utiles à partir des dispositifs connectés. Les données collectées
peuvent être utilisées pour surveiller et contrôler les dispositifs IoT, ainsi que pour
fournir des informations sur les conditions environnementales, les performances
des machines et les comportements des utilisateurs. La collecte de données dans
l’IoT est souvent réalisée à l’aide de capteurs, qui peuvent mesurer une variété
de variables, telles que la température, l’humidité, la pression, la lumière, les
mouvements, les vibrations, etc. Les capteurs peuvent être intégrés à des dispositifs
IoT tels que des appareils portables, des véhicules connectés, des équipements
industriels, des bâtiments intelligents et des infrastructures urbaines. Parmis les
méthodes courantes pour collecter des données dans le domaine de l’IoT, y compris
l’utilisation des capteurs :
— Capteurs connectés à un réseau filaire :
Les capteurs peuvent être connectés à un réseau filaire tel que Ethernet pour
transmettre des données à un serveur central.
— Capteurs connectés à un réseau sans fil : Les capteurs peuvent être connectés
à un réseau sans fil tel que Wi-Fi, Bluetooth ou ZigBee pour transmettre des
données à un serveur central.
les montres intelligentes de la marque Samsung, comme la Galaxy Watch 4, celle-ci
6
est équipée d’un certain nombre de capteurs tels que :
— Capteur du signal PPG

— Accéléromètre
— Gyroscope
— Capteur de lumière ambiante
— Baromètre
— Capteur de température de la peau
— Capteur électrocardiogramme (ECG)
Figure 2.2 – Capteurs de smartwatch Galaxy 4
2.2.3 Protocole de communication

L’internet des objets (IdO) implique la communication entre des milliards
d’appareils, de capteurs et d’actionneurs, souvent éloignés les uns des autres. Pour
que ces appareils communiquent de manière fiable et efficace, ils doivent utiliser
des protocoles de communication spécifiques qui leur permettent de transmettre
des données de manière cohérente et sécurisée. Il existe plusieurs protocoles de
communication pour l’IdO, mais dans ce rapport, nous nous intéresserons au
protocole MQTT[10].
2.3 l’Internet des objets dans le domaine de la

santé
Le domaine de la santé n’a pas très vite adopté l’internet des objets mais une
fois que cela a été fait, les manifestations sont remarquables. Internet des objets
médicaux (IoMT) permet de contrôler et de suivre les patients à distance et même
7
d’identifier certains problèmes médicaux. En quelques années, on a remarqué une

explosion des objets médicaux connectés sur le marché mondial. La plupart sont des
outils de contrôle à distance des patients qui envoient des notifications au personnel
soignant en cas d’urgence. Plus encore, des systèmes sont mis en place pour la
collecte des données qui sont ensuite transmises à travers le réseau[3].
2.4 Intégration de l’IOT dans la solution propo-

sée
— Dans notre plateforme, nous avons utilisé deux concepts clés de l’IoT pour
connecter la smartwatch et l’appareil mobile. Le premier concept est Cloud
Messaging de Firebase, qui est une solution de messagerie en temps réel pour
les applications mobiles et web. Nous avons intégré cette fonctionnalité pour
permettre la communication entre le patient et son docteur de manière rapide
et fiable.
— Le deuxième concept que nous avons utilisé est le protocole MQTT, qui est
un protocole de communication de messagerie légère conçu pour les appareils
à faible puissance et à faible bande passante. Nous avons intégré ce protocole
dans la plateforme ThingSpeak pour permettre la collecte de données de la
smartwatch en temps réel et leur transmission vers le cloud.
— En combinant ces deux concepts, nous avons pu établir une connexion fiable
entre la smartwatch et l’application mobile, tout en permettant la collecte
de données en temps réel et leur stockage dans le cloud pour une analyse
ultérieure.
2.4.1 Firebase Cloud Messaging (FCM)

a/ Définition
— Firebase Cloud Messaging (FCM) est un service de messagerie en temps
réel qui permet aux développeurs d’envoyer des notifications et des
messages cloud à des applications mobiles Android, iOS et Web. FCM
remplace le service de messagerie GCM (Google Cloud Messaging) de
Google et fournit des fonctionnalités améliorées telles que la détection
de l’état de la connexion réseau, les messages groupés et les notifications
riches[8].
— En utilisant FCM, les développeurs peuvent envoyer des notifications
et des messages à des utilisateurs ciblés en temps réel, ce qui améliore
l’expérience utilisateur et l’engagement[8].
8
b/ Architecture de CFM
L’architecture de FCM se compose de trois parties principales :
— Application client : C’est l’application mobile qui envoie et reçoit les
messages de notification. Les applications peuvent recevoir des messages
même lorsqu’elles sont en arrière-plan ou qu’elles ne sont pas en cours
d’exécution[8].
— Serveur d’application : Il s’agit de l’application qui envoie les messages
de notification aux clients via le serveur de cloud messaging de Firebase.
Le serveur d’application peut être hébergé sur un cloud public ou privé[8].
— Serveur de Cloud Messaging de Firebase (FCM) : Le serveur
de FCM reçoit les messages de notification des serveurs d’application
et les transmet aux appareils clients appropriés. FCM prend en charge
plusieurs protocoles, notamment HTTP et XMPP, pour la transmission
de messages[8].
2.4.2 Protocole MQTT

a/ Définition
— Le protocole MQTT (Message Queuing Telemetry Transport) est un
protocole de messagerie léger, basé sur le modèle de publication/abonne-
ment, conçu pour les applications IoT (Internet des objets) où la bande
passante est limitée et la connectivité intermittente peut être un défi[9].
— Il permet aux dispositifs de publier des messages sur un serveur de mes-
sagerie (broker) et de s’abonner à des messages sur le même serveur[9].
— Les messages peuvent contenir des données telles que des capteurs, des
alertes ou des commandes[9].
— MQTT est souvent utilisé pour la collecte et la diffusion de données en
temps réel dans des réseaux de capteurs ou de dispositifs connectés[9].
b/ Architecture de protocole MQTT

Le protocole MQTT suit une architecture de type publish/subscribe, où
les clients MQTT peuvent se connecter à un courtier (broker) pour publier
(publish) des messages ou s’abonner (subscribe) à des sujets (topics) pour
recevoir des messages.
L’architecture MQTT se compose de trois entités principales :
— Le client MQTT : c’est l’application ou l’appareil qui publie ou
s’abonne à des messages via le broker MQTT. Les clients MQTT peuvent
être des appareils IoT, des applications mobiles, des capteurs, etc[5].
9
— Le broker MQTT : c’est le serveur central qui reçoit les messages

publiés par les clients MQTT et les distribue aux clients qui sont abonnés
aux sujets correspondants. Le broker MQTT peut être hébergé sur le
cloud ou localement sur un serveur[5].
— Le sujet (topic) MQTT : c’est une chaîne de caractères utilisée pour
identifier les messages publiés. Les clients MQTT peuvent s’abonner à
un ou plusieurs sujets pour recevoir les messages correspondants[5].
Figure 2.3 – Architecture de protocole MQTT[4]
2.4.3 Protocole MQTT dans la plateforme ThingSpeak

— Dans la plateforme ThingSpeak, le protocole MQTT est utilisé pour la
communication entre les appareils IoT (Internet des Objets) et le cloud
ThingSpeak. ThingSpeak fournit un serveur MQTT pour permettre aux
appareils IoT de publier et de souscrire des données en temps réel.
— Le protocole MQTT est utilisé pour la transmission de données de
capteurs, telles que des données de température, de pression, d’humidité,
etc., depuis les appareils IoT jusqu’au cloud ThingSpeak. Les données
sont encapsulées dans des messages MQTT et envoyées à un canal
ThingSpeak approprié.
— En utilisant le protocole MQTT, les appareils IoT peuvent envoyer des
messages à un canal ThingSpeak de manière fiable, avec une latence
minimale et une utilisation efficace de la bande passante. De plus, les
développeurs peuvent utiliser des bibliothèques de protocole MQTT
existantes pour simplifier le développement d’applications IoT pour
ThingSpeak.
10
2.4.4 L’architecture de SayFR

L’architecture de SayFR est mieux illustré dans la figure 2.3.
Figure 2.4 – Architecture de SayFR
L’architecture physique exploitée est l’architecture en trois niveaux : qui permet de

répartir lesystème sur 2 niveaux qui sont :
- Niveau présentation : Les deux applications (l’application mobile et l’application
de smartwatch)
- Niveau de logique applicative : Serveur
- Niveau de stockage des données : Base de donnée
Cette architecture est mieux illustrée par le diagramme de déploiement suivant :
11
Figure 2.5 – Architecture physique du projet
La conception de la plateforme est décrite à l’aide d’un diagramme de classe

dans la figure ci-dessous :
12
Figure 2.6 – Diagramme de classe de SayFR
2.5 Conclusion
En conclusion, dans ce chapitre, nous avons avons définir quelques notions qu’on
va l’utilisés dans la suite de rapport. nous avons abordé le sujet de l’internet des
objets dans le domaine de la santé. Nous avons également parlé de son rôle dans
notre projet.
13
Chapitre 3
Application de la SmartWatch
3.1 Introduction
Dans ce chapitre nous allons identifier les acteurs de notre application du
smartwatch, ainsi qu’à les modéliser à l’aide de diagrammes de cas d’utilisation et
de séquence. Nous allons ensuite parlé de la réalisation de notre application.
3.2 Présentation
L’application de la smartwatch enregistre les données des capteurs, les stocke et
les transmet. Elle propose une interface utilisateur facile à l’utilisation. L’application
a été développée sur les smartwatches Samsung Galaxy 4. Ces derniers fonctionnent
avec le système d’exploitation Android, qui fournit des SDK pour gérer et interagir
avec les capteurs et les protocoles de communication.
Figure 3.1 – Vue d’ensemble de l’application de smartwatch
14
3.3 Spécification et analyse des besoins

3.3.1 Analyse des besoins
Identification des acteurs
Un acteur est un utilisateur qui est censé utiliser le système pour atteindre
un objectif bien défini objectif. Comme notre application est destinée à un seul
utilisateur qui est le propriétaire de la smartwatch, c’est donc le seul acteur principal
qui utilise l’application en créant son compte pour voir la liste des signaux qui
peuvent être collectés tels que le score ECG, le score PPG... et envoyer les données
de ces signaux.
Besoins fonctionnels
Notre application offre à notre acteur les fonctions suivantes :
— BF1 : Se connecter ou faire un compte.
— BF2 : Envoyer les données des signaux.
— BF3 : Envoyer un message à son médecin.
— BF4 : Envoyer une notification en urgence.
Besoins non fonctionnels

La qualité de l’application présente un facteur important afin de garantir un pro-
duit satisfaisant aux besoins du client. De ce fait, nous visons à satisfaire quelques
considérations que nous trouvons essentielles à savoir :
— Efficacité : L’application doit envoyer les données avec une précision.

— Réutilisabilité : Le code de l’application devra être commenté et très clair
pour permettre des futures améliorations.
— Ergonomie : L’interface utilisateur doit être clair et facile à comprendre.
3.3.2 Spécification des besoins

Langage de modélisation
Pour modéliser les entités, nous avons choisi UML «Unified Modeling Language»
qui est un langage de modélisation visuel commun, sémantiquement et syntaxique-
ment riche pour l’architecture, la conception et la mise en œuvre de système.
Nous présentons dans ce qui suit, le diagramme de cas d’utilisation et les diagrammes
de séquence du système afin de nous aider à bien comprendre le fonctionnement et
le déroulement de fonctionnalités.
15
Les diagrammes de spécification

— Diagramme de cas d’utilisation :
Le diagramme de cas d’utilisation peut résumer les détails des acteurs et
leurs interactions avec le système.
Figure 3.2 – Le diagramme de cas d’utilisation
— Diagrammes de séquence systéme :

Nous nous sommes concentrés dans cette partie sur l’illustration des dia-
grammes de séquence du système pour les cas d’utilisation «Faire un compte»,
«Envoyer notification en urgence» et «Envoyer ses données biomédicales».
16
Figure 3.3 – Diagramme de séquence pour le cas d’utilisation «Faire un compte»
17
Figure 3.4 – Diagramme de séquence pour le cas d’utilisation «Envoyer notifica-

tion»
Figure 3.5 – Diagramme de séquence pour le cas d’utilisation «Envoyer les données
biomédicales d’un patient»
18
3.4 Réalisation
3.4.1 Environnement de travail
Configuration matérielle :
Pour mettre en en oeuvre ce projet, nous avons travaillé sur un ordinateur personnel,
dont la configuration est la suivante :
— Ordinateur : PC PORTABLE HP windows 10
— Processeur : Intel(R) Core(TM) i5-8250U CPU 1.60GHz 1.80 GHz
— Mémoire installée(RAM) : 8.0 GB
Nous avons utilisé aussi la smartwatch Samsung Galaxy Watch 4 qui fonctionne
avec le systéme d’exploitation Abdroid.
Environnement logiciel :
Cette partie est consacrée à citer les logiciels utilisés à la réalisation de notre
application :
— Android Studio : Un environnement de développement des applications mo-
biles Android. Il est basé sur IntelliJ IDEA et utilise le moteur de production
Gradle.
— Firebase : Firebase est une plateforme mobile de Google conçue pour simplifier
la création d’un back-end à la fois évolutif et performant. En d’autres termes,
elle offre une solution rapide pour développer des applications mobiles et
Web.
— ThingSpeak : C’est est un API destinée au domaine de l’Internet des objets
qui nous a permis de collecter et stocker les données provenant des capteurs
de smartwatch en utilisant le protocole MQTT. Dans notre projet, nous
avons opté pour l’utilisation de ce protocole. En outre, ThingSpeak est équipé
d’outils de traitement de données numériques tels que le calcul de la moyenne,
la médiane, la somme, etc. en plus de stocker et récupérer ces données[5].
— Github : C’est une plateforme d’hébergement de code pour le contrôle de
version et la collaboration. Elle permet de partager et sauvegarder le code et
héberge plus d’une dizaine de millions de repositories.
Choix technologiques :
Dans cette partie, nous présentons les langages de programmation et les biblio-
thèques utilisées dans notre application en justifiant à chaque fois notre choix :
— Langage de programmation :
- Java : C’est un langage de programmation populaire pour la création d’appli-
19
cations web et mobile. C’est un langage multiplateforme, orienté objet. Nous

avons choisis de travailler avec Java pour son accés direct aux fonctionnalités
et API du systéme d’exploitation android pour la gestion des capteurs qui
facilite l’integration d’autre fonctionnalité tels que le stockage de données et
la synchronisation avec d’autres appareils.
— Bibliotheques et SDK :
- Samsung Privileged Health SDK | Tracking Service : La plateforme de santé
fournit le suivi des données de santé et l’accès aux données de stockage de
santé. Son service de suivi fournit des données de capteurs brutes et traitées
telles que l’accéléromètre, PPG et les données de composition corporelle que
le capteur BioActive a envoyées. Le nouveau capteur BioActive de la Galaxy
Watch exécute précisément trois capteurs de santé puissants tels que le PPG,
l’ECG, le BIA, la perte de sueur et le SpO2.
Les API de suivi du Samsung Privileged Health SDK permettent à une
application partenaire de suivre les données de capteurs liées à la santé. Une
application importe la bibliothèque de suivi du SDK (priv-health-tracking.aar)
et définit un écouteur d’événements de suivi pour recevoir des événements
de données. Les données de suivi sont transférées à l’application avec des
événements ponctuels ou périodiques jusqu’à ce que l’écouteur d’événements
soit supprimé. Le nombre d’événements et la fréquence des événements
diffèrent selon le type de suivi.
- Les bibliothèques Firebase : pour le stockage, la récupération et la synchro-
nisation des données en temps réel dans la base de données Firebase. Les
bibliothèques Firebase pour Android comprennent également d’autres outils
tels que l’authentification, les notifications, l’analyse, le reporting d’erreurs,
la messagerie en temps réel, la gestion à distance, etc.
- La Bibliothéque Eclipse Paho Java Client : C’est une bibliothèque de clients
MQTT open-source écrite en Java et développée par la fondation Eclipse.
Elle permet de créer des clients MQTT pour communiquer avec des brokers
MQTT. Cette bibliothéque nous facilite l’implementation des fonctionnalités
de communication entre l’application est le broker MQTT[7].
3.4.2 Implémentation
Dans cette partie nous allons présenter le schéma de la base données de notre
application et quelques imprimes écran :
20
Figure 3.6 – Table «Patients»
la figure ci-dessus illustre le schéma du table patients dans la base données de

firebase.
Nous exposerons dans cette section les interfaces Homme-machine de Smart-
Watch. Pour stocker ses informations dans la base de données de firebase l’utilisateur
doit faire un compte.
Figure 3.7 – interface de création de compte
Si l’utilisateur a déjà un compte il se connecte directement. Une fois authentifié,

le patient peut accéder à son espace. il peut consulter la liste des choix possibles, il
peut soit envoyer ses données biomédicales(heartrate, ECG, PPG red, PPG green)
soit envoyer une notification d’urgence aux médecins.
La figure 3.10 illustre ces choix.
21
Figure 3.8 – Interface d’authentification
Figure 3.9 – Interface des choix de patient
La figure ci-dessous, présente l’interface qu’on obtient lorsque le patient clique

sur le boutton d’envois une notification d’urgence.
22
Figure 3.10 – Interface d’envoie d’une notification en urgence
Après avoir rempli le formulaire et cliqué sur le bouton d’envoi, une notification
est envoyée au médecin, comme le montre la figure ci-dessous.
Figure 3.11 – Notification d’urgence
La figure 3.12 ci-dessous, présente l’interface qu’obtient le patient lorsqu’il clique

sur le boutton d’envois des données biomédicales.
Cette interface lui propose une liste des signals qu’il peut envoyer (HeartRate,
ECG, PPG green, PPG red)
23
Figure 3.12 – Interface de liste des signals
L’application peut récupérer des données de capteurs avec un événement de re-

groupement. L’événement sera récupéré à chaque période spécifiée avec les données
de capteur collectées.
— HEART RATE : Dans 600 points de données de fréquence cardiaque, toutes

les 10 minutes (1 Hz).
PPG GREEN : Dans 300 points de données PPG vert, toutes les 12 secondes
(25 Hz).
— PPG RED : 1 point de données PPG rouge, toutes les 10 millisecondes (100
Hz).
— ECG : 5 points de données ECG, toutes les 10 millisecondes (500 Hz). Sinon,
10 points de données ECG, toutes les 20 millisecondes (500 Hz).
En cliquant sur le signal souhaité pour envoyer ses données au médecin, l’application
lui demande de commencer l’envoi, comme le montre la figure ci-dessous.
Figure 3.13 – Interface d’envoie por le signal du rythme cardiaque
24
Figure 3.14 – Interface d’envoie por le signal ECG
Figure 3.15 – Interface d’envoie por le signal PPG
Lorsque l’utilisateur clique sur le bouton "START", les données du signal asso-
ciées à cette action sont récupérées à partir des capteurs de la montre et traitées par
notre code d’application. Une fois le traitement terminé, les données sont affichées
sur le terminal Android Studio. Comme illustré dans les figures suivantes :
25
Figure 3.16 – Visualisation des données du signal du rythme cardiaque
Figure 3.17 – Visualisation des données du signal ECG
26
Figure 3.18 – Visualisation des données du signal PPG
Dans le but d’améliorer la visualisation des données dans notre application

Android, nous prévoyons d’envoyer les données collectées vers le serveur ThingSpeak.
En utilisant cette plateforme, nous pourrons stocker les données collectées dans un
canal spécifique et les visualiser sous forme de graphiques et de tableaux en temps
réel.
Pour ce faire, nous devons suivre les étapes suivantes : dans notre application
smartwatch, nous utilisons ces informations pour envoyer les données vers le
tableau de bord de ThingSpeak en se connectant au client créé dans la plateforme
ThingSpeak.
— Créer un compte ThingSpeak.
— Créer un canal ThingSpeak : Une fois connecté à notre compte, nous pouvons
créer un nouveau canal ThingSpeak en cliquant sur l’onglet "New Channel"
dans le tableau de bord.
— Configurer les champs : Dans notre nouveau canal ThingSpeak, nous de-
vons configurer les différents champs pour les données que nous souhaitons
visualiser.
— Créer un client : Dans ThingSpeak, nous pouvons créer un dispositif qui doit
être connecté à notre canal en cliquant sur l’onglet "add new device" .
— Récupérer les données : Pour envoyer les données de notre application smart-
27
watch vers ThingSpeak, nous devons récupérer l’ID et le mot de passe du

client ainsi que l’ID de notre canal. Ces informations sont disponibles dans
l’onglet "Channel Settings" du tableau de bord pour le canal
— Envoyer des données à ThingSpeak : Dans notre application, on utilise ces
informations pour envoyer des données vers le tableau de bord de ThingSpeak
en se connectant au client créé dans la plateforme.
Figure 3.19 – Utilisation des données
Figure 3.20 – Création d’un client
28
Figure 3.21 – Connexion au canal
— Visualiser les données : Les données seront visualisées dans la plateforme

Thingspeak sur les "dashboard", de la façon dont nous avons configuré les
champs.
29
Figure 3.22 – Visualisation du signal de fréquence cardiaque
Figure 3.23 – Visualisation de chaque signal de fréquence cardiaque
30
3.5 Conclusion
Dans ce chapitre, nous avons parlé de l’application de la montre. Nous avons
cité ses besoins fonctionnels et ses besoins non fonctionnels. Ce qui nous a permis
de procure une vision claire sur le fonctionnement de notre solution en s’appuyant
sur les différents diagrammes.
31
Chapitre 4
Application mobile
4.1 Introduction
Ce chapitre consiste à présenter notre application mobile et à identifier ses
acteurs, ainsi qu’à les modéliser à l’aide de diagrammes de cas d’utilisation et de
séquence. Nous allons ensuite parler de la réalisation de notre application.
4.2 Présentation
Notre application permet aux médecins de surveiller à distance l’état de leurs
patients en créant un compte et en ajoutant le profil du patient. Lorsque l’application
smartwatch envoie les données du capteur, notre application mobile les reçoit et les
enregistre dans le profil du patient.
32
Figure 4.1 – Vue d’ensemble de l’application mobile
4.3 Spécification et analyse des besoins

4.3.1 Analyse des besoins
Identification des acteurs
Notre application est destinée à un seul utilisateur qui est le médecin, c’est
donc le seul acteur principal qui utilise l’application en créant son compte pour
voir la liste de ses patients et voir leurs profils.
Besoins fonctionnels
Notre application offre à notre acteur les fonctions suivantes :
— BF1 : Se connecter ou faire un compte.
— BF2 : Ajouter un patient.
— BF3 : Mise à jour d’un patient.
— BF4 : Suppression d’un patient.
— BF5 : Voir la liste des patients.
— BF6 : Mise à jour de son profil.
33
Besoins non fonctionnels

Nous visons à satisfaire pour cette application aussi :
— L’efficacité.
— La réutilisabilité.
— L’ergonomie.
4.3.2 Spécification des besoins

Nous présentons dans ce qui suit, le diagramme de cas d’utilisation et les
diagrammes de séquence du système afin de nous aider à bien comprendre le
fonctionnement et le déroulement de fonctionnalités.
Diagramme de cas d’utilisation

La figure ci-dessous illustre le diagramme des cas d’utilisation de l’application
mobile.
Figure 4.2 – Diagramme cas d’utilisation
34
Diagrammes de séquence systéme

Nous nous sommes concentrés dans cette partie sur l’illustration des diagrammes
de séquence du système pour les cas d’utilisation «Ajouter patient», «Supprimer
patient».
Figure 4.3 – Diagramme de séquence pour le cas d’utilisation «Ajouter patient»
35
Figure 4.4 – Diagramme de séquence pour le cas d’utilisation «Supprimer patient»
4.4 Réalisation de l’application

4.4.1 Environnement de travail
Configuration matérielle :
Pour mettre en en oeuvre cette application, nous avons travaillé sur 2 ordinateurs
personnels, dont la configuration est la suivante :
— Ordinateurs :
- PC PORTABLE HP windows 10
- PC PORTABLE MSI windows 11
— Processeur :
- Intel(R) Core(TM) i5-8250U CPU 1.60GHz 1.80 GHz
- Intel(R) Core(TM) i7-10750H CPU 2.60GHz 2.59 GHz
— Mémoire installée(RAM) :
- 8.0 GB
- 16.0 GB
36
Nous avons également utilisé comme émulateur un appareil virtuel Pixel 5 API 30
qui fonctionne avec le système d’exploitation Android 11.
Environnement logiciel :
Pour mettre en oeuvre cette application nous avons utilsé aussi
— Android Studio
— Firebase
— Github
Choix technologiques :
Pour programmer cette application nous avons utilisé le langage de programmation
Java, les bibliothéques de Firebase pour le stockage et la récupération des données
et la bibliothéque Eclipse Paho Java Client.
4.4.2 Implémentation
Dans cette partie nous allons présenter le schéma de la base données de notre
application et quelques imprimes écran :
Figure 4.5 – Table «Docteurs»
la figure ci-dessus illustre le schéma du table docteurs dans la base données de

firebase.
Nous exposerons alors dans la section suivantes les interfaces Homme-machine de
notre application mobile. Pour stocker ses informations dans la base de données de
firebase l’utilisateur doit faire un compte.
37
Figure 4.6 – Interface de création de compte
Si l’utilisateur a déjà un compte il se connecte directement. Une fois authentifié,

le docteur peut accéder à son espace. il peut consulter la liste des patients, ajouter,
modifier et supprimer un patients. Il peut également modifier son profil.
38
Figure 4.7 – S’authentifier
Figure 4.14 – profil du docteur
39
Figure 4.8 – Ajouter Figure 4.9 – Liste des

patient patients
Figure 4.10 – Gestion des patients
Figure 4.11 – Modifier patient
40
Figure 4.12 – Supprimer patient
Figure 4.13 – Interface de modification du profil
41
Après que les données de signal d’un patient sont envoyées au serveur par la
smartwatch, le médecin peut consulter ces données en accédant à l’interface de
ce patient par le bouton "SEE MORE" dans l’interface de liste des patients. Ce
processus est effectué en connectant l’application mobile par le protocole mqtt et à
la même canal de la plateforme ThingSpeak que celle utilisée par la smartwatch.
4.5 Conclusion
Dans ce chapitre, nous avons parlé au début de l’architecture générale du projet
puis nous avons cité les besoins fonctionnels et les besoins non fonctionnels.Ce qui
nous a permis de procure une vision claire sur le fonctionnement de notre solution
en s’appuyant sur les différents diagrammes.
La création d’une plateforme de collecte et de traitement de données biomédi-
cales à partir d’une montre connectée représente un défi passionnant et porteur
d’espoir dans le domaine de la santé connectée.
Basée sur le concept de l’Internet des objets (IoT), une telle plateforme nécessite
le développement d’un ensemble de composants liés entre eux. Dans le cadre du
présent projet, nous avons pu développer une application permettant d’accéder aux
données brutes des capteurs embarqués dans une Galaxy Watch 4.
D’une part, nous avons développé une application Android permettant d’accéder
aux données des capteurs et de les envoyer à un serveur distant sur la plateforme
thingspeak. Dans cette étape, nous avons dû utiliser le SDk fourni par Samsung
(après une demande) pour pouvoir lire les données brutes des capteurs.
Dans un second temps, nous avons développé une application mobile permettant
d’accéder aux données enregistrées sur le serveur à partir d’un terminal mobile. La
solution que nous avons proposée est une étape importante pour la mise en place
d’une plateforme de collecte de données à partir de smartwatches. Elle peut être
améliorée par l’ajout d’autres fonctionnalités enrichissantes.
Ce projet nous a permis de consolider non seulement notre formation théo-

rique à travers différents concepts tels que l’IoT mais aussi nos compétences en
développement mobile.
42
Webographie
[1] https://blog.engineering.publicissapient.fr/2015/12/02/linternet-
des-objets-101//ConsultÃľle:01/02/2023.
[2] https://iotindustriel.com/iot-iiot/architecture-iot-lessentiel-
a-savoir/#:~:text=L’architectureConsultÃľle:01/02/2023.
[3] https://webmedy.com/blog/fr/top-benefits-of-iot-in-healthcare/
ConsultÃľle:01/02/2023.
[4] https://www.paessler.com/fr/it- explained/mqttConsultÃľle:04/
04/2023.
[5] https://www.comparitech.com/net-admin/what-is-mqtt/ConsultÃľle:
04/04/2023.
[6] https://www.automation- sense.com/blog/blog- objets- connectes/
thingspeak - api - pour - objets - connectes . htmlConsultÃľle : 04 / 04 /
2023.
[7] https://qkzk.xyz/docs/nsi/cours_premiere/programmation/outils/
libraries_faciles/mqtt/#:~:text=IntroductionConsultÃľle:04/04/
2023.
43
Bibliographie
[8] Guido Albertengo et al. « On the performance of web services, google

cloud messaging and firebase cloud messaging ». In : Digital Communications
and Networks 6.1 (2020), p. 31-37.
[9] TAHA MOHAMED ELAMINE ARADJ. « Usage du protocole MQTT dans
une application de suivi ». In : ().
[10] Sylvain Müller. « Sécurisation d’un réseau d’équipement loT avec le proto-
cole Oauth ». In : (2018).
[11] Amanda Watson et al. « Raproto : an open source platform for rapid
prototyping of wearable medical devices ». In : Proceedings of the Workshop
on Medical Cyber Physical Systems and Internet of Medical Things. 2021,
p. 1-6.
44

Développement D'une Application Android Pour L'acquisition Et Le Traitement de Données Biomédicales À Partir D'une Smartwatch

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Développement D'une Application Android Pour L'acquisition Et Le Traitement de Données Biomédicales À Partir D'une Smartwatch

Transféré par

Droits d'auteur :

Formats disponibles

ÉCOLE NATIONALE D’INGÉNIEURS DE TUNIS

Département des Technologies de l’Information et de la

Sujet : Développement d’une

Année universitaire : 2022/2023

2 L’IoT dans la télésurveillance médicale 5

1.1 Logo SayFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Architecture de l’internet des objets[1] . . . . . . . . . . . . . . . . 6

3.1 Vue d’ensemble de l’application de smartwatch . . . . . . . . . . . . 14

4.1 Vue d’ensemble de l’application mobile . . . . . . . . . . . . . . . . 33

Le rapport comprend quatre chapitres. Le premier chapitre aborde l’état de

1.2 Présentation du projet

créateurs, Fida et Rania (FR).

Figure 1.1 – Logo SayFR

1.3 Objectifs du projet

1.4 Ètude de l’existant

Critère WaDa ROAMM Raproto SayFR

SE Android Tizen Tizen Android

Table 1.1 – Comparaison des applications.

— WaDa : une application autonome pour smartwatch avec systéme d’exploita-

L’IoT dans la télésurveillance

2.2 Définition de l’internet des objets

2.2.1 Architecture de l’internet des objets

On peut décomposer un système IoT en 4 fonctionnalités distinctes comme le

Figure 2.1 – Architecture de l’internet des objets[1]

2.2.2 Les capteurs

est équipée d’un certain nombre de capteurs tels que :

— Capteur du signal PPG

Figure 2.2 – Capteurs de smartwatch Galaxy 4

2.2.3 Protocole de communication

2.3 l’Internet des objets dans le domaine de la

d’identifier certains problèmes médicaux. En quelques années, on a remarqué une

2.4 Intégration de l’IOT dans la solution propo-

2.4.1 Firebase Cloud Messaging (FCM)

2.4.2 Protocole MQTT

b/ Architecture de protocole MQTT

— Le broker MQTT : c’est le serveur central qui reçoit les messages

Figure 2.3 – Architecture de protocole MQTT[4]

2.4.3 Protocole MQTT dans la plateforme ThingSpeak

2.4.4 L’architecture de SayFR

Figure 2.4 – Architecture de SayFR

L’architecture physique exploitée est l’architecture en trois niveaux : qui permet de

Figure 2.5 – Architecture physique du projet

La conception de la plateforme est décrite à l’aide d’un diagramme de classe

Figure 2.6 – Diagramme de classe de SayFR

Figure 3.1 – Vue d’ensemble de l’application de smartwatch

3.3 Spécification et analyse des besoins

Besoins non fonctionnels

— Efficacité : L’application doit envoyer les données avec une précision.

3.3.2 Spécification des besoins

Les diagrammes de spécification

Figure 3.2 – Le diagramme de cas d’utilisation

— Diagrammes de séquence systéme :

Figure 3.3 – Diagramme de séquence pour le cas d’utilisation «Faire un compte»

Figure 3.4 – Diagramme de séquence pour le cas d’utilisation «Envoyer notifica-

cations web et mobile. C’est un langage multiplateforme, orienté objet. Nous

Figure 3.6 – Table «Patients»

la figure ci-dessus illustre le schéma du table patients dans la base données de

Figure 3.7 – interface de création de compte

Si l’utilisateur a déjà un compte il se connecte directement. Une fois authentifié,

Figure 3.8 – Interface d’authentification

Figure 3.9 – Interface des choix de patient

La figure ci-dessous, présente l’interface qu’on obtient lorsque le patient clique

Figure 3.10 – Interface d’envoie d’une notification en urgence