ERP médical pour la TRANSTU : module de gestion pharmaceutiques

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR
ET DE LA RECHERCHE SCIENTIFIQUE
UNIVERSITE TUNIS EL MANAR
INSTITUT SUPERIEUR D’INFORMATIQUE
MEMOIRE DE MASTERE
Présenté en vue de l’obtention du
Diplôme National de Mastère Professionnel en Informatique
Mention : Mastère Professionnel en Logiciels Libres
Spécialité : Développement du Logiciel
Par
Mohamed Aziz CHETOUI
Réalisé au sein de Société des Transports de Tunis
Encadrant professionnel Monsieur Anas SAAID
Encadrant académique Madame Olfa MOURALI
Année Universitaire 2016/2017
ERP médical pour la TRANSTU : module de
gestion pharmaceutiques

Encadrant Entreprise
Encadrant ISI
Signature et cachet :
J’autorise l’étudiant à déposer son rapport de stage en vue d’une soutenance
Signature :
J’autorise l’étudiant à déposer son rapport de stage en vue d’une soutenance

Dédicace
Améliorer votre situation,
par vos propres efforts.
■ Mohamed Aziz Chetoui
Je dédie ce modeste travail à mes parents Belgacem & Zaara, aucun hommage ne pourrait
être à la hauteur de l’amour et l’encouragement dont ils ne cessent de me combler. Que dieu
leur procure bonne santé et longue vie.
À tous ceux que j’aime et qui m’ont soutenu tout au long de ce projet : mes frères et sœurs
Baha, Mohsen, Sourour et Imen. À ma belle-sœur Ines et mes beaux-frères Ahmed et Jad.
Sans oublier mes amis Foued et Yahia.
À toute ma famille.
À mon meilleur ami Ahmed pour les nuits blanches de travail passés à ma compagnie. À
Ghaith pour tous les sacrifices consentis pour me permettre d’atteindre cette étape de ma vie.
Et à tous ceux qui ont contribué de près ou de loin pour que ce travail soit possible.
Je vous dis Merci.

Remerciement
Je tiens à remercier très sincèrement les membres du jury qui mon font le grand honneur
d’accepter de me prêter leur attention et évaluer mon travail. Je serai très reconnaissant à mon
encadrante à l’ISI Madame Olfa MOURALI pour l’aide compétente qu’elle m’a apportée, pour
sa patience, sa disponibilité et son encouragement. Ses notes m’ont été très précieuses pour
structurer ce travail et pour améliorer la qualité des différentes sections.
Je remercie tous ceux qui nous ont accueilli bras ouverts au sein de la société «
TRANSTU » spécialement, mon encadrant Monsieur Anas SAAID pour sa confiance qui ma
aider à accomplir totalement mes tâches. Je remercie mes collègues au travail Rached et Anis
qui m'ont beaucoup soutenu dans ma période de stage. Leurs écoutes et leurs conseils m'ont
permis d’accomplir mon travail.
Mohamed Aziz Chetoui

i
Table des matières
Introduction générale.................................................................................................................. 1
Chapitre I : Analyse.................................................................................................................... 3
Introduction ............................................................................................................................ 3
I. Contexte du projet ........................................................................................................... 3
1. Présentation de l’organisme d’accueil......................................................................... 3
a. Organigramme de la société..................................................................................... 4
b. Description de la fonction médicale......................................................................... 4
2. Etude de l’existant ....................................................................................................... 6
a. Présentation générale des Enterprise Ressource Planning (ERP)............................ 6
b. Les ERP médicaux................................................................................................... 8
c. Comparatif des ERP médicaux ................................................................................ 9
3. Problématique............................................................................................................ 12
4. Solution proposée ...................................................................................................... 12
II. Méthodologie adoptée................................................................................................... 14
1. Présentation de l’UP .................................................................................................. 14
2. Processus de l’UP ...................................................................................................... 16
a. Le processus Rational Unified Process (RUP) ...................................................... 16
b. Le processus 2 Track Unified Process (2TUP)...................................................... 16
3. Choix de la méthodologie.......................................................................................... 18
4. Planification du projet ............................................................................................... 19
III. Spécification des besoins........................................................................................... 19
1. Identification des acteurs........................................................................................... 19
2. Besoins fonctionnels.................................................................................................. 20
3. Besoins non fonctionnels........................................................................................... 21
4. Diagramme des cas d’utilisations.............................................................................. 22
a. Diagramme des cas d’utilisations général.............................................................. 22
b. Raffinement des cas d’utilisations ......................................................................... 22
5. Prototypage des interfaces......................................................................................... 44
Conclusion............................................................................................................................ 44
Chapitre II : Conception........................................................................................................... 45
Introduction .......................................................................................................................... 45

Table des matières
ii
I. Diagrammes de séquences ............................................................................................ 45
1. Diagramme de séquence « S'authentifier »................................................................ 45
2. Diagramme de séquence « Ajouter une prescription ».............................................. 47
3. Diagramme de séquence « Ajouter une commande interne » ................................... 50
4. Diagramme de séquence « Livrer une livraison »..................................................... 53
5. Diagramme de séquence « Ajouter une commande externe »................................... 55
6. Diagramme de séquence « Réceptionner une livraison externe »............................. 57
7. Diagramme de séquence « Editer la fiche inventaire » ............................................. 59
8. Diagramme de séquence « Ajouter un produit »....................................................... 60
II. Diagrammes d’états....................................................................................................... 62
1. Diagramme d’états de l’objet « Prescription ».......................................................... 62
2. Diagramme d’états de l’objet « Commande Interne »............................................... 63
3. Diagramme d’états de l’objet « Livraison Interne ».................................................. 64
4. Diagramme d’états de l’objet « Commande Externe ».............................................. 64
5. Diagramme d’états de l’objet « Livraison Externe »................................................. 65
III. Diagrammes de classes.............................................................................................. 66
Conclusion............................................................................................................................ 69
Chapitre III : Réalisation.......................................................................................................... 70
Introduction .......................................................................................................................... 70
I. Environnement matériel ................................................................................................ 70
1. Architecture matérielle .............................................................................................. 70
2. Architecture applicative............................................................................................. 73
a. Architecture frontend - Angular............................................................................. 74
b. Architecture backend – Spring............................................................................... 76
II. Environnement logiciel ................................................................................................. 77
1. Outils de conception .................................................................................................. 77
2. Outils de développement ........................................................................................... 77
3. Outils de système de gestion de la base de données.................................................. 78
4. Outils de travail collaboratif...................................................................................... 78
5. Framework................................................................................................................. 79
6. Langages de programmation ..................................................................................... 79
III. Implémentation et code ............................................................................................. 80
Conclusion............................................................................................................................ 86
Conclusion générale ................................................................................................................. 87

Table des matières
iii
Annexe A : Raffinements des cas d’utilisations....................................................................... 88
Annexe B : Diagramme de séquence ..................................................................................... 102
Annexe C : Diagramme de GANTT ...................................................................................... 118

iv
Liste des tableaux
Tableau 1 : Raffinement du cas d'utilisation « Ajouter une prescription ».............................. 25
Tableau 2 : Raffinement du cas d'utilisation « Annuler une prescription »............................. 26
Tableau 3 : Raffinement du cas d'utilisation « Modifier une prescription »............................ 27
Tableau 4 : Raffinement du cas d'utilisation « Ajouter une commande interne » ................... 28
Tableau 5 : Raffinement du cas d'utilisation « Imprimer une commande interne »................. 29
Tableau 6 : Raffinement du cas d'utilisation « Valider une commande interne ».................... 30
Tableau 7 : Raffinement du cas d'utilisation « Ajouter une livraison interne »....................... 31
Tableau 8 : Raffinement du cas d'utilisation « Livrer une livraison » ..................................... 32
Tableau 9 : Raffinement du cas d'utilisation « Modifier une livraison »................................. 32
Tableau 10 : Raffinement du cas d'utilisation « Ajouter une commande externe »................. 34
Tableau 11 : Raffinement du cas d'utilisation « Réceptionner une commande externe »........ 34
Tableau 12 : Raffinement du cas d'utilisation « Modifier une commande externe »............... 35
Tableau 13 : Raffinement du cas d'utilisation « Réceptionner une livraison externe » ........... 37
Tableau 14 : Raffinement du cas d'utilisation « Modifier la fiche inventaire »....................... 38
Tableau 15 : Raffinement du cas d'utilisation « Consulter l'état en stock »............................. 40
Tableau 16 : Raffinement du cas d'utilisation « Activer un compte utilisateur » .................... 40
Tableau 17 : Raffinement du cas d'utilisation « Ajouter un produit » ..................................... 43
Tableau 18 : Raffinement du cas d'utilisation « Vérifier le login et le mot de passe »............ 88
Tableau 19 : Raffinement du cas d'utilisation « Afficher la liste des prescriptions ».............. 89
Tableau 20 : Raffinement du cas d'utilisation « Afficher les détails d'une prescription »....... 89
Tableau 21 : Raffinement du cas d'utilisation « Imprimer une prescription »......................... 90
Tableau 22 : Raffinement du cas d'utilisation « Afficher la liste des commandes internes ».. 90
Tableau 23 : Raffinement du cas d'utilisation « Afficher les détails d'une commande interne »
.................................................................................................................................................. 91
Tableau 24 : Raffinement du cas d'utilisation « Annuler une commande interne »................. 91
Tableau 25 : Raffinement du cas d'utilisation « Réceptionner une commande interne » ........ 91
Tableau 26 : Raffinement du cas d'utilisation « Modifier une commande interne » ............... 92
Tableau 27 : Raffinement du cas d'utilisation « Afficher la liste des livraisons internes » ..... 92
Tableau 28 : Raffinement du cas d'utilisation « Afficher les détails d'une livraison » ............ 93
Tableau 29 : Raffinement du cas d'utilisation « Valider une livraison » ................................. 93
Tableau 30 : Raffinement du cas d'utilisation « Imprimer une livraison » .............................. 93

Liste des tableaux
v
Tableau 31 : Raffinement du cas d'utilisation « Annuler une livraison » ................................ 94
Tableau 32 : Raffinement du cas d'utilisation « Afficher la liste des commandes externes » . 94
Tableau 33 : Raffinement du cas d'utilisation « Afficher les détails d'une commande externe »
.................................................................................................................................................. 95
Tableau 34 : Raffinement du cas d'utilisation « Imprimer une commande externe ».............. 95
Tableau 35 : Raffinement du cas d'utilisation « Valider une commande externe »................. 95
Tableau 36 : Raffinement du cas d'utilisation « Annuler une commande externe »................ 96
Tableau 37 : Raffinement du cas d'utilisation « Afficher la liste des livraisons externes »..... 96
Tableau 38 : Raffinement du cas d'utilisation « Afficher les détails d'une livraison externe »97
Tableau 39 : Raffinement du cas d'utilisation « Imprimer une livraison externe » ................. 97
Tableau 40 : Raffinement du cas d'utilisation « Editer la fiche inventaire » ........................... 97
Tableau 41 : Raffinement du cas d'utilisation « Afficher la liste des fiches inventaires »....... 98
Tableau 42 : Raffinement du cas d'utilisation « Afficher les détails d'un inventaire »............ 98
Tableau 43 : Raffinement du cas d'utilisation « Saisir la fiche inventaire »............................ 98
Tableau 44 : Raffinement du cas d'utilisation « Imprimer la fiche inventaire »...................... 99
Tableau 45 : Raffinement du cas d'utilisation « Valider la fiche inventaire » ......................... 99
Tableau 46 : Raffinement du cas d'utilisation « Afficher les statistiques » ........................... 100
Tableau 47 : Raffinement du cas d'utilisation « Ajouter un utilisateur »............................... 100
Tableau 48 : Raffinement du cas d'utilisation « Ouvrir une journée »................................... 100
Tableau 49 : Raffinement du cas d'utilisation « Supprimer un utilisateur » .......................... 101
Tableau 50 : Raffinement du cas d'utilisation « Modifier un utilisateur »............................. 101

vi
Table des figures
Figure 1 : Organigramme de la TRANSTU............................................................................... 4
Figure 2 : Interface de fiche patient de l’ERP « OpenEMR ».................................................. 10
Figure 3 : Interface de l'agenda de l’ERP « DoliMed » ........................................................... 11
Figure 4 : Interface de la liste des modules de l'ERP « Odoo »............................................... 12
Figure 5 : Modèle du système envisagé ................................................................................... 13
Figure 6 : Les dimensions du processus RUP [12] .................................................................. 14
Figure 7 : Les contraintes soumises au système d’information................................................ 17
Figure 8 : Le processus de développement en Y...................................................................... 17
Figure 9 : Diagramme de cas d’utilisations général................................................................. 23
Figure 10 : Diagramme de cas d'utilisation « Gérer les prescriptions »................................... 24
Figure 11 : Interface affichant la carte de l'entête et l'historique de la prescription................. 26
Figure 12 : Diagramme de cas d'utilisation « Gérer les commandes internes »....................... 28
Figure 13 : Diagramme de cas d'utilisation « Gérer les livraisons internes ».......................... 31
Figure 14 : Diagramme de cas d'utilisation « Gérer les commandes externes »...................... 33
Figure 15 : Diagramme de cas d'utilisation « Gérer les livraisons externes » ......................... 36
Figure 16 : Diagramme de cas d'utilisation « Gérer les inventaires »...................................... 38
Figure 17 : Diagramme de cas d'utilisation « Générer les rapports » ...................................... 39
Figure 18 : Diagramme de cas d'utilisation « Administrer ».................................................... 41
Figure 19 : Diagramme de cas d'utilisation « Paramétrer » ..................................................... 42
Figure 20 : Diagramme de cas d'utilisation « Gérer les produits pharmaceutiques » .............. 43
Figure 21 : Prototype d’interface du détail d'une commande interne ...................................... 44
Figure 22 : Diagramme de séquence « S’authentifier »........................................................... 46
Figure 23 : Diagramme de séquence « Ajouter une prescription ».......................................... 48
Figure 24 : Diagramme de séquence « Ajouter une commande interne » ............................... 52
Figure 25 : Diagramme de séquence « Livrer une livraison » ................................................. 54
Figure 26 : Diagramme de séquence « Ajouter une commande externe »............................... 55
Figure 27 : Diagramme de séquence « Réceptionner une livraison externe » ......................... 58
Figure 28 : Diagramme de séquence « Editer la fiche inventaire » ......................................... 59
Figure 29 : Diagramme de séquence « Ajouter un produit » ................................................... 61
Figure 30 : Diagramme d’états « Prescriptions »..................................................................... 63
Figure 31 : Diagramme d’états « Commande Interne »........................................................... 63

Table des figures
vii
Figure 32 : Diagramme d’états « Livraison Interne » .............................................................. 64
Figure 33 : Diagramme d’états « Commande Externe ».......................................................... 65
Figure 34 : Diagramme d’états « Livraison Externe »............................................................. 65
Figure 35 : Diagramme de classes............................................................................................ 67
Figure 36 : Diagramme de classes orientée données................................................................ 68
Figure 37 : Architecture de l'application.................................................................................. 71
Figure 38 : Diagramme de déploiement................................................................................... 72
Figure 39 : Evolution de l’architecture des applications web .................................................. 73
Figure 40 : Architecture frontend............................................................................................. 75
Figure 41 : Architecture Spring................................................................................................ 77
Figure 42 : Interface du registre de découverte Swagger......................................................... 81
Figure 43 : Interface du résultat du service « ListInternalOrder »........................................... 81
Figure 44 : Interface d'ajout d'un utilisateur............................................................................. 82
Figure 45 : Interface de la liste des opérations effectuées sur la base de données................... 82
Figure 46 : Interface de la liste des produits ............................................................................ 83
Figure 47 : Interface de la gestion des DCI.............................................................................. 83
Figure 48 : Interface d'ajout d'un produit ................................................................................. 84
Figure 49 : Interface d'ajout d'une prescription........................................................................ 84
Figure 50 : Interface de la liste et recherche des livraisons internes........................................ 85
Figure 51 : Interface de modification d'une livraison interne .................................................. 85
Figure 52 : Interface d'ajout d'une commande interne ............................................................. 86
Figure 53 : Interface de la liste et recherche des livraisons externes ....................................... 86
Figure 54 : Diagramme de cas d'utilisation « S'authentifier » ................................................. 88
Figure 55 : Diagramme de cas d'utilisation « Afficher les statistiques »................................. 99
Figure 56 : Diagramme de séquence « Annuler une prescription »....................................... 103
Figure 57 : Diagramme de séquence « Valider une commande interne ».............................. 105
Figure 58 : Diagramme de séquence « Modifier une livraison »........................................... 107
Figure 59 : Diagramme de séquence « Imprimer une commande externe ».......................... 109
Figure 60 : Diagramme de séquence « Valider la fiche inventaire » ..................................... 111
Figure 61 : Diagramme de séquence « Afficher les statistiques » ......................................... 113
Figure 62 : Diagramme de séquence « Consulter l'état en stock »......................................... 114
Figure 63 : Diagramme de séquence « Désactiver un compte utilisateur » ........................... 115
Figure 64 : Diagramme de séquence « Ouvrir une journée »................................................. 116
Figure 65 : Diagramme de GANTT - Partie 1 ....................................................................... 119

Table des figures
viii
Figure 66 : Diagramme de GANTT - Partie 2 ....................................................................... 120

ix
Liste des abréviations
2TUP .................................................................................................... 2 Track Unified Process
API ............................................................................. Interface de Programmation Applicative
BSD ........................................................................................... Berkeley Software Distribution
ERP ............................................................................................ Enterprise Ressource Planning
GPL ....................................................................................................... General Public License
IHM ................................................................................................ Interfaces Homme-Machine
JPA ............................................................................................................ Java Persistence API
MVC ......................................................................................................Modèle-Vue-Contrôleur
MVVM................................................................................................. Modèle-Vue-VueModèle
MVW .......................................................................................................Model-View-Whatever
POJO ....................................................................................................... Plain Old Java Object
RUP .....................................................................................................Rational Unified Process
SGBD-R ..............................................Systèmes de gestion de bases de données relationnelles
UP .....................................................................................................................Processus Unifié

