REPUBLIQUE DU CAMEROUN FACULTE DES SCIENCES

REPUBLIC OF CAMEROON FACULTY OF SCIENCE

Peace-Work-Fatherland
******** Département de Mathématiques et
UNIVERSITE DE DSCHANG Informatique
UNIVERSITY OF DSCHANG Department of mathematics and Computer
Scholae Thesaurus DschangensisIbiCordum
Science
BP 96, Dschang (Cameroun) BP 96, DSchang (Cameroun)
Tél. /Fax (237) 233 45 13 81 Tél. /Fax (237) 233 45 13 81
Website : http://www.univ-dschang.org. Website : http://fs.univ-dschang.org.
E-mail : udsrectorat@univ-dschang.org E-mail : dept.math-info@univ-dschang.org

PROJET DE GENIE LOGICIEL : ANALYSE ET

IMPLEMWNTATION D’UNE PLATEFORME EN
LIGNE DE GESTION D’UN DOSSIER PATIENT

Année académique
2020/2021
Table des matières

CHAPITRE I: CADRE GENERAL ET CADRE SPECIFIQUE DU PROJET ...................................... 4

INTRODUCTION GENERALE ET CADRE DU PROJET .............................................................. 5
I. CAHIER DE CHARGE DU PROJET ........................................................................................ 6
II. PRESENTATION DU MODELE DE CYCLE DE VIE IMPLEMENTEE ................................................... 7
III. METHODOLOGIE DU PROJET ................................................................................................... 7
IV. LES METHODOLOGIES EXISTATNTES ....................................................................................... 7
Figure 1: Les contraintes 3C ............................................................................................................ 7
V. Les méthodes classiques ......................................................................................................... 8
1. Les méthodes agiles ................................................................................................................ 9
VI. Comparaison entre les deux méthodes de travail ............................................................ 11
VII. CHOIX DE LA METHODOLOGIE .............................................................................................. 12
CONCLUSION ..................................................................................................................................... 14
I. ETUDE PRELIMINAIRE ................................................................................................................ 16
1. Dictionnaire de données ...................................................................................................... 16
II. CAPTURE DES BESIONS .............................................................................................................. 17
1. Capture des besoins fonctionnels ......................................................................................... 17
2. Capture des besoins non fonctionnels .................................................................................. 17
III. IDENTIFICATION DES ACTEURS ET SPECIFICATION DES BESIONS.......................................... 20
1. Identification des acteurs ...................................................................................................... 20
2. Spécification des besoins fonctionnels : diagramme de cas d’utilisation ............................. 21
Raffinage du diagramme de cas d’utilisation modifier le dossier patient..................................... 22
CONCLUSION ..................................................................................................................................... 26
............................................................................................................................................................... 28
CHAPITRE III. ANALYSE ET ORGANISATION ........................................................................................... 28
DES DONNEES ........................................................................................................................................ 28
INTRODUCTION ................................................................................................................................. 29
I. Vue Statique .............................................................................................................................. 29
1. Diagramme de classes fonctionnels ...................................................................................... 30
2. Diagramme de package fonctionnel...................................................................................... 31
II. Vue Dynamique ......................................................................................................................... 32
1. Diagramme d’activités ........................................................................................................... 32
2. Diagramme états transitions ................................................................................................. 34
3. Diagrammes de séquence ..................................................................................................... 35

1
 CONCLUSION ..................................................................................................................................... 37
CHAPITRE IV. CONCEPTION ................................................................................................................... 38
INTRODUCTION ................................................................................................................................. 39
I. Conception préliminaire ............................................................................................................ 39
Nom du logiciel .................................................................................................................................. 39
1. Présentation de la technologie utilisée pour le front-end ........................................................ 39
2. Logo ....................................................................................................................................... 39
3. Gabarit de mise en page........................................................................................................ 40
II. CONCEPTION DETAILLEE ........................................................................................................... 43
1. Diagramme de classes du cote serveur ................................................................................. 43
III. ARCHITECTURES DES PLATEFORMES UTILISEES .................................................................... 45
1. Architecture cote serveur...................................................................................................... 45
2. Architecture cote client ......................................................................................................... 46
CONCLUSION ..................................................................................................................................... 46
CHAPITRE V : REALISATION ET TEST ...................................................................................................... 47
INTRODUCTION ..................................................................................................................................... 48
I. DESCRIPTION DE L’ENVIRONNEMENT ........................................................................................... 48
 Conception ................................................................................................................................ 48
 Environnements de développement de back-end .................................................................... 48
 Environnement de développement Front-end ......................................................................... 49
 Environnement de dessin et maquettage ................................................................................. 49
 Gestion de projet ....................................................................................................................... 49
II. TESTS ......................................................................................................................................... 49
Affichage des patients à travers les services de l’API .................................................................... 49
Ajout dans la base de données grâce aux services de l’API .......................................................... 50
Interface de connexion pour le personnel médical....................................................................... 50
III. Fiche de présence et présentation des différents travaux

2
3
 CHAPITRE I: CADRE
GENERAL ET CADRE
SPECIFIQUE DU PROJET

4
 INTRODUCTION GENERALE ET CADRE DU PROJET

