CHAPITRE1. CONTEXTEGÉNÉRALDUPROJET Chapitre 1 Contexte général du projet 1 Introduction… [632303]

Rapport PFE
Nom
2018/2019

CHAPITRE1. CONTEXTEGÉNÉRALDUPROJET
Chapitre 1
Contexte général du projet
1 Introduction
Lebutdecechapitreintroductifestdeaffecterletravaildanssoncontextegénéral.Nous
commençonstoutd’abordparuneprésentationdel’entreprised’accueil.Puis,nousdécrivons
lesujetautourduquels’articulenotreprojetdefind’études.Enfin,nouseffectuonsl’étude
desnotions,technologies,solutionsetprincipesutilisésdansnotreprojet.
2 Présentation de l’organisme d’accueil
2.1 Présentation de TakenTech
Figure 1.1–PrésentationdeTakenTech
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
leurcroissance.Takentechsrépondauxbesoinsdesesclientèlesenmatièrede:
•Développentfront-end
•Développementback-end
•ApplicationsmobilesAndroid/IOS
•CMSouCRM
8

CHAPITRE1. CONTEXTEGÉNÉRALDUPROJET
•Créationdessitesvitrine,sitese-commerce
•API,templates
•Interfaced’administration,interfaceresponsive
•Campagnee-mailings,newsletters
•Architecturelogiciel,conseilstechniques…
Takentechsestforméeparungroupedejeunes,talentueuxingénieursissusdegrandesécoles
enTunisieetenFrance,quimaîtrisentdiversesproblématiquesmétierspropresaudomaine
du WEB, agilistes convaincus, font de la satisfaction client leur priorité absolue. Les parte-
nairesdeTakentechsapprécientsonadaptabilitéd’intégrationenéquipeenstart-upscomme
danslesgrandesstructures.
2.2 Fiche d’identité
•Raisonsocial:TakenTech;
•Secteur:servicesinformatiques;
•Directeur:BoumedyenBoussaid;
•Adresse:RueBéchirJaziri,Imm.Amal,App.C2,6000,Gabés,TUNISIE;
•Numérodetéléphone:+21693003968;
•Email:[anonimizat];
•SiteWEB:www.takentechs.com.
3 Présentation du Projet
3.1 Contexte général du projet
Pendant la durée de stage, il nous a été demandé de développer et l’intégrer une appli-
cationWEBdegestionmédicale.Pourleprofessionneldesanté,c’estunservicecompletde
gestion de cabinet médical, qui optimise l’organisation et fait gagner du temps. La plate-
formeoffrelapossibilitédegérerlesrendez-vous,l’horaireetlesdossiersmédicauxàchaque
nouvelle consultation. Pour le patient, c’est un service qui vous permet de trouver rapide-
mentunmédecinetdeprendrerendez-vousenlignesuivantladisponibilité,aussisuivreson
dossiermédicalsécurisé(détaillé).Ainsiaveccetteapplication,lepatientpeutrappelervos
médicamentslelongd’unepériodeprécisée.
Le sujet est certainement intéressant car l’application dont nous parlons est peut être une
réellevaleurajoutéedanslaviedechacunetsesperspectivesd’évolutionsonténormeprivé
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
deGabésentélécommunicationetréseaux.Lestages’estdéroulésurunepériodedequatre
mois,aucoursdelaquellenousavonsappréciéletravailenéquipe.
9

CHAPITRE1. CONTEXTEGÉNÉRALDUPROJET
3.2 Étude de l’existant
Danscettepartienousallonsétudierquelquesexemplesdesapplicationsdéjàexistantes
dansledomainededéveloppement.onachoisideuxapplicationlepluspopulaires:
•Doctolib : Doctolib[2]estunestartupfrançaisefondéeen2013quifournitunserviceen
lignedepriseetdegestionderendez-vousmédicauxmettantenrelationdespatientsetdes
professionnelsdelasanté.Doctolibapourobjectifd’améliorerlequotidiendesprofessionnels
desantéetdespatients.Pourlespatients,ilpermetdetrouverunpraticienprèsdechezsoi
etdeprendrerendez-vousenquelquesclics.
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édecinpourprendreunrendez-vous.
Figure 1.2–AccueildeDoctolib
10

CHAPITRE1. CONTEXTEGÉNÉRALDUPROJET
Figure 1.3–Agendademédecinchoisi
•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
enlignegratuitement.Ilpermetenoutre,d’entrerencontactdirectementavecdespatients
tunisiensetétrangersetderépondreàleursinterrogations.L’applicationpermetdetrouver
unepharmacieàproximité.Lafigure1.4représentel’accueildel’application.
Figure 1.4–AccueildeMed.tn
3.3 Critique l’existant
Cette partie a pour but de dégager les insuffisances et les défaillances des applications
précédentesdontonpeutciter:
•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’urgencesilepraticienchoisin’estpasdisponible.
11