1
Introduction générale
L’informatique ne cesse d’infester les différents domaines d’activités humaines. Cela
s’explique par son apport indéniable. En effet, cet outil permet entre autres l’automatisation des
traitements, la conservation des données, l’exécution rapide des tâches, etc. Ayant constaté
qu’ils peuvent bénéficier de ces avantages, les secteurs médicaux ont opté de ne pas se mettre
en marge de ce processus général d’informatisation. C’est ainsi que les systèmes d’information
des services médicaux ont commencé à voir le jour.
L'évolution des technologies d'information et de communication n’arrête à apporter aux
entreprises des opportunités. Mais ces derniers ne peuvent transformer ces opportunités en
avantages concurrentiels concrets que si elles adhèrent à ces évolutions par le biais de
l'intégration des technologies, notamment d'information et de communication, non seulement
au cœur de leurs métiers mais aussi dans les façons dont elles s'organisent.
C'est à travers l'amélioration des structures organisationnelles et c'est à ce niveau où les
technologies d'information et de communication jouent un rôle clairement considérable. Une
structure organisationnelle axée sur les technologies est beaucoup plus performante que si elle
est encore classique. Mais aussi une structure organisationnelle qui fonctionne encore avec des
technologies plus au moins obsolètes n'est plus au niveau de la performance d'une structure
organisationnelle dotée des technologies nouvelles sur le marché.
Consciente de ces évolutions technologiques et de l'évolution des besoins des services
dans lequel elle opère. La TRANSTU veut mettre en place un ERP médical permettant de mieux
organiser ces services médicaux et pharmaceutiques offerts à ces personnels.
Cet ERP comprendra plusieurs modules à savoir : la Gestion pharmaceutique ; la
Gestion des rendez-vous ; la Gestion des fiches de remboursement ; la Gestion des dossiers
médicaux et la Gestion du service radio. C’est sur le premier que nous avons travaillé durant
notre projet en collaborant avec les autres équipes pour maintenir d’intégration du schéma
global de l’ERP médical de la TRANSTU.

Introduction générale
2
Pour retracer l’acheminement chronologique de mon travail, le présent rapport a été
subdivisé en trois chapitres :
▪ Le premier chapitre, « Analyse » sera dédié à la présentation générale de
l’organisme d’accueil et la spécification des besoins.
▪ Le deuxième chapitre, « Conception » sera consacré à la modélisation des
besoins spécifiés dans les diagrammes UML.
▪ Le troisième chapitre, « Réalisation » sera assigné à la présentation de
l’environnement matériel et logiciels et l’implémentation du projet.
Le rapport s’achève par une conclusion générale rappelant les réalisations essentielles
du travail et présentant les perspectives futures de développement de l’application.

Chapitre I : Analyse
3
Introduction
Nous présentons dans ce chapitre, une étude préalable de notre travail. Dans un premier
temps, nous mettons notre projet dans son contexte général. Par la suite, nous décrivons la
méthodologie adoptée, ainsi qu’une spécification de besoins.
I. Contexte du projet
Dans cette partie, nous allons introduire une présentation de l’entreprise, ensuite une
étude de l’existant, ainsi qu’une définition de notre problématique et la solution proposé.
1. Présentation de l’organisme d’accueil
La Société des transports de Tunis est un organisme public à caractère non administratif
crée par la loi 2003-33 du 28 Avril 2003 instituant la fusion de la Société nationale des
transports, opérateur de transport public de voyageurs par bus, et la Société du Métro Léger de
Tunis, opérateur de transport public de voyageur par mode ferré métro et le Tunis-Goulette-
Marsa, ligne ferroviaire qui relie Tunis à La Marsa en passant par La Goulette. La Société des
transports de Tunis a pour dénomination commerciale TRANSTU et s’est vue assignée la
mission du transport en commun urbain et suburbain de voyageurs par mode bus et ferré. Par
mode ferré, il s’agit de l’exploitation de lignes de métro ainsi que de la ligne Tunis-Goulette-
Marsa. L’organisation structurelle de la Société des transports de Tunis a été approuvée par la
promulgation du décret n°703/2005 du 1er Mars 2005. L’organigramme a été mis en place par
le Décret N°2006-2380 du 28 Août 2006 fixant les conditions d'octroi et de retrait des emplois
fonctionnels au sein de la Société des Transports de Tunis. Il dote la Société des transports de
Tunis d’un président directeur général secondé par un secrétaire général et un directeur général
adjoint auxquels sont rattachés 4 directions centrales, 12 départements, 27 directions, 54
divisions et 136 services. [1]
La TRANSTU est une entreprise dont l’activité en 2013 a été du point de vue :
▪ Des effectifs : 8005 agents bénéficiant de la gratuité des soins et des traitements ;
▪ Des moyens techniques : 1247 bus et 207 rames métro et TGM ;
▪ De l’exploitation :
- Une longueur de réseau bus de 7344.1km et 160.2 km pour le réseau
ferré ;
- Un nombre de lignes de 231 pour le réseau bus et 7 pour le réseau ferré ;

4
- Le nombre de voyageurs transportés a été de 214 650.5 milliers de
voyageurs répartis à raison de 132 774.1 pour le réseau bus et 81 876.1 pour
le réseau ferré.
▪ Du chiffre d’affaire : les recettes globales ont été de 52 599 milliers de dinars.
[2]
a. Organigramme de la société
La Figure 1 illustre l’organigramme de la société TRANSTU.
Figure 1 : Organigramme de la TRANSTU
b. Description de la fonction médicale
Sur le plan organisationnel, La fonction médicale actuellement est centralisée au niveau
de la direction médico-sociale dont dépendent actuellement l’ensemble des dispensaires de
l’entreprise. Ce dernier relève du département ressources humaine de la direction centrale
ressource humaines et juridique qui est composé de deux divisons :
▪ La division sociale qui a pour mission de mettre en œuvre la politique de
l’entreprise en matière d’assistance et d’entraide sociale. De cette division dépendent
deux services le service social et le service des affaires sociales et de la vie associative.
▪ La division médicale quant à elle, initialement composée de 3 services à savoir :

5
- Le service logistique médicale qui a pour mission de doter les services
médicaux centraux et décentralisés d’une logistique médicale suffisante et en
bon fonctionnement.
- Le service central de médecine de travail et de contrôle qui a pour mission
d’assurer la médecine de contrôle ainsi que qu’un rôle préventif dans le
domaine de la santé de travail.
- Le service médecine curative qui a pour mission d’assurer la médecine
curative pour l’ensemble du personnel au siège et dans les unités
décentralisées.
Depuis janvier 2011 les unités médicales décentralisées sont également rattachées à la
division médicale. Ces unités ont pour mission d’assurer un rôle préventif dans le domaine de
la santé de travail et ces principales tâches qui leurs sont assignées sont :
▪ Procéder aux examens médicaux périodiques ou de reprise de travail et aux
examens spontanés en cas d’urgence ;
▪ Veiller à la protection du personnel du district ou du réseau concerné contre les
risques liés aux maladies professionnelles et aux accidents de travail ;
▪ Préparer les données et documents nécessaires demandés par l’inspection
médicale du travail ;
▪ Sensibiliser le personnel des districts ou du réseau concerné en matière
d’hygiène ;
▪ Préparer le rapport d’activité du service.
Sur le plan procédural, tous les agents de l’entreprise ainsi que les retraités ont leur
dossier médical au niveau d’un des dispensaires de l’entreprise conformément aux articles 116
et 117 du statut du personnel des agents des entreprises de publiques de transport de voyageurs
et du métro légers approuvé par le décret 99-1730 du 9 août 1999. Les malades se présentent
au niveau du dispensaire où le dossier est géré et sont auscultés par un médecin généraliste ;
médecin de travail ou généraliste conventionné qui soit prescrit un traitement soit oriente le
malade vers un spécialiste conventionné dans tous les cas de figure lorsqu’un traitement est
prescrit, le malade se présente à la pharmacie de l’entreprise où un préparateur qui soit lui remet
son traitement, soit lui donne un bon de médicament pour s’approvisionner auprès des
pharmacies conventionnées. Pour les agents affectés au dépôt Tebourba, ils sont orientés vers
une pharmacie conventionnée. La maîtrise de leur consommation sera effectuée grâce à la saisie

6
sur place des bons de médicaments et par une solution de migration vers l’application de gestion
des produits pharmaceutiques à la charge du contractant. [3]
2. Etude de l’existant
La TRANSTU a un Enterprise Ressource Planning (ERP) global et cherche à mettre en
place un ERP médical dont les modules sont :
▪ Gestion pharmaceutique ;
▪ Gestion des rendez-vous ;
▪ Gestion des fiches de remboursement ;
▪ Gestion des dossiers médicaux ;
▪ Gestion du service radio.
Ces modules sont proposés sous forme de projets permettant la gestion de la fonction
médicale et pharmaceutique. C’est dans ce cadre que se présente note sujet de mémoire qui
porte sur le premier module à savoir la gestion pharmaceutique de TRANSTU.
a. Présentation générale des Enterprise Ressource Planning (ERP)
Définition : « Le terme ERP vient de l’anglais ‘‘Enterprise Ressource Planning’’. ERP a été
traduit en français par l’acronyme PGI (Progiciel de Gestion Intégré) et se définit comme un
groupe de modules relié à une base de données unique. » [4]
Un ERP est un progiciel1
qui permet de gérer l’ensemble des processus opérationnels
d’une entreprise en intégrant plusieurs fonctions de gestion dans un système. Il est défini par
un sous-ensemble du système d’information qui intègre les caractéristiques suivantes :
▪ Gestion effective de plusieurs domaines de l’entreprise par des modules intégrés
ou des progiciels susceptibles d’assurer une collaboration des processus ;
▪ Existence d’un référentiel2
unique des données ainsi que les indications
nécessaires pour retrouver les données elles-mêmes sur une base de données ;
▪ Adaptations rapides aux règles de fonctionnement (professionnelles, légales ou
résultant de l’organisation interne de l’entreprise et les règles dictées par le marché);
▪ Unicité d’administration du sous-système applicatif ;
1
Programme (ou ensemble de programmes informatiques) cohérent, indépendant et documenté, conçu pour
être fourni à plusieurs utilisateurs en vue d'une même application ou d'une même fonction, qu'un usager peut
utiliser de façon autonome. [37]
2
Le référentiel est défini comme étant l’ensemble des références des données.

7
▪ Uniformisation des Interfaces Homme-Machine (IHM) : même ergonomie des
écrans, mêmes boutons, même famille de barres menu, mêmes touches de fonctions
et de raccourcis. [5]
Les ERP sont caractérisés par leur modularité. Chaque module d’ERP dispose de
fonctions standards qui seront paramétrées pour coïncider avec le fonctionnement souhaité par
l’entreprise. En complément, le prestataire peut développer des spécifiques pour les fonctions
manquantes à son progiciel.
Les ERP intègrent de plus en plus de modules utiles à l’entreprise. Certains de ces
modules ont accumulé tellement de fonctions, qu’ils sont maintenant proposés comme des
logiciels indépendants.
Les modules que l’on retrouve généralement en standard dans un ERP pour entreprise
sont :
▪ La gestion des ventes : permet de gérer la chaîne commerciale en passant par les
devis, la saisie de commandes et l’édition des bons de livraison et des factures. On y
trouve également les fonctions de gestion des tarifs, du prévisionnel, et la gestion des
contrats.
▪ La gestion des achats : on y retrouve les fonctions symétriques à la vente
(demandes de prix, gestion tarifaire, commandes, etc.) ainsi que la gestion des
réapprovisionnements. Cela inclut aussi les achats de sous-traitance.
▪ La gestion de la relation client : permet de gérer les fiches tierces, et les actions
associées (prospection, suivi contact, etc.).
▪ La gestion de la production : cœur de la gestion des entreprises manufacturière,
la GPAO couvre toutes les données techniques (gamme, nomenclature), le lancement
des ordres de fabrication et la planification. On trouve aussi la gestion des
programmes de fabrication, et le suivi de la charge et de la capacité des ateliers.
▪ La gestion des stocks : depuis la réception des matières premières jusqu’à la
préparation des expéditions.
▪ La gestion financière : ce module est destiné aux décideurs. Il s’agit d’un outil
de reporting combinant les informations des autres modules pour en extraire des
statistiques.
▪ La gestion comptable, de trésorerie, des amortissements : obligation pour les
entreprises, elle peut également être sous-traitée. La comptabilité peut être générale
ou analytique. Ce module n’est pas toujours présent en standard.

8
▪ La gestion de la paie : obligation pour les entreprises, elle peut aussi être sous-
traitée. Comme pour la comptabilité, ce module n’est pas toujours présent en standard.
Cette liste des modules fonctionnels n’est pas exhaustive. On pourrait y rajouter la
gestion des points de vente, la gestion d’affaires de plus en plus utilisée, la gestion électronique
de la documentation, la gestion de la qualité, la gestion des ressources humaines, le décisionnel
ou bien la gestion de la maintenance pour gérer un parc machines. [6]
b. Les ERP médicaux
En solidarité, la santé, le médical et le paramédical sont des supports techniques
essentiels lors des interventions humanitaires que ce soit dans un contexte d’urgence ou de
développement, d’où vient un nombre énorme des biens offertes et une évolution exorbitante
du secteur médical en termes de nombre de patient, de médicament et d’actions. Par souci de
nombre de difficultés affecter différemment les services médicaux, donc une nécessité d’en
développer une solution informatique. Une accumulation des fonctionnalités demandées a
donné naissance aux ERP médicaux.
Un ERP médical est une extension des ERP destiné au secteur médical, répond aux
fonctionnalités principales qui sont :
▪ Dossier Médical Global ;
▪ Système d'Information Hospitalier ;
▪ Système d'Information de Santé.
Les ERP médicaux intègrent des modules comme les prescriptions, la facturation, les
rapports, l'examen et historique des patients, l'admission des patients, le stock médical et la
gestion de stock. Ils permettent la collaboration essentielle entre les intervenants de la
production de soins autour des dossiers patients.
Les modules que l’on trouve généralement dans un ERP médical sont : [7]
▪ Gestion des maladies et les procédures médicales ;
▪ Gestion des patients ;
▪ Gestion des docteurs ;
▪ Gestion des laboratoires ;
▪ Gestion des stocks et des approvisionnements médicaux ;
▪ Gestion financière ;
▪ Gestion des produits médicaux ;
▪ Gestion des dossiers médicaux ;

9
▪ Planification des soins ;
▪ Gestion d’hospitalisations.
c. Comparatif des ERP médicaux
Dans cette partie, nous allons introduire les ERP médicaux existants, ainsi que leurs
fonctionnalités offertes.
“ OpenEMR
C’est un ERP open source assujetti aux termes de la GNU General Public License
(GPL), permet la gestion de la pratique médicale et des dossiers médicaux qui prend également
en charge les enregistrements médicaux électroniques. [8]
Ces fonctionnalités principales sont :
▪ Gestion des dossiers médicaux : permet la sauvegarde des données du patient tel
que les rendez-vous, les médicaments prescrits, les problèmes médicaux, etc.
▪ Données démographiques du patient : c’est la fiche du patient contenant ces
informations principales, sa couverture assurance, son suivi décisif, etc.
▪ Planification des patients : permet la gestion des rendez-vous selon un
algorithme de planification suivant le type de rendez-vous, la classification du patient,
etc.
▪ Gestion des prescriptions : permet la création des ordonnances et le suivi des
médicaments.
▪ Gestion des règles de décisions clinique : permet le rappel des médecins et des
patients, le calcule clinique de la mesure de qualité, etc.
▪ Facturation médicale : permet la gestion des prises en charge, le suivi des
dossiers d’assurance et le compte client, etc.
La Figure 2 présente une interface de l’ERP « OpenEMR ».

10
Figure 2 : Interface de fiche patient de l’ERP « OpenEMR »
“ DoliMed
C’est un ERP open source, une version de Dolibarr ERP spécialisé des actes médicaux,
destiné pour les cabinets médicaux. [9]
▪ Gestion des patients : permet la création de la fiche du patient, un calendrier pour
le patient et toutes ces données cliniques.
▪ Annuaire des médecins : permet la gestion des médecins ainsi que leurs
disponibilités ou non.
▪ Gestion des consultations : permet les enregistrements des demandes d'analyses
radiologiques du patient ainsi que les résultats.
▪ Statistiques : permet la création des caractéristiques selon plusieurs critères de
sélection.
La Figure 3 illustre une interface de l’ERP « DoliMed ».

11
Figure 3 : Interface de l'agenda de l’ERP « DoliMed »
“ Odoo Medical
C’est un module extensible de l’ERP open source Odoo assujetti aux termes de la licence
Affero GPL-3, permet la gestion des services essentiels de fonction médicale. [10]
▪ Gestion des patients : permet la gestion des fiches patients et leurs données
médicales
▪ Gestion des médecins : permet l’administration des médecins suivant leurs
calendriers et leurs charges horaires.
▪ Gestion pharmacie : permet la gestion des médicaments et des prescriptions.
▪ Gestion des services hospitaliers : permet la gestion des services hospitaliers
selon leurs spécialités telles que la médecine pédiatrique, médecine gynécologie, etc.
La Figure 4 présente une interface de l’ERP « Odoo ».

12
Figure 4 : Interface de la liste des modules de l'ERP « Odoo »
3. Problématique
Dans les entreprises publiques, les services médicaux offerts aux personnels sont très
répandus, soit ces services sont gérés d’une manière non informatisée tel que les paperasses,
soit d’une manière informatisée et chaque service avait son propre système d’information tel
qu’un système pour les rendez-vous des consultations et des radios et un système pour la gestion
de la pharmacie ainsi qu’un autre pour les fiches médicales, le remboursement, etc. et ces
systèmes la plupart de temps ne couvre pas les besoins fonctionnels.
Cette mauvaise gestion de l’information coute très chers aux entreprises tandis que ces
services offerts se caractérisent par la gratuité et ceci se produise dans des situations de double
même triple saisie de la même information, un nombre élevé d’erreurs et d’incohérences entre
les différents systèmes, des erreurs humaines survenaient régulièrement et aussi coute très chers
en termes de temps vue le nombre important des secteurs médicaux. Ceci mène l’établissement
de la fonction médical à commettre des erreurs de rédaction, d’archivage et des problèmes
d’exploitation, de communication.
4. Solution proposée
Notre solution proposée au sein de la TRANSTU consiste à développer un ERP médical
qui va interfacer avec l’ERP de la TRANSTU. Comme le montre la Figure 5, nous illustrons