L’organisation hospitalière est caractérisée par une activité complexe. Elle est
aujourd’hui fortement interpellée par le développement informatisé du processus
de soins au patient mis à la disposition des médecins, des personnels soignants et
des services administratifs. Ces dernières années, les réformes hospitalières en
termes de gouvernance ont incité à la modernisation des systèmes d’information
dans le prolongement de l’e-santé. Grâce aux progrès de la médecine, le partage
des données médicales a été déployé dans la prise en charge des patients
permettant de contrôler les dépenses et d’évoluer vers une qualité de la santé
publique.
Aujourd’hui, afin d’accéder aux données médicales du patient et d’améliorer
la qualité des soins, le système d’information hospitalier encourage la
circulation du dossier patient entre tous les professionnels médicaux dans la
prise en charge du patient consultant ou hospitalisé. Si de nombreux chercheurs
et théoriciens étudient les phénomènes liés au système d’information hospitalier,
peu s’interrogent sur le dossier patient informatisé et son impact sur la qualité de
production de soins.
La qualité de production de soins nous amène à mettre en place une
Application ou une plateforme de Gestion du dossier patient informatisé
dans les hôpitaux publics camerounais et dont l’administration centrale sera
logée au Ministère de la santé publique.
A partir d’une étude exploratoire. Plus largement, elle appréhende les
interrogations à l’égard du système d’information hospitalier qui rythme la
production de soins, de la fin du séjour hospitalier ou du classement des
documents archivés. Deux approches sont envisagées pour atteindre notre
objectif. Les recherches sur le contenu s’attachent à se demander « de quoi il est
composé ». Les recherches sur le processus mettent en évidence le
comportement de « l’objet dans le temps », afin de saisir son évolution
(Grenier & Josserand, 2007). La mise en place du dossier patient informatisé
aura un impact sur l’organisation hospitalière qui ne produit pas les mêmes
effets dans tous les services médicaux. Cette « équivocité de la technologie »
(Weick, 1990) induit des différences dans l’accompagnement du patient selon
les médecins, les disciplines médicales. L’objectif de notre projet vise à mettre
œuvre un système de gestion du dossier patient informatisé et son rôle sera
d’amélioration de la qualité de soins ; de favoriser une prise en charge rapide

5
des patients dans les hôpitaux ; de réduire la durée des patients dans les hôpitaux
et même éviter la saturation des hôpitaux et la réduction des dépenses des
patients. A partir du comité de pilotage responsable de l’informatisation du
dossier patient dans quelques hôpitaux et services de santé du Cameroun, nous
présenterons les travaux effectues et La démarche adoptée dans le cadre
d’analyse et conception retenu et l’application obtenue à la fin du projet.

I. CAHIER DE CHARGE DU PROJET

Souhaitant, améliorer le suivi des patients dans nos hôpitaux, le secteur de la

santé désire être en possession de tous les antécédents d’un patient. C’est-à-dire
que le personnel médical devant un patient, voudrait savoir toutes les
informations relatives aux traitements, examens, constantes médicales
personnelles (Poids, groupe sanguin, Rhésus…) qui sont liés au patient en
question.
De plus, l’on voudrait savoir dans quel établissement de santé chaque soins et/ou
traitements ont été administrés et par quel personnel médical ; ainsi, la
modification dans le «carnet électronique du patient » ne peut être fait que par
le personnel assurant les soins dudit patient. Ceci, sachant que ledit personnel
soit ajouté par le secteur médical, dispose d’un compte à partir duquel il pourra
modifier le dossier des patients, et bien-sûr est rattaché à un établissement de
santé. Les médecins et infirmières établissent la consultation, des soins, des
diagnostiques. En plus des opérations citées, le médecin établit des prescriptions
(de médicaments ou alors d’examens) ; les résultats des examens sont donnés
par les techniciens médicaux.
Le personnel soignant ayant pris en charge le patient, pourrait ainsi être contacté
par le personnel médical étant en train de prendre soin du patient dans l’optique
d’avoir des renseignements pouvant contribuer à la guérison du patient.
Le patient, lui-même disposera de son carnet électronique accessible en lecture
seule à partir de son compte sur la plateforme (en ligne), garantissant ainsi la
confidentialité de son carnet. Il est à noter que ce dernier doit être accessible
également pour le personnel médical.
Par ailleurs, dans le cas des urgences ou inconscience où le patient ne sera pas
capable de communiquer ses identifiants dans le système, le personnel médical
devra lui créer un compte dans lequel seront notés tous les soins administrés.
Une fois le patient en état lucide, s’il disposait déjà d’un compte, le nouveau
crée devra être jumelé à l’ancien (et par la suite supprimé) et conservé si non.

6
En outre, il est aussi nécessaire de préciser que, lors des troubles de connexion
pendant la modification du dossier patient ou alors lors de sa création, le
système devra réaliser l’opération et la synchronisera directement lorsque l’on
sera dans des conditions de connexion stables.

II. PRESENTATION DU MODELE DE CYCLE DE VIE IMPLEMENTEE

Le développement d’une application logiciel, comme toute autre tâche de

conception requière une analyse et une circonscription des besoins et des outils a
utilisés par l’application. Pour notre système, avant de commencer la phase de
d’implémentation par le codage, il nous faut tout d’abord une organisation des
idées, les documenter, puis organiser la réalisation en définissant les modules et
les étapes de la réalisation. Cette démarche antérieure à l’écriture que l’on
appelle modélisation ; son produit et un module. Ici la modélisation consistera à
créer une représentation virtuelle d’une réalité de telle façon à faire ressortir les
points auxquels nous nous intéresserons pour faire fonctionner notre application.
Dans le cadre de notre projet nous utiliserons la méthodologie UML pour la
modélisation de nos différents diagrammes.

III. METHODOLOGIE DU PROJET

Tout développement de logiciel nécessite de reposer sur une méthode. Il existe différentes
méthodes de développement mais aussi divers types de cycles de développement entrant dans
la réalisation d'un logiciel. Ces cycles prendront en compte toutes les étapes de la conception
d’un logiciel.

IV. LES METHODOLOGIES EXISTATNTES

L’objectif du chef de projet est de pouvoir mener son projet à terme en respectant les délais
et le budget alloué. Pour atteindre cet objectif, il doit prendre en compte les 3C (voir Figure 4
ci-dessous) qui sont les trois contraintes que constitue le projet.