CHAPITRE1. CONTEXTEGÉNÉRALDUPROJET
•PourMed.tn,leprincipedecetteapplicationestextramaisonrésumelemanquedegestion
dudossiermédical.Aussil’absencedesparamètres(duréedeconsultation…)degestiondes
rendez-vous.
3.4 Solution proposée
Après avoir fait critique les applications existantes sur le marché. nous allons proposer
notre solution dans le but de gérer les taches de médecins et patients. Notre solution est
de développer une application simple à utiliser qui facilite les tâches de médecin en lui
offrantlapossibilitédegérerledossiermédicaltelqueàchaqueconsultationpeutconsulter
l’historiqued’étatdusantéetajouterunrésumédelanouvelleconsultationetdutraitement
donnéseraportésurledossiermédical.Ainsiquecetteapplicationpeutrappelerlepatient
desuivresestraitementpendantunepériodepréciséeparlemédecinàl’aided’unemail.Les
fonctionnalitésquecetteapplicationproposeraserontdétailléesdanslechapitresuivant.
4 Conclusion
ToutaulongdeceChapitrenousavonsprésentélecadredeprojetainsiqu’uneétudede
marché afin de proposer notre solution respectant les objectifs demandés par la société. Le
Chapitresuivantprésentel’analyseetlaconception,uneétapeprimordialedansl’élaboration
etlacréationdetouteapplication.
12

CHAPITRE2. ANALYSEETCONCEPTION
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
etdynamiqueàtraversunensembledediagrammeUML.
2 Capture des besoins :
Au cours de cette activité, nous allons extraire en premier lieu les acteurs principaux,
lesbesoinsfonctionnelsainsiquelesbesoinsnonfonctionnels.Endeuxièmelieu,nousallons
identifierlesdifférentsdiagrammesUML.
2.1 Identification des acteurs :
Pournotreapplication,nousavonsidentifielesacteurssuivants:
•Administrateur : Cetacteurest lapersonneresponsabledel’administrationde l’appli-
cationavecleplushautniveaudeprivilège.
•Médecin : Personnequidiagnostiqueetentraitantlesmaladies.Unmédecinestunpro-
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
lasantécommelepsychologue,lepharmacien,l’infirmièreoulechirurgien-dentiste.
•Patient : estunepersonnephysiquerecevantuneattentionmédicaleouquiestprodigué
unsoin.Ilal’accèsdesdifférentsservicesprésentsdansl’application.
13

CHAPITRE2. ANALYSEETCONCEPTION
2.2 Identification des besoins fonctionnels par acteurs :
Les besoins fonctionnels correspondent aux fonctionnalité que l’application doit fournir
auxutilisateur.
2.2.1 Spécification des besoins pour l’acteur "Administrateur"
L’applicationpermetdegarantirlesfonctionnalitéssuivantesàl’administrateur:
•Authentification:pouravoiraccèsauxdifférentsservicesdel’applicationentoutesécurité.
L’administrateurdoitd’authentifierparsonidentifiantetsonmotdepasse.
•Gérerlescomptesmédecins:l’administrationdenotreapplicationpeutconsultervalider,
bloquer,etsupprimerunmédecin.
2.2.2 Spécification des besoins pour l’acteur "Médecin"
L’applicationpermetdegarantirlesfonctionnalitéssuivantes:
•Authentification:pouravoiraccèsauxdifférentsservicesdel’applicationentoutesécurité.
Lemédecindoitd’authentifierparsonidentifiantetsonmotdepasse.
•Modifierprofil:aprèsavoirs’identifierlemédecinpeutmodifiersesdonnées.
•Générer la disponibilité : Chaque médecin génère sa disponibilité (horaire de travail,
créneauindisponible).
•SuividesRDV:aprèsconsulterlalistedesRDVlemédecinpeutannulerunRDV.
•GérerduDossierMédical:lemédecinpeutconsulteretgérerledossiermédicalàchaque
nouvelle consultation tel qu’il rédige l’observation de l’examine et l’ordonnance peut aussi
demanderaupatientdefairedesexamenscomplémentaires.
•Imprimer ordonnance et analyse : le médecin à la possibilité d’imprimer l’ordonnance et
l’analyseàtoutmoment.
2.2.3 Spécification des besoins pour l’acteur "Patient"
Lesystèmepermetdegarantirlesfonctionnalitéssuivantesaupatient:
•Authentification:pouravoiraccèsauxdifférentsservicesdel’applicationentoutesécurité.
Lepatientdoitd’authentifierparsonidentifiantetsonmotdepasse.
•Modifierprofil:aprèsavoirs’identifierlemédecinpeutmodifiersesdonnées.
•Suivi par calendrier : chaque patient peut avoir un historique de ses rendez-vous déjà
acceptésousformed’unelisteousuruncalendrier.
•GérerlesRDV:lepatientpeutprendreunrendez-vouspouruneconsultationenligneou
réelle,aussiilpeutannulerlerendez-vous.
•SuividuDossierMédical:lepatientpeutconsultersondossiermédicaldétaillé.
14