13
les modules de notre ERP en tenant compte au module de la gestion des ressources humaines
qu’on va l’utiliser.
Figure 5 : Modèle du système envisagé
Notre ERP se compose de cinq modules :
▪ Gestion pharmaceutique : c’est notre premier module et celui qu’on doit
développer en urgence suite aux problèmes de la mal gestion des médicaments chez
la pharmacie de la TRANSTU et ces dépôts.
▪ Gestion des rendez-vous : ce module concerne les consultations et la prise des
rendez-vous.
▪ Gestion de service radio : ce module permet la gestion des rendez-vous pour
l’imagerie médicale ainsi que la sauvegarde de résultat et les demandes
hospitalisations ou d’explorations.
▪ Gestion des dossiers médicaux : ce module permet la gestion fiches médicaux
des agents et ces antécédents.
▪ Gestion des fiches de remboursement : ce module permet la gestion des dossiers
de prise en charge et les fiches de remboursements suivant les bulletins de soins.

14
II. Méthodologie adoptée
Définition : « Processus Unifié (UP) : Un processus unifié est un processus de
développement logiciel construit sur UML ; il est itératif et incrémental, centré sur
l’architecture, conduit par les cas d’utilisation et piloté par les risques. » [11]
1. Présentation de l’UP
La gestion de l’UP est organisée par les 4 phases suivantes (Cf. Figure 6) :
▪ Inception : spécification des besoins et aussi une sorte d'étude de faisabilité où
on effectue les recherches nécessaires pour décider si on poursuit ou non le projet.
▪ Élaboration : on développe de façon incrémentale l'architecture du noyau, les
risques et la plupart des besoins sont identifiés.
▪ Construction : on construit des sous-ensembles exécutables et stables du produit
final.
▪ Transition : le produit final est livré en version bêta à la disposition des
utilisateurs.
Figure 6 : Les dimensions du processus RUP [12]
Les activités de développement sont définies par six disciplines fondamentales qui
décrivent la modélisation métier :

15
▪ La capture des besoins : c’est la définition des besoins, autrement, inventorier
les besoins principaux et fournir une liste de leurs fonctions, recenser les besoins
fonctionnels (du point de vue de l'utilisateur) et appréhender les besoins non
fonctionnels (technique) en livrant une liste des exigences.
▪ L’analyse : accéder à une compréhension des besoins et des exigences du client.
Il s'agit de livrer des spécifications pour permettre de choisir la conception de la
solution. Un modèle d'analyse livre une spécification complète des besoins issus des
cas d'utilisation et les structure sous une forme qui facilite la compréhension
(scénarios), la préparation (définition de l'architecture), la modification et la
maintenance du futur système.
▪ La conception : permet d'acquérir une compréhension approfondie des
contraintes liées au langage de programmation, à l'utilisation des composants et au
système d'exploitation. Elle détermine les principales interfaces et les transcrit à l'aide
d'une notation commune. Elle constitue un point de départ à l'implémentation en
décomposant le travail d'implémentation en sous-système et en créant une abstraction
transparente de l'implémentation.
▪ L’implémentation : le résultat de la conception pour implémenter le système sous
formes de composants. Ces objectifs principaux sont de planifier les intégrations des
composants pour chaque itération, et de produire les classes et les sous-systèmes sous
formes de codes sources.
▪ Le test : permet de vérifier des résultats de l'implémentation en testant la
construction. Outre, c’est planifier pour chaque itération, l’implémenter en créant des
cas de tests, effectuer les tests unitaires pour valider le fonctionnement du code,
intégration continue pour détecter des anomalies et les tests fonctionnels pour valider
la conformité aux besoins en prendront en compte le résultat de chacun.
▪ Le déploiement : c’est la description de la configuration matérielle des unités de
traitements et de l’architecture technique, des nœuds (serveurs, postes de travail et
périphériques) et de leur interconnexion
Dans une démarche traditionnelle, le processus de développement était caractérisé par :
▪ Un processus de type séquentiel : développement organisé en phases qui
regroupent des étapes, elles-mêmes décomposées en tâche.

16
▪ Les niveaux de découpage coïncident : la fin d’une phase correspond à la
conclusion de ses étapes, qui elles-mêmes se terminent avec l’accomplissement des
tâches qui les composent.
Dans une approche UP :
▪ Le processus est de type itératif ;
▪ Les découpages ne coïncident pas : les activités (taches, phases, étapes, etc.) se
déroulent dans plusieurs dimensions.
L’UP est donc constituée de plusieurs disciplines d’activité de production et de contrôle
de cette production. Tout processus UP répond aux caractéristiques suivantes :
▪ Itératif et incrémental ;
▪ Piloté par les risques ;
▪ Orienté composant ;
▪ Piloté par les cas d’utilisation ;
▪ Centré sur l’architecture ;
▪ Orienté utilisateur.
2. Processus de l’UP
Il existe plusieurs modèle type du processus de l’UP, parmi les en cite le Rational
Unified Process (RUP) et le 2 Track Unified Process (2TUP).
a. Le processus Rational Unified Process (RUP)
C’est un dérivé de l’UP permet d’affecter selon une approche disciplinée à l’affectation
des tâches et des responsabilités. Son but est d'assurer la production d’un logiciel de grande
qualité satisfaisant les besoins de ses utilisateurs finaux dans des délais et avec un budget
prévisible.
b. Le processus 2 Track Unified Process (2TUP)
2TUP est un processus UP qui répond aux caractéristiques de l’UP. Il apporte une
réponse aux contraintes de changement continuel imposées aux systèmes d’information de
l’entreprise. En ce sens, il renforce le contrôle sur les capacités d’évolution et de correction de
tels systèmes. « 2 Track » signifie littéralement que le processus suit deux chemins. Il s’agit des
chemins « fonctionnels » et « d’architecture technique », qui correspondent aux deux axes de
changement imposés au système informatique (Cf. Figure 7).

17
Figure 7 : Les contraintes soumises au système d’information
L’axiome du 2TUP consiste à constater que toute évolution imposée au système
d’information peut se décomposer et se traiter parallèlement, suivant un axe fonctionnel et un
axe technique.
À l’issue des évolutions du modèle fonctionnel et de l’architecture technique, la
réalisation du système consiste à fusionner les résultats des deux branches. Cette fusion conduit
à l’obtention d’un processus de développement en forme de Y, comme illustré par la Figure 8.
Figure 8 : Le processus de développement en Y
La branche gauche (fonctionnelle) comporte :
▪ La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé
sur le métier des utilisateurs. Elle qualifie au plus tôt le risque de produire un système
inadapté aux utilisateurs. De son côté, la maîtrise d’œuvre consolide les spécifications
et en vérifie la cohérence et l’exhaustivité 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 termes de métier. Les résultats de l’analyse ne dépendent d’aucune
technologie particulière.

18
La branche droite (architecture technique) comporte :
▪ La capture des besoins techniques, qui recense toutes les contraintes et les choix
dimensionnant la conception du système. Les outils et les matériels sélectionnés ainsi
que la prise en compte de contraintes d’intégration avec l’existant conditionnent
généralement des 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 la moins dépendante
possible des aspects fonctionnels. Elle a pour objectif 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 informatique et écarte la plupart des risques de niveau technique.
L’importance de sa réussite est telle qu’il est conseillé de réaliser un prototype pour
assurer sa validité.
La branche du milieu comporte :
▪ La conception préliminaire, qui représente une étape délicate, car elle intègre le
modèle d’analyse dans l’architecture technique de manière à tracer la cartographie des
composants du système à développer ;
▪ La conception détaillée, qui étudie ensuite comment réaliser chaque composant
;
▪ L’étape de codage, qui produit ces composants et teste au fur et à mesure les
unités de code réalisées ;
▪ L’étape de recette, qui consiste enfin à valider les fonctions du système
développé. [11]
3. Choix de la méthodologie
Nous avons opté pour la méthodologie UP afin de :
▪ Faciliter la compréhension graduelle du problème,
▪ Permettre l’identification et la prise en charge des risques de tous types.
▪ Suivre un rythme accéléré en travaillant efficacement vers les objectifs clairs et
à court terme.
▪ Centrer le processus sur les besoins des utilisateurs, facteur clé de succès du
projet.
▪ Aboutir à un système dont l’architecture favorise son évolutivité et la
réutilisation de ses composants.

19
Cependant, notre choix s’est porté sur le processus 2TUP car il apporte une réponse aux
contraintes de changements continuels imposés aux systèmes d’information. En ce sens, il
renforce le contrôle sur les capacités d’évolution et de correction de tels systèmes, ainsi que
notre projet est mis sous deux contraintes facteurs qui sont les contraintes techniques suite aux
choix technologie mené par les perspectives prise par l’entreprise et des contraintes fonctionnels
suite aux besoins spécifique de la fonction de la distribution des produits pharmaceutiques.
4. Planification du projet
La conduite du projet est relativement complexe si on ne suit pas une démarche, une
méthodologie et un planning bien défini à l’avance. Ainsi que, notre projet suit plusieurs phases,
à la fin de chaque phase des livrables sont réalisées pour indiquer l’état d’avancement du projet.
C’est, donc, une nécessite d’élaboré le diagramme de GANTT. (Cf. Annexe C).
Le diagramme de GANTT, couramment utilisé en gestion de projet, est l'un des outils
les plus efficaces pour représenter visuellement l'état d'avancement des différentes activités
(tâches) qui constituent un projet et permet donc de visualiser d'un seul coup d'œil :
▪ Les différentes tâches à envisager ;
▪ La date de début et la date de fin de chaque tâche ;
▪ Le chevauchement éventuel des tâches, et la durée de ce chevauchement ;
▪ La date de début et la date de fin du projet dans son ensemble.
III. Spécification des besoins
Tout au long de cette partie, nous allons identifier et préciser les besoins à satisfaire.
Ces besoins représentent les fonctionnalités à réaliser dans notre projet.
1. Identification des acteurs
Définition : « Un acteur représente l’abstraction d’un rôle joué par des entités externes
(utilisateur, dispositif matériel ou autre système) qui interagissent directement avec le système
étudié. » [11]
Dans le cadre de notre projet les acteurs sont les suivants :
▪ Pharmacien : Il assure toutes les opérations des ordonnances et leurs
distributions, ainsi que les commandes internes.
▪ Préparateur : Sa fonction consiste à effectuer les opérations faites sur les
ordonnances et leurs distributions.

20
▪ Gestionnaire de dépôt : Il gère le stock au niveau de l’entrepôt, ainsi que les
livraisons internes, les commandes et les livraisons externes, aussi leurs réceptions.
▪ Responsable Inventaire : Il assure la mission de contrôle de la quantité au stock.
▪ Agent d’inventaire : Chargé de la saisie des inventaires.
▪ Gestionnaire : Il consulte les statistiques et génère des rapports de suivi.
▪ Administrateur : C’est l’acteur qui possède le privilège de plus haut niveau. Cet
acteur est capable de manipuler toutes les fonctionnalités proposées par l’application
notamment la gestion des prescriptions, des produits et leurs familles, la gestion
commandes et livraisons internes et externes, etc. Ainsi que la gestion des utilisateurs.
2. Besoins fonctionnels
Après avoir élaboré le diagramme de contexte statique qui a pour objet de définir la
frontière fonctionnelle entre le système considéré comme une boîte noire et son environnement.
Dans cette partie, nous allons identifier les besoins de ces acteurs.
Définition : « Les besoins fonctionnels expriment une action que doit effectuer le système en
réponse à une demande (sorties qui sont produites pour un ensemble donné d’entrées). » [13]
Nous devons définir les services souhaités. Dans ce qui suit, nous décrivons les
différents besoins fonctionnels de notre système :
▪ Gestion des prescriptions : Constitue le principal point de sortie des produits
pharmaceutique du stock. Elle est caractérisée par deux types :
- Distribution ordinaire : Consiste à distribuer la totalité des médicaments
prescrits dans l’ordonnance.
- Distribution partielle : Consiste à distribuer une partie des médicaments
prescrits. En effet, dans certains cas, le médecin prescrit une quantité de
médicaments pour une longue durée qui sera distribuée partiellement à l'agent.
▪ Gestion des commandes et livraisons interne : Consiste à gérer les échanges de
produits pharmaceutiques entre l’entrepôt et la pharmacie. La gestion des commandes
se caractérise par deux types :
- Commande assistée : Consiste à proposer automatiquement une
commande de tous les produits en rupture.
- Commande ordinaire : Consiste à créer une commande normale.
▪ Gestion des commandes et livraisons externe : Consiste à gérer les commandes
effectuées au près du fournisseur exclusif (Pharmacie Centrale de Tunisie) et les

21
livraisons suivant un ou plusieurs réceptions pour la commande crée. Aussi la gestion
des commandes externes se caractérise par deux types, la commande assistée et la
commande ordinaire.
▪ Gestion des inventaires : Consiste à éditer les fiches inventaires, permettre la
saisi des quantités physiques des produits en stock en justifiant l’écart s’il existe et la
validation des fiches inventaires.
▪ Paramétrage : Consiste à gérer les districts, les rôles, les emplacements, les
produits pharmaceutiques et ces différentes caractéristiques tels que dci, classe
pharmaceutiques, formes, etc.
▪ Administration : Consiste à consulter le journal des opérations faites sur le
système, à ouvrir une journée de travail selon le type et à gérer les utilisateurs en
créant des comptes, les activant, les désactivant, etc.
▪ Les rapports : Consiste à générer les rapports tels que la consultation de l’état
en stock.
▪ Les statistiques : Consiste à consulter les statistiques telles que la répartition des
prescriptions saisie par préparateur, etc.
3. Besoins non fonctionnels
Les besoins non fonctionnels sont des besoins qui ont un aspect visible pour l’utilisateur
et ils caractérisent le système. Ce sont des besoins en matière de performance qui exige la
conformité aux standards, la complétude et la cohérence, ne concernent pas le comportement
du système et sous lesquelles le système doit rester opérationnel.
Nous citons :
▪ Besoin d’évolutivité : Notre système doit porter conscient sur la possibilité
d’évolutivité des interfaces (point de vue qualité et design) pour des fins d’utilisation
plus fiable et d’accès aux informations (point de vue simplicité et disponibilité).
▪ Besoin de sécurité : La gestion des rôles des utilisateurs et leurs accès ainsi que
la mise en place d’un système d’authentification et génération des tokens selon
l’utilisateur connectée et des mots de passe cryptés sur un système 64bit ;
▪ Besoin de performance : Optimisation du temps de chargement des pages ;
▪ Besoin de portabilité et de compatibilité : Notre application doit être portable
sur tous les environnements logiciels et peut être utilisé par différent terminal ;

22
4. Diagramme des cas d’utilisations
Définition : « Un cas d’utilisation (use case) représente un ensemble de séquences d’actions
réalisées par le système et produisant un résultat observable intéressant pour un acteur
particulier. » [11]
a. Diagramme des cas d’utilisations général
Après avoir identifié les besoins fonctionnels et les besoins non fonctionnels, nous
présentons les besoins de notre module de manière formelle en utilisant le diagramme des cas
d’utilisations du langage de modélisation UML.
La Figure 9 illustre le diagramme des cas d’utilisations général.
b. Raffinement des cas d’utilisations
Les besoins à réaliser dans notre projet, ont été spécifiés et pour mieux s’expliquer nous
allons vous présenter les raffinements des cas d’utilisations de ainsi qu’une description
textuelle.
“ « Gérer les prescriptions »
La Figure 10 présente le diagramme du cas d’utilisation de la gestion des prescriptions.
Nous allons décrire les cas d’utilisations illustré dans le diagramme de la gestion des
prescriptions. (Cf. Tableau 1, Tableau 2, Tableau 3).

23
Figure 9 : Diagramme de cas d’utilisations général

24
Figure 10 : Diagramme de cas d'utilisation « Gérer les prescriptions »

25
Tableau 1 : Raffinement du cas d'utilisation « Ajouter une prescription »
Cas d’utilisation Ajouter une prescription.
Acteur - Préparateur ;
- Pharmacien.
Précondition - L’utilisateur est authentifié ;
- Agent existe.
Postcondition - Prescription ajoutée ;
- Distribution crée.
Description du
scénario
- Le préparateur ouvre l’interface de saisie d’une prescription ;
- Le système affiche la carte3
de l’entête de la prescription et la
carte d’historique des ordonnances ;
- Le préparateur saisie la matricule de l’agent et choisit son district ;
- Le système vérifie la matricule ;
- Le système affiche l’historique des prescriptions et les
informations relatives à l’agent ;
▪ Consulter une prescription :
- Le préparateur clique sur le bouton « Consulter » ;
- Le système affiche une carte de la prescription choisie
et affiche l’entête et toute les distributions.
▪ Distribuer une prescription :
- Le préparateur clique sur le bouton « Distribuer » ;
- Le système affiche la liste des produits à distribuer
ainsi que la quantité prescrite ;
- Le préparateur saisit la quantité à distribuer et la date
de la prochaine distribution et confirme la ligne de la
distribution ;
- (1) Le système vérifie les champs vides ;
• Supprimer une ligne de la distribution :
- Le préparateur clique sur le bouton
« Supprimer » ;
- Le système efface la ligne de la distribution
courante.
• Modifier une ligne de la distribution :
- Le préparateur clique sur le bouton
« Editer » ;
- Le système ouvre la ligne grisée.
- Le système vérifie les la disponibilité des produits à
distribuer ;
- Le préparateur confirme la distribution ;
- Le système affiche l’interface de l’impression.
- Le préparateur imprime la distribution.
▪ Saisir une prescription
- Le préparateur choisit la périodicité du produit.
• Produit périodique :
- Le préparateur clique sur le bouton radio
« Périodique »
3
Une carte est un conteneur de contenu flexible et extensible. Il comprend des options pour les en-têtes et les
pieds de page, une grande variété de contenu, des couleurs d'arrière-plan contextuelles et des options
d'affichage puissantes. [40]

26
- Le système affiche les champs nécessaires
- Le préparateur saisit la quantité par
distribution et la date de la prochaine
distribution.
- Redirection vers le point (1) du raffinement.
• Produit non périodique :
- Le préparateur choisit le produit à distribuer
et saisit la quantité prescrite ;
- Redirection vers le point (1) du raffinement.
Exception - Les champs son vides ;
- L’agent n’existe pas.
Interface La Figure 11 montre une interface avec une carte affichant l’entête de
l’ordonnance et une carte pour l’affichage de l’historique.
Figure 11 : Interface affichant la carte de l'entête et l'historique de la prescription
Tableau 2 : Raffinement du cas d'utilisation « Annuler une prescription »
Cas d’utilisation Annuler une prescription.
- Pharmacien.
- Prescription ouverte en distribution.
Postcondition Prescription annulée.
Description du
scénario
- Le préparateur ouvre l’interface de recherche d’une prescription ;
- Le système affiche l’interface de la liste des prescriptions ;
▪ Rechercher une prescription :
- Le préparateur choisit les critères de recherche (par la
date début et la date fin, par une liste des produits) et
rempli le formulaire ;

27
- Le système affiche le résultat selon le ou les critères
choisis.
▪ Afficher la liste des prescriptions de l’agent
- Le préparateur saisit la matricule de l’agent ;
- Le système vérifie la matricule ;
- Le système affiche la liste des prescriptions de l’agent choisi ;
- Le préparateur clique sur le bouton « Détail » ;
- Le système affiche les détails de la prescription choisit ;
- Le préparateur clique sur le bouton « Annuler » ;
- Le système affiche un message de vérification de l’annulation ;
- Le préparateur confirme l’annulation ;
- Le système ferme la prescription ouverte pour distribution et
affiche un message de succès d’annulation.
Exception Prescription fermée en distribution.
Tableau 3 : Raffinement du cas d'utilisation « Modifier une prescription »
Cas d’utilisation Modifier une prescription.
Acteur - Préparateur.
- Pharmacien.
- Détails de la prescription affichés ;
- Prescription ouverte en distribution.
Postcondition Prescription modifiée.
Description du
scénario
- Le préparateur clique sur le bouton « Modifier » ;
- Le système ouvre les lignes non fermées en distribution et affiche
deux boutons « Editer » et « Supprimer » ;
▪ Supprimer une ligne de la prescription :
- Le préparateur clique sur le bouton « Supprimer » ;
- Le système efface la ligne de la distribution.
▪ Modifier une ligne de la prescription :
- Le préparateur clique sur le bouton « Editer » ;
- Le système ouvre la ligne grisée.
- Le préparateur modifie la quantité distribuée et la date
de la prochaine distribution.
- Le système vérifie les champs et affiche une vue de succès de
modification.
Exception Prescription fermée en distribution.
“ « Gérer les commandes internes »
La Figure 12 illustre le diagramme du cas d’utilisation de la gestion des commandes
internes.
Dans cette partie, nous allons raffiner les cas d’utilisations du diagramme de la gestion
des commandes internes. (Cf. Tableau 4, Tableau 5, Tableau 6).

28
Figure 12 : Diagramme de cas d'utilisation « Gérer les commandes internes »
Tableau 4 : Raffinement du cas d'utilisation « Ajouter une commande interne »
Cas d’utilisation Ajouter une commande interne.
Acteur Pharmacien.
Précondition L’utilisateur est authentifié.
Postcondition Commande interne ajoutée.
Description du
scénario
- Le pharmacien ouvre l’interface de saisie d’une commande
interne ;
- Le système affiche l’interface ;
- Le pharmacien choisit le type de la commande (selon le type de
produit à commander) ;
- Le système affiche le formulaire de saisie ;
▪ Ajouter une commande interne assistée
- Le pharmacien clique sur le bouton « Stock rupture » ;

29
- Le système affiche une carte de la liste des produits en
rupture ;
- Le pharmacien saisie les quantités à commander.
▪ Ajouter une commande interne non assistée
- Le pharmacien saisie les produits et les quantités
commandées ;
- Le système affiche la quantité en pharmacie et en
dépôt de chaque produit à commander ;
• Supprimer une ligne de la commande :
- Le pharmacien clique sur le bouton
« Supprimer » ;
- Le système efface la ligne de la commande.
• Valider une ligne de la commande :
« Valider » ;
- Le système vérifie les champs et grise la
ligne valider.
• Ajouter une ligne de la commande :
« Ajouter » ;
- Le système ajoute une ligne à remplir.
- Le pharmacien clique sur le bouton « Commander » ;
- Le système ajoute la commande et affiche un message de succès
d’ajout.
Exception Les lignes sont vides.
Tableau 5 : Raffinement du cas d'utilisation « Imprimer une commande interne »
Cas d’utilisation Imprimer une commande interne.
Acteur Pharmacien.
Postcondition Commande interne imprimée.
Description du
scénario
- Le pharmacien ouvre l’interface de recherche d’une commande
interne ;
- Le système affiche la liste des commandes internes ;
▪ Rechercher une commande :
- Le pharmacien remplit le formulaire de recherche
selon les critères choisis (par la date début et la date
fin, par la liste des produits, par numéro de la
commande) ;
- Le système affiche le résultat selon le ou les critères choisis ;
- Le pharmacien clique sur la commande à afficher dans la liste des
commandes ;
- Le système affiche les détails de la commande choisie ;
- Le pharmacien clique sur le bouton « Imprimer » ;
- Le système affiche l’interface de l’impression ;
- Le pharmacien imprime la commande.
Exception Liste des commandes internes vide.

30
Tableau 6 : Raffinement du cas d'utilisation « Valider une commande interne »
Cas d’utilisation Valider une commande interne.
Acteur Pharmacien.
- Détails de la commande interne affichés ;
- Commande interne en état « Brouillon ».
Postcondition Commande interne validée.
Description du
scénario
- Le pharmacien clique sur le bouton « Valider » ;
- Le système modifie l’état de la commande et affiche un message
de succès de validation.
Exception - Commande interne en état « Validée » ;
- Commande interne en état « Annulée » ;
- Commande interne en état « Réceptionnée ».
“ « Gérer les livraisons internes »
La Figure 13 présente le diagramme du cas d’utilisation de la gestion des livraisons
internes.
Nous allons présenter le raffinement des cas d’utilisations de la gestion des livraisons.
(Cf. Tableau 7, Tableau 8, Tableau 9).

31
Figure 13 : Diagramme de cas d'utilisation « Gérer les livraisons internes »
Tableau 7 : Raffinement du cas d'utilisation « Ajouter une livraison interne »
Cas d’utilisation Ajouter une livraison interne.
Acteur Gestionnaire de dépôt.
- Commande interne validée
Postcondition Livraison interne ajoutée.
Description du
scénario
- Le gestionnaire de dépôt ouvre l’interface de saisie d’une
livraison interne ;
- Le système affiche la liste des commandes validées ;
- Le gestionnaire de dépôt choisit la commande à livrer ;
- Le système affiche le formulaire de saisie (liste des produits
commander, quantité commander, quantité à livrer) ;

32
- Le gestionnaire de dépôt saisie la quantité à livrer et clique sur le
bouton « Valider » ;
- Le système ajoute la livraison et affiche un message de succès
d’ajout.
Exception Liste des commandes internes validées vide.
Tableau 8 : Raffinement du cas d'utilisation « Livrer une livraison »
Cas d’utilisation Livrer une livraison.
- Livraison interne en état « Validée ».
Postcondition Livraison interne livrée.
Description du
scénario
- Le gestionnaire de dépôt ouvre l’interface de recherche d’une
livraison interne ;
- Le système affiche la liste des livraisons internes ;
▪ Rechercher une livraison :
- Le gestionnaire de dépôt remplit le formulaire de
recherche selon les critères choisis (par la date début
et la date fin, par la liste des produits, par numéro de
la livraison) ;
- Le gestionnaire de dépôt clique sur la livraison à afficher dans la
liste ;
- Le système affiche les détails de la livraison choisie ;
- Le gestionnaire de dépôt clique sur le bouton « Livrer » ;
- Le système modifie l’état de la livraison et affiche un message de
succès de la livraison.
Exception - Livraison interne en état « Brouillon » ;
- Livraison interne en état « Annulée » ;
- Livraison interne en état « Livrée ».
Tableau 9 : Raffinement du cas d'utilisation « Modifier une livraison »
Cas d’utilisation Modifier une livraison.
- Détails de la livraison interne affichés ;
- Livraison interne en état « Brouillon ».
Postcondition Livraison interne modifiée.
Description du
scénario
- Le gestionnaire de dépôt clique sur le bouton « Modifier » ;
- Le système affiche le formulaire.
- Le gestionnaire de dépôt modifie les quantités à livrer ;
- Le gestionnaire de dépôt clique sur le bouton « Valider » la
livraison ;
- Le système modifie la livraison et affiche un message de succès
de modification.
Exception - Livraison interne en état « Validée » ;

33
“ « Gérer les commandes externes »
La Figure 14 illustre le diagramme du cas d’utilisation de la gestion des commandes
externes.
Figure 14 : Diagramme de cas d'utilisation « Gérer les commandes externes »
commandes externes. (Cf. Tableau 10, Tableau 11, Tableau 12).

34
Tableau 10 : Raffinement du cas d'utilisation « Ajouter une commande externe »
Cas d’utilisation Ajouter une commande externe.
Postcondition Commande externe ajoutée.
Description du
scénario
- Le gestionnaire de dépôt ouvre l’interface de saisie d’une
commande externe ;
- Le système affiche le formulaire de saisie ;
▪ Ajouter une commande externe assistée
- Le gestionnaire de dépôt clique sur le bouton « Stock
rupture » ;
- Le système affiche une carte de la liste des produits en
rupture ;
- Le gestionnaire de dépôt saisit les quantités à
commander.
▪ Ajouter une commande externe non assistée
- Le gestionnaire de dépôt saisit les produits et les
quantités commandées ;
- Le système affiche la quantité en pharmacie et en
dépôt de chaque produit à commander ;
• Supprimer une ligne de la commande :
- Le gestionnaire de dépôt clique sur le
bouton « Supprimer » ;
• Valider une ligne de la commande :
bouton « Valider » ;
- Le système vérifie les champs et grise la
ligne à valider.
• Ajouter une ligne de la commande :
bouton « Ajouter » ;
- Le système ajoute une ligne à remplir.
- Le gestionnaire de dépôt sur le bouton « Commander » ;
- Le système ajoute la commande et affiche un message de succès
d’ajout.
Exception Les lignes sont vides.
Tableau 11 : Raffinement du cas d'utilisation « Réceptionner une commande externe »
Cas d’utilisation Réceptionner une commande externe.
- Commande externe en état « Validée ».
Postcondition Commande externe réceptionnée.
Description du
scénario
commande externe ;
- Le système affiche la liste des commandes externe ;

35
la commande) ;
- Le gestionnaire de dépôt clique sur la commande à afficher dans
la liste des commandes ;
- Le système affiche les détails de la commande choisi ;
- Le gestionnaire de dépôt clique sur le bouton « Réceptionner » ;
- Le système affiche une carte de réception avec un formulaire
contenant la liste des produits commander ;
- Le gestionnaire de dépôt choisi les produits et saisie les quantités
livrées.
- Le système ajoute une réception, vérifie s’il existe déjà une
livraison externe de cette commande sinon il la crée, modifie
l’état de la commande et affiche un message de succès de la
réception.
Exception - Commande externe en état « Brouillon » ;
- Commande externe en état « Annulée » ;
- Commande externe en état « Réceptionnée ».
Tableau 12 : Raffinement du cas d'utilisation « Modifier une commande externe »
Cas d’utilisation Modifier une commande externe.
- Détails de la commande externe affichés ;
- Commande externe en état « Brouillon ».
Postcondition Commande externe modifiée.
Description du
scénario
- Le gestionnaire de dépôt clique sur le bouton « Modifier » ;
- Le système ouvre les lignes de la commande grisée.
▪ Supprimer une ligne de la commande :
- Le gestionnaire de dépôt clique sur le bouton
« Supprimer » ;
▪ Valider une ligne de la commande :
- Le gestionnaire de dépôt modifie le produit ou la
quantité à commander et clique sur le bouton
« Valider » ;
- Le système vérifie les champs et grise la ligne à
valider.
▪ Ajouter une ligne de la commande :
- Le gestionnaire de dépôt clique sur le bouton
« Ajouter » ;
- Le système ajoute une ligne à remplir
- Le gestionnaire de dépôt clique sur le bouton « Valider » la
commande ;

36
- Le système modifie la commande et affiche un message de succès
de modification.
Exception - Commande externe en état « Validée » ;
- Commande externe en état « Réceptionnée » ;
- Commande interne en état « Réceptionnée partiellement ».
“ « Gérer les livraisons externes »
La Figure 15 présente le diagramme du cas d’utilisation de la gestion des livraisons
externes.
Figure 15 : Diagramme de cas d'utilisation « Gérer les livraisons externes »
des livraisons externes. (Cf. Tableau 13).

37
Tableau 13 : Raffinement du cas d'utilisation « Réceptionner une livraison externe »
Cas d’utilisation Réceptionner une livraison externe.
- Commande externe en état « Réceptionnée partiellement ».
Postcondition Livraison externe réceptionnée.
Description du
scénario
livraison externe ;
- Le système affiche la liste des livraisons externes ;
la livraison) ;
liste ;
- Le système affiche les détails de la livraison choisie ;
- Le gestionnaire de dépôt clique sur le bouton « Réceptionner » ;
- Le système affiche une carte de réception avec un formulaire
contenant la liste des produits commander ;
- Le gestionnaire de dépôt choisit les produits et saisit les quantités
livrées.
- Le système ajoute une réception et modifie l’état de la livraison et
affiche une vue de succès de la réception.
Exception - Livraison externe en état « Réceptionnée ».
“ « Gérer les inventaires »
La Figure 16 illustre le diagramme du cas d’utilisation de la gestion des inventaires.
Nous allons présenter le raffinement des cas d’utilisations de la gestion des inventaires.
(Cf. Tableau 14).