Figure 1: Les contraintes 3C

7
Pour atteindre son objectif, le chef de projet peut avoir recours à plusieurs méthodes de
gestion de projet. Il existe deux grandes familles de méthode de développement ; nous citons
les méthodes classiques ou traditionnelles et les méthodes agiles.

V. Les méthodes classiques

Une méthode classique est une méthode de développement figée. Le client expose sa
problématique au début et le développeur s’en charge entièrement de lui livrer à la fin de la
période programmée au projet la solution complète. Aucun retour vers client ne se fait tout au
long de la période du développement de la solution.
Les cycles classiques de développement d'applications sont : les modèles en cascade, les
modèles en V, le prototypage et les modèles en spirale.

Figure 2:Cycle de vie des méthodes classiques

Dans un cycle « en cascade » (comme indiqué dans la Figure 5 ci-dessus) les risques sont
détectés tardivement puisqu’il faut attendre la fin du développement pour effectuer la phase
de test. Plus le projet avance, plus l’impact des risques augmente : il sera toujours plus
difficile et coûteux de revenir en arrière lorsqu’on découvre une anomalie tardivement.

8
 1. Les méthodes agiles

Les méthodes de développement dites « méthodes agiles » (en anglais Agile Modeling, noté
AG) visent à réduire le cycle de vie du logiciel en développant une version minimale, puis en
intégrant les fonctionnalités par un processus itératif basé sur une écoute client et des tests
tout au long du cycle de développement.
Les méthodes agiles prônent quatre valeurs fondamentales (entre parenthèse, les citations du
manifeste) :
L'équipe (« Personnes et interaction plutôt que processus et outils »).
L'application (« Logiciel fonctionnel plutôt que documentation complète »)
La collaboration (« Collaboration avec le client plutôt que négociation de contrat »)
L'acceptation du changement (« Réagir au changement plutôt que suivre un plan »).
Parmi les méthodes agiles, nous distinguons 2TUP, RUP4 et XP5.

a. La méthode 2TUP

 Définition : préconise un cycle de vie en Y qui dissocie la résolution des questions

fonctionnelles et techniques. Le cycle de vie de 2TUP s'apparente à un cycle de
développement en cascade mais introduit une forme itérative interne à certaines
tâches.

Figure 3: Cycle de vie en Y

9
  Avantages : cette méthode permet essentiellement la séparation entre les besoins
fonctionnels et techniques (voir Figure 3 ci-dessus).

b. La méthode RUP

 Définition : se caractérise par une approche globale nommée « Vue 4+1 ». Les 5
composants de cette vue sont : la vue des Cas d'utilisation, la vue Logique, la vue
d'Implémentation, la vue du Processus, la vue du Déploiement (voir Figure
7cidessous).

Figure 4: La vue 4+1 de RUP

 Avantages : RUP offre un processus guide formel et adaptable comme guide

d'activité.

c. La méthode XP
 Définition : est très axée sur la partie construction de l'application. Une de ses
originalités réside dans l’approche de planification qui se matérialise sous la forme
d’un jeu intitulé « Planning Game » et qui implique simultanément les utilisateurs et
les développeurs. La Figure 5 ci-dessous illustre le cycle de vie de la méthode XP.

Figure 5: Cycle de vie XP

10
  Avantages : On notera des techniques particulières liées à la production du code
comme la programmation en binôme, l'appropriation collective du code, la Ré
factorisation et l’Intégration continue.

VI. Comparaison entre les deux méthodes de travail

Ci-dessous un tableau récapitulatif des différences entre la méthode traditionnelle et la

méthode agile :
Thèmes Approche traditionnelle Approche agiles
En cascade ou en V, sans Itératif et incrémental
Cycle de vie rétroaction possible, phases
séquentielles.

Prédictive, caractérisée par des Adaptative avec plusieurs niveaux de

Planification plans plus ou moins détaillés sur la planification (macro- et micro
base d’un périmètre et d’exigences planification) avec ajustements si
définies et stables au début du nécessaires au fil de l’eau en fonction des
projet. changements survenus.

Produite en quantité importante Réduite au strict nécessaire au profit

Documentation comme support de communication, d’incréments fonctionnels opérationnels
de validation et de pour obtenir le feedback du client.
contractualisation.

Une équipe avec des ressources Une équipe responsabilisée où

Equipe spécialisées, dirigées par un chef l’interactive et la communication sont
de projet. privilégiées, soutenue par le chef de
projet.

Contrôle qualité à la fin du cycle Un contrôle qualité précoce et

Qualité de développement. Le client permanent,
découvre le produit fini au niveau du produit et du processus. Le
client visualise les résultats tôt et
fréquemment.

Résistance voire opposition au Accueil favorable au changement

Changement changement. inéluctable, intégré dans le processus.
Processus lourds de gestion des
changements acceptés.

Mesure de la conformité aux plans Un seul indicateur d’avancement : le

Suivie de initiaux. nombre de fonctionnalités
l’avancement Analyse des écarts. implémentées
et le travail restant à faire.

11
 Processus distinct, rigoureux, de Gestion des risques intégrée dans le
Gestion des risques gestion des risques. processus global, avec
responsabilisation
de chacun dans l’identification et la
résolution des risques.
Pilotage par les risques.

Mesure de Respect des engagements initiaux Satisfaction client par la livraison de

succès en termes de coût, de budget et de valeur ajoutée.
niveau de qualité

Figure 6: Comparaison entre méthodes classiques et méthodes agiles

