République Algérienne Démocratique et

Populaire
Ministère de l’enseignement supérieur et de
La recherche scientifique
Université Larbi Tébessi – Tébessa

Faculté des Sciences Exactes et des Sciences de la Nature et de la Vie

Département : Mathématiques et Informatique

Mémoire de fin d'étude

Pour l'obtention du diplôme de LICENCE

Domaine : Mathématiques et Informatique

Filière : Informatique

Conception et réalisation d’une Application mobile

carte fidélité pour laboratiore d’analyse médical
«MedicLab»

Option : Systèmes d’information

Thème Présenté Par :

 Harkati Oussama
 Cheriet Mohamed

 Encadreur : Dr. Bendib Issam

 Devant l’examinateur :Dr. Daouadi.K
 Date de soutenance :05/06/2022
 Résumé

Ce projet vise à créer une application mobile de carte de fidédilé pour laboratoire d’analyse médical
La mémoire contient une partie théorique sur l’introduction au contexte où nous avons effectué une étude de
l’existant afin de dégager les différents problèmes reconnus pour la gestion et la comptabilité de fidélité pour
laboratoire médical et de définir les solutions possibles puis une bref description sur les applications mobiles.
Nous avons opté pour l’approche UML pour décrire les principales fonctionnalités de notre système,
dans une deuxième étape nous avons utilisé la plateforme Android pour la réalisation de l’application mobile
qui se base sur java et [Link] système de gestion de base de données choisi est Firebase.
Mots clés : Fidélité, Laboratoire d’analyses medical , application mobile, ANDROID, Firebase.

Abstract

This project aims to create a mobile application of loyalty card, accounting and administrator medical
analysis laboratory. This dissertation contains a theoretical part about the introduction of the context where we
carried out a study of the existing one in order to identify the different problems recognized to the cash
management and loyalty client of the medical analysis laboratory and to define the possible solutions then we
presented a small description about the mobiles [Link] elected the UML approach to describe the
principle functionalities of our system
In a second step, we used the android platform to implement the mobile application that is based on java
and [Link] database management use dis firebase.
Key words: loyalty, medical analysis, mobile application, ANDROID, Firebase.

‫ملخـص‬

‫ٌهدف هذا المشروع إلى انشاء تطبٌق للهاتف المحمول بطاقة وفاء لمخبر التحالٌل الطبٌة‬
‫تحتوي هذه المذكرة على جزء نظري حول مقدمة عن المحتوى أٌن اجرٌنا دراسة حول الحالة الموجودة من أجل‬
‫ ثم قدما وصف مختصر‬,‫التعرف على المشاكل المختلفة التً تصادف إدارة مخبر التحالٌل الطبٌة و تحدٌد الحلول الممكنة‬
.‫حول تطبٌقات الهواتف‬
‫ استعملنا بٌئة أندروٌد أستودٌو النشاء التطبٌق و‬،‫ الخطوة الثانٌة‬.‫ لوصف اهم وظائف النظام‬UML ‫اخترنا طرٌقة‬
.Firebase ‫تم اختٌار نظام إدارة قواعد البٌانات‬. ‫ و جافا‬XML ً‫التً ترتكز على لغت‬
 Dedicaces
Je dédie ce modeste travail qui aurait pu aboutir et voir la lumière avec l’aide de dieu

A nos chères sœurs et nos frères,

En témoignage de nos sincères reconnaissances pour les efforts qu’ils ont consenti pour
l’accomplissement de ce projet. On leur dédie ce modeste travail en témoignage de notre grand
amour et notre gratitude infinie.

A tous nos amis,

Pour leur aide et leur soutien moral durant l’élaboration du travail de fin d’études. A toute nos
Familles

A tous ceux dont l’oubli du nom n’est guère celui du cœur...

« De l’union « si » avec « mais » naquit enfant nommé « jamais » » «Il n’y a pas de « si » ni de «
mais », il faut réussir »
 Remerciements
Nos vifs remerciements vont d’emblée à Dieu le tout puissant qui nous a doté d’une grande
volonté et d’un savoir adéquat pour mener à bien cet humble travail.

Nous adressons nos remerciements tout particulièrement : Á nos chers parents, notre fierté et
bien sur la source de notre réussite car ils se sont sacrifiés pour nous fournir une atmosphère de
travail disposant de toutes les meilleures conditions, sans eux rien n’aurait pu être facile, que
dieux nous les garde et les protège afin que l’on puisse leurs rendre un peu du beaucoup qu’ils
nous ont procuré.

Á notre Encadreur Dr Bendib Issam pour ses disponibilités, savoir-faire et son soutiens, il nous a
inculqué une grande confiance et il nous a orienté dans le bon sens quant à l’élaboration de ce
projet.

Aux membres du jury qui ont accepté d’évaluer notre travail.

Á nos très chers frères, sœurs, ami (es) et à toutes les personnes qui ont contribué à la réussite de
ce travail.

Enfin, nous tenons à remercier toute la promotion 2021-2022 licence informatique systèmes
informations. Ainsi que tous nos enseignants et les membres du département math et
informatique de Université Larbi Tébessi -Tébessa
 Table des matieres

Table des matières ........................................................................................... I

Liste des figures ............................................................................................ IV
Liste des tables ................................................................................................ V
Introduction générale : .................................................................................... 2

Chapitre 1 : ApplicationMobiles et MedicLab

Introduction :................................................................................................... 4
Partie I : Application mobile : ....................................................................... 4
1.1. Introduction : ............................................................................................................................................ 4
1.2. Types d’application mobile : .................................................................................................................... 4
1.2.1. Applications natives : ....................................................................................................................... 4
1.2.2. Applications Web : ........................................................................................................................... 5
1.2.3. Applications hybrides :..................................................................................................................... 5
1.3. Les systèmes d’exploitation mobiles :...................................................................................................... 5
1.3.1. Android : .......................................................................................................................................... 5
1.3.2. iOS : ................................................................................................................................................. 6
1.3.3. Windows Phone : ............................................................................................................................. 6
1.4. Pourquoi avons-nous choisi Android ? .................................................................................................... 6
1.5. Fonctionnalités d’Android : ..................................................................................................................... 6
1.6. Développement d’une application sur Android : ..................................................................................... 6
1.7. Composants d’une application Android : ................................................................................................. 7
1.8. Avantages et inconvénients d’Android : .................................................................................................. 8
1.8.1. Les Avantages : ................................................................................................................................ 8
1.8.2. Inconvénients : ................................................................................................................................. 8
Partie II : Etude de l’existant : ...................................................................... 8
2.1. Critique de l’existant : .............................................................................................................................. 8
2.2. Solution proposée : ................................................................................................................................... 9
2.3. Spécification :........................................................................................................................................... 9
2.3.1. Spécification des besoins fonctionnels : ........................................................................................... 9
2.3.2. Spécification des besoins non fonctionnels : .................................................................................. 10
2.+4. Cadre du projet : ..................................................................................................................................... 10