38
Figure 16 : Diagramme de cas d'utilisation « Gérer les inventaires »
Tableau 14 : Raffinement du cas d'utilisation « Modifier la fiche inventaire »
Cas d’utilisation Modifier la fiche inventaire.
Acteur Agent d’inventaire.
Postcondition Inventaire modifié.
Description du
scénario
- L’agent d’inventaire ouvre l’interface de recherche d’un
inventaire ;
- Le système affiche la liste des inventaires ;
▪ Rechercher un inventaire :

39
- L’agent d’inventaire remplit le formulaire de
recherche selon les critères choisit (par la date début et
la date fin, par numéro de l’inventaire) ;
- L’agent inventaire clique sur l’inventaire à afficher dans la liste ;
- Le système affiche les détails de l’inventaire choisi ;
- L’agent d’inventaire clique sur le bouton « Modifier » ;
- Le système affiche la liste des produits et ouvre le formulaire de
modification des quantités ;
- L’agent d’inventaire modifie les quantités et clique sur le bouton
« Valider » ;
- Le système modifie l’inventaire et affiche un message de succès
de modification.
Exception Liste des inventaires vide.
“ « Générer les rapports »
La Figure 17 illustre le diagramme du cas d’utilisation « Générer les rapports ».
Figure 17 : Diagramme de cas d'utilisation « Générer les rapports »
Dans cette partie, nous allons raffiner les cas d’utilisations du diagramme « Générer les
rapports ». (Cf. Tableau 15).

40
Tableau 15 : Raffinement du cas d'utilisation « Consulter l'état en stock »
Cas d’utilisation Consulter l'état en stock.
Acteur Gestionnaire.
Postcondition Rapport de l’état en stock généré.
Description du
scénario
- Le gestionnaire ouvre l’interface de l’état en stock ;
- Le système génère le rapport de l’état en stock (liste de produits et
les quantités disponible dans les dépôts et la pharmacie) et affiche
l’interface d’impression ;
- Le gestionnaire imprime le rapport.
Exception
“ « Administrer »
La Figure 18 présente le diagramme du cas d’utilisation « Administrer ».
Nous allons présenter le raffinement des cas d’utilisations « Administrer ». (Cf. Tableau
16).
Tableau 16 : Raffinement du cas d'utilisation « Activer un compte utilisateur »
Cas d’utilisation Activer un compte utilisateur.
Acteur Administrateur.
Précondition - L’utilisateur est authentifié.
- Utilisateur existe
Postcondition Utilisateur activé.
Description du
scénario
- L’administrateur ouvre l’interface de la liste des utilisateurs ;
- Le système affiche la liste des utilisateurs ;
- L’administrateur choisit l’utilisateur à activer ;
- Le système affiche les détails de l’utilisateur ;
- L’administrateur clique sur le bouton radio « Activer » et clique
sur le bouton « Enregistrer » ;
- Le système enregistre les modifications et affiche un message de
succès.
Exception L’utilisateur n’existe pas.

41
Figure 18 : Diagramme de cas d'utilisation « Administrer »
“ « Paramétrer »
La Figure 19 illustre le diagramme du cas d’utilisation « Paramétrer ».
Nous allons présenter, finalement, le diagramme du cas d’utilisations de la gestion des
produits pharmaceutiques. (Cf. Figure 20).

42
Figure 19 : Diagramme de cas d'utilisation « Paramétrer »
Remarque : pour tous les autres cas d’utilisations du diagramme « Paramétrer » ça sera
les mêmes cas que ceux qui sont présenté dans le diagramme du cas d’utilisations « Gérer les
produits pharmaceutiques ».
Nous allons décrire le cas d’utilisations illustré dans le diagramme « Paramétrer ». (Cf.
Tableau 17).

43
Figure 20 : Diagramme de cas d'utilisation « Gérer les produits pharmaceutiques »
Tableau 17 : Raffinement du cas d'utilisation « Ajouter un produit »
Cas d’utilisation Ajouter un produit.
Postcondition Produit ajouté.
Description du
scénario
- L’administrateur ouvre l’interface de gestion des produits ;
- Le système affiche la carte d’ajout ;
- L’administrateur remplit le formulaire et clique sur le bouton
« Ajouter » ;
- Le système vérifie les champs vides et ajoute le produit.
Exception Les champs sont vides.
Le reste des raffinements sera présenté dans l’Annexe A.