CHAPITRE2. ANALYSEETCONCEPTION
•Gérer les rappels des médicaments : le patient a la possibilité de configurer un rappel de
médicamentselonl’ordonnancedemédecinàpartird’unmailpendantuneduréedemandée.
2.3 Identification des besoins non fonctionnels :
Lesbesoinsnonfonctionnelssontlesexigencesdufutursystèmequiontunaspectvisuel
pour l’utilisateur, mais qui ne sont pas directement liées au comportement du système. Les
besoinsnonfonctionnelsdenotresystèmesontdécritscommesuit:
•Sécurité:Notreapplicationcomportedesinformationspersonnellesetsensibles,doncelle
doitrespecterlesrèglesrelativesàlasécuritédessystèmesinformatiques.Nousdevonsavoir
un système d’accès sécurisé qui se base sur l’authentification et la cryptage des mots de
passe.
•Disponibilité:Nousdevonsavoirunsystèmed’accèsdisponibleàtoutmoment(lesweek-
ends,lesvacancesetlespériodesdemaintenance).Aussidoitêtrefacilementaccessible.
•Larapiditédutraitement:l’applicationdoitavoirunerapiditéd’exécutionetd’accèsàla
basededonnéesenévitantl’utilisationdeplusieursboucless’ilestpossible.
•Laconfidentialité:Vuquenotreapplicationcontientdesdonnéespersonnellesdupatient.
C’est pour cette raison le système doit garantir la confidentialité de l’information, tel que
seullemédecinpeutconsultersesconsultations.
•Ergonomie:l’applicationdoitfourniruneinterfacesimpleetergonomiquepourl’utilisateur
afindegarantirunefacilitéd’exploitationetunerapiditédeservice.
3 Modélisation de l’application
3.1 Langage de modélisation «UML»
Pourbiencomprendrenotreprojet,nousavonsbesoind’unlangageunifiépoursamodé-
lisation.NousavonschoisilelangageUML[4],abréviationde"UnifiedModelingLanguage"
présenteégalementlemeilleuroutilschématiserdessystèmescomplexesdansunformatgra-
phique et textuel simplifié et standardisé. En tant que logiciel de modélisation, nous avons
utilisédraw.io[5]c’estunlogicieldemodélisationUMLopensource.Étantfacileàopérer,il
nouspermetdecomprendrelesdifférentstypesdediagrammesUML.lefigure2.1représente
lelogodelogiciel.
3.2 Diagramme de cas d’utilisation
Lediagrammecasd’utilisationreprésentelesinteractionsfonctionnellesentrelesacteurs
denotresystème.
15

CHAPITRE2. ANALYSEETCONCEPTION
Figure 2.1–Logo"draw.io"
3.2.1 Diagramme de cas d’utilisation global
Ci-dessous, nous allons représenter le diagramme de cas d’utilisation globale de notre
applicationenutilisantlelangagedemodélisationuniverselleUML:
16

CHAPITRE2. ANALYSEETCONCEPTION
Figure 2.2–Diagrammedecasd’utilisationglobal
3.2.2 Diagramme de cas d’utilisation «S’identifier»
Lafigure2.3illustreleDiagrammedecasd’utilisation«S’identifier».
Letableau2.1montrel’analyseducasd’utilisation«S’identifier».
17

CHAPITRE2. ANALYSEETCONCEPTION
Figure 2.3–Diagrammedecasd’utilisation«S’identifier»
Table 2.1– Descriptionducasd’utilisation«S’identifier»
Titre Authentification
Acteurs Utilisateur
Préconditions utilisateurinscrit
Postconditions utilisateurconnecté
Descriptiondescénarioprincipale 1. L’acteur saisit son login et son mot de
passe.
2. Le système vérifie la combinaison login et
motdepasse
3.le système affiche l’interface correspon-
dante.
A2:Exception Si les coordonnées fausse, un message d’er-
reurseraaffiché.
18

