CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET Chapitre 1 Contexte général du projet 1 Introduction Le but de ce chapitre introductif est de mettre le… [632302]

Rapport PFE
Nom
2018/2019

CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
Chapitre 1
Contexte général du projet
1 Introduction
Le but de ce chapitre introductif est de mettre le travail dans son contexte général. Nous
commençons tout d’abord par une présentation de l’entreprise d’accueil. Puis, nous décrivons
le sujet autour du quel s’articule notre projet de fin d’études. Enfin, nous effectuons l’étude
des notions,technologies, solutions et principes utilisés dans notre projet.
2 Présentation de l’organisme d’accueil
2.1 Présentation de TakenTech
Figure 1.1 – Présentation de TakenTech
TakenTechs[1] est une agence de développement WEB basée à Gabes, en Tunisie. Les
équipes de Takentechs offrent des services de haute qualité aux start-ups, ainsi que des
grands comptes, en les assistant au perfectionnement de leurs projets WEB afin d’assurer
leur croissance. Takentechs répond aux besoins de ses clientèles en matière de :
Développent front-end
Développement back-end
Applications mobiles Android/IOS
CMS ou CRM
8

CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
Création des sites vitrine, sites e-commerce
API, templates
Interface d’administration, interface responsive
Campagne e-mailings, newsletters
Architecture logiciel, conseils techniques …
Takentechs est formée par un groupe de jeunes, talentueux ingénieurs issus de grandes écoles
en Tunisie et en France, qui maîtrisent diverses problématiques métiers propres au domaine
du WEB, agilistes convaincus, font de la satisfaction client leur priorité absolue. Les parte-
naires de Takentechs apprécient son adaptabilité d’intégration en équipe en start-ups comme
dans les grandes structures.
2.2 Fiche d’identité
Raison social : TakenTech;
Secteur : services informatiques;
Directeur : Boumedyen Boussaid;
Adresse : Rue Béchir Jaziri, Imm. Amal, App. C2, 6000, Gabés, TUNISIE;
Numéro de téléphone : +216 93 003 968;
Email : [anonimizat];
Site WEB : www.takentechs.com.
3 Présentation du Projet
3.1 Contexte général du projet
Pendantladuréedestage,ilnousaétédemandédefaireledéveloppementetl’intégration
d’une application WEB de gestion médicale. Pour le professionnel de santé, c’est un service
complet de gestion de cabinet médical, qui optimise l’organisation et fait gagner du temps.
La plateforme offre la possibilité de gérer les rendez-vous, l’horaire et les dossiers médicaux
à chaque nouvelle consultation. Pour le patient, c’est un service qui vous permet de trouver
rapidement un médecin et de prendre rendez-vous en ligne suivant la disponibilité, aussi
suivre son dossier médical sécurisé (détaillé). Ainsi avec cette application, le patient peut
rappeler vos médicaments le long d’une période précisée.
Le sujet est certainement intéressant car l’application dont nous parlons est peut être une
réelle valeur ajoutée dans la vie de chacun et ses perspectives d’évolution sont énorme privé
avec le progrès continu de la technologie. Notre travail est réalisé dans le cadre de stage de
projet de fin d’études, qui vient de conclure notre formation à l’école nationale d’ingénieur
de Gabés en télécommunication et réseaux. Le stage s’est déroulé sur une période de quatre
mois, au cours de laquelle nous avons apprécié le travail en équipe.
9

CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
3.2 Étude de l’existant
Dans le but d’atteindre les objectifs de notre application et apporter de la valeur ajoutée
audomainededéveloppement,ilestnécessairedefaireuneétudedessolutionsdéjàexistantes
sur le marché. Cette étude nous permet d’analyser les fonctionnalités déjà développées et
surtout de mettre en relief leurs limites. Par la suite, nous pouvons dégager les solutions
envisageables qui peuvent faire face aux problèmes liés aux solutions existantes ou bien
améliorer les services offerts. Dans ce qui suit, on cite quelques exemples des applications
existantes sur le marché :
Doctolib : Doctolib[2] est une startup française fondée en 2013 qui fournit un service en
ligne de prise et de gestion de rendez-vous médicaux mettant en relation des patients et des
professionnels de la santé. Doctolib a pour objectif d’améliorer le quotidien des professionnels
de santé et des patients. Pour les patients, il permet de trouver un praticien près de chez soi
et de prendre rendez-vous en quelques clics.
Nous présentons ci-dessous quelques imprimes écran de l’application Doctolib utilise par
le client la première figure représente l’interface d’accueil et l’autre représente l’agenda de
médecin pour prendre un rendez-vous.
Figure 1.2 – Accueil de Doctolib
10

CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
Figure 1.3 – Agenda de médecin choisi
Med.tn : Med.tn[3] est une plateforme sécurisée dont vous permet pour le patient
de trouver rapidement un médecin le plus proche de chez vous et de prendre rendez-vous
en ligne gratuitement. Il permet en outre, d’entrer en contact directement avec des patients
tunisiens et étrangers et de répondre à leurs interrogations. L’application permet de trouver
une pharmacie à proximité. La figure 1.4 représente l’accueil de l’application.
Figure 1.4 – Accueil de Med.tn
3.3 Critique l’existant
Cette partie a pour but de dégager les insuffisances et les défaillances des applications
précédentes dont on peut citer :
Pour Doctolib, on constate qu’il y a plein de bonnes idées dans cette application. Le
concept est excellent mais on relève l’absence de dossier médical contenant des historiques
du consultations en ligne pour le patient. Aussi la difficulté de prise de rendez-vous en cas
d’urgence si le praticien choisi n’est pas disponible.
11

CHAPITRE 1. CONTEXTE GÉNÉRAL DU PROJET
PourMed.tn,leprincipedecetteapplicationestextramaisonrésumelemanquedegestion
du dossier médical. Aussi l’absence des paramètres (durée de consultation …) de gestion des
rendez-vous.
3.4 Solution proposée
Après avoir fait critique les applications existantes sur le marché. On propose alors de
réaliser une nouvelle application permettant l’organisation et l’automatisation des tâches.
Notre solution est de développer une application simple à utiliser qui facilite les tâches de
médecin en lui offrant la possibilité de gérer le dossier médical tel que à chaque consultation
peut consulter l’historique d’état du santé et ajouter un résumé de la nouvelle consultation
et du traitement donné sera porté sur le dossier médical. Ainsi que cette application peut
rappeler le patient de suivre ses traitement pendant une période précisée par le médecin à
l’aide d’un email. Les fonctionnalités que cette application proposera seront détaillées dans
le chapitre suivant.
4 Conclusion
Tout au long de ce Chapitre nous avons présenté le cadre de projet ainsi qu’une étude de
marché afin de proposer notre solution respectant les objectifs demandés par la société. Le
Chapitresuivantprésentel’analyseet laconception,uneétapeprimordialedansl’élaboration
et la création de toute application.
12

CHAPITRE 2. ANALYSE ET CONCEPTION
Chapitre 2
Analyse et conception
1 Introduction
Dans ce chapitre, nous présentons la phase d’analyse et de conception. Ainsi, nous spé-
cifions, en premier lieu, les besoins fonctionnels et non fonctionnels de tous les utilisateurs.
En deuxième lieu, nous détaillons la modélisation de l’application de point de vue statique
et dynamique à travers un ensemble de diagramme UML.
2 Capture des besoins :
Au cours de cette activité, nous allons extraire en premier lieu les acteurs principaux,
les besoins fonctionnels ainsi que les besoins non fonctionnels. En deuxième lieu, nous allons
identifier les différents diagrammes UML.
2.1 Identification des acteurs :
Un acteur est une personne, un matériel ou un logiciel qui interagit avec le système dans
le but de réaliser une ou plusieurs tâches.Pour notre application, nous avons identifie les
acteurs suivants :
Administrateur : Cet acteur est la personne responsable de l’administration de l’appli-
cation avec le plus haut niveau de privilège.
Médecin : Personne qui diagnostique et en traitant les maladies. Un médecin est un pro-
fessionnel de la santé titulaire d’un diplôme de docteur en médecine, il soigne les maladies,
pathologies et blessures, il travaille généralement au sein d’une équipe de professionnels de
la santé comme le psychologue, le pharmacien, l’infirmière ou le chirurgien-dentiste.
Patient : est une personne physique recevant une attention médicale ou qui est prodi-
gué un soin. Il a les droits d’accès libres et il profite des différents services présents dans
13

CHAPITRE 2. ANALYSE ET CONCEPTION
l’application.
2.2 Identification des besoins fonctionnels par acteurs :
Les besoins fonctionnels représentent les exigences du futur système en termes de fonc-
tionnalités.
2.2.1 Spécification des besoins pour l’acteur "Administrateur"
L’application permet de garantir les fonctionnalités suivantes à l’administrateur :
Authentification : l’administrateur possède un identifiant et un mot de passe spécifique
qui lui permet de vérifier son identité, afin d’autoriser l’accès aux différents services de
l’application en toute sécurité.
Gérer les comptes médecins : l’administration de notre application peut consulter valider,
bloquer, et supprimer un médecin.
2.2.2 Spécification des besoins pour l’acteur "Médecin"
L’application permet de garantir les fonctionnalités suivantes :
Authentification : le médecin possède un identifiant et un mot de passe spécifique qui lui
permet de vérifier son identité, afin d’autoriser l’accès aux différents services de l’application
en toute sécurité.
Modifier profil : après avoir s’identifier le médecin peut modifier ses données.
Gérer la disponibilité : Chaque médecin doit concevoir ses créneaux en spécifiant l’horaire
de disponibilité avec la possibilité de basculer un temps de réservation et le désactiver.
Suivi des RDV : après consulter la liste des RDV le médecin peut annuler un RDV.
Gérer du Dossier Médical : le médecin peut consulter et gérer le dossier médical à chaque
nouvelle consultation tel qu’il rédige l’observation de l’examine et l’ordonnance peut aussi
demander au patient de faire des examens complémentaires.
Imprimer ordonnance et analyse : le médecin à la possibilité d’imprimer l’ordonnance et
l’analyse à tout moment.
2.2.3 Spécification des besoins pour l’acteur "Patient"
Le système permet de garantir les fonctionnalités suivantes au patient :
Authentification : le médecin possède un login et un mot de passe spécifique qui lui permet
de vérifier son identité, afin d’autoriser l’accès aux différents services de l’application en toute
sécurité.
Modifier profil : après avoir s’identifier le médecin peut modifier ses données.
14