Conclusion: .................................................................................................... 11
Chapitre 1 : Analyse et Conception
Introduction :................................................................................................. 13
[Link]ésentation d’UML : ................................................................................ 13
1.1. Définition : ............................................................................................................................................. 13
1.2. Présentation des Diagrammes UML : .................................................................................................... 14
1.2.1. Définition du diagramme de cas d’utilisation : .............................................................................. 14
1.2.2. Définition du diagramme de séquence : ......................................................................................... 15
1.2.3. Définition du diagramme de classe : .............................................................................................. 15

[Link] de notre système : .................................................................. 16

2.1. Diagramme de cas d’utilisation : ............................................................................................................ 16
2.1.1. Diagramme cas d’utilisation globale de l’application : ................................................................. 17
2.1.2. Diagramme cas d’utilisation «Client» ........................................................................................... 18
2.1.3. Diagramme cas d’utilisation «Admin» : ....................................................................................... 20
2.2. Diagramme de séquence : ...................................................................................................................... 22
2.2.1. Représentation du diagramme de séquence: cas "créer un compte(register)" : .............................. 24
2.2.2. Représentation du diagramme de séquence :cas « s’authentifier (log in) » ................................... 25
2.2.3. Représentation du diagramme de séquence :cas « mot de passe oublié »Erreur ! Signet non défini.
2.2.4. Représentation du diagramme de séquence :cas«ajouter client» : ......... Erreur ! Signet non défini.
2.2.5. Représentation du diagramme de séquence :cas" générer et scanner code QR"………………………29
2.2.6. Représentation du diagramme de séquence :cas "offres et analyses"……………………………………...30
2.3. Diagramme de classe :............................................................................................................................ 29
2.4. Modèle relationnel : ............................................................................................................................... 31

Conclusion : ................................................................................................... 32

II
 Chapitre 3 : Implémentation
Introduction :................................................................................................. 34
[Link] : ......................................................................................... 34
1.1. StarUML : .............................................................................................................................................. 34
1.2. Microsoft office Word (2007) : .............................................................................................................. 34
1.3. Android Studio : ..................................................................................................................................... 34
1.4. Firebase : ................................................................................................................................................ 34
1.5. Sdk Android : ......................................................................................................................................... 35

[Link] utilisés : ...................................................................................... 35

2.1. Java :....................................................................................................................................................... 35
2.2. XML : ..................................................................................................................................................... 35

[Link] base de données Firebase : .................................................................. 35

[Link] Hommes Machine : ........................... Erreur ! Signet non défini.
3.1.1. Interface d’identification : ...................................................................................................................... 40
3.1.2. Interface d’authentification : .................................................................................................................. 41
3.3. Interface mot de passe oublieé : ............................................................................................................. 42
4. Interface d’accueil ......................................................................................................................... 44
4.1 Coté client :……………………………………………………………………………..41

4.2. Coté Administrateur : .............................................................................. Erreur ! Signet non défini.

4.2.1 Interface de l'activité de l'administrateur………………………………………………43
4.2.2 Interfaces « 2 » de l’activité de l’administrateur :……………………………………………….
Erreur ! Signet non défini.
4.2.3. Interface carte fidélité : ........................................................................... Erreur ! Signet non défini.
4.2.4. Interface des offres et tarifs : ................................................................... Erreur ! Signet non défini.
4.2.5. Interface des analyses : ................................................................................................................... 50

Conclusion : ............................................................ Erreur ! Signet non défini.

Conclusion generale : .................................................................................... 53
Liste des bibliographies : .............................................................................. 54
 Liste des figures
Figure 01 : La hiérarchie des diagrammes UML 2.0 sous forme d'un diagramme de classes........... 14
Figure 02 : Diagramme cas d’utilisation global ....................................... Erreur ! Signet non défini.18
Figure 03 : Diagramme cas d’utilisation «Client» .............................................................................. 18
Figure 04 : Diagramme cas d’utilisation «Admin» ............................................................................ 20
Figure 05 : Diagramme de séquence «créer un compte» ........................... Erreur ! Signet non défini.
Figure 07 : Diagramme de séquence «Authentification» ................................................................. 24
Figure 08 : Diagramme de séquence «Mot de passe oublié» ........................................................... 25
Figure 09 : Diagramme de séquence «Ajouter client» ...................................................................... 26
Figure 10 : Diagramme de séquence «générer et scanner code QR» ............................................... 26
Figure 11 : Diagramme de séquence «offres et analyses» ............................................................... 30
Figure 11 : Diagramme de classe ....................................................................................................... 31
Figure 12 : La BDD MedicLab sous Firebase ...................................................................................... 36
Figure 13 : Données admin et client .................................................................................................. 37
Figure 14 : Données (attributs) Admin .............................................................................................. 38
Figure 15 : Données (attributs) client ................................................................................................ 39
Figure 16 : Logo de l’application........................................................................................................ 40
Figure 17 : Welcome en style animé ................................................................................................. 41
Figure 18 : Type d’identification ........................................................................................................ 41
Figure 19 : Création du compte admin .............................................................................................. 42
Figure 20 : Log in client / admin ........................................................................................................ 42
Figure 21 : Mot de passe oublié client / admin ................................................................................. 43
Figure 22 : Générer code QR client ................................................................................................... 44
Figure 23 : Interface activité admin................................................................................................... 45
Figure 24 : Interface scan code QR (Admin) ...................................................................................... 46
Figure 25 : Interface ajouter nouveau client ..................................................................................... 47
Figure 26 : Interface carte fidélité ..................................................................................................... 48
Figure 27 : Interface offres et catégories ......................................................................................... 49
Figure 28 : Interface d’éditer les analyses ......................................................................................... 50
Figure 29 : Interface envoyer les analyses ........................................................................................ 51

IV
 Liste des tables
Tableau 01 : Description textuelle du cas d'utilisation "S'authentifier" ........................................... 14
Tableau 02 : Description textuelle du cas d'utilisation "Générer code QR" ..................................... 19
Tableau 03 : Description textuelle du cas d'utilisation "Suivre les offres" ....................................... 19
Tableau 04 : Description textuelle du cas d'utilisation "Suivre les analyses" ................................... 20
Tableau 05 : Description textuelle du cas d'utilisation "Remplir lformulaire"Erreur ! Signet non défini.
Tableau 06 : Description textuelle du cas d'utilisation "Scan code QR" ........................................... 21
Tableau 07 : Description textuelle du cas d'utilisation "voir les offres" ........................................... 21
Tableau 08 : Description textuelle du cas d'utilisation "éditer les analyses" ................................... 21
Tableau 09 : Description textuelle du cas d'utilisation "Register" .................................................... 22
Tableau 10 : Présentation des classes de l'application ..................................................................... 29
Tableau 09 : Présentation des champs de l'application .................................................................... 31
Introduction
Générale
Introduction générale :

Le marché de la téléphonie portable connait actuellement une véritable révolution, d'un simple
téléphone portable pour émettre des appels à un téléphone évolué doté de capacités proches d'un
véritable ordinateur appelé Smartphone.
Légers, puissants et intelligents, ces Smartphones remplaceront de plus en plus l'équipement de
téléphonie standard dans les boutiques. Les applications mobiles ne seront plus uniquement l'apanage
des hommes d'affaires, des networkers sociaux et des joueurs. Tout le monde pourra les utiliser. [1]
Dans ce cadre intervient notre projet de fin d'étude visant à mettre en œuvre les connaissances acquises
lors de notre formation au sein de l’université de Larbi Tébessi –Tébessa- dont l'objectif est de :