CHAPITRE2. ANALYSEETCONCEPTION
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
listedesmédecins,aussiilfautvérifierquelecomptel’existencedemédecinavantd’accepter
ou refuser comme illustre la figure 2.4 qui représente le diagrammes de cas d’utilisation
«Gestiondesmédecins».
Figure 2.4–Diagrammedecasd’utilisation«Gestiondesmédecins»
Le tableau 2.2 montre la description textuelle du sous cas d’utilisation «valider un compte
médecin».
Table 2.2–Diagrammedusouscasd’utilisation«valideruncomptemédecins»
Résumé L’administrateur de notre application per-
metdevaliderplusieursmédecins
Préconditions L’administrateurestauthentifié
Postconditions le médecin devient un membre de la liste de
l’application
Scénarionominal 1.L’administrateuraffichelalistedesméde-
cindéjàinscrits,
2.L’administrateur vérifier que le médecin
existe,
3.l’administrateurvalidelecompte.
Scénariod’exception A3 : Si le médecin n’existe pas l’administra-
teursupprimelecompte.
19

CHAPITRE2. ANALYSEETCONCEPTION
3.2.4 Diagramme de cas d’utilisation «gérer les dossiers médicales des patients»
La figure 2.5 illustre le diagramme de cas d’utilisation «gérer les dossiers médicales des
patients».
Figure 2.5–Diagrammedecasd’utilisation«gérerlesdossiersmédicalesdespatients»
Letableau2.3montreladescriptiontextuelleducasd’utilisation«gérerlesdossiersmédicales
despatients».
Table 2.3– Diagrammeducasd’utilisation«gérerlesdossiersmédicalesdespatients»
Résumé Lemédecindenotreapplicationpeutconsul-
teretajouterdesconsultations
Préconditions le médecin est authentifié et rendes-vous ré-
servé
Postconditions ajoutdeconsultationàdossiermédical
Descriptiondescénarioprincipale 1.Lemédecinaffichelalistedesrendez-vous
dujour,
2.lemédecinchoisitunrendez-vous,
3.lesystèmeouvreuneinterfacedenouvelle
consultation,
4. le médecin ajoute l’observation, fichier,
analyseetordonnancepuiscliquesurlebou-
ton«Enregistrer»,
6.lemédecinimprimel’ordonnance.
20

CHAPITRE2. ANALYSEETCONCEPTION
3.2.5 Diagramme de cas d’utilisation «Gestion des rendez-vous du patients»
Pourfixerunrendez-vous,lepatientchoisiladateetl’heuresouhaitédanslecalendrier
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«Gestiondesrendez-vousdupatients».
Figure 2.6–Diagrammedecasd’utilisation«Gestiondesrendez-vousdupatients»
Letableau2.4montrel’analyseducasd’utilisation«Prendreunrendez-vous».
Table 2.4–Souscasd’utilisation«Prendreunrendez-vous»
Résumé Lepatientdenotreapplicationpeutprendre
unrendez-vousfacilement.
Préconditions lerendez-vousnonréservé.
Postconditions Unnouveaurendez-vousseraajouté
Descriptiondescénarioprincipale 1. Le patient accède au calendrier de méde-
cin,
2.lepatientchoisitladateetl’heuresouhai-
tés,
3.lerendez-vousseraaffectéàladateappro-
priésurl’agenda.
21

CHAPITRE2. ANALYSEETCONCEPTION
Tableau2.5:Analysedusouscasd’utilisation«Annulerrendez-vous»
Table 2.5–Souscasd’utilisation«Annulerrendez-vous»
Résumé Un patient peut annuler un rendez-vous à
toutinstant.
Préconditions Rendez-vousréservé
Postconditions Rendez-vousannulé
Descriptiondescénarioprincipale 1.Lepatientaccèdeàlalistederendez-vous,
2.lepatientchoisitlerendez-vous,
3.lerendez-vousestannuléetlecréneaude-
vientlibreaucalendrier,
4.unmaildeformationestenvoyéauméde-
cin.
3.2.6 Diagramme de cas d’utilisation «Gestion des rendez-vous du médecins»
La figure 2.7 représente le diagramme de cas d’utilisation «Gestion des rendez-vous du
médecins»
Figure 2.7–Diagrammedecasd’utilisation«Gestiondesrendez-vousdumédecins»
Tableau2.6représenteleDescriptiondusouscasd’utilisation«Générerdisponibilité»
Table 2.6– Souscasd’utilisation«Générerdisponibilité»
Résumé La génération de disponibilité est indispen-
sablepourlaréservationd’unrendez-vous.
Préconditions Médecinauthentifié.
Postconditions Créneauxgénérés.
Scénarionominal 1.lemédecinouvrele"calendrier"dedispo-
nibilité,
2.lemédecinchoisitladateettempssouhai-
tés,
3. le temps sera bloqué à la date approprié
surlecalendrier.
22