CHAPITRE 2. ANALYSE ET CONCEPTION
Suivi par calendrier : elle intéresse tout patient enregistré qui peut avoir à sa disposition
tout un historique de ses rendez-vous déjà pris soit en tant que liste ou sur un calendrier.
Gérer les RDV : le patient peut prendre un rendez-vous pour une consultation en ligne ou
réelle, aussi il peut annuler le rendez-vous.
Suivi du Dossier Médical : le patient peut consulter son dossier médical détaillé.
Gérer les rappels des médicaments : le patient a la possibilité de configurer un rappel de
médicament selon l’ordonnance de médecin à partir d’un mail pendant une durée demandée.
2.3 Identification des besoins non fonctionnels :
Les besoins non fonctionnels sont les exigences du futur système qui ont un aspect visuel
pour l’utilisateur, mais qui ne sont pas directement liées au comportement du système. Les
besoins non fonctionnels de notre système sont décrits comme suit :
Sécurité : Notre application comporte des informations personnelles et sensibles, donc elle
doit respecter les règles relatives à la sécurité des systèmes informatiques. Nous devons avoir
un système d’accès sécurisé qui se base sur l’authentification et la cryptage des mots de
passe.
Disponibilité : l’application doit être ouvert à tout instant pour être utilisée par n’importe
quel utilisateur, et doit être facilement accessible. Nous devons avoir un système d’accès
disponible les week-ends, les vacances et des périodes de maintenance.
La rapidité du traitement : l’application doit avoir une rapidité d’exécution et d’accès à la
base de données en évitant l’utilisation de plusieurs boucles s’il est possible.
La confidentialité : Vu que notre application contient des données personnelles du patient.
C’est pour cette raison le système doit garantir la confidentialité de l’information, tel que
seul le médecin peut consulter ses consultations.
Ergonomie:l’applicationdoitfourniruneinterfacesimpleetergonomiquepourl’utilisateur
afin de garantir une facilité d’exploitation et une rapidité de service.
3 Modélisation de l’application
3.1 Langage de modélisation «UML»
Pour bien comprendre notre projet, nous avons besoin d’un langage unifié pour sa modé-
lisation. Nous avons choisi le langage UML[4], abréviation de "Unified Modeling Language"
présente également le meilleur outil schématiser des systèmes complexes dans un format gra-
phique et textuel simplifié et standardisé. En tant que logiciel de modélisation, nous avons
utilisé draw.io[5] c’est un logiciel de modélisation UML open source. Étant facile à opérer, il
nous permet de comprendre les différents types de diagrammes UML. le figure 2.1 représente
le logo de logiciel .
15

CHAPITRE 2. ANALYSE ET CONCEPTION
Figure 2.1 – Logo "draw.io"
3.2 Diagramme de cas d’utilisation
Le diagramme cas d’utilisation répresente les interactions fonctionnelles entre les acteurs
et le système en déterminant les besoins des utilisateurs.
3.2.1 Diagramme de cas d’utilisation global
Ci-dessous, nous allons représenter le diagramme de cas d’utilisation globale de notre
application en utilisant le langage de modélisation universelle UML :
16

CHAPITRE 2. ANALYSE ET CONCEPTION
Figure 2.2 – Diagramme de cas d’utilisation global
3.2.2 Diagramme de cas d’utilisation «S’authentifier»
La figure 2.3 illustre le Diagramme de cas d’utilisation «S’authentifier».
Le tableau 2.1 montre la description du cas d’utilisation «S’authentifier».
17

CHAPITRE 2. ANALYSE ET CONCEPTION
Figure 2.3 – Diagramme de cas d’utilisation «S’authentifier»
Table2.1 – Description du cas d’utilisation « S’authentifier »
Titre Authentification
Acteurs Utilisateur
Pré conditions utilisateur inscrit
Post conditions utilisateur connecté
Description de scénario principale 1. L’acteur saisit son login et son mot de
passe.
2. IL clique sur le bouton « Connecter »
3. Le système vérifie la combinaison login et
mot de passe
4.le système affiche l’interface correspon-
dante.
A3 : Exception Si le login et le mot de passe sont incorrects,
le système affiche un message d’erreur.
18