« développer une application mobile de carte fidélité pour laboratiore d’analyse médical»

On voit que, les modes de consommation évoluent au fil du temps. Avec les moyens de
communication plus performants et rapides, cette mutation est encore plus palpable. Depuis quelques
années, pour la gestion et la comptabilité concernant les anciens et les nouveaux clients et la création de
carte fiélité pour eux. [2]
Notre projet consiste à développer une application mobile et d’exploiter une nouvelle
technologie mobile qui se base de l’utilisation des systèmes d’exploitation androïde destinée aux
tablettes tactiles et smartphones sous Androïde. Et dans notre application, nous avons essayé d'intégrer
le concept du «MedicLab» dans le terme de programmation en concertant et réalisant une application
mobile pour la fidélité des clients et pour atteindre nos objectifs, nous avons utilisé Firebase comme
base de données, le langage de modélisation UML, l'environnement de développement Android Studio.
Nous allons détailler le projet dans ce rapport sur trois chapitres :
Chapitre 1 : ce chapitre contient deux parties; la première est dédiée pour une généralisation sur
les applications mobiles, la deuxième partie est pour Spécification et analyse des besoins.
Chapitre 2 : ce chapitre introduit les notions de base utilisée pour faire une conception via
l’approche UML, par la suite on présente la conception du système à implémenter.
Chapitre 3 : ce dernier chapitre présent le système de carte de fidélité «MedicLab» réalisé ainsi
que les langages et les outils utilisés durant l’implémentation.

2
 1
CHAPITRE

Application
Mobiles et
MedicLab
Introduction :

Dans ce chapitre, nous allons parler comme début sur les applications mobiles, donner leurs
différents types ainsi que leur architecture, leur fonctionnement et rajouter quelques exemples sur les
Systèmes d’exploitation mobiles, et nous concluons avec leurs principaux avantages et inconvénients.
Dans la deuxième partie de ce chapitre nous mettons la fidélité des clients de laboratoire
d’analyse méedical dans son cadre général. Par la suite, nous abordons l’étude de l’existant du projet,
suivie d’une critique pour pouvoir dégager les contraintes à respecter pendant la réalisation de notre
projet. Ainsi, ce chapitre présente l’ensemble des besoins qu’ils soient fonctionnels et non fonctionnels.
La carte de fidélité pour laboratoire d’analyse médical est un service proposé par des personnes
physiques ou morales consistant à ajouter, modifier, donner des offres pour les clients fidéles de
laboratoire

Partie I : Application mobile :

1.1. Introduction :

Au moment de lancement de cette nouvelle invention technologique, tout le monde se posait la

même question : Qu’est-ce qu’une application mobile ?
Une question habituelle au quelle il faut répondre avec une bonne précision afin d’éviter tout
amalgame avec autres notions. Pour être simple et claire, l’application mobile se définit comme étant
logiciel téléchargeable et qu’on installe facilement sur son Smartphone comme nous le faisons avec
tout logiciel sur notre pc portable.
Le téléchargement de l’application mobile se fait suivant deux options :
 Sur téléphone par le biais de connexion internet.
 Sur pc en le branchant avec le téléphone mobile.
1.2. Types d’application mobile :

Techniquement parlant, il y a trois types d’application mobile que tout utilisateur peut
rencontrer :
1.2.1. Applications natives :

Une application native est une application mobile qui est développée spécifiquement pour un
des systèmes d’exploitation utilisés par les Smartphones et les tablettes (iOS, Android, Windows Phone
etc.). Elle est conçue avec un langage spécifique à son système d’exploitation et ne peut être distribuée
que par l’intermédiaire des plateformes d’applications qui contrôlent sa nature et ses contenus.

4
 1.2.2. Applications Web :

Une application web mobile est une application développée en HTML accessible et exécutable
par le biais d’un navigateur Internet pour téléphone mobile.
Elle utilise le navigateur du Smartphone et ne nécessite pas forcément de télécharger
l’application. Elle est normalement accessible par tous les Smartphones quel que soit leur marque et
leur système d’exploitation. L’application web mobile « complète » les applications natives qui sont
développées spécifiquement pour un système d’exploitation et qui doivent être téléchargées et
installées par les mobinautes.
1.2.3. Applications hybrides :

L’application hybride est une application pour mobiles qui combine des éléments HTML5 sous
forme d’application web mobile et des éléments d’une application native permettant l’utilisation des
fonctionnalités natives des Smartphones et d’être distribuée en tant qu’application sur les plateformes
d’applications (App Store, Android Market, etc.).

1.3. Les systèmes d’exploitation mobiles :

Un système d’exploitation ou OS « Operating System » en anglais est un super logiciel qui

permet de gérer toutes les autres applications (mise en marche, arrêt, allocation des ressources
mémoires) et la communication avec le support physique.
Un système d’exploitation mobile est un système d’exploitation conçu pour fonctionner sur un
appareil mobile. Ce type de système d’exploitation se concentre entre autres sur la gestion de la
connectivité sans fil et celle des différents types d’interface.
Il y’a plusieurs systèmes d’exploitations mobiles, les plus connus sont :
1.3.1. Android :

Elaboré par Google, Android est un système d’exploitation fondé sur un noyau Linux.
Disponible via une licence Apache version 2, le système d’exploitation inclut tous les utilitaires requis
par un constructeur ou par un opérateur pour mettre en œuvre un téléphone portable. Androïde a été
conçu pour intégrer au mieux des applications existantes de Google comme le service de courrier
Gmail, ou celui de cartographie, Google Maps, ou encore Google Agenda, Google Talk, You Tube.
 1.3.2. iOS :

iOS, anciennement iPhone OS, est le système d’exploitation mobile développé par Apple pour
l’iPhone. Reconnu pour sa fluidité, son ergonomie et son intuitivité : c’est le système d’exploitation le
plus abouti à ce jour. Il dispose du portail App Store, qui avec un catalogue de 500 000 applications,
s’est imposé comme une référence parmi les kiosques d’applications mobiles.
1.3.3. Windows Phone :

Le 15 février 2010 Microsoft a lancé un nouveau système d’exploitation pour mobile, Windows
Phone [Link] inclut des services de Microsoft comme Windows Live. Il intègre aussi des fonctionnalités
média sociaux tel Facebook et Twitter. Comme Windows Phone 7 est une nouvelle plate-forme, il
n’existe aucune compatibilité avec les applications Windows Mobile.
1.4. Pourquoi avons-nous choisi Android ?

Android est un système d’exploitation puissant et moderne, qui se caractérise par la simplicité et
la flexibilité ; cela signifie que le système est développé avec un simple langage java, et il s’adapte à
beaucoup de structures différentes. De plus, Android est open source ; donc il offre aux développeurs la
possibilité d’améliorer les applications. Le noyau Linux lui fournit une grande mémoire, la gestion de
processus, le modèle de sécurité, etc. Le SDK de l’Android offre complètement les APIs, avec un accès
facile pour développer l’application .
1.5. Fonctionnalités d’Android :