Les méthodes agiles seront plus utilisées pour les gros projets car elles offrent une meilleure
adaptabilité, visibilité et gestion des risques. Elles pourraient tout aussi bien être utilisées
pour les projets où il n’y pas de documentations détaillées, le client peut alors voir
l’évolution du projet et l’adapter selon ses besoins.
En revanche, les méthodes classiques seront plus utilisées si nous avons une idée très
précise du projet avec un cahier des charges et planning très détaillé où nous avons anticipé
tous les risques possibles.
Le chef de projet se retrouve souvent seul face à lui-même lors de la prise de décision, de
gérer les retours client, devant l’incertitude afin de satisfaire le client tout en respectant les
3C. On pourrait alors l’assimiler à un art martial car il doit avoir une grande maitrise de soi et
de l’environnement de chaque projet auquel il est amené à gérer.

VII. CHOIX DE LA METHODOLOGIE

Devant le nombre de méthodes disponibles, le choix parmi elles devient difficile, beaucoup
de questions peuvent se poser à un chef de projet lors d’un démarrage de projet :
Comment vais-je organiser les équipes de développement ?
Quelles tâches attribuer à qui ?
Quel temps faudrait-il pour livrer le produit ?
Comment faire participer le client au développement afin de capter les besoins de
celui-ci ?
Comment éviter des dérives et de mauvaises estimations qui vont allonger les coûts et
le temps de développement ?
Comment vais-je procéder pour que le produit soit évolutif et facilement
maintenable ?
Nous pouvons citer à ce propos les méthodes de développement objet suivantes : 2TUP,
RUP, XP, AUP6 et Open UP.
C’est ainsi que notre choix s’est orientée vers la méthode agile en particulier la méthode
2TUP, du fait de son approche nouvelle et originale est essentiellement de la séparation entre
les besoins techniques et fonctionnels.

12
Notre projet est basé sur un processus de développement bien défini qui va de la
détermination des besoins fonctionnels attendus du système jusqu’à la conception et le
codage final. Ce processus se base lui-même sur le Processus Unifié (Unified Process) qui est
devenu un standard général réunissant les meilleures pratiques de développement.
Cette méthode ne se base aucunement sur un processus linéaire mais bien, sur un
développement itératif et incrémental.
Nous allons d’abord définir les différents concepts et étapes constituant la méthode 2TUP
1. Définition de 2TUP
2TUP (Two Track Unified Process) implémente le processus unifié, méthode de
développement qui considère le cycle de vie d'un logiciel sous-forme incrémentale et
itérative afin de s'adapter aux changements continuels dans l'organisation du système
d'information à représenter. En ce sens, il renforce le contrôle sur les capacités d’évolution et
de correction de tels systèmes.
2. Description de la méthode 2TUP
La méthode 2TUP sépare initialement les aspects techniques des aspects fonctionnels avant
de les regrouper dans la phase de réalisation. La figure ci-dessous (Figure 9) détaille les
différentes phases du développement.

Figure 7: Processus de développement en Y

La branche de gauche (branche fonctionnelle) contient deux phases :

 Capture des besoins fonctionnels, qui produit le modèle des besoins focalisés sur le
métier des utilisateurs. Elle qualifie, au plus tôt le risque de produire un système
inadapté aux utilisateurs
 L’analyse, qui consiste à étudier précisément la spécification fonctionnelle de
manière à obtenir une idée de ce que va réaliser le système en terme de métier.
La branche de droite (branche technique) intègre deux phases :

13
  La capture des besoins techniques, qui recense toutes les contraintes sur les choix
de dimensionnant et la conception du système. Il s’agit de la spécification des outils
(logiciels), de la structure des matériels à exploiter ainsi que la prise en compte des
contraintes d’intégration avec l’existant (pré requis d’architecture technique).
 La conception générique, qui définit ensuite les composants nécessaires à la
construction de l’architecture technique. Cette conception est complètement
indépendante des aspects fonctionnels spécifiés dans la branche gauche. Elle a pour
objectif de d’uniformiser et de réutiliser les mêmes mécanismes pour tout un système.
L’architecture technique construit le squelette du système, son importance est telle
qu’il est conseillé de réaliser un prototype de manière à valider les principes par le
codage et les tests.
La branche du milieu se compose de quatre phases :
 La conception préliminaire, qui consiste à appliquer les concepts liés aux
fonctionnalités du système et à intégrer les composants techniques au système. Il
s’agit d’intégrer les fonctions métiers et applicatives dans l’architecture technique
définie dans la phase de conception générique.
 La conception détaillée, qui étudie ensuite comment réaliser chaque composant.
 L’étape de codage, qui produit ses composants et tests au fur et à mesure les
unités de code réalisées.
 L’étape de recette, qui consiste enfin à valider les fonctionnalités du système
développé.

Writing of presentation

CONCLUSION
Ayant présenté le secteur médical camerounais et les désirs de ce dernier, les méthodes de projets
où nous avons choisi le 2TUP, il est nécessaire afin de modéliser et concevoir une plateforme
connectée pour la gestion d’un dossier patient, d’établir un ensemble opérations
hiérarchiques suivant ce processus unifié.

14
 CHAPITRE II: ETUDE
PRELIMINAIRE ET CAPTURE
DES BESIONS

15
 I. ETUDE PRELIMINAIRE
1. Dictionnaire de données

Par sa définition, le dictionnaire de données est une collection de métadonnées ou de

données de référence nécessaire à la conception d'une base de données relationnelle. Notre
dictionnaire de données est obtenu après une analyse profonde de nos échanges avec les personnels
de santé, les patients et les personnels administratifs.

N° CODE DESIGNATION NATURE CONTRAINTES

01 idConsultation Identifiant de la fiche de Numérique UNIQUE, NOT
consultation NULL

02 idDiagnostic Identifiant du Numériques UNIQUE, NOT

diagnostique NULL

03 idPrescription Identifiant d’une Numérique UNIQUE, NOT