CHAPITRE 2. ANALYSE ET CONCEPTION
3.2.3 Diagramme de cas d’utilisation «Gestion des médecins»
L’administrateur doit faire tout d’abord une authentification, puis il peut consulter la
liste des médecins, aussi il faut vérifier que le compte l’existence de médecin avant d’accepter
ou refuser comme illustre La figure 2.4 qui représente le diagrammes de cas d’utilisation
«Gestion des médecins».
Figure 2.4 – Diagramme de cas d’utilisation «Gestion des médecins»
Le tableau 2.2 montre la description textuelle du sous cas d’utilisation «valider un compte
médecin».
Table2.2 – Diagramme du sous cas d’utilisation «valider un compte médecins»
Résumé L’administrateur de notre application per-
met de valider plusieurs médecins
Pré conditions L’administrateur est authentifié
Post conditions le médecin devient un membre de la liste de
l’application
Scénario nominal 1. L’administrateur affiche la liste des méde-
cin déjà inscrits,
2.L’administrateur vérifier que le médecin
existe,
3. l’administrateur valide le compte.
Scénario d’exception A3 : Si le médecin n’existe pas l’administra-
teur supprime le compte .
19

CHAPITRE 2. ANALYSE ET CONCEPTION
3.2.4 Diagrammedecasd’utilisation«gérerlesdossiersmédicalesdespatients»
La figure 2.5 illustre le diagramme de cas d’utilisation «gérer les dossiers médicales des
patients».
Figure 2.5 – Diagramme de cas d’utilisation «gérer les dossiers médicales des patients»
Letableau2.3montreladescriptiontextuelleducasd’utilisation«gérerlesdossiersmédicales
des patients».
Table2.3 – Diagramme du cas d’utilisation «gérer les dossiers médicales des patients»
Résumé Le médecin de notre application peut consul-
ter et ajouter des consultations
Pré conditions le médecin est authentifié et rendes-vous ré-
servé
Post conditions ajout de consultation à dossier médical
Description de scénario principale 1. Le médecin affiche la liste des rendez-vous
du jour,
2. le médecin choisit un rendez-vous,
3. le système ouvre une interface de nouvelle
consultation,
4. le médecin ajoute l’observation, fichier,
analyse et ordonnance puis clique sur le bou-
ton «Enregistrer»,
6. le médecin imprime l’ordonnance.
20

CHAPITRE 2. ANALYSE ET CONCEPTION
3.2.5 Diagramme de cas d’utilisation «Suivi des rendez-vous du patients»
Pour prendre un rendez-vous, le patient choisi la date et l’heure souhaité dans le
calendrier de médecin. Si ne peut pas sélectionner la date et/ou l’heure c’est à dire que le
médecin pas disponible ou réservé par un autre patient. La figure 2.6 illustre le diagramme
de cas d’utilisation «Suivi des rendez-vous du patients».
Figure 2.6 – Diagramme de cas d’utilisation «Suivi des rendez-vous du patients»
Le tableau 2.4 montre la description textuelle du cas d’utilisation «Prendre un rendez-
vous».
Table2.4 – Sous cas d’utilisation «Prendre un rendez-vous»
Résumé Le patient de notre application peut prendre
un rendez-vous facilement.
Pré conditions le rendez-vous non réservé.
Post conditions Un nouveau rendez-vous sera ajouté
Description de scénario principale 1. Le patient accède au calendrier de méde-
cin,
2. le patient choisit la date et l’heure souhai-
tés,
3. le rendez-vous sera affecté à la date appro-
prié sur l’agenda.
21

CHAPITRE 2. ANALYSE ET CONCEPTION
Tableau 2.5 : Description du sous cas d’utilisation « Annuler rendez-vous »
Table2.5 – Sous cas d’utilisation «Annuler rendez-vous»
Résumé Un patient peut annuler un rendez-vous à
tout instant.
Pré conditions Rendez-vous déjà existant
Post conditions Rendez-vous annulé
Description de scénario principale 1. Lepatientaccèdeàla listederendez-voud,
2. le patient choisit le rendez-vous ,
3. le rendez-vous est annulé et le créneau de-
vient libre au calendrier,
4. un mail de formation est envoyé au méde-
cin.
3.2.6 Diagramme de cas d’utilisation «Suivi des rendez-vous du médecins»
La figure 2.7 représente le diagramme de cas d’utilisation «Suivi des rendez-vous du
médecins»
Figure 2.7 – Diagramme de cas d’utilisation «Suivi des rendez-vous du médecins»
Tableau 2.6 représente le Description du sous cas d’utilisation « Générer disponibilité »
Table2.6 – Sous cas d’utilisation «Générer disponibilité »
Résumé La génération de disponibilité est indispen-
sable pour la réservation d’un rendez-vous.
Pré conditions Médecin authentifié .
Post conditions Créneaux générés.
Scénario nominal 1. le médecin ouvre le "calendrier" de dispo-
nibilité,
2. le médecin choisit la date et temps souhai-
tés,
3. le temps sera bloqué à la date approprié
sur le calendrier.
22