CHAPITRE2. ANALYSEETCONCEPTION
Tableau2.7représenteDescriptiondusouscasd’utilisation«Annulerrendez-vous»
Table 2.7– Souscasd’utilisation«Annulerrendez-vous»
Résumé le médecin peut annuler un rendez-vous à
toutinstant.
Préconditions Rendez-vousdéjàexistant
Postconditions Rendez-vousannulé
Descriptiondescénarioprincipale 1. Le médecin accède à la liste de rendez-
vous,
2.lemédecinchoisitlerendez-vous,
3.lerendez-vousestannulée,
4.unmaildeformationestenvoyéaupatient.
3.3 Conception :
Dans cette section, nous allons exprimer le diagramme de classes de notre projet aussi
lesdiagrammesdesé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’ensembledesinformationsgéréesauniveaudusystèmeainsiquelesrelationsentreelles.
3.3.1.1 Diagramme de classe global : Lediagrammedeclassedenotresystèmed’in-
formationestillustréparlafigure2.8.
23

CHAPITRE2. ANALYSEETCONCEPTION
Figure 2.8–Diagrammedeclasseglobal
3.3.1.2 Description du diagramme de classe : Notrediagrammedeclassescontenir
plusieurstables.Lesplusintéressantsontlessuivantes:
•Lesclassesmédecinetpatient:sontdesclassesquireprésententlesacteursprincipalesde
notreapplication.
•LaclasseSpécialité:estuneclassequidéfinitlespécialitéattribuéàchaquemédecin,d’où
un médecin peut avoir une seule spécialité et une spécialité peut être attribué à plusieurs
médecins.
24

CHAPITRE2. ANALYSEETCONCEPTION
•La classe Rendez-vous : pour prendre un rendez-vous, l’utilisateur nécessite d’accéder au
calendrierdumédecinsélectionné.
•La classe Notification : après passer la consultation le médecin donne l’ordonnance, le
patientpeutfixédesnotificationssurlesmédicamentsselonladurée.
•LaclasseDossier-Médical:estuneclassequireprésentelesinformationsmédicalesaffecté
àchaquepatient,contientunelistedesconsultationsgèreparunouplusieursmédecins.
•La classe Administrateur : est une classe qui représente l’administrateur de l’application
peutvérifierl’existencedemédecinetgèrelesparamètresdesrecettes.
•LaclasseConsultation:estuneclassecomposedesquatreclassesObservation,Ordonnance,
FichieretAnalysequisontajoutésparunmédecin.
dereprésenterdescollaborationsentreobjetsselonunpointdevuetemporel
3.3.2 Diagramme de séquence
Lesdiagrammesdeséquencessontlareprésentationgraphiquedesinteractionsentreles
acteurs et le système selon un ordre chronologique. Dans cette partie, nous allons détailler
quelquesdiagrammesdeséquenceslesplusimportantsdansnotreapplicationrelatifauxcas
d’utilisationsdéjàétudiés
Acestade,Danscettepartie,nousallonsprésenterlesdifférentsdiagrammesdeséquences
correspondantsauxdifférentscasd’utilisationsdéjàétudiés.
3.3.2.1 Diagramme de séquence «S’authentifier» Nousallonsactuellementprésen-
ter le cas d’utilisation « S’identifier» en tant que diagrammes de séquence. La figure 2.9
illustrelediagrammedeséquencepourauthentifierunutilisateur.
25

CHAPITRE2. ANALYSEETCONCEPTION
Figure 2.9–Diagrammedeséquence«S’authentifier»
3.3.2.2 Diagramme de séquence «Gestion des médecins» Dans cette partie nous
allons extraire les interactions pour le cas d’utilisation «Gestion des médecins» sous forme
dediagrammedeséquence.
Lafigure2.10illustrelediagrammedeséquencepourgérerunmédecin.
26

CHAPITRE2. ANALYSEETCONCEPTION
Figure 2.10–Diagrammedeséquence«Gestiondesmédecins»
3.3.2.3 Diagramme de séquence «Gestion des dossiers médicales» Lafigure2.11
illustrelediagrammedeséquencerelatifaucasd’utilisation«gérerlesdossiersmédicalesde
patient»
27