44
5. Prototypage des interfaces
Cette étape consiste à préparer quelques interfaces graphiques de l’application en
utilisant un outil de conception des prototypes afin de mesurer le degré de satisfaction du client
par rapport à la compréhension du projet. L’interaction qui se produit entre l’utilisateur final et
l’équipe du projet, à la suite de la discussion sur ces interfaces, permet d’ajuster les besoins et
de les concevoir de manière précise et exacte. En effet, les interfaces graphiques font que
l’utilisateur final soit plus interactif, précis et le pousse à mieux s’exprimer. La Figure 21,
présente un prototype d’interface du détail d’une commande interne
Figure 21 : Prototype d’interface du détail d'une commande interne
Conclusion
Dans ce chapitre, nous avons passé en revue par les différentes notions nécessaires à la
compréhension de notre sujet. Nous avons présenté notre projet dans son environnement. Par
la suite, nous avons mené une étude de notre méthodologie, ainsi que l’identification des
besoins fonctionnels et non fonctionnels et le diagramme des cas d’utilisations général et ses
raffinements nécessaires.

Chapitre II : Conception
45
Introduction
Ce chapitre a pour objectif principal de concevoir la solution retenue lors de l’analyse
de l’application, de modéliser le problème d’une façon orientée objet et de décrire d’une
manière détaillée la conception des différents cas d’utilisation. En effet, cette partie du rapport
sera consacrée pour les diagrammes d’UML.
I. Diagrammes de séquences
Dans cette partie, nous mettons l’accent sur les diagrammes de séquences qui
représentent les interactions entre objets en indiquant la chronologie des échanges. Cette
représentation peut se réaliser par cas d’utilisation en considérant les différents scénarios
associés.
Définition : « Le diagramme de séquence décrit les interactions entre un groupe d’objets en
montrant, de façon séquentielle, les envois de message qui interviennent entre les objets. Le
diagramme peut également montrer les flux de données échangées lors des envois de
message. » [14]
Les objets d’analyse sont des instances de classes d’analyse qui représentent les
éléments majeurs ayant des comportements et des responsabilités pour le système. On distingue
trois types d’objet :
▪ Les objets d’interfaces : Ils représentent l’interface qui est en interaction directe
avec l’utilisateur.
▪ Les objets de contrôles : Ils représentent les activités système. Ces objets dirigent
les activités des entités et d’interfaces.
▪ Les objets d’entités : Ce sont des entités persistantes au système (tel que les
tables de la base de données).
1. Diagramme de séquence « S'authentifier »
La Figure 22 montre le diagramme de séquence de l’authentification.

46
Figure 22 : Diagramme de séquence « S’authentifier »

47
“ Description textuelle du diagramme de séquence « S’authentifier »
▪ Acteur : Tous les acteurs.
▪ Précondition : Serveur disponible.
▪ Postcondition : Utilisateur authentifié.
▪ Description du scénario :
 Scénario normal :
1. L’utilisateur accède à l’interface d’Authentification et saisit son login
et son mot de passe.
2. Les données saisies lors de la demande de connexion seront envoyées
vers le contrôleur « login » qui va vérifier l’existence de l’utilisateur
dans l’entité « Utilisateur ».
3. L’entité « Utilisateur » envoie au contrôleur de connexion l’objet
Utilisateur qui à son tour vérifie le mot de passe.
4. Le contrôleur demande la liste des rôles de l’utilisateur courant.
5. L’entité « Rôle » envoie la liste des rôles de l’utilisateur demandé.
6. Le contrôleur crée le « token » de l’utilisateur et redirige la page vers
l’interface d’accueil.
 Scénario d’erreur :
A. Login erroné. L’enchainement de A démarrera du point 3 du scénario
normal.
4. L’entité « Utilisateur » envoie un objet nul.
5. Un message d’erreur est envoyé à l’interface de connexion.
B. Mot de passe incorrecte. L’enchainement de B démarrera du point 3 du
scénario normal.
4. Un message d’erreur est envoyé à l’interface de connexion.
2. Diagramme de séquence « Ajouter une prescription »
La Figure 23 illustre le diagramme de séquence d’ajout d’une prescription.

48
Figure 23 : Diagramme de séquence « Ajouter une prescription »

49
“ Description textuelle du diagramme de séquence « Ajouter une prescription »
▪ Acteur : Préparateur, Pharmacien.
▪ Précondition : L’utilisateur est authentifié, agent existe.
▪ Postcondition : Prescription ajoutée, distribution crée.
▪ Description des scénarios :
1. Le préparateur demande d’ajouter une prescription.
2. Le contrôleur demande le type et l’état de la journée.
3. L’entité « Day » envoie au contrôleur la liste des journées ouverte.
4. Le contrôleur vérifie le type de la journée ouverte et permet l’affichage
de l’interface d’ajout et demande la liste des districts.
5. L’entité « District » envoie la liste des districts qui sera affichée dans
l’interface d’ajout.
6. Le préparateur saisit la matricule de l’agent.
7. Le contrôleur demande l’objet « Agent ».
8. L’entité « Agent » envoie l’objet au contrôleur qui vérifie à son tour le
résultat envoyé et demande la liste des produits.
9. L’entité « Product » envoie la liste des produits qui sera affiché.
10. Le contrôleur demande la liste des prescriptions de l’agent sélectionné
et la liste des distributions.
11. Les deux entités « Prescription » et « Distribution » envoie leurs
résultats.
12. Le préparateur remplit les lignes de la prescription.
13. L’interface envoie les données saisies au contrôleur qui a son tour
vérifie les règles de gestion.
14. Le contrôleur demande l’ajout de l’entête de la prescription.
15. Le contrôleur demande l’insertion des lignes de la prescription dans
l’entité « PrescriptionLine ».
16. L’entité « Prescription » retourne le résultat de l’insertion.
17. Le contrôleur demande l’ajout de l’entête de la distribution et ces lignes,
la modification de la quantité en stock et l’ajout du nouveau
mouvement.
18. L’entité « Distribution » envoie le résultat de l’ajout.

50
19. Le contrôleur affiche l’interface d’impression de la prescription.
A. Aucune journée ouverte. L’enchainement de A démarrera du point 4 du
scénario normal.
5. L’interface ne s’affiche pas.
B. Matricule de l’agent incorrecte. L’enchainement de B démarrera du
point 8 du scénario normal.
9. Un message de vérification du matricule de l’agent est envoyé à
l’interface d’ajout.
C. Les règles de gestion ne sont pas vérifiées. L’enchainement de C
démarrera du point 13 du scénario normal.
14. Un message d’erreur est envoyé à l’interface d’ajout.
3. Diagramme de séquence « Ajouter une commande interne »
La Figure 24 présente le diagramme de séquence d’ajout d’une commande interne.
“ Description textuelle du diagramme de séquence « Ajouter une commande interne »
▪ Acteur : Pharmacien.
▪ Précondition : L’utilisateur est authentifié.
▪ Postcondition : Commande interne ajoutée.
1. Le pharmacien demande d’ajouter une commande interne.
de l’interface d’ajout d’une commande interne.
5. Le contrôleur demande la liste des types de produits et la liste des
emplacements.
6. Le pharmacien choisi le type des produits à commander.
7. L’interface envoie le choix du pharmacien au contrôleur qui à son tour
demande la liste des produits selon le type choisi.
8. L’entité « Product » envoie la liste des produits.

51
9. Le pharmacien choisi l’assistance de la commande à crée et saisi la liste
des produits et les quantités commandés.
10. L’interface envoie ces données au contrôleur qui à son vérifie les règles
de gestion.
11. Le contrôleur demande l’ajout de l’entête de la commande ainsi que ces
lignes.
12. L’entité « InternalOrder » envoie la réponse suite à ajout.
13. Le contrôleur envoie un message de succès d’ajout à l’interface.
scénario normal.
B. Le pharmacien choisi de crée une commande assistée. L’enchainement
de B démarrera du point 9 du scénario normal.
10. Le contrôleur demande la liste des produits en rupture.
11. L’entité « Stock » envoie la liste des produits au contrôleur qui à
son tour demande l’affichage de la liste.
12. Le pharmacien choisi les produits à commander et saisie les
quantités.
13. L’interface envoie ces données au contrôleur qui à son tour
demande l’ajout de l’entête de la commande et ces lignes.
14. L’entité « InternalOrder » envoie la réponse suite à l’ajout.
15. Le contrôleur envoie un message de succès d’ajout à l’interface
11. Le contrôleur envoie un message d’erreur à l’interface d’ajout.

52
Figure 24 : Diagramme de séquence « Ajouter une commande interne »

53
4. Diagramme de séquence « Livrer une livraison »
La Figure 25 montre le diagramme de séquence « Livrer une livraison ».
“ Description textuelle du diagramme de séquence « Livrer une livraison »
▪ Acteur : Gestionnaire de dépôt.
▪ Précondition : L’utilisateur est authentifié, livraison interne à l’état validée.
▪ Postcondition : Livraison interne livrée.
1. Le gestionnaire de dépôt demande d’afficher la liste des livraisons
internes.
de l’interface « Liste des livraisons internes ».
5. Le contrôleur demande la liste des livraisons internes et leurs lignes
ainsi que les commandes internes et leurs lignes.
6. Le gestionnaire de dépôt choisi la livraison à afficher.
7. L’interface affiche les détails de la livraison sélectionnée.
8. Le gestionnaire de dépôt clique sur le bouton « Livrer ».
9. L’interface envoie le nouvel état au contrôleur qui à son tour demande
le changement de l’état de la livraison, ajoute un mouvement en stock
et modifie les quantités en stock.
10. L’entité « InternalDelivery » retourne le résultat au contrôleur.
11. Le contrôleur envoie un message de succès de livraison à l’interface.
scénario normal.

54
Figure 25 : Diagramme de séquence « Livrer une livraison »

55
5. Diagramme de séquence « Ajouter une commande externe »
La Figure 26 présente le diagramme de séquence d’ajout d’une commande externe.
Figure 26 : Diagramme de séquence « Ajouter une commande externe »

56
“ Description textuelle du diagramme de séquence « Ajouter une commande externe »
▪ Postcondition : Commande externe ajoutée.
1. Le gestionnaire de dépôt demande d’ajouter une commande externe.
de l’interface d’ajout d’une commande externe.
5. Le contrôleur demande la liste des produits et la liste des emplacements.
6. Le gestionnaire de dépôt choisi l’assistance de la commande à crée et
saisi la liste des produits et les quantités commandés.
7. L’interface envoie ces données au contrôleur qui à son vérifie les règles
de gestion.
8. Le contrôleur demande l’ajout de l’entête de la commande ainsi que ces
lignes.
9. L’entité « ExtarnalOrder » envoie la réponse suite à ajout.
scénario normal.
B. Le gestionnaire de dépôt choisi de crée une commande assistée.
L’enchainement de B démarrera du point 6 du scénario normal.
7. Le contrôleur demande la liste des produits en rupture.
8. L’entité « Stock » envoie la liste des produits au contrôleur qui à
son tour demande l’affichage de la liste.
9. Le gestionnaire choisi les produits à commander et saisie les
quantités.
10. L’interface envoie ces données au contrôleur qui à son tour
demande l’ajout de l’entête de la commande et ces lignes.
11. L’entité « ExternalOrder » envoie la réponse suite à l’ajout.

57
12. Le contrôleur envoie un message de succès d’ajout à l’interface
6. Diagramme de séquence « Réceptionner une livraison externe »
La Figure 27 illustre le diagramme de séquence « Réceptionner une livraison externe ».
“ Description textuelle du diagramme de séquence « Réceptionner une livraison
externe »
▪ Précondition : L’utilisateur est authentifié, commande externe à l’état
partiellement réceptionnée.
▪ Postcondition : Livraison externe réceptionnée.
externes.
de la liste des livraisons externes.
5. Le contrôleur demande la liste des commandes externes et leurs lignes,
la liste des livraisons externes, la liste des produits.
7. L’interface affiche la livraison.
8. Le gestionnaire de dépôt clique sur le bouton « Réceptionner » et saisie
les quantités réceptionnées.
9. L’interface envoie ces données au contrôleur qui a son tour demande
l’ajout de l’entête de la réception et ces lignes, ajoute un mouvement et
modifie les quantités en stock.
10. L’entité « Reception » envoie la réponse suite à l’ajout d’une réception
au contrôleur.

58
scénario normal.
Figure 27 : Diagramme de séquence « Réceptionner une livraison externe »

59
7. Diagramme de séquence « Editer la fiche inventaire »
La Figure 28 montre le diagramme de séquence d’édition de la fiche inventaire.
Figure 28 : Diagramme de séquence « Editer la fiche inventaire »

60
“ Description textuelle du diagramme de séquence « Editer la fiche inventaire »
▪ Acteur : Agent inventaire.
▪ Postcondition : Inventaire éditée.
1. L’agent inventaire demande d’afficher l’interface d’édition
d’inventaire.
de l’interface d’édition d’inventaire.
5. Le contrôleur demande la liste des produits, la liste des emplacements
et les quantités en stock.
6. L’agent inventaire enregistre la fiche.
7. L’interface envoie la fiche inventaire au contrôleur qui a son tour
demande l’ajout de l’entête de la fiche ainsi que ces lignes.
8. L’entité « Inventory » envoie un message de réponse suite à l’ajout au
contrôleur.
scénario normal.
8. Diagramme de séquence « Ajouter un produit »
La Figure 29 présente le diagramme de séquence d’ajout d’un produit.

61
Figure 29 : Diagramme de séquence « Ajouter un produit »
“ Description textuelle du diagramme de séquence « Ajouter un produit »
▪ Acteur : Administrateur.
▪ Postcondition : Produit ajouté.

62
1. L’administrateur demande d’afficher la liste des produits.
2. Le contrôleur demande la liste des produits, la liste des types de
produits, la liste des dci, la liste des classe pharmaceutiques, la liste des
formes, la liste des unités des distributions, la liste des présentations et
la liste des dosages.
3. Les entités envoient leurs listes.
4. L’administrateur saisie les informations et choisi le type, le dci, la
formes, etc.
5. L’interface envoie au contrôleur les données qui a son tour vérifie les
règles de gestion.
6. Le contrôleur demande l’ajout du produit
7. L’entité « Product » envoie un message de réponse.
8. Le contrôleur envoie à l’interface un message de succès d’ajout.
A. Les règles de gestion ne sont pas vérifiées. L’enchainement de C
Le reste des diagrammes de séquence sera présenté dans l’Annexe B.
II. Diagrammes d’états
Définition : « Le diagramme d’états représente le cycle de vie commun aux objets d’une même
classe. Ce diagramme complète la connaissance des classes en analyse et en conception. » [11].
1. Diagramme d’états de l’objet « Prescription »
La Figure 30 illustre le diagramme d’états de l’objet « Prescriptions ».

63
Figure 30 : Diagramme d’états « Prescriptions »
“ Description textuelle du diagramme d’états « Prescriptions »
L’objet prescription étant initialisé et suite à un événement de création, l’objet
commence à l’état crée et après une vérification de la périodicité, on se trouve à deux cas, soit
à une périodicité vrai qui nous mène à l’état distribuée partiellement, soit à une périodicité faux
de la prescription qui nous file à l’état distribuée. A ce stade-là (l’état distribuée partiellement),
l’objet est face à un des deux événements. Soit il procède l’événement distribuer et passe à l’état
distribuée et par la suite l’état finale si cette condition est vérifiée « la quantité prescrite de
chaque ligne est égale à la quantité distribuée », soit il procède l’événement annuler et par la
suite l’état final.
2. Diagramme d’états de l’objet « Commande Interne »
La Figure 31 présente le diagramme d’états de l’objet « Commande Interne ».
Figure 31 : Diagramme d’états « Commande Interne »

64
“ Description textuelle du diagramme d’états « Commande Interne »
Etant initialisé, l’objet commande interne après l’événement « créer » passe à l’état
brouillon qui permet sa modification ou, soit de déclencher l’événement « annuler » qui procède
l’état annulée, celle qui mène à sa finalisation, soit de déclencher l’événement « valider » qui
procède l’état validée, là on est directement face à l’état réceptionnée qui suit l’événement livrer
et automatiquement son état final.
3. Diagramme d’états de l’objet « Livraison Interne »
La Figure 32 montre le diagramme d’états de l’objet « Livraisons Interne »
Figure 32 : Diagramme d’états « Livraison Interne »
“ Description textuelle du diagramme d’états « Livraison Interne »
Si la commande interne est à l’état validée, on peut créer et initialiser un objet
« Livraisons Interne » qui peut être modifié dans son état brouillon, valider ou annuler qui est
pratiquement l’état final de la livraison interne. S’il est à l’état validée, il peut passer à livrée
après l’événement livrer et ainsi, il sera à son état final.
4. Diagramme d’états de l’objet « Commande Externe »
La Figure 33 illustre le diagramme d’états de l’objet « Commande Externe »

65
Figure 33 : Diagramme d’états « Commande Externe »
“ Description textuelle du diagramme d’états « Commande Externe »
L’objet commande externe, étant initialisé, passe à l’état brouillon suite à l’événement
de création et là il peut, soit être modifié, soit annulé, soit validé. Prenant maintenant le cas où
il est annulé, l’objet prend l’état annulée et c’est automatiquement son état final et prenant le
cas où il est à l’état validée. Ça peut déclencher un des deux événements, soit réceptionner et
prend l’état réceptionner partiellement et à cette état une action d’entrée doit être faite, une
vérification de l’existence de l’objet « livraison externe » sinon sa création par l’action « ouvrir
livraison externe », soit il prend l’état réceptionnée et si seulement si cette condition est vérifier
« La quantité commandée est égale à la quantité livrée de chaque ligne de la commande » et à
cette état une action d’entrée est déclencher « fermer la livraison externe ». N’oublions pas que
la commander externe peut être passé de l’état réceptionnée partiellement à l’état réceptionnée
suite à l’événement « fermer ».
5. Diagramme d’états de l’objet « Livraison Externe »
La Figure 34 présente le diagramme d’état de l’objet « Livraisons Externe »
Figure 34 : Diagramme d’états « Livraison Externe »