CHAPITRE 2. ANALYSE ET CONCEPTION
Tableau 2.7 représente Description du sous cas d’utilisation « Annuler rendez-vous »
Table2.7 – Sous cas d’utilisation «Annuler rendez-vous»
Résumé le médecin peut annuler un rendez-vous à
tout instant.
Pré conditions Rendez-vous déjà existant
Post conditions Rendez-vous annulé
Description de scénario principale 1. Le médecin accède à la liste de rendez-
vous,
2. le médecin choisit le rendez-vous,
3.le rendez-vous est annulée ,
4.unmaildeformationestenvoyéaupatient.
3.3 Conception :
Dans cette partie, nous allons exprimer le diagramme de classes de notre projet ainsi
que les diagrammes de séquence.
3.3.1 Diagramme de classe
Le diagramme de classes permet de représenter une vue statique de notre application.
Il a pour objectif la modélisation des entités du système d’information. Il décrit donc
l’ensemble des informations gérées au niveau du système ainsi que les relations entre elles.
3.3.1.1 Diagramme de classe global : Le diagramme de classe de notre système d’in-
formation est illustré par la figure 2.8.
23

CHAPITRE 2. ANALYSE ET CONCEPTION
Figure 2.8 – Diagramme de classe global
3.3.1.2 Description du diagramme de classe : Notre diagramme de classes contenir
plusieurs tables. Les plus importantes sont les suivantes :
Les classes médecin et patient : sont des classes qui représentent les acteurs principales de
notre application.
La classe Spécialité : est une classe qui définit le spécialité affecté à chaque médecin, d’où
un médecin peut avoir une seule spécialité et une spécialité peut être affecté à plusieurs
médecins.
24

CHAPITRE 2. ANALYSE ET CONCEPTION
La classe Rendez-vous : pour prendre un rendez-vous, l’utilisateur nécessite d’accéder au
calendrier du médecin sélectionné.
La classe Notification : après passer la consultation le médecin donne l’ordonnance, le
patient peut fixé des notifications sur les médicaments selon la durée.
La classe Dossier-Médical : est une classe qui représente les informations médicales affecté
à chaque patient ,contient une liste des consultations gère par un ou plusieurs médecins.
La classe Administrateur : est une classe qui représente l’administrateur de l’application
peut vérifier l’existence de médecin et gère les paramètres des recettes .
LaclasseConsultation:estuneclassecomposedesquatreclassesObservation,Ordonnance,
Fichier et Analyse qui sont ajoutés par un médecin .
de représenter des collaborations entre objets selon un point de vue temporel
3.3.2 Diagramme de séquence
Les diagrammes de séquences sont la représentation des collaborations entre objets selon
un point de vue temporel. A ce stade, Dans cette partie, nous allons présenter les différents
diagrammes de séquences correspondants aux différents cas d’utilisations déjà étudiés.
3.3.2.1 Diagramme de séquence «S’authentifier» Nous allons maintenant repré-
senter le cas d’utilisation « S’authentifier » sous forme de diagrammes de séquence. La figure
2.9 illustre le diagramme de séquence pour authentifier un utilisateur.
25

CHAPITRE 2. ANALYSE ET CONCEPTION
Figure 2.9 – Diagramme de séquence «S’authentifier»
3.3.2.2 Diagramme de séquence «Gestion des médecins» Nous allons maintenant
exprimer les interactions pour le cas d’utilisation «Gestion des médecins» sous forme de
diagramme de séquence.
La figure 2.10 illustre le diagramme de séquence pour gérer un médecin.
26

CHAPITRE 2. ANALYSE ET CONCEPTION
Figure 2.10 – Diagramme de séquence «Gestion des médecins»
3.3.2.3 Diagramme de séquence «Gestion des dossiers médicales» La figure 2.11
illustre le diagramme de séquence relatif au cas d’utilisation «gérer les dossiers médicales de
patient»
27

CHAPITRE 2. ANALYSE ET CONCEPTION
Figure 2.11 – Diagramme de séquence «Gestion des dossiers médicales»
3.3.2.4 Diagramme de séquence de «Prendre rendez-vous» La figure 2.12 illustre
le diagramme de séquence relatif au sous cas d’utilisation «Prendre un RDV» correspond
au diagramme de cas d’utilisation «Suivi des rendez-vous du patients».
28

CHAPITRE 2. ANALYSE ET CONCEPTION
Figure 2.12 – Diagramme de séquence «Prendre un rendez-vous»
3.3.2.5 Diagramme de séquence «Annuler rendez-vous» La figure 2.13 illustre le
diagramme de séquence pour annuler un rendez-vous.
29

CHAPITRE 2. ANALYSE ET CONCEPTION
Figure 2.13 – Diagramme de séquence «Annuler un rendez-vous»
3.3.2.6 Diagrammedeséquencede«Générerdisponibilité» Lafigure2.14illustre
le diagramme de séquence générer disponibilité correspond au diagramme de cas d’utilisation
« Suivi des rendez-vous du médecins ».
30

CHAPITRE 2. ANALYSE ET CONCEPTION
Figure 2.14 – Diagramme de séquence «Générer disponibilité»
3.3.2.7 Diagramme de séquence de «Annuler rendez-vous» La figure 2.15 illustre
le diagramme de séquence d’annuler de rendez-vous pour le médecin.
31

CHAPITRE 2. ANALYSE ET CONCEPTION
Figure 2.15 – Diagramme de séquence «Annuler rendez-vous»
3.4 Diagramme d’activité du sous cas d’utilisation «prendre un
RDV»
pour prendre un rendez-vous nous avons besoin de suivre les étapes de ces fonctions
illustrées dans le diagramme d’activité de la Figure 2.16.
32