prescription NULL
04 prescriptionType Type de prescription Alphabétique NOT NULL
(conseil, médicament)
05 PrescriptionLibel Contenu de la prescription Alphanumérique NOT NULL
06 drugLibel Identifiant d’un Alphanumérique UNIQUE NOT
médicament NULL
07 IdExam Libellé d’un médicament Alphanumérique UNIQUE NOT
NULL
08 examName Identifiant d’un examen Numérique UNIQUE, NOT
NULL
09 idIll Identifiant d’une maladie Numérique UNIQUE, NOT
NULL
10 illName Nom de la maladie Alphanumérique NOT NULL
11 firstName Prénom d’une personne Alphabétique

12 givenName Nom d’une personne Alphabétique NOT NULL

13 Sex Sexe d’une personne Alphabétique NOT NULL

14 Age Age d’une personne Numérique NOT NULL

15 fatherName Nom du père Alphabétique

16 motherName Nom de la mère Alphabétique

17 Adresse Adresse Alphanumérique UNIQUE, NOT

NULL
18 Temperature Température du patient Numérique NOT NULL
Texte
19 Weight Poids du patient Numérique NOT NULL

16
 20 boodGroup Groupe sanguin du patient Alphanumérique NOT NULL
21 Rhesus Rhesus du patient Alphanumérique NOT NULL

22 Electrophorèse Electrophorèse du patient Alphabétique NOT NULL

23 Tension Tension artérielle Numérique NOT NULL

24 medicalStaffType Type de personnel Alphabétique NOT NULL
médical

II. CAPTURE DES BESIONS

Après une étude du système présenté dans le cahier de charge ci-haut, cette
partie est réservée à la description des exigences fonctionnelles et non
fonctionnelles
1. Capture des besoins fonctionnels
Les besoins fonctionnels sont les différents services que le futur système devra
fournir aux futurs utilisateurs dudit système.
Ces besoins se regroupent comme suit:

• Création des comptes utilisateurs.

• Authentification des utilisateurs.
• Lister les informations et traitements relatives aux patients.
• Impression de dossiers patients.
• Modification du dossier patient.
• Fusion des dossiers patients.
• Gestion des comptes

2. Capture des besoins non fonctionnels

a. Besoin opérationnels

• Portabilité: la plateforme doit être disponible et tourner sur tout type de

système d’exploitation et médias.
• Robustesse : l’application doit pouvoir fonctionner même dans les
conditions anormales.

17
 • La sécurité au niveau de l’accès aux données : assurer la confidentialité
du dossier patient.
• La modification du dossier patient ne doit se faire que par le personnel
médical.
• Le système devra gérer un grand nombre de patients; de ce fait, un
grand volume de dossiers patient, hôpitaux et personnel médical.
• Le système doit pouvoir fonctionner en plein temps c’est-à-dire 24h/24
• Lors des trouble de connections, les données devront être enregistrées
chez le client et une foi la connexion rétablie, elles devront être
envoyées dans la base de donnée centrale.

b. Choix techniques

Dans ce contexte où les besoins techniques sont directement en quelques sortes des conséquences
des besoins opérationnels eux même désire des futurs utilisateurs du logiciel, nous présentons ci-
dessous les différents concepts entrant dans les attentes d’un point de vue technique ou
informatique.

i. API
« Application Programming interface » interface de programmation d’application est un
ensemble normalisé, hiérarchique et ordonné de classes, de méthodes, de fonctions et de constantes
qui sert de façade par laquelle un logiciel offre des service à un autre.

Notre système devant être portatif et assez distribué, il devra couvrir le maximum de médias : le web
(ce qui inclut tout type de medias pouvant y accéder), une application desktop pour la sédentarité du
personnel médical, et une application mobile dans le cadre de fournir un dossier patient numérique
disponible chez le patient et facilement utilisable.

Pour atteindre ces objectifs, aurons donc besoin de mettre sur pied une « API » pouvant fournir des
services à des clients web, mobiles et desktop. Mais dans le cadre de ce projet, nous limiterons à la
production du client web.

18
Figure 9: description des services d'une API Figure 8:Description du fonctionnement d'une API:

ii. Spring boot

Issue lui-même de Spring, Spring boot est un Framework permettant de mettre sur pied les
infrastructures d’une application java. Il est le plus souvent utilisé pour des développements en
entreprise comme toutes les autres technologies java car inclut un aspect sécurité dû au fait que java
est un langage compilé garantissant ainsi l’intégrité des données et le fonctionnement de
l’application.

En outre, le Framework pring boot offre des outils techniques permettant de définir les « API
RestFul ».

iii. Mariadb
C’est un gestionnaire de base de données sous licence GPL tournant sous tout système
garantissant une certaine portabilité. Elle permet de gérer une quantité importante de données
telles celles relative au stockage et à la gestion des dossiers patients.

Il est à noter que cette base de donnée pourrait migrer vers un plus volumineuse dans le cas où

Le système devra encore grossir en données.

19
 iv. La base de données Derby
Derby est une base de donnée embarqué dans spring boot, l’on la sollicitera dans le but de stocker
des données lors des trouble de connexions liés à la base de données centrale MariaDb ; données
qui, lorsque la connectivité avec la base de donnée centrale sera rétablie, devront y être stockées.

v. DAO
« Data Accessing Objet » objet d’accès aux données est patron utilisé dans l’architecture
logicielle objet.

III. IDENTIFICATION DES ACTEURS ET SPECIFICATION DES BESIONS

1. Identification des acteurs

Notre système est constitué de 03 principaux acteurs à savoir:

Tableau 1:Identifiaction des acteurs et leur Rôle

Acteurs Actions
Personnel soignant  Authentication
 Impression du document patient
 Consultation des dossiers patient
 Modification des dossiers patient
 Production des dossiers patient
 Fusionner les dossiers patient

