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.
Acteur - Préparateur ;
- 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
- Livraison interne en état « Annulée » ;
- Livraison interne en état « Livrée ».
“ « 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 »
Nous allons décrire les cas d’utilisations illustré dans le diagramme de la gestion des
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
▪ Rechercher une commande :
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 « Annulé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 »
Dans cette partie, nous allons raffiner les cas d’utilisations du diagramme de la gestion
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 ;
▪ Rechercher une livraison :
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 « 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.
Acteur Administrateur.
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
C. Les règles de gestion ne sont pas vérifiées. L’enchainement de C
démarrera du point 10 du scénario normal.
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.

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

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

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

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

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