Android a été conçu pour intégrer au mieux les applications existantes de Google comme le
service de courrier Gmail. Les fonctionnalités proposées par Android différent d’une version à une
autre, on peut citer les plus importantes :
 Augmentation de la performance et de la vitesse.
 Fonctionnalité de Hot spot Wifi.
 Partage de contact sur Bluetooth.
 Ecran d’accueil personnalisable.
 Disponibilité des Widgets.
 La possibilité de filmer et de prendre des photos en même temps.
 Mise à jour automatique des applications.

1.6. Développement d’une application sur Android :

Voici les différentes étapes principales dans le processus de développement d’une application

sur Android :

6
  Création du projet.

 Dessiner des interfaces en fichiers XML ou en codage : les vues (View) : Text, Edit, List,
Image, Web, Map, etc.

 Choisir les layouts qui sont une ressource indiquant les interfaces des activités.

 Organiser des ressources : les constantes globales ([Link]), les icônes, les images, etc.

 Création des activités : chaque activité peut correspondre à un écran ou une fonction de cette
application.

 Créer et mettre à jour le fichier de configuration : [Link] (configuration de

l’application) est utilisé pour stocker les dispositions (settings) globales comme les permissions
de l’application, les activités, les filtres de l’intention.

1.7. Composants d’une application Android :

Les composants d’une application sont les éléments essentiels d’une application Android, Ces
composants sont lâchement couplés par le fichier de manifestation
d’application [Link] qui décrit chaque composant de l’application et comment ils
interagissent.
Il existe quatre composants principaux qui peuvent être utilisés dans une application Android :

1 Activités (Activity)
Ils dictent l’interface utilisateur et manipulent l’interaction de l’utilisateur avec
l’écran du téléphone intelligent.

2 Services
Ils traitent le traitement de fond associé à une application.

3 Récepteurs de diffusion (BroadcastReceiver)

Ils gèrent la communication entre le système d’exploitation Android et les
applications.

4 Fournisseurs de contenu (Contents providers)

Ils traitent les problèmes de gestion des données et des bases de données
 1.8. Avantages et inconvénients d’Android :

1.8.1. Les Avantages :

 OS Kernel Robuste.

 Bibliothèque innovante.

 Facilités de développement.

 Exécution rapide.

1.8.2. Inconvénients :

 Parmi les inconvénients majeurs chez Android :

 Les considérations des performances qui nécessitent des périphériques assez puissants et
rapides.

 La difficulté d’intégration pour les vendeurs et sa forte dépendance de Google.

Partie II : Etude de l’existant :

Les bonnes idées sont souvent d'une simplicité déconcertante, nous avons donc incaré l’idée
de « MedicLab» qui rapproche le client à la direction du laboratoire d’analyses médical qui propose des
offres au client en général et à sa famille en particulier, où les membres de la famille de client peut
également bénéficier d’offres et de réduction sur les couts des tests médicaux, aussi l’administration de
laboratoire bénéficie également lors de la réalisation de ces offres, car l’administration traitera avec
tous les membres de la famille d’un seul client, ainsi les revenus et les bénéfices de l’administration
seront augmenter.
2.1. Critique de l’existant :

Les problèmes du système des analyses médical comprennent entre autres ce qui suit:
 Problème des files d’attentes : ça peut durer longtemps pour payer et recevoir les résultats des
analyses médical.
 Les pertes de temps : aller à un laboratoire pour faire des analyses, des fois l’attente dure et à
la fin le type d’analyse n’est pas disponible.
 La situation géographique : le déplacement peut être distant du lieu de départ pour recevoir
les résultats des analyses alors on peut les envoyer avec l’application.
 La situation de payement : le prix élevés des analyses sous la réduction et les offres de
l’application attirer l’attention des clients.

8
 2.2. Solution proposée :

Suite aux inconvénients précédemment cités, nous proposons la mise en place d'une application
Android qui automatise les différentes activités.
La solution qu’on propose est de développer une application pour la fidélité des clients de
laboratoire d’analyse médical garantissant:
 Avoir des offres sur tout les types d’analyses.
 Bénéficier des gains pour tout les utilisateurs.
 Attirer les clients d’etre des fidéles au laboratoire.
 Créer une liaison entre les clients et l’administrateur.

Notre application utilise des technologies sûres et fiables afin d'améliorer plusieurs aspects du
déroulement des analyses et des offres. Elle consiste essentiellement à conjuguer des outils
informatiques et électroniques modernes afin de faire la majorité des opérations qui sont effectuées
pendant l’envoie d’informations entre le l’admin et le client.
2.3. Spécification :

Dans cette section du chapitre, nous nous intéressons aux besoins de cette application à travers
les spécifications fonctionnelles et non fonctionnelles de qualité selon les besoins des utilisateurs.
2.3.1. Spécification des besoins fonctionnels :

Les besoins fonctionnels représentent les principales fonctionnalités du système. Ces besoins
proviennent généralement des utilisateurs du système.
MedicLab est une entreprise virtuelle spécialisée dans la mise en relation des clients (patients)
et l’administrateur du laboratoire. La mission consiste au développement d'une application mobile qui
rendra plus aisé la possession des analyses et des offres gestionner par l’administrateur conventionnés
aux clients abonnés à l’application. Clients (Patients), Administrateur. Chaque acteur aura accès à une
plateforme dédiée en fonction de ses besoins.

Création d’une application devra permettre la gestion des comptes des différents utilisateurs en
différenciant leurs droits. On distinguera deux types d’utilisateurs :

 CLient / Client de la société MedicLab

 Admin / Administrateur de la société MedicLab
  Le client devra être mesure de :
 se rendre à l’administration pour remplir son propre formulaire à l’aide de l’admin
 communiquer avec l’application en utilisant l’adresse email et le mot de passe
 générer le code QR et l’affichier à l’administrateur pour le scanner
 Recevoir les résultats des analyses dans un formulaire envoyé via l’application
 L’administrateur :
 une fois que ladmin c'est enregistré dans l'application il pourra ajouter un nouveau compte pour
le nouveau client via le formulaire d'information qui sera enregistré dans la base de données de
créer une carte de fidélité pour lui et les membres de sa famille
 les clients fidèles qui sont déjà inscits, l’admin scanne leur QR code et pour continuer la mise à
jour pour la carte de fidélité
 envoyer les résultats des analyses via l’application au client qui est déjà préciser.

2.3.2. Spécification des besoins non fonctionnels :

Les besoins non fonctionnels se sont les exigences qui caractérisent un système. Ces besoins peuvent
être énoncés suivant des plans de classifications :
 Ergonomie : Les interfaces doivent être simples, conviviales, clairs et ne doivent pas nécessiter
de connaissances assez poussées des utilisateurs pour leurs permettre de se sentir alaise et
familiariser avec l’environnement.
 Robustesse : L’application doit permettre le stockage des informations des utilisateurs, en