CHAPITRE2. ANALYSEETCONCEPTION
Figure 2.11–Diagrammedeséquence«Gestiondesdossiersmédicales»
3.3.2.4 Diagramme de séquence «Prendre rendez-vous» La figure 2.12 présente
lediagrammedeséquencecorrespondantausouscasd’utilisation«PrendreunRDV».
28

CHAPITRE2. ANALYSEETCONCEPTION
Figure 2.12–Diagrammedeséquence«Prendreunrendez-vous»
3.3.2.5 Diagramme de séquence «Annuler rendez-vous» La figure 2.13 présente
lediagrammedeséquencepourlesouscasd’utilisationannulerunrendez-vous.
29

CHAPITRE2. ANALYSEETCONCEPTION
Figure 2.13–Diagrammedeséquence«Annulerunrendez-vous»
3.3.2.6 Diagramme de séquence de «Générer disponibilité» Lafigure2.14illustre
lediagrammedeséquencegénérerdisponibilitécorrespondaudiagrammedecasd’utilisation
«Suividesrendez-vousdumédecins».
30

CHAPITRE2. ANALYSEETCONCEPTION
Figure 2.14–Diagrammedeséquence«Générerdisponibilité»
3.3.2.7 Diagramme de séquence de «Annuler rendez-vous» Lafigure2.15illustre
lediagrammedeséquenced’annulerderendez-vouspourlemédecin.
31

CHAPITRE2. ANALYSEETCONCEPTION
Figure 2.15–Diagrammedeséquence«Annulerrendez-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éesdanslediagrammed’activitédelaFigure2.16.
32

CHAPITRE2. ANALYSEETCONCEPTION
Figure 2.16–Diagrammed’activité«Gestionmédecin»
33

CHAPITRE2. ANALYSEETCONCEPTION
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 «Gestion des
rendez-vousdupatient».
Figure 2.17–Diagrammed’état-transition«Gestiondesrendez-vousdupatient»
4 Conclusion
Ce chapitre concerne les diagrammes à savoir la réalisation du module de gestion des
médecin,gestiondossier-médicaletnotificationdesmédicamentsetgestiondesrendez-vous
et disponibilité côté Web en passant par la spécification et la conception. Dans le chapitre
suivantnousentamons.
34

CHAPITRE3. 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-
giquesutilisés.Finalementnousdonnonsunaperçusurletravailréalisé.
2 Environnement de développement
Danscettesectionnousallonsprésenterl’environnementdedéveloppementdel’applica-
tionquenousavonsutilisés.
2.1 Langage de développement
•PHP[6]:Ledéveloppementdepartieback-enddel’applicationsebasesurlePHPest
un langage de script serveur et un outil puissant pour créer des pages Web dynamiques et
interactives.AussiPHPestunealternativelargementutilisée,gratuiteetefficace.
Figure 3.1–Logo"PHP"
35

CHAPITRE3. RÉALISATION
•TypeScript:C’estunesurcouchedeJavaScriptquipermetuntypagestatiqueoptionnel
des variables et des fonctions, la création des classes et des interfaces, l’import de modules,
toutenconservantl’approchenon-contraignantedeJavaScript.
Figure 3.2–Logo"TypeScript"
2.2 Plateforme de développement
Git est un système de contrôle de version distribué gratuit et à source ouverte, conçu
pourgérertoutprojet •Git[8]: C’estunsystèmedecontrôledeversionsetgèredesources.
Son logo est représenté dans la figure suivante. •Postman[9] : Postman est un logiciel qui
Figure 3.3–Logo"Git"
permet de créer et envoyer des requêtes HTTP. C’est un outil très pratique pour tester
rapidement une API et générer le code dans votre langage favori. Son logo est représenté
danslafiguresuivante
Figure 3.4–Logo"Postman"
2.3 Framework de développement
•LeFrameworkSymfony[10]: SymfonyestunensembledecomposantsPHPainsiqu’un
frameworkMVClibreécritenPHP.Ilfournitdesfonctionnalitésmodulantesetadaptables
qui permettent de faciliter et d’accélérer le développement d’un site WEB. Son logo est re-
présentédanslafiguresuivante.
36