CHAPITRE 2. ANALYSE ET CONCEPTION
Figure 2.16 – Diagramme d’activité «Gestion médecin»
33

CHAPITRE 2. ANALYSE ET CONCEPTION
3.5 Diagramme d’état-transition du cas d’utilisation «suivi des
rendez-vous du patient»
Le diagramme d’état-transition permet d’analyser les changements d’états d’un objet ou
d’un composant, en réponse aux interactions avec des acteurs. La figure 2.17 représente le
diagramme d’état-transition correspond au diagramme du cas d’utilisation «suivi des rendez-
vous du patient».
Figure 2.17 – Diagramme d’état-transition «suivi des rendez-vous du patient»
4 Conclusion
Ce chapitre concerne les diagrammes à savoir la réalisation du module de gestion des
médecin, gestion dossier-médical et notification des médicaments et gestion des rendez-vous
et disponibilité côté Web en passant par la spécification et la conception. Dans le chapitre
suivant nous entamons .
34

CHAPITRE 3. RÉALISATION
Chapitre 3
Réalisation
1 Introduction
Ce dernier chapitre traite la phase qui a pour objectif l’implémentation de notre appli-
cation. Nous commençons, tout d’abord, par la description de l’environnement matériel et
logiciel utilisés pour développer notre solution. Ensuite nous justifions nos choix technolo-
giques utilisés. Finalement nous donnons un aperçu sur le travail réalisé.
2 Environnement de développement
Dans cette section nous allons présenter l’environnement de développement de l’applica-
tion que nous avons utilisés.
2.1 Langage de développement
PHP[6] : Le développement de partie back-end de l’application se base sur le PHP est
un langage de programmation libre pratiqué pour développer des pages Web dynamiques
via un serveur HTTP, mais pouvant également fonctionner comme n’importe quel langage
interprété de façon locale. PHP est un langage impératif orienté-objet.
Figure 3.1 – Logo "PHP"
35

CHAPITRE 3. RÉALISATION
TypeScript : C’est une surcouche de JavaScript qui permet un typage statique optionnel
des variables et des fonctions, la création des classes et des interfaces, l’import de modules,
tout en conservant l’approche non-contraignante de JavaScript.
Figure 3.2 – Logo "TypeScript"
2.2 Plateforme de développement
Visual Studio 2018 Professionnel[7] : Visual Studio Professional 2018 utilise tous le
même environnement de développement intégré (IDE), qui permet de partager des outils et
facilite la création de solutions faisant appel à plusieurs langages. Son logo est représenté
dans la figure suivante
Figure 3.3 – Logo "Visual studio"
Git est un système de contrôle de version distribué gratuit et à source ouverte, conçu pour
gérer tout projet Git[8] : C’est un système de contrôle de versions et gère de sources.
Son logo est représenté dans la figure suivante. Postman[9] : Postman est une application
Figure 3.4 – Logo "Git"
permettant avec un navigateur WEB de lancer des appels d’API et de les tester. Postman
permet d’envoyer des requêtes vers l’API de site puis il permet de formater le résultat sur
plusieurs formats tels que JSON, XML, HTML et autres.Son logo est représenté dans la
figure suivante
36

CHAPITRE 3. RÉALISATION
Figure 3.5 – Logo "Postman"
2.3 Framework de développement
Le Framework Symfony[10] : Symfony est un ensemble de composants PHP ainsi qu’un
framework MVC libre écrit en PHP. Il fournit des fonctionnalités modulantes et adaptables
qui permettent de faciliter et d’accélérer le développement d’un site WEB. Son logo est re-
présenté dans la figure suivante.
Figure 3.6 – Logo "Symfony"
-Doctrine est l’un des ORM (object relational mapping) les plus connus qui existent ac-
tuellement. Il est utilisé dans des frameworks très connus (symfony, Zend Framework), et il
est aussi simple à prendre en main et puissant. Son logo est présenté dans la figure suivante.
-Twigest un moteur de template php dans la même lignée que smarty et directement intégré
Figure 3.7 – Logo "Doctrine"
dans Symfony4. Très puissant, twig permettra de gérer de l’héritage entre templates, séparer
les couches de présentation et métiers. Son logo s’est affiché dans la figure suivante.
Figure 3.8 – Logo "Twig"
Framework Angular 6/7[11] : Angular 6/7 est l’un des frameworks les plus populaires pour
le développement d’applications Web. Angular 6 est l’évolution de AngularJS qui est un lan-
gage de programmation base sur TypeScript. Son logo s’est affiché dans la figure suivante.
37