assurant une bonne gestion d’erreurs.
 Sécurité : L’application doit garantir l’intégrité et la confidentialité de ses données.
L’accès à la partie administration doit être sécurisé et authentifié.
 Performance : Un temps de réponse raisonnable au moment de l’identification et des
traitements des données.

Les utilisateurs non administrateur, ne doivent pas s’apercevoir des données sécurisées.
2.4. Cadre du projet :

Dans le cadre de notre projet de fin d’étude au sein de l’Université Larbi Tébessi nous avons eu
comme tâche de concevoir et développer d’une application mobile pour la carte de fidélité. L’objectif
visé est de faciliter la tâche des offres pour les clients fidéles de laboratoire un système facile à utiliser.

10
 Conclusion:
Suite à l’étude faite dans la première partie ce chapitre concernant les applications mobiles et
leur importance dans le monde d’aujourd’hui, cela nous a aidés à comprendre les notions de base.

Dans la deuxième partie nous avons présenté une étude de l’existant du carte fidélité, les
lacunes qu’il comprend ainsi que les solutions que nous proposons pour pallier ces problèmes, nous
avons aussi cité les besoins fonctionnels et non fonctionnels qui sont indispensables pour plus de gains
et mieux faciliter le travail à réaliser.
Dans le chapitre suivant nous allons aborder l’étude conceptuelle de notre application mobile,
tout en mentionnant tous les scénarios possibles, les acteurs et les diagrammes.
 2
CHAPITRE

Analyse et
Conception

12
 Introduction :

Le recours à la modélisation est une pratique indispensable au développement logiciel. Elle a

pour rôle de cerner les problèmes : les identifier, trouver leurs solutions, schématiser ces dernières, puis
enfin préparer le terrain d’action. Un modèle est, en effet, une représentation abstraite d’un système
afin d’en faciliter son étude et sa documentation. C’est un outil majeur de communication entre les
différents intervenants au sein d’un projet. En outre, les systèmes devenant de plus en plus complexes,
leur compréhension et leur maîtrise globale dépassent les capacités d’un seul individu. La construction
d’un modèle abstrait aide à y remédier. Ce chapitre sera consacré à la conception de notre application.
D’abord, nous introduisons le langage UML et ses différents diagrammes. Ensuite, nous
présenterons la modélisation proprement dite de notre projet en utilisant trois diagrammes.

1. Présentation d’UML :

Le méta modèle UML fournit une panoplie d'outils permettant de représenter l'ensemble des
éléments du monde objet (classes, objets, ...) ainsi que les liens qui les relie.
1.1. Définition :

UML (UnifiedModelingLanguage) est le résultat d’une opération d’unification d’un ensemble

de concepts pris à partir des méthodes orientées objets dans le but de modéliser d’une manière claire et
précise la structure et le comportement d’un système, indépendamment de toute méthode et tout
langage de programmation.
L’utilisation d’UML est un choix à faire compte tenu des opportunités qu’il offre et des
exigences du travail entamées. Il nous propose un nombre de diagrammes qui nous assistent durant
l’analyse des besoins, la conception de données, l’implémentation et le déploiement du système types
de diagrammes.
 1.2. Présentation des Diagrammes UML :

UML dans sa version 2 s’articule autour de treize types de diagrammes, chacun d’entre eux est
dédié à la représentation d’un système logiciel suivant un point de vue particulier. Ces diagrammes sont
regroupés dans deux grands ensembles : les diagrammes structurels et les diagrammes
comportementaux. L’ensemble des quatorze types de diagrammes UML peut ainsi être résumé sur la
figure suivante :

Figure 01 : La hiérarchie des diagrammes UML 2.0 sous forme d'un diagramme de classes

Nous présentons ci-dessous les diagrammes UML 2.0, que nous avons utilisés dans le cadre de
ce projet et quelques notions de base qui leurs sont associées.

1.2.1. Définition du diagramme de cas d’utilisation :

Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au système. Il
constitue un des diagrammes les plus structurants dans l’analyse d’un système
 Acteur : Représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel
ou autre système) qui interagit directement avec le système étudié.
 Cas d’utilisation (use case) : Représente un ensemble de séquences d’actions qui sont
réalisées par le système et qui produisent un résultat observable intéressant pour un acteur
particulier.

14
  Les relations entre acteurs : La seule relation entre acteur est la relation de généralisation.
Quand un acteur fils hérite d’un acteur père, il hérite en réalité de toutes les associations du
père.
 Les relations entre cas d’utilisation :
 Relation d’inclusion (Include) : Une relation d’inclusion d’un cas d’utilisation A par
rapport à un cas d’utilisation B signifie qu’une instance de A contient le comportement
décrit dans B.
 Relation d’extension (Extend) : Une relation d’extension d’un cas d’utilisation A par
un cas d’utilisation B signifie qu’une instance de A peut être étendue par le
comportement décrit dans B.
 Relation de généralisation : Les cas d’utilisation descendants héritent de la description
de leurs parents communs. Chacun d’entre eux peut néanmoins comprendre des
interactions spécifiques supplémentaires.

1.2.2. Définition du diagramme de séquence :

Ce diagramme permet de décrire les scénarios de chaque cas d’utilisation en mettant l’accent sur
la chronologie des opérations en interaction avec les objets.
 Scénario : Représente une succession particulière d’enchaînements, s’exécutant du début à la
fin du cas d’utilisation, un enchaînement étant l’unité de description de séquences d’actions.
 Ligne de vie : Représente l’ensemble des opérations exécutées par un objet.
 Message : Un message est une transmission d’information unidirectionnelle entre deux objets,
l’objet émetteur et l’objet récepteur.

1.2.3. Définition du diagramme de classe :

Le diagramme de classe est le point central dans un développement orienté objet. En analyse, il
a pour objectif de décrire la structure des entités manipulées par les utilisateurs. En conception, le
diagramme de classes représente la structure d’un code orienté objet.
 Une classe : Représente la description abstraite d’un ensemble d’objets possédant les mêmes
caractéristiques. On peut parler également de type.
 Un objet : Est une entité aux frontières bien définies, possédant une identité et encapsulant un
état et un comportement. Un objet est une instance (ou occurrence) d’une classe.
 Un attribut : Représente un type d’information contenu dans une classe.
 Une opération : Représente un élément de comportement (un service) contenu dans une classe.
  Une association : Représente une relation sémantique durable entre deux classes.
 Une superclasse : Est une classe plus générale reliée à une ou plusieurs autres classes plus
spécialisées (sous-classes) par une relation de généralisation. Les sous-classes" Héritent " des
propriétés de leur superclasse et peuvent comporter des propriétés spécifiques supplémentaires.

Apres avoir expliqué le fonctionnement des différents diagrammes nous allons détailler leur utilisation
dans l’analyse et la conception.

2. Conception de notre système :

Après avoir présenté les concepts théoriques fondamentaux du formalisme UML et les différents
diagrammes. Dans cette partie nous présentons la conception de notre application carte de fidélité
« MedicLab » en utilisons 1 diagramme statique et 2 dynamiques présenté.

2.1. Diagramme de cas d’utilisation :