20
 Patient  Authentication
 Impression du document patient
 Consultation des dossiers patient
Administrateur services  Ajout des hôpitaux et personnel
médical
 Muter le personnel médical
 Mise à jour des informations sur le
personnel médical et sur les
hôpitaux

2. Spécification des besoins fonctionnels : diagramme de cas d’utilisation

Figure 10: Diagramme de cas d’'utilisation

21
Raffinage du diagramme de cas d’utilisation modifier le dossier patient

Figure 11: Diagramme de cas d'utilisation modifier le dossier patient

a. Fiche descriptive des cas d’utilisation

Tableau 2: Consultation des dossiers patient

Sommaire
Titre Consultation des dossiers patient

But Permettre aux patients et aux personnels

soignant de consulter le dossier d’un patient
Résume Apres authentification cette fiche sera
accessible chez le personnel soignant, après
avoir entre les informations du patient et
pareil chez le patient qui souhaite consulter
son carnet médical.
Acteurs Patient et personnel soignant
Précondition S’authentifier
Post condition
Scenarios nominaux
1. S’authentifier
2. Recherche du patient (exclusivement pour le personnel médical)
3. Recherche des soins
4. Consulter le dossier patient
Scenarios d’erreur
1.a) si l’utilisateur saisir des données d’authentification erronées :

22
 o Le système affiche un message d’erreur
o Retour à l’étape du scenario nominal pour s’authentifier

Tableau 3: Description des cas d’utilisation « impression des dossiers patient »

Sommaire
Titre Impression des dossiers patients

But Permettre aux patients et aux personnels

soignant d’imprimer les dossiers patients
Résume Apres authentiquassions et après sélection du
dossier patient cette fiche pourra être
imprimé par le personnel soignant, pareil chez
le patient qui souhaite imprimer son carnet
médical.
Acteurs Patient et personnel soignant
Précondition S’authentifier
Post condition
Scenarios nominaux
5. S’authentifier
6. Consulter le dossier patient
7. Sélection des articles à imprimer
8. Imprimer le dossier
Scenarios alternatifs

Tableau 4: Description des cas d’utilisation « modification du dossier patient »

Sommaire
Titre modification du dossier patient

But Permettre au personnel soignant d’ajouter de

nouvelles données dans les dossiers patients
Résume Apres authentication et après sélection du
dossier patient cette fiche pourra subir une
modification avec l’ajout des nouvelles
donnes par le personnel soignant.
Acteurs personnel soignant
Précondition S’authentifier et recherche du dossier patient
Post condition
Scenarios nominaux
9. S’authentifier
10. Recherche du dossier patient
11. Consulter le dossier patient
12. Enregistrer les données du formulaire
13. Valider l’enregistrement

23
 Scenarios alternatifs
11.b) si l’utilisateur saisir les informations erronées du patient :
o Le système affiche un message d’erreur
o Retour à l’étape du scenario nominal pour la recherche du
dossier patient.

Tableau 5: Description des cas d’utilisation « production du dossier patient »

Sommaire
Titre création du dossier patient

But Permettre au personnel soignant de produit le

dossier patient si n’existe pas dans le système.
Résume Apres authentication et sélection du dossier
patient si cette fiche n’existe pas le personnel
soignant pourra la créer.

Acteurs personnel soignant

Précondition S’authentifier et cherche du dossier patient
Post condition
Scenarios nominaux
14. S’authentifier
15. Recherche du dossier patient
16. Création du dossier patient
17. Enregistrer les données du formulaire
18. Valider la création du dossier
Scenarios d’erreurs
14.a) si l’utilisateur saisir des données d’authentification erronées :
o Le système affiche un message d’erreur
o Retour à l’étape du scenario nominal pour s’authentifier.
16 .a Si les informations entrées correspondent à ceux d’un autre
patient :
o Le système renvoie un message d’erreur

Scenarios alternatifs
15. a non recherche du dossier patient s’il n’existe pas et passage à 16

3. Digrammes de classes candidates fonctionnelles

Après ce qui précède, il est important de définir à priori les différentes classes pouvant intervenir
dans le système.

24
 Figure 12: Diagramme de classes candidates

4. Spécification des besoins techniques

a. Diagrammes de cas d’utilisation technique

Figure 13: Diagramme de classes techniques

b. Spécification des composants et architecture

Le système à concevoir devant être en ligne, il sera nécessaire de disposer d’une plateforme
d’hébergement. Par ailleurs, pour plus de connectivité et disponibilité du système, nous mettrons sur

25
pied un API, qui pourra fournir ses services aux applications web, desktop et mobiles; mais dans ce
projet, nous nous limiterons à la version web.

Figure 14: Component diagram: Architecture

CONCLUSION

Les cadres général et spécifiques du projet et le cahier de charge ainsi présentés, à partir des besoins
fonctionnels et opérationnels, nous avons comme attente de réaliser une application web fournir par
une API Restful grâce à spring boot et en utilisant le SGBD MariaDb. Ceci fait, nous devons analyser
toutes les données récupérées .Cette dernière opération fera l’objet du prochain chapitre intitulé
analyse et organisation des données.

26
27
CHAPITRE III. ANALYSE ET
ORGANISATION
DES DONNEES

28
 INTRODUCTION

Après une spécification détaillée des besoins fonctionnels et techniques de

l’application, ce présent chapitre sera consacré entièrement à la phase d’analyse
de la méthode 2 TUP.
Toute phase d’analyse est composée d’une vue statique illustrée par les
diagrammes de classe participantes et une vue dynamique présentée par des
diagrammes de séquences, diagrammes d’activités et diagrammes d’état
transition.
I. Vue Statique