CHAPITRE 3. RÉALISATION
Figure 3.9 – Logo "Angular"
3 Description générale du système
3.1 Diagramme déploiement du système
Nous nous proposons de présenter le diagramme "déploiement général du système"
dans ce qui va suivre, en respectant une certaine méthodologie. Ce diagramme décrit le
déploiement physique des informations générées par le logiciel sur des composants matériels.
Notre diagramme de déploiement est constitué de cinq noeuds principaux :
PC médecin : qui est composé d’un navigateur WEB qui sert d’outils de communication
entre les utilisateurs de notre système et le reste des noeuds. les utilisateurs lancent leurs
demandes sous forme de HTTP request et en reçoivent de HTTP response et le même
principe pour le PC patient.
Front-end : la couche présentation qui regroupe l’ensemble des formulaires et les interfaces
à communiquer au navigateur par flux HTTP suite à une demande de l’utilisateur.
Back-end : le programme d’écoute Campaign fournit deux interfaces
-une interface entre les clients Front-end et les processus serveur analytiques Back-end.
– une interface de base de données qui est l’interface reliant notre application avec la base
de données.
le serveur de base de données : qui contient la base de données de notre application. L’ap-
plication WEB campaign (Front-end) et le programme d’écoute (Back-end) communiquent
sur TCP/IP pour traiter les demandes et les transaction de processus comme illustre la
figure suivante.
38

CHAPITRE 3. RÉALISATION
Figure 3.10 – «Diagramme déploiement du système»
3.2 Architecture de l’application
Le but de ce travail était de créer une application Web intuitive, efficace et sécurisée
en utilisant les solutions les plus modernes et innovantes disponibles dans le domaine du
développement WEB. Nous avons utilisé le modèle d’application client-serveur, avec la com-
munication entre deux parties utilisant le protocole HTTP (Hypertext Transfer Protocol).
Le schéma simple du modèle d’application est présenté à la Fig. 3.11. En tant que noyau
d’applications développées côté serveur (back-end), nous avons utilisé le framework Sym-
fony4 entièrement évolutif et orienté objet [10] avec l’architecture basée sur le contrôleur de
modèle-vue (MVC) le plus fiable et le plus efficace motif de conception [11]. Le framework
Symfony4 était supporté par le paquet Doctrine pour gestion de la base de données et avec
les modèles TWIG pour faciliter la préparation de la vue. Côté client (front-end) pour la
présentation et le traitement des données, nous avons utilisé le Bibliothèques Bootstrap et
Angular 6/7.
39

CHAPITRE 3. RÉALISATION
Figure 3.11 – «Architecture de l’application»
Notreapplicationréaliséeprésentedesinterfacesattractives,lisiblesetfacilesàmanipuler.
Dans ce qui suit, on illustre les principales interfaces de notre application.
4 Interface de l’application
Après les phases d’étude préalable, la conception et la modélisation fonctionnelle et orga-
nisationnelle, on a développé les interfaces de notre application en mentionnant des imprimés
écrans.
4.1 Interface d’accueil
Lafigureci-dessousmontrel’interfaceprincipaledel’applicationquicontientdeuxbouton
une pour l’interface d’authentification du médecin et l’autre pour l’interface d’authentifica-
tion du patient.
40

CHAPITRE 3. RÉALISATION
Figure 3.12 – «interface login médecin»
4.2 Les interfaces d’utilisateur en tant que médecin
4.2.1 Interface Authentification
La figure 3.13 présente l’interface login qui permet aux médecins de s’identifier à l’aide de
leuradresseemailetleurmotdepasse.Silemédecinestconnecté,lapageduRendez-vousdu
jour est affichée.Si le identifiant et le mot de passe sont faux un message d’erreur sera affiché.
Figure 3.13 – «interface login médecin»
41

CHAPITRE 3. RÉALISATION
4.2.2 Interface rendez-vous du jour
La figure 3.14 représente l’interface pour consulter la liste des rendez-vous du jour.Si la
consultation est commencé, le médecin peut accéder à l’interface de nouvelle consultation .
Figure 3.14 – «interface rendez-vous du jour»
4.2.3 Interface nouvelle consultation
La consultation est une étape postérieure qui se provoque suite à la prise de rendez-vous,
le médecin peut ajouter une consultation à dossier médical de patient concerné. La figure
3.14 représente l’interface d’ajout une nouvelle consultation, les détails de patient et les
historiques nous donne une idée sur l’état de patient.
Figure 3.15 – «interface nouvelle consultation»
42

CHAPITRE 3. RÉALISATION
4.2.4 Interface liste des consultations
La figure 3.16 représente l’interface de liste des consultations tel que le médecin peut
imprimer les ordonnances et les analyses aussi consulter les observations et les fichiers mé-
dicales.
Figure 3.16 – «interface imprimer l’ordonnance»
4.2.5 Interface modifier le profil
À travers la figure 3.17, le médecin peut modifier son profil.
Figure 3.17 – «interface modifier le profil»
4.2.6 Générer disponibilité
le médecin peut suivre la liste de ses rendez-vous dans un calendrier et au même temps
peut générer son horaire indisponible tel que on clique sur la case.Une fenêtre pop-up se
43