Acteurs du système : Notre application contient

 Un client: est celui qui a le droit de s’inscrire à l’application, ainsi que faire des commandes
concernant les analyses médical.
 Un administrateur : est celui qui a le droit de s’inscrire à l’application, ajouter les clients
disponible dans laboratoire, recevoir les commandes des clients (les acceptes ou non). Et qui
créér pour le client son propre compte
 Un utilisateur : est celui qui a utiliser les fonctionnalités de l’application soit le client ou
l’admin.

16
 2.1.1. Diagramme cas d’utilisation globale de l’application :

Le diagramme suivant résume tous les cas d’utilisation associés à tous les acteurs de notre application.

Figure 02 : Diagramme cas d’utilisation global

Diagrammes détaillés et Description textuelles de quelques cas d’utilisation :

Pour donner une autre définition du cas d’utilisation on peut dire que c’est une collection de
scénario de succès ou d’échec qui décrit la façon dont un acteur particulier utilise un système pour
atteindre un objectif pour détailler la dynamique du cas d’utilisation, la procédure la plus évidente
consiste à recenser de façon textuelle toutes les interactions entre les acteurs et le système. Le cas
d’utilisation doit avoir un début et une fin clairement identifiés, il faut aussi préciser les variantes
possibles tout essayant d'ordonner séquentiellement les descriptions afin d'améliorer leur lisibilité.
Tableau 01 : Description textuelle du cas d'utilisation "S'authentifier"

Cas utilisation S’authentifier.

Auteur [Link]
Objectif Vérifier que l’utilisateur a bien le droit d’accès à l’application.
Pré condition Avoir un compte.
 L’utilisateur demande l’accès à l’application.
 Le système affiche l’interface Authentification.
Scénario nominal  L’utilisateur introduit son email et le mot de passe.
 Le système vérifie l’existence de l’utilisateur. [A]
 Le système donne l’accès à l’interface correspondante.
 Si un champ d’information n’est pas valide ou l’utilisateur n’existe
Alternative [A]
pas, le système affiche un message d’erreur et réaffiche l’interface

2.1.2 Diagramme cas d’utilisation «Client»

Le diagramme ci-dessous représente le diagramme des cas d’utilisation associés à "le client"

Figure 03 : Diagramme cas d’utilisation «Client»

18
Tableau 02 : Description textuelle du cas d'utilisation "Générer code QR"

Cas utilisation Générer code QR

Auteur Client.
Objectif Exposer le code QR au admin pour l’accés des données
Pré condition S’authentifier.
 Le client se connecte en utilisant l’email et le mot de passe.
 Le système donne l’accès à l’interface correspondante.
Scénario nominal
 Le client doit entrer l’ID pour générer le code QR. [A]
 Le système affiche le code QR.
 Lorsque L’ID qui a le client entrer pour généner le code QR n’est pas
Alternative [A]
le meme qui s’identifer, l’opération ne termine pas.

Tableau 03 : Description textuelle du cas d'utilisation "Suivre les offres"

Cas utilisation Suivre les offres.

Auteur Client.
Objectif Suivre les offres que l’application a proposé
 S’authentifier.
Pré condition
 Le code QR est déjà scanné.
 Le client demande à l’administrateur de savoir la catégorie d’offre
Scénario nominal
qu’il a arrivé.

Tableau 04 : Description textuelle du cas d'utilisation "Suivre les analyses"

Cas utilisation Suivre les analyses

Auteur Client.
Objectif Suivre les offres que l’application a proposé
 S’authentifier.
Pré condition
 Le code QR est déjà scanné.
 Le client demande à l’administrateur de savoir la catégorie d’énalyse
Scénario nominal
et le prix.
 2.1.2. Diagramme cas d’utilisation «Admin»

Figure 04 : Diagramme cas d’utilisation «Admin»

Tableau 05 : Description textuelle du cas d'utilisation "remplir formulaire"

Cas utilisation Remplir formulaire

Auteur Admin
Objectif Ajouter un nouveau client.
Pré condition S’authentifier.
 L’utilisateur demande de client ces information et ces données et les
remplire dans le formulaire .
Scénario nominal
 Le système donne l’accès à l’interface correspondante.
 Le système enregistre toute les informations dans la base de donées .

20
Tableau 06 : Description textuelle du cas d'utilisation " scan code QR"

Cas utilisation Scan code QR.

Auteur Admin
Objectif Accéder à l’interface des informations (offres et catégories)
Pré condition S’authentifier.
 L’utilisateur demande de scanner le code QR qui concerne le client
Scénario nominal pour le scanner.
 Le système donne l’accès à l’interface correspondante.
Alternative N’existe pas

Tableau 07 : Description textuelle du cas d'utilisation "voir les offres"

Cas utilisation voir les offres.

Auteur Admin.
Objectif Suivre les offres que l’application a proposé et le calcul de nouveau tarif
S’authentifier.
Pré condition
Le code QR est déjà scanné.
 L’administrateur veut savoir la catégorie d’offre que le client fidéle a
Scénario nominal
arrivé, pour que les tarifs sera sous des nouveaux offres.

Tableau 08 : Description textuelle du cas d'utilisation "éditer l’analyse"

Cas utilisation Editer l’analyse

Auteur Admin.
Objectif Le client recevoir ces résultats concernant les analyses.
S’authentifier.
Pré condition
Le code QR est déjà scanné.
Scénario nominal  L’admine edite les resultats des analyses pour les envoyer au client.
Tableau 09 : Description textuelle du cas d'utilisation "Register"

Cas utilisation Register

Auteur Admin
Créer un nouveau compte et accéder à l’interface des informations (offres
Objectif
et catégories)
Pré condition N’éxiste pas.
 L’administrateur veut crée un compte dans l’application pour la
diréction des clients et des offres. Le système donne l’accès à
Scénario nominal
l’interface correspondante utilisant son propre adresse email et un mot
de passe.

2.2. Diagramme de séquence :

Dans cette section, nous présentons les diagrammes de séquences des cas d'utilisations que nous
avons décrites textuellement plus haut.

22
 2.2.1. Représentation du diagramme de séquence: cas "créer un compte (register)" :

Pour créer un compte, l’administrateur doit entrer ses informations tout dépends de sa utilisation.
Ces informations sont préétablies dans une base de données. Dans notre système lors d’une création de
compte

Figure 05 : Diagramme de séquence «créer compte»

 2.2.2. Représentation du diagramme de séquence: cas "S’authentifier (Log in)" :

L’authentification consiste à assurer la confidentialité des données, elle se base sur la

vérification des informations associées à un utilisateur (un email et un mot de passe). Ces informations
sont préétablies dans une base de données. Dans notre système lors d’une authentification, deux cas se
présentent : les informations introduites par l’utilisateur sont incomplètes ou incorrectes, dans ce cas un
message d’erreur s’affiche

Figure 06 : Diagramme de séquence «Authentification»

24
2.2.3. Représentation du diagramme de séquence "Mot de Passe oublié":