Dans cette section, nous avons identifié les classes d'analyse qui vont participer
à la
réalisation des cas d'utilisation.
Il y a trois types de classes : « entité », « contrôle », « services » et « accès
données ».
Ces classes seront représentées dans les diagrammes de classes participantes.
Les classes « entité » vont seulement posséder des attributs. Ceux-ci
représentent généralement les informations persistantes de l'application et
des champs de saisie. Elles constituent en outre les différentes classes
tuple.
Les classes « contrôle » vont seulement posséder des opérations. Ceux-ci
correspondent à la logique de l'application, au travail de règles.
Les classes « services » vont posséder elles aussi des opérations
correspondantes aux services fournis aux différents contrôles de
l’application.
Nous représenterons et détaillerons certains d'entre eux dans la section
suivante.

29
 1. Diagramme de classes fonctionnels
Le diagramme de classes fonctionnelles définies l’ensemble des relations entre les différentes classes
entités. Il est donc défini comme suit :

Figure 15: Diagramme de classes fonctionnelles

2. Diagramme de classes de contrôle

Celui-ci s’insère dans la catégorie technique car assure de contrôle de différentes données de l’API
sous le modèle MVC.

30
 3. Diagramme de package fonctionnel
Ce diagramme permet de ressembler des classes à fortes cohérence ensemble en occurrence les
classes « medicalStaff », « Patient » qui s’insère dans le package « acteurs » ; et par ailleurs les
classes relative au dossier patient « MedicalNoteBook », « Examen », « prescription », « Result »,
« InTakeInLoad » qui s’insèrent dans le package « InTakeInLoad ».

Figure 16: Diagramme dépendance entre les packages

31
Les différents packages constitués forment ainsi des services que produiront notre applications, il est
donc nécessaires de les mettre en communication dans l’optique d’obtenir le fonctionnement final
de notre logiciel.

II. Vue Dynamique

1. Diagramme d’activités
Les diagrammes d’activités permettent de d’illustrer de façon pragmatique, dynamique et
fonctionnels les cas d’utilisations dans le but comprendre le fonctionnement du système à mettre sur
pied. Nous n’illustrerons que ces cas complexes notamment la modification du dossier patient :
« Note book ».

32
Figure 17: Diagramme d'activités du cas d'utilisation modifier le dossier patient

33
 2. Diagramme états transitions
Les diagrammes état-transitions font percevoir le différent comportement des objets et ainsi
permettent d’appuyer la recherche des opérations à implémenter dans les classes associées.

Dans le cadre de notre projet, l’objet au comportement le plus complexe est le dossier patient :
« NoteBook » ; ce dernier n’étant qu’une composition des prises en charge : « InTakeInLoad », elles
même compositions de consultations, examens, prescriptions, résultats d’examen et potentiellement
d’allergie des patients, il est nécessaire de tout d’abord décrire de comportement des objets les plus
internes.

a. Diagramme d’état transition d’un examen

Figure 18: diagramme état transition d'un Examen

34
 b. Diagramme de état transition du dossier patient

3. Diagrammes de séquence
Dans un système, les diagrammes de séquence sont nécessaire dans de but de recueillir les différents
messages échangé entre un acteur, ce en fonction du temps.

35
Diagramme de séquence de la modification du dossier patient

36
Consultation du dossier patient

ONCLUSION
Dans ce chapitre, nous avons décrit l'étape d’analyse de la méthode 2TUP de point de vue
statique avec la présentation de quelques diagrammes de classes et de point de
vue dynamique en précisant certains diagrammes de séquence, d’activités, et d’état transition
le plus souvent relatif au dossier patient constituant la gestion dynamique de notre système.
Le chapitre suivant présentera l'étape de la conception.

37
CHAPITRE IV. CONCEPTION

38
 INTRODUCTION

Après la phase d’analyse, nous allons entamer, dans ce chapitre la conception du projet. En
utilisant la méthode 2TUP, dans un premier temps, nous commenceront par une conception
préliminaire présentant le logo et la conception de l’application web et des interfaces
associées par la suite, nous passeront à une conception détaillée du projet en tenant compte
des contraintes fonctionnelles et technologiques rencontrées.

I. Conception préliminaire
Cette partie est consacrée pour la présentation de la charte graphique de notre application qui
est un document de travail qui contient l’ensemble des règles d’utilisation des signes
graphiques qui constitue l’identité graphique pour pouvoir les décliner sur différents support
d’une même identité.

Nom du logiciel
Nous avons choisi « E-Medical note book » pour electronic medical note book pour la traduction
française « Carnet médicale électronique »

Par ailleurs, le slogan adopté est « Save your health » de traduction française préserver notre santé
car le but de ce logiciel est de permettre l’amélioration des services de prise en charge des patients.

1. Présentation de la technologie utilisée pour le front-end

Désirant dans ce projet de produire une application web, nous devons utiliser une technologie
permettant de requêter l’API à mettre sur pied.

La technologie front-end que l’on utilisera dans le cadre de ce projet sera le Framework React Js.

Figure 19: technologie front-end :React JS

React Js est un Framework JavaScript permettant de fournir des interfaces pour application web.
Nous l’utiliserons cette technologie particulièrement pour la facilité de définition des composants,
l’aisance dans les requêtes des « API Rest Full » et la grande communauté dont il dispose.

2. Logo
Le logotype de notre solution, représenté dans la Figure ci-dessous, est à l’origine de
relation de lettrage « Elctronic Medical notebook », et un médicament symbolisant la guérison

39
car le but notre de notre logiciel est de fournir un dossier patient numérique comportant tous
les antécédents médicaux du patient, permettant une meilleure gestion des soins en vue de son
rétablissement.
Par ailleurs, le symbole de connexion réseau symbolise que le document est numérique et
accessible partout où que nous soyons.

Figure 20: Logo de l'application