CHAPITRE3. RÉALISATION
Figure 3.5–Logo"Symfony"
-Doctrine est l’un des ORM (object relational mapping) les plus connus qui existent ac-
tuellement.Ilestutilisédansdesframeworkstrèsconnus(symfony,ZendFramework),etil
estaussisimpleàprendreenmainetpuissant.Sonlogoestprésentédanslafiguresuivante.
-Twig estunmoteurdetemplatephpdanslamêmelignéequesmartyetdirectementintégré
Figure 3.6–Logo"Doctrine"
dansSymfony4.Trèspuissant,twigpermettradegérerdel’héritageentretemplates,séparer
lescouchesdeprésentationetmétiers.Sonlogos’estaffichédanslafiguresuivante.
Figure 3.7–Logo"Twig"
•FrameworkAngular6/7[11]:Angular6/7estl’undesframeworkslespluspopulairespour
ledéveloppementd’applicationsWeb.Angular6estl’évolutiondeAngularJSquiestunlan-
gage de programmation base sur TypeScript. Son logo s’est affiché dans la figure suivante.
Figure 3.8–Logo"Angular"
37

CHAPITRE3. RÉALISATION
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éploiementphysiquedesinformationsgénéréesparlelogicielsurdescomposantsmatériels.
Notrediagrammededéploiementestconstituéde:
•PC médecin et patient : qui est formé d’un navigateur WEB qui sert d’outils de
communicationentrelesutilisateursdenotresystèmeetlerestedesnoeuds.lesutilisateurs
lancentleursdemandessousformedeHTTPrequestetenreçoiventdeHTTPresponse.
•Front-end:lacoucheprésentationquiregroupel’ensembledesformulairesetlesinterfaces
àcommuniqueraunavigateurparfluxHTTPsuiteàunedemandedel’utilisateur.
•Back-end:leprogrammed’écouteCampaignfournitdeuxinterfaces
-uneinterfaceentrelesclientsFront-endetlesprocessusserveuranalytiquesBack-end.
-uneinterfacequiestl’interfacejoindrenotreapplicationaveclabasededonnées.
•le serveur : qui comporte la base de données de notre système. L’application WEB
campaign (Front-end) et le programme d’écoute (Back-end) communiquent sur TCP/IP
pourtraiterlesdemandesetlestransactiondeprocessuscommeillustrelafiguresuivante.
Figure 3.9–«Diagrammedéploiementdusystème»
38

CHAPITRE3. RÉALISATION
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éveloppementWEB.Nousavonsutilisélemodèled’applicationclient-serveur,aveclacom-
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-
fony4entièrementévolutifetorientéobjet[10]avecl’architecturebaséesurlecontrôleurde
modèle-vue (MVC) le plus fiable et le plus efficace motif de conception [11]. Le framework
Symfony4étaitsupportéparlepaquetDoctrinepourgestiondelabasededonnéesetavec
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
Angular6/7.
39

CHAPITRE3. RÉALISATION
Figure 3.10–«Architecturedel’application»
Notreapplicationréaliséeprésentedesinterfacesattractives,lisiblesetfacilesàmanipuler.
Danscequisuit,onillustrelesprincipalesinterfacesdenotreapplication.
4 Interface de l’application
Aprèslesphasesd’étudepréalable,laconceptionetlamodélisationfonctionnelleetorga-
nisationnelle,onadéveloppélesinterfacesdenotreapplicationenmentionnantdesimprimé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-
tiondupatient.
40

CHAPITRE3. RÉALISATION
Figure 3.11–«interfaceloginmédecin»
4.2 Les interfaces d’utilisateur en tant que médecin
4.2.1 Interface Authentification
Lafigure3.13présentel’interfaceloginquipermetauxmédecinsdes’identifieràl’aidede
leuradresseemailetleurmotdepasse.Silemédecinestconnecté,lapageduRendez-vousdu
jourestaffichée.Sileidentifiantetlemotdepassesontfauxunmessaged’erreurseraaffiché.
Figure 3.12–«interfaceloginmédecin»
41

CHAPITRE3. 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
consultationestcommencé,lemédecinpeutaccéderàl’interfacedenouvelleconsultation.
Figure 3.13–«interfacerendez-vousdujour»
4.2.3 Interface nouvelle consultation
Laconsultationestuneétapepostérieurequiseprovoquesuiteàlaprisederendez-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
historiquesnousdonneuneidéesurl’étatdepatient.
Figure 3.14–«interfacenouvelleconsultation»
42

CHAPITRE3. 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.15–«interfaceimprimerl’ordonnance»
4.2.5 Interface modifier le profil
Àtraverslafigure3.17,lemédecinpeutmodifiersonprofil.
Figure 3.16–«interfacemodifierleprofil»
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

CHAPITRE3. RÉALISATION
déclenche pour appliquer les modifications du disponibilité au temps choisi.La figure 3.18
représentel’interfacedemodificationdedisponibilité.
Figure 3.17–«gérerdisponibilité»
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.Unefenêtredeconfirmations’affiche.Lafigure3.19représentel’interfaced’annulation
rendez-vous.unefoisquemédecincliquesur’OK’unmaildeformationestenvoyéaupatient
etlecréneaudevientindisponibleaucalendrier.
Figure 3.18–«annulerrendez-vous»
Lafigure3.20représentel’interfacederéceptiondemaildeconfirmation.
44