Pendant l’authentification, l’utilisateur peut tomber dans le cas où il a oublié le mot de passe,
dans ce cas l’utilisateur accéde à l’interface « mot de passe oublié » où il peut entrer son adresse
email, maintenant il va recevoir un nouveau mot de passe, il continue avec le nouveau mot de
passe pour accéder à l’interface suivante.

Figure 07 : Diagramme de séquence «Mot de Passe oublié»

 Représentation du diagramme de séquence: cas "ajouter client"

Après l’authentification de l’administrateur et l’accées à l’interface du formulaire pour ajouter

un nouveau client, l’admin commence d’éditer les informations du client, les données qui sont envoyés
seront enregistrer dans la base de données et l’opération est terminée avec succées, d’une autre part le
nouveau client obtient un code QR spécifié pour lui.

Figure 08 : Diagramme de séquence «Ajouter client»

26
 2.2.4 Représentation du diagramme de séquence: cas "générer et scanner code QR"

Après l’authentification du deux utilisateurs, le client continue pour afficher son code QR par entrer le
texte pour le générer, ici le client montre le code à l’administrateur pour le scanner, après la réalisation
de l’opération sur le système et la base de données, le résultat sera afficher sur l’interface suivante de
l’administrateur.

Figure 9 : Diagramme de séquence « générer et scanner code QR »

2.2.5. Représentation du diagramme de séquence: cas " offres et analyses" :

Après l’authentification de deux utilisateurs, le client (fidèle) faire la demande d’avoir les tarifs
et les résultats des analyses, dans ce cas l’administrateur accéde à les interfaces qui correspond, après la
réalisation de l’opération sur le système et la base de données, l’administrateur peut informer le client
de toute les informations concernant les tarifs et les résultats des analyses.

Figure 10 : Diagramme de séquence «offres et analyses »

28
2.3. Diagramme de classe :

Il s'agit ici d'une vue. Le diagramme de classes ci-dessous modélise les concepts du système de
vote ainsi que les concepts internes créés de toutes pièces dans le cadre de l'implémentation de ce
système. Notre diagramme de classe permet de modéliser les classes du système et leurs relations
indépendamment d'un langage de programmation particulier.

Tableau 10 : Présentation des classes de l'application

Classe Désignation
User Contient les informations en commun avec le client (fidèle) et l’admin.
Fidèle Contient les informations concernant un Fidèle.
admin Contient les informations concernant un admin.
famille Contient les informations concernant une famille d’un fidèle.
Analyse Contient les informations concernant les analyses.
Type analyse Contient les informations du toute les types des analyses disponibles.
offre Classe qui contient les informations des offres proposés.
reduction Cette classe contient les catégoriés et taux de reduction .
Benifice Cette classe contient le pourcentage réduit du tarifs.
Tableau 11 : Présentation des champs de l'application

Classe Attributs Méthodes

Utilisateur ID,
Nom,
Prénom,
Admin EmailAd, getEmailAd ()
MotdepasseAd, getMotdepasseAd()
Fidèle NumcarteFidèle, getNumcarteFidèle()
Adresse, getAdresse()
Age, getAge()
Groupage, getGroupage()
EmailFidèle, getEmailFidèle()
Sexe, getSexe()
MembresFamille, getMembresFamille()
Famille IDFam,
NomFam,
PrenomFam,
NumCarteFam,
Analyse IDAnalyse, getDateAnalyse()
CodeAnalyse, getResultatAnalyse()
DateAnalyse,
ResultatAnalyse,
Type Analyse IDTA, getDesingation()
Desingation, getObservation()
Observation,
Offre IDOffre,
DesingationOffre,
Benifice IDB, getpourcentage()
pourcentage
Reduction IDR, getTauxReduction()
Taux Reduction, Categorie getCategorie()

30
 Figure 11 : Diagramme de classe

2.4. Modèle relationnel :

A partir de la description conceptuelle que nous avons effectuée, on peut réaliser le relationnel;
vu que le système d'information ne peut pas le manipulé directement; et ça en utilisons des règles de
passages de l'UML vers le relationnel.

Les règles de passage:

 Transformation des classes : chaque classe du diagramme UML il faut choisir un attribut de la
classe pouvant jouer le rôle de clé.
  Transformation des associations : Nous distinguons trois familles d’association
 Association 1..* : il faut ajouter un attribut de type clé étrangère dans la relation fils de
l'association. L'attribut porte le nom de la clé primaire de la relation père de l’association.
 Association *..* et n-aire et classes-association : la classe-association devient une relation. La
clé primaire de cette relation est la concaténation des identifiants des classes connectées à
l'association.
 Association 1..1 : il faut ajouter un attribut de type clé étrangère dans la relation dérivée de la
classe ayant la multiplicité minimale égale à un. L'attribut porte le nom de la clé primaire de la
relation dérivée de la classe connectée à l'association. Si les deux multiplicités minimales sont à
un, il est préférable de fusionner les deux classes en une seule.
 En appliquant ces règles de transformation d'un diagramme de classe vers un modèle
relationnel.
 nous avons abouti au schéma relationnel suivant :

 Utilisateur( ID, Nom, Prénom)

 Administrateur( EmailAd, MotdepasseAd)
 Client ( NumcarteFidèle*, Adresse, Age, Groupage, EmailFidèle, Sexe, MembresFamille )
 Famille ( IDFam, NomFam, PrenomFam, NumCarteFidèle* )
 Analyse ( IDAnalyse, CodeAnalyse*, DateAnalyse, ResultatAnalyse )
 Type analyse ( IDTA, Desingation, Observation, CodeAnalyse* )
 Offre ( IDOffre, DesingationOffre )
 Bénifice ( IDB, Pourcentage )

Conclusion

Dans ce chapitre on a présenté la conception du projet avant l’implémentation de notre

application pour carte de fidèlité de laboratoire d’analyses médical. La conception a été faite par UML,
et on a parlé des modules de développement que nous avons utilisé pour mener à bien notre projet En
deuxième lieu nous avons présenté les règles de passage du modèle conceptuel au modèle relationnel.
Dans le chapitre suivant, nous allons parler de l’implémentation du site avec sa base de données et des
captures d’écran de ses pages et son fonctionnement.

32
CHAPITRE 3
Implémentation
nnnhlkrken
Introduction :

Dans ce chapitre nous entamons la partie pratique, ou nous allons présenter l’environnement,
technologies et applications mobile, l’architecture de l’application avec des captures d’écrans des
différentes fonctionnalités de l’application avec la description de quelques interfaces

1. Environnement :

1.1. StarUML :

Nous avons choisi l'outil de modélisation StarUML qui nous a aidé à schématisé les
diagrammes de notre projet.

1.2. Microsoft office Word (2010) :

A l'aide de cet éditeur notre rap compilateur offrit par Microsoft office Word
pour la mise en forme du texte.

1.3. Android Studio :

Nous avons utilisé aussi, Android studio, c'est un environnement de

développement pour développer des applications Android. Il est basé sur IntelliJ IDEA.
Ce logiciel fonction sur tous les systèmes d'exploitation, Windows, Linux ou MacOs.

1.4. Firebase :

Firebase est la plate-forme unifiée de Google qui réunit des fonctionnalités