CHAPITRE 3. RÉALISATION
déclenche pour appliquer les modifications du disponibilité au temps choisi.La figure 3.18
représente l’interface de modification de disponibilité.
Figure 3.18 – «gérer disponibilité»
4.2.7 Annuler rendez-vous
Après avoir réservé un rendez-vous, le médecin peut afficher par la suite la liste de ses
rendez-vous réservés.Par ailleurs, pour annuler un rendez-vous le médecin clique sur slide
toggle.Une fenêtre de confirmation s’affiche.La figure 3.19 représente l’interface d’annulation
rendez-vous.une fois que médecin clique sur ’OK’ un mail de formation est envoyé au patient
et le créneau devient indisponible au calendrier.
Figure 3.19 – «annuler rendez-vous»
La figure 3.20 représente l’interface de réception de mail de confirmation.
44

CHAPITRE 3. RÉALISATION
Figure 3.20 – «Notification de confirmation de rendez-vous par mail»
4.3 Les interfaces d’utilisateur en tant que administrateur
4.3.1 Interface Authentification
La figure 3.21 représente l’interface d’authentification administrateur.Si l’administrateur
est connecté, la liste des médecins est affichée.
Figure 3.21 – «interface login administrateur»
4.3.2 Interface consulter la liste des médecins
La figure 3.22 représente l’interface pour consulter la liste des médecins.
45

CHAPITRE 3. RÉALISATION
Figure 3.22 – «interface de liste des médecins»
via cette interface, l’administrateur peut gérer les médecins. Il peut consulter, valider,
bloquer, modifier l’état d’abonnement ou supprimer un médecin. Dans ce qui suit, nous
allons détailler les scénarios de la gestion des médecins sous forme des captures d’écran. La
figure 3.23 représente l’interface de consulter compte médecin.
Figure 3.23 – «interface compte du médecin»
46

CHAPITRE 3. RÉALISATION
Pour supprimer un médecin,l’administrateur clique sur l’icône de poubelle et automati-
quement une fenêtre s’affiche disant si accepte la suppression de médecin.
La figure 3.24 représente l’interface de suppression d’un médecin.
Figure 3.24 – «interface supprimer un utilisateur»
À travers la figure 3.25 l’administrateur peut bloquer un médecin déjà validé, par un clic
sur le bouton "médecin valide" vice versa peut valider par un clic sur le bouton "médecin
en-cours", aussi peut modifier l’état d’abonnement sélect ’suspendu’ ou ’en-cours’.
Figure 3.25 – «interface bloquer valider un médecin et modifier l’état d’abonnement»
4.4 Les interfaces d’utilisateur en tant que patient
4.4.1 Interface Authentification
La figure 3.26 représente l’interface d’authentification Patient .Si le patient est connecté,
la page de dossier médical est affichée.
47

CHAPITRE 3. RÉALISATION
Figure 3.26 – «interface login patient»
4.4.2 Interface de dossier médical
À travers cette interface, le patient peut prendre une idée sur votre santé à partir de la
liste des consultations.
Figure 3.27 – «interface de dossier médical»
48

CHAPITRE 3. RÉALISATION
4.4.3 Interface pour modifier le profil
Dans cette interface, le patient a le droit de modifier son profil.
Figure 3.28 – «interface modifier le profil»
4.4.4 Interface «prendre un RDV»
À travers cette interface, le patient peut faire une recherche sur le médecin avec son nom
ou sa spécialité après peut accéder à Une interface calendrier de médecin choisi. La figure
3.29 représente la liste des médecins.
Figure 3.29 – «interface liste médecin»
À travers cette interface, le patient peut consulter les créneaux disponibles et les rendez-
vous de médecin.Si la possibilité en cliquant simplement sur un créneau libre, Une fenêtre
49

CHAPITRE 3. RÉALISATION
pop-up se déclenche pour ajouter un nouveau rendez-vous. La figure 3.30 représente l’agenda
de médecin choisi.
Figure 3.30 – «interface calendrier médecin choisi»
La figure 3.31 représente la fenêtre d’ajout un rendez-vous.
Figure 3.31 – «interface ajouter un RDV»
50

CHAPITRE 3. RÉALISATION
4.4.5 Interface «annuler RDV»
Le patient peut afficher par la suite la liste de ses rendez-vous réservés sous forme d’un
liste comme montre la figure 3.32.
Figure 3.32 – «interface ajouter un RDV»
À travers cette interface le patient peut annuler un RDV choisi en cliquant simplement
sur slide toggle une fenêtre pop-up déclenche pour confirmer l’annulation et libérer le créneau
en agenda de médecin et aussi un mail de formation est envoyé au médecin.
4.4.6 Interface notification médicament
La figure suivante représente les rappels en cours et la liste des médicaments tel que
à travers cette interface le patient peut ajouter une notification sur médicament choisi on
simple clic sur l’icône et automatiquement une fenêtre s’affiche.
51

Figure 3.33 – «interface liste des médicaments»
La figure 3.34 représente formulaire d’ajout une notification.Si le patient clique sur ’en-
registrer’ un mail sera envoyé pendant une période précise.
Figure 3.34 – «interface ajout notification»
5 Conclusion
Dans ce chapitre, nous avons annoncé les différentes technologies logicielles utilisées dans
la réalisation du projet en mettant l’accent sur le principe du fonctionnement et les spé-
cifications techniques de chaque technologie. Ensuite, nous avons exposé les résultats de
développement à l’aide des aperçus d’écran avec description de chacun.
52