CHAPITRE3. RÉALISATION
Figure 3.19–«Notificationdeconfirmationderendez-vousparmail»
4.3 Les interfaces d’utilisateur en tant que administrateur
4.3.1 Interface Authentification
Lafigure3.21représentel’interfaced’authentificationadministrateur.Sil’administrateur
estconnecté,lalistedesmédecinsestaffichée.
Figure 3.20–«interfaceloginadministrateur»
4.3.2 Interface consulter la liste des médecins
Lafigure3.22présentel’interfacepourconsulterlalistedesmédecins.
45

CHAPITRE3. RÉALISATION
Figure 3.21–«listedesmédecins»
L’administrateurpeutgérerlesmédecinsàpartirdecetteinterface.Ilpeutconsulter,va-
lider,bloquer,modifierl’étatd’abonnementousupprimerlecompte.Lafigure3.23présente
l’interfacedeconsultercomptemédecin.
Figure 3.22–«interfacecomptedumédecin»
46

CHAPITRE3. RÉALISATION
Pour supprimer un médecin,l’administrateur clique sur l’icône de poubelle et automati-
quementunefenêtres’affichedisantsiacceptelasuppressiondemédecin.
Lafigure3.24présentelafenêtredesuppressiond’unmédecin.
Figure 3.23–«supprimerunmédecin»
Via la figure 3.25 l’administrateur peut bloquer un médecin déjà validé, par un clic sur le
bouton"médecinvalide"viceversapeutvaliderparunclicsurlebouton"médecinen-cours",
aussipeutmodifierl’étatd’abonnementsélect’suspendu’ou’en-cours’.
Figure 3.24–«interfacebloquervaliderunmédecinetmodifierl’étatd’abonnement»
4.4 Les interfaces d’utilisateur en tant que patient
4.4.1 Interface Authentification
Lafigure3.26représentel’interfaced’authentificationPatient.Silepatientestconnecté,
lapagededossiermédicalestaffichée.
47

CHAPITRE3. RÉALISATION
Figure 3.25–«interfaceloginpatient»
4.4.2 Interface de dossier médical
À travers cette interface, le patient peut prendre une idée sur votre santé à partir de la
listedesconsultations.
Figure 3.26–«interfacededossiermédical»
48

CHAPITRE3. RÉALISATION
4.4.3 Interface pour modifier le profil
Danscetteinterface,lepatientaledroitdemodifiersonprofil.
Figure 3.27–«interfacemodifierleprofil»
4.4.4 Interface «prendre un RDV»
Àtraverscetteinterface,lepatientpeutfaireunerecherchesurlemédecinavecsonnom
ou sa spécialité après peut accéder à Une interface calendrier de médecin choisi. La figure
3.29représentelalistedesmédecins.
Figure 3.28–«interfacelistemédecin»
Àtraverscetteinterface,lepatientpeutconsulterlescréneauxdisponiblesetlesrendez-
vous de médecin.Si la possibilité en cliquant simplement sur un créneau libre, Une fenêtre
49

CHAPITRE3. RÉALISATION
pop-upsedéclenchepourajouterunnouveaurendez-vous.Lafigure3.30représentel’agenda
demédecinchoisi.
Figure 3.29–«interfacecalendriermédecinchoisi»
Lafigure3.31représentelafenêtred’ajoutunrendez-vous.
Figure 3.30–«interfaceajouterunRDV»
50

CHAPITRE3. 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
listecommemontrelafigure3.32.
Figure 3.31–«interfaceajouterunRDV»
À travers cette interface le patient peut annuler un RDV choisi en cliquant simplement
surslidetoggleunefenêtrepop-updéclenchepourconfirmerl’annulationetlibérerlecréneau
enagendademédecinetaussiunmaildeformationestenvoyéaumé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
simpleclicsurl’icôneetautomatiquementunefenêtres’affiche.
51

Figure 3.32–«interfacelistedesmédicaments»
La figure 3.34 représente formulaire d’ajout une notification.Si le patient clique sur ’en-
registrer’unmailseraenvoyépendantunepériodeprécise.
Figure 3.33–«interfaceajoutnotification»
5 Conclusion
Danscechapitre,nousavonsannoncélesdifférentestechnologieslogiciellesutiliséesdans
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’aidedesaperçusd’écranavecdescriptiondechacun.
52