3. Gabarit de mise en page

C’est la dernière étape avant la réalisation graphique, qui se présent par une version papier du
produit final où nous avons schématisé le produit écran par écran.
a. Formulaire de connexion pour l’administrateur

Figure 21: formulaire de connexion d'un administrateur

40
 b. Formulaire de connexion du personnel médical

Figure 22: formulaire de connexion du personnel médical

c. Formulaire de connexion d’un patient

Figure 23: Formulaire de connexion d'un patient

41
 d. Page Présentant un dossier patient et l’ensemble de des prise en charge

Figure 24: Affichage des prises en charge

Les bandes bleues présentent les différentes prises en charge et le bouton « more » situé à
juste en bas permet d’afficher les informations relatives aux prises en charge (examens,
consultation…etc.).
Dans le sidecar, une fois le critère de recherche spécifieé (recherche par hôpitaux, par date,
par médecin, par examen, par médicament pris…etc.).
La pagination des prise en charge peut être sélectionnée avec au bas de la page
Le bouton « Plus » permet au personnel médical d’ajouter des informations dans le dossier
patient (ce bouton ne sera pas présent dans l’interface fourni au patient car celui-ci ne peut
lui-même insérer des informations médicales dans son dossier.

42
 e. Affichage détaillée des prise en charge dans un dossier patient

Figure 25: Affichage d'une prise en charge

Dans cette interface, s’ajoute le bouton d’impression dans la «Sidebar » imprimant tous les prises en
charges déroulée dans la page.

II. CONCEPTION DETAILLEE

Dans cette partie, nous allons présenter de façon détaille les différentes classes, des méthodes et
des attributs. Nous insisterons sur les diagrammes de la cote serveur.

1. Diagramme de classes du cote serveur

Notre système se base sur le design pattern « MVC » pour model view controller. Notre système
étant implémenté sur le système d’API, alors, les parties Modeles et controlleurs sont gérées dans
l’API et la partir front-end à l’aide de React Js.

43
 a. Diagramme de classes des couches controlleur et acces donnees lies aux patients

Figure 26:diagramme de classes lie au patient de la cote serveur

44
 b. Diagramme de classes des couches contrôleur et accès données lies aux Prises en
charges(InTakeInLoad).

Figure 27 Diagramme de classes de gestion de la prise en charge de la cote serveur

Ces diagrammes seront pareillement structures pour les autres entités et constituent des packages
pour chaque entité.

Spécifications du cote client

Les interfaces sont organisées sur le principe de composants : chaque identité visuelle est en fait un
composant react en occurrence la sidebar, les prises en charge…etc.

III. ARCHITECTURES DES PLATEFORMES UTILISEES

La technologie Objet requiert une architecture. C'est cette architecture qui organise les interactions
entre objets. Nous avons l'habitude de regrouper ces objets en classes, ces classes en domaines, et
ces domaines en couches. Les couches permettent de présenter l'architecture de l'application. Les
équipes de réalisation s'attribuent alors des responsabilités sur le développement de chaque couche.
Aussi, si modéliser est indispensable, construire une architecture à couche est un critère de qualité
dans le cadre d'un développement Objet. Reste à choisir le nombre de couches et à définir leur
contenu.

1. Architecture cote serveur

La plateforme Spring boot est basée sur un modèle en couches. Chaque couche communique avec sa
couche inférieure et sa couche supérieure. Le langage JAVA étant totalement portable, le

45
développement du système ne dépendra absolument pas de la machine sur laquelle il fonctionnera.
La Figure ci-dessous représente les couches de l’architecture Java

Figure 28: Architecture java

Notre architecture de la cote back-end ne prend pas en compte la couche présentation car nous
implémentons le principe d’API Rest Full.

2. Architecture cote client

L’architecture d’une page web avec react est la suivante

Navigateur
Chrome, Edge, Firefox, Opéra

Framework
React Js

CONCLUSION

Dans ce chapitre, nous avons présenté l’étape de la conception soit le diagramme de classe descriptif
du projet. Le chapitre qui suit sera consacré spécialement à la phase de réalisation et aux différents
tests qui ont été faits tout au long de ce projet

46
CHAPITRE V : REALISATION ET
TEST

47
 INTRODUCTION

Après avoir finalisé l’étape de conception, nous passons dans ce chapitre à l’implémentation de notre
application. Nous commençons par la définition de notre environnement de développement. Par la
suite, nous enchainons par la présentation et la description détaillée des différentes étapes de la
solution finale.

I. DESCRIPTION DE L’ENVIRONNEMENT
Conception
Au niveau de la phase de conception, nous avons utilisé l’AGL Bouml pour la représentation des
éléments UML.

Figure 29: Log de Bouml

Environnements de développement de back-end

Pour la définition de l’API avec le Framework Spring boot, nous avons utilisé l’IDE Spring Tool
Suite 4, le test de l’API avec Postman, et comme SGBD MariaDb.

48
 Environnement de développement Front-end
Pour le développement du coté front-end nous utilisons l’éditeur Visual studio code

Environnement de dessin et maquettage

Pour la mise sur pied des différentes maquettes d’interfaces, nous avons utilisé le logiciel Edraw Max

Gestion de projet
Pour la gestion du code, nous utilisons le logiciel git et le dépôt gitLab.

A cet effet, les liens de nos dépôts gitLab sont :

 Lien du dépôt Front-end (hp-vision-front-end): https://gitlab.com/Darwin99/hp-vision.git

 Lien du dépôt back-end (hp-vision-back-end) : https://gitlab.com/Darwin99/hp-vision-front-
end.git

II. TESTS

Affichage des patients à travers les services de l’API

49
Ajout dans la base de données grâce aux services de l’API

Interface de connexion pour le personnel médical

50