66
“ Description textuelle du diagramme d’états « Livraison Externe »
L’objet « Livraisons externe » peut prendre l’état réceptionnée partiellement suite à
l’événement ouvrir et si seulement si la commande externe est à l’état réceptionnée
partiellement. Aussi l’événement fermer peut-être fait si la commande externe est à l’état
réceptionné, autrement, la quantité commandée est égale à la quantité livrée de chaque ligne de
la commande ».
III. Diagrammes de classes
Le diagramme de classes constitue l’un des pivots essentiels de la modélisation avec
UML. En effet, ce diagramme permet de donner la représentation statique du système à
développer. Cette représentation est centrée sur les concepts de classe et d’association.
Définition : « Le diagramme de classes présente un ensemble de classeurs. Il décrit les classes
et leurs relations. Il peut également décrire les regroupements de classes en paquetages, les
interfaces et les objets, les classes qui participent à une collaboration ou qui réalisent un cas
d’utilisation ». [15]
La Figure 35 illustre le diagramme de classes, ainsi que la Figure 36 montre le
diagramme de classes orienté données.
Remarque : Les classes colorées en bleu sont celles du schéma global de l’ERP médical
que nous œuvrons à mettrons en place. Ces classes seront utilisées par les autres modules et qui
sont : « Product » ; « Day » ; « DayTpe » ; « State » ; « Location » ; « Agent » ;
« District » ; « Dci » ; « Dosage » ; « Form » ; « Type » ; « Presentation » ;
« DistributionUnit » et la classe « « PharmaClass ».

67
Figure 35 : Diagramme de classes

68
Figure 36 : Diagramme de classes orientée données

69
Conclusion
Dans ce chapitre, nous avons mis l’accent sur la partie de la conception en commençant
par les diagrammes de séquences. Par la suite, les diagrammes d’états ainsi que le diagramme
de classe.

Chapitre III : Réalisation
70
Introduction
Ce chapitre vise à présenter, dans un premier temps, l’architecture matérielle et
applicative de notre projet puis l’environnement logiciel dont les Frameworks et les langages
utilisés et finissons par l’implémentation et le code.
I. Environnement matériel
Dans cette partie, nous allons identifier l’architecture matérielle que nous avons utilisés
pour de notre projet et l’architecture applicative de notre application dont la partie frontend et
backend, ainsi que le déploiement de notre application.
1. Architecture matérielle
Notre application se présente sous la forme d’une architecture trois tiers ou ce qu’on
appelle également architecture à trois niveaux. L’architecture trois tiers est l’application du
modèle le plus général qui est le multi-tiers et c’est également une extension du modèle
client/serveur. Plus spécifiquement c’est une architecture partagée entre : [16]
▪ Un client : L’ordinateur demandeur de ressources, équipé d’une interface
utilisateur (généralement un navigateur web) chargé de la présentation.
▪ Un serveur d’application : Chargé de fournir la ressource mais faisant appel à
un autre serveur.
▪ Un serveur de base de données : Fournissant au serveur d’application les
données dont il a besoin. Etant donné l’emploi massif du terme de l’architecture à 3
niveaux, celui-ci peut parfois désigner aussi les architectures suivantes :
- Partage d’application entre client, serveur intermédiaire, et serveur d’entreprise.
- Partage d’application entre client, serveur d’application, et serveur de base de
données de l’entreprise.
La Figure 37 illustre l’architecture de notre application dont ces trois niveaux.

71
Figure 37 : Architecture de l'application
De ce fait, notre application se base sur deux serveurs :
▪ Serveur de base de données – PostgreSQL : c’est l’un des principaux Systèmes
de Gestion de Bases de Données Relationnelles (SGBD-R) du marché. Il est libre et
gratuit sous la licence Berkeley Software Distribution4
(BSD) [17]. Se caractérise par
sa fiabilité et stabilité, ne craint pas les bases de données de grande taille et fonctionne
sur les principales plateformes Unix du marché. [18]
▪ Serveur Web : notre serveur web se compose de deux serveurs, un serveur
d’application Java pour le backend et un serveur d’application JavaScript
- Serveur d’application Java – Pivotal tc Server : c’est un serveur HTTP
permet l’exécution des applications Spring Java, connu par sa compatibilité
avec le serveur Apache Tomcat et sa simplicité et performance. [19]
- Serveur d’application JavaScript – Node.js : c’est un outil permettant de
mettre en place une application web. NodeJS est une plateforme construite sur
le moteur JavaScript V8 de Chrome. Il se distingue des autres plateformes
grâce à une approche non bloquante permettant d'effectuer des entrées/sorties
de manière asynchrone. [20]
4
Une licence libre utilisée pour la distribution de logiciels. Elle sert à réutiliser tout ou partie du logiciel sans
restriction, qu'il soit intégré dans un logiciel libre ou propriétaire.

72
Présentons alors l’architecture matérielle de notre application par un diagramme de
déploiement qui englobe les nœuds correspondant aux supports physiques comme le montre la
Figure 38.
Figure 38 : Diagramme de déploiement
Définition : « Le diagramme de déploiement permet de représenter l’architecture physique
supportant l’exploitation du système. Cette architecture comprend des nœuds correspondant
aux supports physiques (serveurs, routeurs, …) ainsi que la répartition des artefacts logiciels
(bibliothèques, exécutables, …) sur ces nœuds. C’est un véritable réseau constitué de nœuds et
de connexions entre ces nœuds qui modélisent cette architecture. » [21]
La modélisation du déploiement de note application montre trois couches :
▪ Couche accès aux données : c’est la partie qui prend en charge la communication
avec le serveur de la base de données via la Java Persistence API (JPA), c’est la
couche persistance.
▪ Couche métier : celle qui communique avec la couche persistance via les
annotations et se compose de de deux nœuds, l’une dont les web service sont
implémenter et prêt à consommer et l’autre dont les contrôleurs des services sont
implémenter.

73
▪ Couche présentation : c’est la partie frontend, elle se compose de trois nœuds,
l’une est notre vue dont les Template HTML sont implémenter, l’autre est le modèle
dont la partie service qui prend en charge la communication avec le backend via l’api
REST et qui est injecter dans les composant qui forme la VueModèle.
2. Architecture applicative
Les applications Web évoluent, en passant par des multiples technologies de sites Web
dynamiques (PHP, ASP, Java), plusieurs architectures applicatives et des outils avancés. Une
nouvelle vague technologique qui submerge le paysage des applications Web, s’appelle «
architecture MV* côté client » [22], utilise principalement ce principe d’architecture : le serveur
ne doit plus gérer l’affichage mais seulement envoyer des données brutes à afficher, et toute la
génération des écrans et la gestion des interactions avec l’utilisateur doivent être gérées côté
client.
La Figure 39 illustre l’évolution de l’architecture des applications web.
Figure 39 : Evolution de l’architecture des applications web

74
Dans le premier modèle, l’application Web est principalement exécutée côté serveur et
ce dernier l’envoie directement au navigateur les pages HTML, le CSS, à chaque action le
serveur est interrogé et renvoie la nouvelle page HTML.
Le deuxième modèle introduit le patron de AJAX, Ce principe d’architecture permet de
rendre l’application plus réactive en réduisant les échanges entre le navigateur et le serveur.
Chaque action nécessite de récupérer des nouvelles données, une partie de la page rafraîchis et
non plus toute la page. Le serveur envoie seulement des fragments d’IHM. Cela est nécessite la
mise en place d’outils JavaScript côté client pour gérer ces rafraîchissements partiels.
Le troisième modèle présente la nouvelle architecture MV* côté client. Le serveur ne
renvoie que des données brutes non mises en forme pour l’affichage, côté client, dans le
navigateur, que l’IHM est généré. Le terme MV* se réfère au patron Modèle-Vue-Contrôleur
(MVC) pour Modèle Vue Contrôleur, qui est très utilisé côté serveur pour découper les
différentes problématiques de gestion des vues et des données. L’important dans cette nouvelle
architecture est donc le déplacement de toute la logique d’IHM du serveur vers le client. Cette
séparation des responsabilités entre le serveur et le client rendre l’intégration élémentaire d’une
maquette structurée plus facile et simplifie l’identification des problèmes de rendu en
concentrant ses efforts sur le contenu plutôt que sur la structure initiale, aussi elle permet au
navigateur d’effectuer le rendu des éléments plus rapidement et amène plus de souplesse vis-à-
vis des autres intervenants dans l’application.
a. Architecture frontend - Angular
AngularJS est un JavaScript Framework conçu par Google permet l’ajout des balises
HTML avec des balises script étend les attributs HTML avec Directives et lie les données au
format HTML avec expressions. Une infrastructure Modèle-Vue-VueModèle (MVVM) qui est
conçue pour construire des applications web, et moins des sites web. Google parle même
d'infrastructure Model-View-Whatever (MVW). Le principe du MVVM, c’est que les données
que les clients saisis engendrent une mise à jour du contrôleur qui met à jour par ricochet la
vue. Et pas besoin de Template temporaire de pré génération. AngularJS utilise directement la
vue HTML d'origine pour répercuter ces mises à jour.
Un facteur majeur de renforcement de cette architecture, c’est de mutualiser le code du
backend pour de multiples clients. La Figure 40 présente un schéma valorisation la
mutualisation du code backend.

75
Figure 40 : Architecture frontend
Un atout majeur de cette architecture est la mise en place d’une Interface de
Programmation Applicative (API) : orientée fonctionnel et développée dans une technologie
standard comme JSON sur HTTP, afin de rendre l’application utilisable par de nombreux autres
clients que le client Web initiale.
De plus, c’est un patron d’architecture utilisé par les applications mobiles. Cependant
avec une architecture Web MVC côté serveur, on n’a plus besoin d’une couche générateur des
IHM. On a qu’à consommer directement les services de l’API.
Cette architecture a pour avantage de :
▪ Améliorer la productivité des développements ;
▪ Produire des applications Web plus puissantes, plus riches, plus ergonomiques ;
▪ Remplacer une application lourde complexe ;
▪ Création des équipes par technos frontend et backend. [23]

76
b. Architecture backend – Spring
Spring est Framework Java conçu comme une sorte de boîte à outils disponible sous
deux formes, celle d'un jar (librairie Java) unique et celle de plusieurs fichiers jar permettant de
ne rajouter au projet que la partie que l'on souhaite utiliser.
Spring est organisé en modules, reposant tous sur le module Spring Core :
▪ Spring Core : implémente notamment le concept d'inversion de contrôle
(injection de dépendance). Il est également responsable de la gestion et de la
configuration du conteneur.
▪ Spring Context : Ce module étend Spring Core. Il fournit une sorte de base de
données d'objets, permet de charger des ressources (telles que des fichiers de
configuration) ou encore la propagation d'évènements et la création de contexte.
▪ Spring AOP : Permet d'intégrer de la programmation orientée aspect.
Spring se base sur l’architecture multicouche et se compose de trois couches qui sont :
▪ Une couche présentation : qui peut être Spring MVC, Struts.
▪ Une couche métier : qui en l'occurrence est constituée de Plain Old Java Object
(POJO)
▪ Une couche d'accès aux données : qui peut être JDBC, Hibernate, JDO, etc.
Comme le présente la Figure 41, Spring se base sur trois parties, le web service, le
registre et le service implémenté. Son principe de fonctionnement est que Web-Application fera
la demande au service en utilisant une API RESTful et un registre découverte de service doit
être présent, de sorte que les autres services peuvent s’y trouver.

77
Figure 41 : Architecture Spring
II. Environnement logiciel
Dans cette partie, nous allons présenter les outils logiciels utilisés à l’implémentation de
notre projet.
1. Outils de conception
Enterprise Architect est un logiciel de conception UML,
édité par Sparx Systems. Couvrant, par ses fonctionnalités,
l’ensemble des étapes du cycle de conception d’application. Nos
diagrammes de cas d’utilisation, de séquence, de classe, ont été
réalisés à l’aide de ce logiciel. [24]
2. Outils de développement
Spring Tool Suite est environnement de développement
intégré basée sur mesure tout-en-un Eclipse comporte les outils
nécessaires tel que Maven et Gradle et le cadre d’exécution des
applications Java EE tel que Pivotal tc Server. [25]

78
Visual Studio Code est un éditeur de code source gratuit,
conçu par Microsoft permet d'éditer et de débugger votre code, il
intègre tous outils nécessaires tels que Git et supporte une douzaine
de langages différents avec une petite préférence pour ASP.net et
NodeJS. [26]
3. Outils de système de gestion de la base de données
PgAdmin est un outil d'administration graphique pour
PostgreSQL distribué selon les termes de la licence PostgreSQL,
pris en charge sur de nombreuses plates-formes et l’outil de requête
comprend un langage de script appelé pgScript pour
l'administration des tâches d'administration et de développement.
[27]
4. Outils de travail collaboratif
Git est un logiciel de gestion de version décentralisée,
assujetti au terme de la licence GPL-2, il permet de gérer des
codes sources en suivant l’évolution d’un fichier de code ligne par
ligne de code. [28]
Bitbucket est un service web d’hébergement de gestion de
développement de logiciel. Il permet le contrôle de version et
facilite le travail collaboratif, aussi il permet les révisions du code
avec des pullrequest et offre l’outil « SourceTree » qui simplifie
les interactions avec l’espace de dépôt Git et Mercurial grâce à son
interface graphique [29]

79
Jira est système de suivi des bugs et de gestion de projet
développé par Atlassian. Il permet de planifier les tâches à faire,
les suivre, et les affecter aux membres et en plus, il permet de
générer des rapports de performances de l’équipe. [30]
5. Framework
Angular 2 est la nouvelle version améliorée du Framework
JavaScript AngularJS. Il favorise une architecture basée sur les
composants en exploitant les nouvelles fonctionnalités de ES2015
ou TypeScript comme les classes et les modules. [31]
Spring boot est un Framework Spring libre sous la licence
GPL-2 utilisé avec la norme J2EE. Il est identifié comme étant un
conteneur léger et permet de faciliter la programmation en Java
avec les POJO et développer des microservices REST. [32]
Bootstrap est une collection d'outils utile à la création du
design de sites et d'applications web. C'est un ensemble qui
contient des codes HTML et CSS, des formulaires, etc. [33]
6. Langages de programmation
TypsScript est un langage de programmation libre et open-
source développé par Microsoft qui a pour but d'améliorer et de
sécuriser la production de code JavaScript. C'est une extension de
JavaScript. Le code TypeScript est transcompilé en JavaScript et
interprété par n'importe quel navigateur web ou moteur JavaScript
en une deuxième étape. [34]

80
HTML 5 est un langage de balise des applications web,
sans toutefois délaisser l’accessibilité et la sémantique. Il se
positionne également comme concurrent des technologies Flash et
Silverlight et permet à des applications de s’exécuter en mode hors-
ligne. [35]
CSS 3 est un langage de programmation qui sert à décrire
la présentation des documents HTML et XML. Les standards
définissent CSS sont publiés par le W3C. il est aussi utilisé dans la
conception de sites web et bien pris en charge par les navigateurs
web. [36]
Java est un langage de programmation informatique orienté
objet rachetée en 2009 par la société Oracle. Il se caractérise par sa
portabilité sur plusieurs systèmes d’exploitation et a permis la
naissance de plusieurs Framework tels que Struts, Spring, JSF, etc.
III. Implémentation et code
Cette partie, sera consacrée à présenter les interfaces de notre application. Dans un
premier temps, nous allons présenter l’interface du registre de découverte des services
implémenter (Cf. Figure 42, Figure 43).

81
Figure 42 : Interface du registre de découverte Swagger
Figure 43 : Interface du résultat du service « ListInternalOrder »
La Figure 44 présente l’ajout d’un compte utilisateur et la Figure 45 illustre la liste des
opération faites sur le système. Celle c’est la partie d’administration.

82
Figure 44 : Interface d'ajout d'un utilisateur
Figure 45 : Interface de la liste des opérations effectuées sur la base de données
Les Figure 46, Figure 47 etFigure 48 montrent respectivement l’interface de la liste des
produits, l’interface de la gestion des DCI et l’interface d’ajout d’un produit pharmaceutique.
Cette partie présente le paramétrage de notre ERP.

83
Figure 46 : Interface de la liste des produits
Figure 47 : Interface de la gestion des DCI

84
Figure 48 : Interface d'ajout d'un produit
La Figure 49 illustre l’interface d’ajout d’une prescription.
Figure 49 : Interface d'ajout d'une prescription
Les Figure 50, Figure 51, Figure 52 et Figure 53 présentent respectivement l’interface
de la liste et la recherche des livraisons internes, l’interface de la modification d’une livraison

85
interne, l’interface d’ajout d’une commande interne et l’interface de la liste et recherche des
livraisons externes.
Figure 50 : Interface de la liste et recherche des livraisons internes
Figure 51 : Interface de modification d'une livraison interne

86
Figure 52 : Interface d'ajout d'une commande interne
Figure 53 : Interface de la liste et recherche des livraisons externes
Conclusion
Dans ce chapitre, nous avons présenté notre environnement matériel en commençant par
l’architecture matérielle dont on a illustré le diagramme de déploiement et l’architecture
applicative côté frontend et backend. Ainsi que notre environnement logiciel dont une
présentation des différents outils utilisés.

87
Conclusion générale
Durant la période de stage, nous avons conçu et développé notre module de gestion
pharmaceutique de l’ERP médical pour la TRANSTU.
Le présent manuscrit détaille toutes les étapes par lesquelles nous sommes passées pour
arriver au résultat attendu. Nous avons essayé tout au long de notre travail de construire notre
projet en utilisant les étapes de la méthodologie UP.
Ce stage de fin d’études, nous a permis de découvrir un environnement professionnel
différent de nos expériences précédentes. Nous avons pu ainsi découvrir le travail en équipe au
sein d’un plateau de plusieurs personnes. Ensuite au niveau organisationnel, nous avons appris
à nous organiser, à utiliser des outils et des méthodes de travail collaboratif.
Malgré toutes les difficultés rencontrées au niveau du Framework du frontend, Angular
2 et du backend, Spring boot et les contraintes de temps, nous avons réussi à réaliser notre projet
tout en respectant l’aspect sécuritaire et en préparant la documentation nécessaire.
Finalement, notre travail ne s’arrête pas à ce niveau, il reste ouvert à d’autres modules
qui devront être développés pour former l’ERP médical final de la TRANSTU. En effet
plusieurs fonctionnalités peuvent être ajoutées à notre ERP notamment l’interaction dynamique
avec le module GRH en certifiant les congés de maladie par le dossier médical de l’agent, aussi
l’interconnexion avec le module de financier dont sa partie des fiches de paies en prouvant
l’absences des agents et la gestion du matériels médicaux, et même la gestion de la logistique
du service médical.