puissantes pour votre application, y compris un backend mobile, des données d'analyse,
ainsi que des outils qui vous permettront de favoriser la croissance et la monétisation
de votre produit.

34
 1.5. Sdk Android :

Nous avons utilisé SDK car les fonctions de SDK est accès au Hardw d'accueil riche par
l'utilisation des Widgets ….

Langages utilisés :

2.1. Java :

C'est le langage de programmation orientée objet, studio et il garantit la

portabilité des applications.

2.2. XML :

eXtensible Markup Language (en français : langage extensible dé balisage),

c'est le deuxième langage que nous avons utilisé, ce langage basé sur les balises
ouvrantes et fermantes.

2. La base de données Firebase :

Nous allons créer une base de données pour l’application avec Firebase. La technologie utilisée
est la base de données temps réel NoSQL (Realtime DataBase). Hébergée dans le Cloud, elle stocke et
elle synchronise les données utilisateurs en temps réel. A l’aide d’une simple API, Firebase fournit à
l’application les valeurs actuelles des données et les rafraîchit automatiquement. Par ce biais, la
plateforme permet en autre de gérer l’authentification des utilisateurs, de tester son application sur
toutes les plateformes (web, iOS, Android), d’effectuer des mises a jour à distance, d’obtenir et
d’analyser des rapports de crash… L’utilisateur dispose de Google Analytics qui dresse des rapports
sur l’expérience utilisateur et permet par exemple de déclencher des notifications en conséquence.
Figure 12 : La BDD MedicLab sous Firebas

36
Figure 13 : données admin et client
Figure 14 : données ( attributs ) admin

38
Figure 15 : données ( attributs ) client
 3. Interfaces Hommes Machine :

Dans cette partie on va présenter notre version concrète interfaces .Ci-dessous le logo de notre
application :

Figure 16 : logo de l’application

3.1.1 Interface d’identification :

l’utilisateur un compte dans l’application, alors il va entrer avec son propre identification,
soit client ou Administrateur.

40
Figure 17 : welcome en style animé Figure 18 : type d’identification

3.1.2 Interface d’authentification :

Après que l’utilisateur a choisi son identification, il accède à cette interface qu’est séparé
pour les deux (client et l’admin). L’administrateur a deux choix, soit la création d’un
nouveau compte ou d’authentifier, mais le client peut que d’authentifer.
 Figure 19 : Création de compte admin Figure 20 : Log in client / admin

3.1.3 Interface Mot de passe oublié :

En cas où l’utilisateur oublie son mot de passe pour se connecter, il peut récupérer un nouveau mot
de passe qui sera envoyé dans sa boite d’email , par cliquer sur « forgot password » et éditer l’adresse
email, un message sera envoyé sur gmail contient le nouveau mot de passe.

42
Figure 21 : Mot de passe oublié client / admin
4. Interface d’accueil :

4.1. Coté client :

Dans cette interface, il faut que le client entre l’adresse email qui correspend à son

compte pour générer le code QR.

Figure 22 : Générer code QR client

44
4.2. Coté Administrateur :

4.2.1 Interface de l’activité de l’administrateur :

Après la connexion de l’administrateur, le système fait suggérer cette interface pour choisir
l’activiter que l’admin veut, soit d’ajouter un nouveau client ou de scanner le QR code d’un client
fidèle.

Figure 23 : Interface activité Administrateur

4.2.2 Interface « 2 » de l’activité de l’administrateur :
Les interfaces suivantes expliquent le fonctionnement des deux boutton dans l’activité
soit par scanner le code QR d’un client qu’il existe déjà et l’accés à l’iterface suivante. Ou
avec remplir le formulaire par les données du nouveau client

Figure 24 : Interface Scan code QR < Administrateur >

46
Figure 25 : Interface ajouter nouveau client
 4.2.3 Interface carte de fidélité :
Après le scanner de code QR, le système affiche par default l’interface qui contient la carte de
fidélité et les informations personelles du client.

Figure 26 : Interface carte fidélité

48
4.2.4 Interface des offres et tarifs :

Après avoir la crte de fidélité, l’administrateur accéde pour calculer les tarifs par le boutton
« Voir Offre » , A chaque fois le client ou l’un des membres de sa famille veut faire un nouveau
analyse, le système ajoute 1.5% remise dés le pramier tarifs, la catégorie des offres augmente 10%
tant que le client fait des analyses.

Figure 27 : Interface offres et catégories

 4.2.5 Interface des analyses :
Après avoir la carte de fidélité, l’administrateur accéde pour modifier et envoyer les résultas des
analyses par le boutton « Edite Analyse », maintenant l’administrateur remplie l’email, edite les
informations concernant les analyses et les envoyer par sélectionner « Gmail » .
En conclusion, l’adiminstrateur peut rejoindre le ficher qui contient les informations des dernièrs
analyses et les envoyer.

Figure 28 : Interface d’éditer les analyses

50
Figure 29 : Interface d’envoyer les analyses
Conclusion
Générale

52
Conclusion generale :
Nous voici à l'apocalypse de notre travail scientifique de fin de Notre premier cycle qui a porté
sur la «Conception et réalisation d’une application mobile pour carte fidélité de laboratoire d’analyse
médical ».
Pour mener à bien ce projet, nous avons dû approfondir nos connaissances tant du point de vue
de la conception de la base de données que du point de vue de la programmation.
La réalisation de ce projet a duré quelques mois. Il nous a permis non seulement de comprendre
la complexité d'un projet, mais également les méthodes à mettre en place et les différentes étapes
nécessaires à la réalisation d’un projet d'application mobile.
Pendant le cycle de la réalisation du projet, nous avons mis en pratique de nombreuses
connaissances et compétences acquises durant l'année d’études universitaire en Licence SI, tant au
niveau organisationnel, technique que conceptuel.
De plus, ce projet nous a permis de nous familiariser avec la démarche de création d’une
application. Le logiciel conçu nous a permis de mieux connaître le monde des e-commerce et les
difficultés rencontrer dans le domaine de gestion de laboratoire d’analyses médical et les technologies
nécessaires à la conception d’une application mobile basée sur l’informatisation de ce système.
Ce projet a fait l'objet d'une expérience intéressante, qui nous a permis d'améliorer nos
connaissances et nos compétences dans le domaine de la modélisation et de la programmation.
Cependant, au cours de la réalisation de ce projet, nous avons rencontré des difficultés. Malgré
ces difficultés, nous pouvons penser à concevoir un système plus général..
De ce qui précède, il est difficile de prétendre avoir eu une solution idéale, toutefois nous
espérons avoir répondu tant soi peu à notre problématique et confirmé nos hypothèses et dans ce qui
suit nous allons essayer de lister des perspectives de notre système. Autrement dit, nous allons
présenter les améliorations qui peuvent y être apportées.
En effet, ce travail est une œuvre humaine, n'est pas un modèle unique et parfait, c'est pourquoi
nous restons ouverts à toutes les critiques et sommes prêts à recevoir toutes les suggestions et
remarques tendant à améliorer d'avantage cette étude.
 Liste des bibliographies
[1] [Link]
[2 [Link]

54