88
Annexe A : Raffinements des cas d’utilisations
Dans ce annexe nous allons présenter les raffinements des cas d’utilisations.
“ « S'authentifier »
La Figure 54 illustre le diagramme de cas d’utilisation de l’authentification.
Figure 54 : Diagramme de cas d'utilisation « S'authentifier »
Après avoir présenté le diagramme du cas d’utilisation « S’authentifier », nous allons
présenter le raffinement du cas d’utilisation. (Cf. Tableau 18).
Tableau 18 : Raffinement du cas d'utilisation « Vérifier le login et le mot de passe »
Cas d’utilisation Vérifier le login et le mot de passe.
Acteur Tous les acteurs.
Précondition Serveur disponible.
Postcondition Utilisateur authentifié.
Description du
scénario
- L’utilisateur ouvert l’interface d’authentification ;
- Le système affiche le formulaire d’authentification ;
- L’utilisateur saisie son login et son mot de passe et clique sur le
bouton de « Connexion » ;
- Le système vérifie les champs vides et le login ainsi que le mot de
passe ;
- Le système affiche la page d’accueil.
Exception - Les champs son vides ;
- Login et mot de passe incorrecte.

89
“ « Gérer les prescriptions »
prescriptions illustré par la Figure 10. (Cf. Tableau 19, Tableau 20, Tableau 21).
Tableau 19 : Raffinement du cas d'utilisation « Afficher la liste des prescriptions »
Cas d’utilisation Afficher la liste des prescriptions.
- Pharmacien.
Précondition L’utilisateur est authentifié ;
Postcondition Liste des prescriptions affichée.
Description du
scénario
- Le préparateur ouvre l’interface de recherche d’une prescription ;
- Le système affiche l’interface de la liste des prescriptions ;
▪ Rechercher une prescription :
- Le préparateur choisit les critères de recherche (par la
date début et la date fin, par une liste des produits) et
rempli le formulaire ;
choisis.
▪ Afficher la liste des prescriptions de l’agent
- Le préparateur saisie le matricule de l’agent ;
- Le système vérifie le matricule ;
- Le système affiche la liste des prescriptions de l’agent
choisi.
Exception Liste des prescriptions vide.
Tableau 20 : Raffinement du cas d'utilisation « Afficher les détails d'une prescription »
Cas d’utilisation Afficher les détails d'une prescription.
- Pharmacien.
- Liste des prescriptions affichée.
Postcondition Détails de la prescription affiché.
Description du
scénario
- Le préparateur clique sur le bouton « Détail » ;
- Le système affiche les détails de la prescription choisie.

90
Tableau 21 : Raffinement du cas d'utilisation « Imprimer une prescription »
Cas d’utilisation Imprimer une prescription.
- Pharmacien.
- Détails de la prescription affichés.
Postcondition Prescription imprimée.
Description du scénario - Le préparateur clique sur le bouton « Imprimer » ;
- Le préparateur imprime la prescription.
“ « Gérer les commandes internes »
des commandes internes comme le montre la Figure 13. (Cf. Tableau 22, Tableau 23, Tableau
24, Tableau 25, Tableau 26).
Tableau 22 : Raffinement du cas d'utilisation « Afficher la liste des commandes internes »
Cas d’utilisation Afficher la liste des commandes internes.
Acteur Pharmacien.
Postcondition Liste des commandes internes affichée.
Description du
scénario
- Le pharmacien ouvre l’interface de recherche d’une commande
interne ;
- Le système affiche la liste des commandes internes ;
- Le pharmacien remplit le formulaire de recherche
selon les critères choisit (par la date début et la date
fin, par la liste des produits, par numéro de la
commande) ;
choisis.

91
Tableau 23 : Raffinement du cas d'utilisation « Afficher les détails d'une commande interne »
Cas d’utilisation Afficher les détails d'une commande interne.
Acteur Pharmacien.
- Liste des commandes internes affichée.
Postcondition Détails de la commande interne affichés.
Description du
scénario
- Le pharmacien clique sur la commande à afficher dans la liste des
commandes ;
- Le système affiche les détails de la commande choisie.
Tableau 24 : Raffinement du cas d'utilisation « Annuler une commande interne »
Cas d’utilisation Annuler une commande interne.
Acteur Pharmacien.
Postcondition Commande interne annulée.
Description du
scénario
- Le pharmacien clique sur le bouton « Annuler » ;
de succès d’annulation.
Tableau 25 : Raffinement du cas d'utilisation « Réceptionner une commande interne »
Cas d’utilisation Réceptionner une commande interne.
Acteur Pharmacien.
- Commande interne en état « Validée ».
Postcondition Commande interne réceptionnée.
Description du
scénario
- Le pharmacien clique sur le bouton « Réceptionner » ;
de succès de la réception.
Exception - Commande interne en état « Brouillon » ;

92
Tableau 26 : Raffinement du cas d'utilisation « Modifier une commande interne »
Cas d’utilisation Modifier une commande interne.
Acteur Pharmacien.
Postcondition Commande interne modifiée.
Description du
scénario
- Le pharmacien clique sur le bouton « Modifier » ;
- Le système ouvre les lignes de la commande grisée.
▪ Supprimer une ligne de la commande :
- Le pharmacien clique sur le bouton « Supprimer » ;
▪ Valider une ligne de la commande :
- Le pharmacien modifie le produit ou la quantité à
commander et clique sur le bouton « Valider » ;
- Le système vérifie les champs et grise la ligne validée.
▪ Ajouter une ligne de la commande :
- Le pharmacien clique sur le bouton « Ajouter » ;
- Le système ajoute une ligne à remplir
- Le pharmacien clique sur le bouton « Valider » la commande ;
- Le système modifie la commande et affiche un message de succès
de modification.
“ « Gérer les livraisons internes »
Nous allons présenter le raffinement des cas d’utilisations de la gestion des livraisons
présenté la Figure 13. (Cf. Tableau 27, Tableau 28, Tableau 29, Tableau 30, Tableau 31).
Tableau 27 : Raffinement du cas d'utilisation « Afficher la liste des livraisons internes »
Cas d’utilisation Afficher la liste des livraisons internes.
Postcondition Liste des livraisons internes affichée.
Description du
scénario
livraison interne ;
- Le système affiche la liste des livraisons internes ;
la date fin, par la liste des produits, par numéro de la
livraison) ;

93
choisis.
Exception Liste des livraisons internes vide.
Tableau 28 : Raffinement du cas d'utilisation « Afficher les détails d'une livraison »
Cas d’utilisation Afficher les détails d'une livraison interne.
- Liste des livraisons internes affichée.
Postcondition Détails de la livraison interne affichés.
Description du
scénario
liste ;
- Le système affiche les détails de la livraison choisie.
Exception Liste des livraisons internes vide.
Tableau 29 : Raffinement du cas d'utilisation « Valider une livraison »
Cas d’utilisation Valider une livraison.
Postcondition Livraison interne validée.
Description du
scénario
- Le gestionnaire de dépôt clique sur le bouton « Valider » ;
- Le système valide la livraison et affiche un message de succès de
validation.
Tableau 30 : Raffinement du cas d'utilisation « Imprimer une livraison »
Cas d’utilisation Imprimer une livraison.
- Détails de la livraison interne affichés.
Postcondition Livraison interne imprimée.
Description du
scénario
- Le gestionnaire de dépôt clique sur le bouton « Imprimer » ;
- Le gestionnaire de dépôt imprime la livraison.

94
Tableau 31 : Raffinement du cas d'utilisation « Annuler une livraison »
Cas d’utilisation Annuler une livraison.
Postcondition Livraison interne annulée.
Description du
scénario
- Le gestionnaire de dépôt clique sur le bouton « Annuler » ;
- Le système modifie l’état de la livraison et affiche un message de
succès d’annulation.
Exception - Livraison interne en état « Validée » ;
“ « Gérer les commandes externes »
commandes externes illustré par la Figure 14. (Cf. Tableau 32, Tableau 33, Tableau 34, Tableau
35).
Tableau 32 : Raffinement du cas d'utilisation « Afficher la liste des commandes externes »
Cas d’utilisation Afficher la liste des commandes externes.
Postcondition Liste des commandes externes affichée.
Description du
scénario
commande externe ;
- Le système affiche la liste des commandes externe ;
commande) ;
choisis.
Exception Liste des commandes externes vide.

95
Tableau 33 : Raffinement du cas d'utilisation « Afficher les détails d'une commande externe »
Cas d’utilisation Afficher les détails d'une commande externe.
- Liste des commandes externes affichée.
Postcondition Détails de la commande externe affichés.
Description du
scénario
- Le gestionnaire de dépôt clique sur la commande à afficher dans
la liste des commandes ;
- Le système affiche les détails de la commande choisie.
Tableau 34 : Raffinement du cas d'utilisation « Imprimer une commande externe »
Cas d’utilisation Imprimer une commande externe.
- Détails de la commande externe affichés.
Postcondition Commande externe imprimée.
Description du
scénario
- Le gestionnaire de dépôt imprime la commande.
Tableau 35 : Raffinement du cas d'utilisation « Valider une commande externe »
Cas d’utilisation Valider une commande externe.
Postcondition Commande externe validée.
Description du
scénario
- Le gestionnaire de dépôt clique sur le bouton « Valider » ;
de succès de validation.
- Commande interne en état « Réceptionnée » ;

96
Tableau 36 : Raffinement du cas d'utilisation « Annuler une commande externe »
Cas d’utilisation Annuler une commande externe.
Postcondition Commande externe annulée.
Description du
scénario
- Le gestionnaire de dépôt clique sur le bouton « Annuler » ;
de succès d’annulation.
Exception - Commande externe en état « Validée » ;
- Commande externe en état « Réceptionnée » ;
“ « Gérer les livraisons externes »
Dans cette partie nous allons raffiner les cas d’utilisations du diagramme de la gestion
des livraisons externes comme le montre la Figure 15. (Cf. Tableau 37, Tableau 38, Tableau
39).
Tableau 37 : Raffinement du cas d'utilisation « Afficher la liste des livraisons externes »
Cas d’utilisation Afficher la liste des livraisons externes.
Postcondition Liste des livraisons externes affichée.
Description du
scénario
livraison externe ;
- Le système affiche la liste des livraisons externes ;
livraison) ;
choisis.
Exception Liste des livraisons externes vide.

97
Tableau 38 : Raffinement du cas d'utilisation « Afficher les détails d'une livraison externe »
Cas d’utilisation Afficher les détails d'une livraison externe.
- Liste des livraisons externes affichée.
Postcondition Détails de la livraison externe affichés.
Description du
scénario
liste ;
- Le système affiche les détails de la livraison choisie.
Tableau 39 : Raffinement du cas d'utilisation « Imprimer une livraison externe »
Cas d’utilisation Imprimer une livraison externe.
- Détails de la livraison externe affichés.
Postcondition Livraison externe imprimée.
Description du
scénario
- Le gestionnaire de dépôt imprime la livraison.
“ « Gérer les inventaires »
Nous allons présenter le raffinement des cas d’utilisations de la gestion des inventaires
présenté par la Figure 16. (Cf. Tableau 40, Tableau 41, Tableau 42, Tableau 43, Tableau 44,
Tableau 45).
Tableau 40 : Raffinement du cas d'utilisation « Editer la fiche inventaire »
Cas d’utilisation Editer la fiche inventaire.
Postcondition Inventaire édité.
Description du
scénario
- L’agent d’inventaire ouvre l’interface de saisie d’un inventaire ;
- Le système affiche la liste des produits ainsi que les quantités
disponibles en stock de la pharmacie et en stocks des dépôts ;
- L’agent d’inventaire clique sur le bouton « Editer » ;
- Le système ajoute un inventaire et affiche un message d’ajout.
Exception - Stock vide ;
- Liste des produits n’existe pas.

98
Tableau 41 : Raffinement du cas d'utilisation « Afficher la liste des fiches inventaires »
Cas d’utilisation Afficher la liste des fiches inventaires.
Postcondition Liste des inventaires affichée.
Description du
scénario
- L’agent d’inventaire ouvre l’interface de recherche d’un
inventaire ;
- Le système affiche la liste des inventaires ;
▪ Rechercher un inventaire :
- L’agent d’inventaire remplit le formulaire de
la date fin, par numéro de l’inventaire) ;
choisis.
Tableau 42 : Raffinement du cas d'utilisation « Afficher les détails d'un inventaire »
Cas d’utilisation Afficher les détails d'un inventaire.
- Liste des inventaires affichée.
Postcondition Détails de l’inventaire affichés.
Description du
scénario
- L’agent d’inventaire clique sur l’inventaire à afficher dans la liste
;
- Le système affiche les détails de l’inventaire choisi.
Tableau 43 : Raffinement du cas d'utilisation « Saisir la fiche inventaire »
Cas d’utilisation Saisir la fiche inventaire.
- Détails de l’inventaire affichés.
Postcondition Inventaire saisi.
Description du
scénario
- L’agent d’inventaire clique sur le bouton « Saisir » ;
- Le système affiche la liste des produits et le formulaire de saisie
des quantités ;
- L’agent d’inventaire saisit les quantités et clique sur le bouton
« Valider » ;
- Le système modifie l’inventaire et affiche un message de succès
de saisie.

99
Tableau 44 : Raffinement du cas d'utilisation « Imprimer la fiche inventaire »
Cas d’utilisation Imprimer la fiche inventaire.
- Détails de l’inventaire affichés.
Postcondition Inventaire imprimé.
Description du
scénario
- L’agent d’inventaire clique sur le bouton « Imprimer » ;
- L’agent d’inventaire imprime l’inventaire.
Tableau 45 : Raffinement du cas d'utilisation « Valider la fiche inventaire »
Cas d’utilisation Valider la fiche inventaire.
Acteur Responsable inventaire.
- Détails de l’inventaire affichés ;
- Inventaire rempli.
Postcondition Inventaire validé.
Description du
scénario
- Le responsable inventaire clique sur le bouton « Valider » ;
- Le système valide l’inventaire et affiche une vue de succès de
validation.
Exception - Liste des inventaires vide ;
- Inventaire non saisi.
“ « Afficher les statistiques »
La Figure 55 présente le diagramme du cas d’utilisation « Afficher les statistiques ».
Figure 55 : Diagramme de cas d'utilisation « Afficher les statistiques »

100
Nous allons décrire le cas d’utilisations illustré dans le diagramme « Afficher les
statistiques ». (Cf. Tableau 46).
Tableau 46 : Raffinement du cas d'utilisation « Afficher les statistiques »
Cas d’utilisation Afficher les statistiques.
Acteur Gestionnaire.
Postcondition Statistiques affichés.
Description du
scénario
- Le gestionnaire ouvre l’interface des statistiques ;
- Le système affiche des cartes illustrant les statistiques (répartition
de la saisie des prescriptions par jour de la semaine, répartition
des prescriptions saisie par préparateur, …).
Exception
“ « Administrer »
Nous allons présenter le raffinement des cas d’utilisations « Administrer » illustré par
la Figure 18 (Cf. Tableau 47, Tableau 48, Tableau 49, Tableau 50).
Tableau 47 : Raffinement du cas d'utilisation « Ajouter un utilisateur »
Cas d’utilisation Ajouter un utilisateur.
Postcondition Utilisateur ajouté.
Description du
scénario
- L’administrateur ouvre l’interface de saisie de l’utilisateur ;
- Le système affiche le formulaire d’ajout ;
- L’administrateur remplit le formulaire et choisit les rôles à
affecter ;
- Le système vérifie les champs vides et ajoute l’utilisateur.
Exception Les champs sont vides.
Tableau 48 : Raffinement du cas d'utilisation « Ouvrir une journée »
Cas d’utilisation Ouvrir une journée.
Postcondition Journée ouverte.
Description du
scénario
- L’administrateur affiche le calendrier et clique sur le jour dont la
journée doit être ouverte ;
- Le système affiche le formulaire d’ouverture de la journée ;
- L’administrateur choisit le type de la journée et l’état de la
journée (ouverte ou non) et clique sur le bouton « Ouvrir » ;

101
- Le système ajoute la journée et affiche le calendrier.
Exception
Tableau 49 : Raffinement du cas d'utilisation « Supprimer un utilisateur »
Cas d’utilisation Supprimer un utilisateur.
Postcondition Utilisateur supprimé.
Description du
scénario
- L’administrateur clique sur le bouton « Supprimer » ;
- Le système affiche un message de vérification de la suppression ;
- L’administrateur confirme la suppression ;
- Le système supprime l’utilisateur et affiche un message de succès
de la suppression.
Tableau 50 : Raffinement du cas d'utilisation « Modifier un utilisateur »
Cas d’utilisation Modifier un utilisateur.
Postcondition Utilisateur modifié.
Description du
scénario
- L’administrateur choisit l’utilisateur à modifier ;
- Le système affiche les détails de l’utilisateur ;
- L’administrateur clique sur le bouton « Modifier » ;
- Le système ouvre le formulaire de modification ;
- L’administrateur modifie les champs nécessaires et clique sur le
bouton « Enregistrer » ;
- Le système vérifie les champs vides et enregistre les
modifications.

102
Annexe B : Diagramme de séquence
Dans ce annexe nous allons décrire des scénarios d’utilisations de notre système par des
diagrammes de séquence.
“ Diagramme de séquence « Annuler une prescription »
La Figure 56 présente le diagramme de séquence « Annuler une prescription ».

103
Figure 56 : Diagramme de séquence « Annuler une prescription »

104
“ Description textuelle du diagramme de séquence « Annuler une prescription »
▪ Acteur : Préparateur, Pharmacien.
▪ Précondition : L’utilisateur est authentifié, prescription ouverte en distribution.
▪ Postcondition : Prescription annulée.
1. Le préparateur demande d’afficher la liste des prescriptions.
de l’interface « Liste des prescriptions ».
5. Le préparateur saisie le matricule de l’agent.
6. Le contrôleur demande l’objet « Agent ».
7. L’entité « Agent » envoie l’objet au contrôleur qui vérifie à son tour le
résultat envoyé et demande la liste des prescriptions et ces lignes, ainsi
que la liste des distributions et ces lignes de l’agent courant.
8. Les entités « Prescription », « PrescriptionLine », « Distribution » et
« DistributionLine » envoient leurs résultats à l’interface.
9. Le préparateur choisi la prescription à annuler.
10. L’interface affiche les détails de la prescription.
11. Le préparateur clique sur le bouton « Annuler » et l’interface affiche la
vue de confirmation de l’annulation.
12. Le préparateur clique sur « Oui » et l’interface envoie la confirmation
au contrôleur.
13. Le contrôleur demande le changement de l’état de la prescription.
scénario normal.
B. Matricule de l’agent incorrecte. L’enchainement de B démarrera du
point 7 du scénario normal.
8. Un message de vérification du matricule de l’agent est envoyé à
l’interface de la liste.

105
C. La confirmation de l’annulation n’est pas confirmée. L’enchainement
de C démarrera du point 11 du scénario normal.
11. La vue de la confirmation se ferme.
12. Diagramme de séquence « Valider une commande interne »
La Figure 57 illustre le diagramme de séquence « Valider une commande interne ».
Figure 57 : Diagramme de séquence « Valider une commande interne »

106
“ Description textuelle du diagramme de séquence « Valider une commande interne »
▪ Acteur : Pharmacien.
▪ Précondition : L’utilisateur est authentifié, commande interne à l’état brouillon.
▪ Postcondition : Commande interne validée.
1. Le pharmacien demande d’afficher la liste des commandes internes.
de l’interface « Liste des commandes internes ».
5. Le contrôleur demande la liste des commandes internes et leurs lignes.
6. Le pharmacien choisi la commande à afficher.
7. L’interface affiche les détails de la commande sélectionnée.
8. Le pharmacien clique sur le bouton « Valider ».
9. L’interface envoie le nouvel état au contrôleur qui à son tour demande
la validation de la commande.
10. L’entité « InternalOrder » retourne le résultat au contrôleur.
11. Le contrôleur envoie un message de succès de validation à l’interface.
scénario normal.
“ Diagramme de séquence « Modifier une livraison »

107
La Figure 58 montre le diagramme de séquence « Modifier une livraison ».
Figure 58 : Diagramme de séquence « Modifier une livraison »
“ Description textuelle du diagramme de séquence « Modifier une livraison »
▪ Précondition : L’utilisateur est authentifié, livraison interne à l’état brouillon.
▪ Postcondition : Livraison interne modifiée.

108
internes.
de l’interface « Liste des livraisons internes ».
5. Le contrôleur demande la liste des livraisons internes et leurs lignes
ainsi que les commandes internes et leurs lignes.
7. L’interface affiche les détails de la livraison sélectionnée.
8. Le gestionnaire de dépôt modifie la livraison dans ces quantités à livrer.
9. L’interface envoie la livraison modifiée au contrôleur qui à son tour
demande le changement des lignes de la livraison courantes.
10. L’entité « InternalDeliveryLine » retourne le résultat au contrôleur.
11. Le contrôleur envoie un message de succès de livraison à l’interface.
scénario normal.
“ Diagramme de séquence « Imprimer une commande externe »

109
La Figure 59 présente le diagramme de séquence « Imprimer une commande externe ».
Figure 59 : Diagramme de séquence « Imprimer une commande externe »
“ Description textuelle du diagramme de séquence « Imprimer une commande externe
»
▪ Postcondition : Commande externe imprimée.

110
1. Le gestionnaire de dépôt demande d’afficher la liste des commandes
externes.
de la liste des commandes externes.
5. Le contrôleur demande la liste des commandes externes et leurs lignes.
6. Le gestionnaire de dépôt choisi la commande à afficher.
7. L’interface affiche la commande.
8. Le gestionnaire de dépôt clique sur le bouton « Imprimer ».
9. Le contrôleur envoie un message de succès d’impression à l’interface.
scénario normal.
“ Diagramme de séquence « Valider la fiche inventaire »
La Figure 60 illustre le diagramme de séquence « Valider la fiche inventaire ».

111
Figure 60 : Diagramme de séquence « Valider la fiche inventaire »
“ Description textuelle du diagramme de séquence « Valider la fiche inventaire »
▪ Acteur : Responsable inventaire.
▪ Précondition : L’utilisateur est authentifié, inventaire rempli.

112
▪ Postcondition : Inventaire validé.
1. Le responsable d’inventaire demande d’afficher la liste des inventaires.
de la liste.
5. Le contrôleur demande la liste des inventaires et les lignes de chaque
inventaire.
6. Le responsable inventaire choisi la fiche à afficher.
7. L’interface affiche les détails de l’inventaire choisi.
8. Le responsable inventaire clique sur le bouton « Valider ».
9. L’interface envoie au contrôleur l’identifiant de l’inventaire qui a son
tour demande la validation de l’inventaire.
10. L’entité « Inventory » envoie le résultat de la validation au contrôleur.
11. Le contrôleur envoie un message de succès à l’interface.
scénario normal.
“ Diagramme de séquence « Afficher les statistiques »
La Figure 61 montre le diagramme de séquence « Afficher les statistiques ».

113
Figure 61 : Diagramme de séquence « Afficher les statistiques »
“ Description textuelle du diagramme de séquence « Afficher les statistiques »
▪ Acteur : Gestionnaire.
▪ Postcondition : Statistiques affichés.
1. Le gestionnaire demande d’afficher les statistiques.
2. Le contrôleur demande la liste des utilisateurs, la liste des prescriptions
et crée les statistiques.
3. L’interface affiche les statistiques.
“ Diagramme de séquence « Consulter l'état en stock »
La Figure 62 présente le diagramme de séquence « Consulter l'état en stock ».

114
Figure 62 : Diagramme de séquence « Consulter l'état en stock »
“ Description textuelle du diagramme de séquence « Consulter l'état en stock »
▪ Acteur : Gestionnaire.
▪ Postcondition : Rapport de l’état en stock est généré.
1. Le gestionnaire demande de consulter l’état en stock.
2. Le contrôleur demande la liste des produits, la liste des produits en stock
et génère le rapport de l’état en stock.
3. L’interface affiche le rapport.
“ Diagramme de séquence « Désactiver un compte utilisateur »
La Figure 63 illustre le diagramme de séquence « Désactiver un compte utilisateur ».

115
Figure 63 : Diagramme de séquence « Désactiver un compte utilisateur »
“ Description textuelle du diagramme de séquence « Désactiver un compte utilisateur »
▪ Postcondition : Compte utilisateur désactivé.
1. L’administrateur demande d’afficher la liste des utilisateurs.
2. Le contrôleur demande la liste des utilisateurs.
3. L’administrateur choisi l’utilisateur à désactiver.
4. L’interface affiche les détails de l’utilisateur sélectionné.
5. L’administrateur clique sur le bouton « Désactiver » et le contrôleur à
son tour demande la désactivation du compte.

116
6. L’entité « Utilisateur » envoie un message de réponse au contrôleur.
7. Le contrôleur envoie à l’interface un message de succès.
“ Diagramme de séquence « Ouvrir une journée »
La Figure 64 montre le diagramme de séquence « Ouvrir une journée ».
Figure 64 : Diagramme de séquence « Ouvrir une journée »
“ Description textuelle du diagramme de séquence « Ouvrir une journée »

117
▪ Postcondition : Journée ouverte.
1. L’administrateur demande d’afficher le calendrier.
2. Le contrôleur demande la liste des journées et leurs types.
3. L’entité « Day » envoie la liste des journées et l’entité « DayType »
envoie la liste des types des journées.
4. L’administrateur choisi le un jour du calendrier dont il veut ouvrir une
journée de travail et choisi son type.
5. L’interface envoie au contrôleur les données qui a son tour demande
l’ajout d’une journée.
6. L’entité « Day » envoie un message de réponse.
7. Le contrôleur envoie à l’interface un message de succès d’ouverture
d’une journée.

118
Annexe C : Diagramme de GANTT
Les Figure 65 et Figure 66 présentent le diagramme de GANTT de notre projet.

119
Figure 65 : Diagramme de GANTT - Partie 1

120
Figure 66 : Diagramme de GANTT - Partie 2

121
Bibliographie
[1] TRANSTU, «HISTORIQUE - Transport collectif,» TRANSTU, [En ligne]. Available:
http://www.transtu.tn/fr/historique/transport-collectif.html. [Accès le 12 Avril 2017].
[2] TRANSTU, «A PROPOS - Ressources humaines,» TRANSTU, [En ligne]. Available:
http://www.transtu.tn/fr/entreprise/0003-ressources-humaines.html. [Accès le 13 Avril
2017].
[3] TRANSTU, «Termes de référence technique,» Tunis, 2017.
[4] C. M. ERP, «Définition d'un ERP : progiciel de gestion intégré,» [En ligne]. Available:
https://www.choisirmonerp.com/erp/definition-d-un-erp. [Accès le 5 Mais 2017].
[5] J.-L. Lequeux, Manager avec les ERP : architecture orientée services (SOA), Paris:
Éditions d’Organisation, Groupe Eyrolles, 2008.
[6] J. Rémy, «Un ERP dans ma PME,» La Ronde des Vivetières, 2016.
[7] medERP, «medERPLogiciel complet de gestion de dossiers médicaux,» Novembre
2014. [En ligne]. Available:
http://www.mederp.net/downloads/Presentation_mederp_clinique.pdf. [Accès le 7 Mai
2017].
[8] OpenEMR, «OpenEMR Features,» 6 Mai 2017. [En ligne]. Available: http://www.open-
emr.org/wiki/index.php/OpenEMR_Features. [Accès le 12 Mai 2017].
[9] Dolibarr, «Module Medical Center - Dolibarr Open Source ERP CRM Wiki,» [En
ligne]. Available: https://wiki.dolibarr.org/index.php/Module_Medical_Center. [Accès
le 12 Mai 2017].
[10] Odoo, «Odoo Medical,» [En ligne]. Available:
https://www.odoo.com/apps/modules/10.0/medical/. [Accès le 17 Mai 2017].
[11] P. Roques et F. Vallée, UML 2 en action: De l'analyse des besoins à la conception,
Paris: Eyrolles, 2011.
[12] P. Kruchten, Introduction au Rational Unified Process, Canada: Editions Eyrolles, 1999.
[13] U. d. Q. à. Montréal, «La spécification des besoins,» Université du Québec à Montréal,
Québec, 2004.

Bibliographie
122
[14] L. Debrauwer et F. Van der Heyde, UML 2 : Modélisation des objets, Paris: Editions
ENI, 2006.
[15] C. Benoît, O. Aomar et T.-M. Yann, UML 2 : Pratique de la modélisation, Pearson,
2010.
[16] O. DIANE, «ARCHITECTURE CLIENT / SERVEUR,» 11 Novembre 2016. [En
ligne]. Available: https://www.supinfo.com/articles/single/2519-architecture-client-
serveur. [Accès le 27 Mai 2017].
[17] B. s. wikibis, «Licence BSD,» Berkeley software distribution , 23 Mars 2009. [En
ligne]. Available: http://www.berkeley-software.wikibis.com/licence_bsd.php. [Accès le
28 Mai 2017].
[18] E. DUROSELLE, «PostgreSQL : Présentation rapide,» 19 Novembre 2004. [En ligne].
Available: https://www.postgresql.org/message-
id/attachment/6011/presentation_erwan_fs.html. [Accès le 29 Mai 2017].
[19] VMware, «Pivotal tc Server,» VMware, [En ligne]. Available:
https://www.vmware.com/products/pivotal-tcserver.html. [Accès le 29 Mai 2017].
[20] Grafikart, «Qu'est ce que NodeJS ?,» Grafikart, 15 Septembre 2016. [En ligne].
Available: https://www.grafikart.fr/formations/nodejs/nodejs-intro. [Accès le 29 Mai
2017].
[21] J. Gabay et D. Gabay, UML 2 Analyse et conception -Mise en oeuvre guidée avec
études de cas, Dunod, 2008.
[22] F. Petitit, «Les nouvelles architectures front Web et leur impact sur les DSI – Partie 1,»
29 Octobre 2013. [En ligne]. Available: http://blog.octo.com/les-nouvelles-
architectures-front-web-et-leur-impact-sur-les-dsi-partie-1/. [Accès le 13 Avril 2017].
[23] A. C.-. Damais, «AngularJS : le framework JavaScript de Google au crible,» 15 Otobre
2016. [En ligne]. Available: http://www.journaldunet.com/web-
tech/developpeur/1132120-angularjs-le-framework-javascript-de-google-au-crible/.
[Accès le 29 Mai 2017].
[24] S. Systems, «Enterprise Architect,» Sparx Systems, [En ligne]. Available:
http://www.sparxsystems.com.au/. [Accès le 02 Juin 2017].
[25] Spring, «Outil Spring Suite,» Spring by pivotal, [En ligne]. Available:
https://spring.io/tools. [Accès le 03 Juin 2017].

Bibliographie
123
[26] V. Studio, «Visual Studio Code,» Microsoft, [En ligne]. Available:
https://code.visualstudio.com/. [Accès le 03 Juin 2017].
[27] PostgreSQL, «pgAdmin,» PostgreSQL, [En ligne]. Available:
https://www.pgadmin.org/. [Accès le 03 Juin 2017].
[28] Git, «git--everything-is-local,» Git, [En ligne]. Available: https://git-scm.com/. [Accès
le 3 Juin 2017].
[29] Atlassian, «Bitbucket,» Atlassian, [En ligne]. Available:
https://fr.atlassian.com/software/bitbucket. [Accès le 4 Juin 2017].
[30] Atlassian, «Jira Software,» Atlassian, [En ligne]. Available:
https://fr.atlassian.com/software/jira. [Accès le 4 Juin 2017].
[31] Angular, «Agular,» Google, [En ligne]. Available: https://angular.io/. [Accès le 5 Juin
2017].
[32] Spring, «Spring,» Spring by Pivotal, [En ligne]. Available: https://spring.io/. [Accès le 5
Juin 2017].
[33] Bootstrap, «Bootsrap,» Bootstrap, [En ligne]. Available: http://getbootstrap.com/.
[Accès le 5 Juin 2017].
[34] TypeScript, «TypeScript,» [En ligne]. Available: https://www.typescriptlang.org/.
[Accès le 6 Juin 2017].
[35] openclassrooms, «Qu’est-ce que le html5 ?,» [En ligne]. Available:
http://openclassrooms.com/courses/. [Accès le 5 Juin 2017].
[36] lsystems, «Formation au html 5, xhtml et css,» [En ligne]. Available:
http://www.lsystems.fr/formation/html. [Accès le 5 Juin 2017].
[37] D. V. d. l. L. Française, «DVLF : progiciel,» DVLF, [En ligne]. Available:
https://dvlf.uchicago.edu/mot/progiciel. [Accès le 5 Mai 2017].
[38] F. Di Gallo, «Méthodologie des systèmes d'information - UML,» Cours du Cycle
Probatoire du Cnam.doc, Paris, 2001.
[39] D. Conan, C. Taconet et C. Bac, «Introduction au langage de modélisation UML,»
Télécom SudParis , Paris, 2015.
[40] Bootsrtap, «Cartes · Bootstrap,» Bootsrtap, [En ligne]. Available: https://v4-
alpha.getbootstrap.com/components/card/. [Accès le 02 06 2017].

Bibliographie
124
TITRE : ERP médical pour la TRANSTU - module de gestion pharmaceutiques
Résumé : L’objectif du projet est d’implémenter un module de la gestion pharmaceutique de
l’ERP médical pour la TRANSTU. En effet, la solution proposée a pour but d'améliorer la
structure organisationnelle des services médicaux offerts par l’entreprise et d’éviter la mauvaise
gestion de l’information. Tout au long de ce travail, nous avons utilisé le Framework Angular
2 pour la partie frontend et le Framework Spring boot pour la partie backend et la méthodologie
UP pour la conception de notre projet.
Mots clés : Module, ERP médical, Angular 2, Spring boot, UP.
TITLE : Medical ERP for TRANSTU - pharmaceutical management module
Abstract : The objective of the project is to implement a module of the pharmaceutical
management of medical ERP for TRANSTU. The proposed solution aims to improve the
organizational structure of the medical services offered by the company and to avoid
mismanagement of information. Throughout this work, we have used the Angular 2 Framework
for the frontend part and the Spring Boot Framework for the backend part and the UP
methodology was used to design our project.
Keyword : Module, Medical ERP, Angular 2, Spring boot, UP.
‫العنوان‬:‫تونس‬ ‫نقل‬ ‫لشركة‬ ‫الطبي‬ ‫المدمج‬ ‫اإلدارة‬ ‫نظام‬-‫الصيدلي‬ ‫التصرف‬ ‫وحدة‬
:‫الملخص‬‫ال‬‫هدف‬‫من‬‫المشروع‬‫هو‬‫إنجاز‬‫تونس‬ ‫نقل‬ ‫لشركة‬ ‫المدمج‬ ‫اإلدارة‬ ‫نظام‬ ‫من‬ ‫الصيدلي‬ ‫التصرف‬ ‫وحدة‬.‫في‬
‫الواقع‬،‫المقترح‬ ‫الحل‬ ‫يهدف‬‫إلى‬‫وتجنب‬ ‫الشركة‬ ‫قبل‬ ‫من‬ ‫المقدمة‬ ‫الطبية‬ ‫للخدمات‬ ‫التنظيمي‬ ‫الهيكل‬ ‫تحسين‬
‫استخدمنا‬ ،‫العمل‬ ‫هذا‬ ‫طوال‬ .‫المعلومات‬ ‫إدارة‬ ‫سوء‬‫اإلنقالر‬ ‫نضام‬2‫وسبرينغ‬ ‫البرنامج‬ ‫من‬ ‫األمامي‬ ‫للجزء‬ ‫بالنسبة‬
‫الموحد‬ ‫العلمية‬ ‫ونظام‬ ‫البرنامج‬ ‫من‬ ‫الخلفي‬ ‫للجزء‬ ‫بالنسبة‬ ‫بوت‬‫ة‬‫للتصميم‬.
:‫المفاتيح‬ ‫الكلمات‬‫وحدة‬،‫المدمج‬ ‫اإلدارة‬ ‫نظام‬،‫الطبي‬‫اإلنقالر‬2،‫بوت‬ ‫سبرينغ‬،‫الموحدة‬ ‫العلمية‬ ‫نظام‬.

ERP médical pour la TRANSTU : module de gestion pharmaceutiques

Contenu connexe

Tendances (20)

Similaire à ERP médical pour la TRANSTU : module de gestion pharmaceutiques (20)

ERP médical pour la TRANSTU : module de gestion pharmaceutiques