Mise en place d'un logiciel de gestion de pharmacie

PROPHARM

Logiciel de Gestion de Pharmacie

Par :

BEDJAOUI CHAOUCHE Mohamed
BENTATOU Zakaria
ERRAMI Mouhamed Nabil
SAHRAOUI Youcef

Le 21 avril 2009
4 Année Informatique

Table des matières

I La Méthode 2TUP 2

1 Processus de Développement Logiciel 2

2 Processus Unifié (Unified Process) 2

3 Le Processus 2TUP 3

4 Un processus de modélisation avec UML 4

II Conception du Logiciel 6

1 Etude Préliminaire 6

1.1 Présentation du projet 6

1.2 Grands choix techniques 6

1.3 Recueille des besoins fonctionnels 6

1.3.1 Gestion de la vente de médicament 6

1.3.2 Gestiondestock 7

1.3.3 Affichage de recettes journalières 7

1.4 Identifier les acteurs 7

1.4.1 L'Employé de la Pharmacie 7

1.4.2 Le Pharmacien 7

1.5 Identifier les messages 7

1.6 Modéliserlecontexte 8

2 Capture des Besoins Fonctionnels 10

2.1 Liste préliminaire des Cas d'Utilisation de PROPHARM 10

2.2 Description préliminaire des cas d'utilisation 10

2.2.1 Traiter la Vente 10

2.2.2 Verifier la Disponibilité et la Validité de chaque Medicament 11

2.2.3 Gérer le Stock 11

2.2.4 Consulter les Montants des Recettes 11

2.3 Décrire les cas d'utilisation 12

2.3.1 Casd'UtilisationTRAITERLAVENTE 12

2.3.2 Cas d'utilisation GERER STOCK 16

2.3.3 Cas d'utilisation CONSULTER RECETTE 19

3 Analyse 22

3.1 Développement du modèle Statique 22

3.2 Développement du modèle Dynamique 23

3.2.1 Traitement de vente 23

3.2.2 Gestiondestock 24

3.2.3 Consultation de la recette 26

III Conclusion générale 27

Introduction:

P

oUR notre mini projet nous avons opté pour le thème Gestion de Pharmacie. Notre choix a été motivé par plusieurs points et spécialement le fait d'avoir un client pour notre logiciel ce qui nous permet de nous initier à l'approche client développeur et au cycle de vie du logiciel, et

nous engage à concevoir un produit fiable, robuste et répondant complètement au besoins du client. Ce choix a été influé aussi par les outils informatiques que nous allions mettre en oeuvre pour ce logiciel à savoir la conception d'une base de données, une Interface utilisateur graphique(GUI) et de toute la programmation qu'il y a derrière afin de satisfaire le cahier de charge du client et aboutir à une application simple, utile, performante, ergonomique et fiable.

La conception et la mise en oeuvre des bases de données constituent un volet très important de l'informatique car elles sont aujourd'hui au coeur des applications quotidiennes et du système d'information des entreprises.

Les GUI constituent aussi une partie primordiale de l'informatique moderne car ils permettent la vulgarisation des applications pour le grand public et l'augmentation de l'interaction des utilisateurs avec le logiciel permettant ainsi une prise en main facile et une organisation visuelle efficace surtout quant il s'agit de la manipulation des bases de données.

C'est pour toutes ces raisons que nous avons choisi ce projet, et nous espérons que ce travail nous permettra d'enrichir notre savoir et surtout répondre aux besoin de notre client.

Première partie

La Méthode 2TUP

L

A complexité croissante des systèmes informatique a conduit les concepteurs à s'intéresser aux méthodes. Définir un seul processus universel serait une grave erreur car la variété des systèmes et des techniques ne le permet pas. Devant le nombre de méthodes disponibles, le

choix parmi elles devient difficile, beaucoup de questions peuvent se poser à un chef de projet lors d'un démarrage de projet:

Comment vais-je organiser les équipes de développement?

Quelles tâches attribuer à qui?

Quel temps faudrait-il pour livrer le produit?

Comment faire participer le client au développement afin de capter les besoins de celui-ci? Comment éviter des dérives et de mauvaises estimations qui vont allonger les coûts et le temps de développement?

1 Processus de Développement Logiciel

Un processus définit une séquence d'étapes, en partie ordonnées, qui concourent à l'obtention d'un système logiciel ou a l'évolution d'un système existant. L'objet d'un processus de développement est de produire des logiciels de qualité qui répondent aux besoins de leurs utilisateurs dans des délais et des coûts prévisibles.

2 Processus Unifié (Unified Process)

Un processus unifié est un processus de développement logiciel construit sur UML; il est itéra-

tif et incrémental, centré sur l'architecture, conduit par les cas d'utilisation et piloté par les risques.
-Itérative et Incrémentale la méthode est itérative dans le sens où elle propose de faire des
itérations lors de ses différentes phases, ceci garantit que le modèle construit à chaque phase
ou étape soit affiné et amélioré. Chaque itération peut servir aussi à ajouter de nouveaux
incréments.

- Conduite par les Cas d'Utilisation elle est orientée utilisateur pour répondre aux besoins de celui-ci.

- Centrée sur l'Architecture les modèles définit tout au long du processus de développement vont contribuer à établir une architecture cohérente et solide.

- Pilotée par les Risques en définissant des priorités pour chaque fonctionnalité, on peut minimiser les risques d'échec du projet.

Ces activités de développement sont définies par6 disciplines fondamentales qui décrivent la capture des besoins, la modélisation métier, l'analyse et la conception, l'implémentation, le test et le déploiement. Le processus unifié doit donc être compris comme une trame commune des meilleures pratiques de développement, et non comme l'ultime tentative d'élaborer un processus universel.

3 Le Processus 2TUP

2TUP signifie « 2 Track Unified Process ». C'est un processus qui répond aux caractéristiques du Processus Unifié. Le processus 2TUP 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 d'information.

FiGuRE 1 - Le système d'information soumis à deux types de contraintes

La branche gauche (fonctionnelle) capitalise la connaissance du métier de l'entreprise. Elle

constitue généralement un investissement pour le moyen et le long terme. Les fonctions du système d'information sont en effet indépendantes des technologies utilisées. Cette branche comporte les étapes suivantes:

- La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le métier des utilisateurs.

- L'analyse.

La branche droite (architecture technique) capitalise un savoir faire technique. Elle consti-

tue un investissement pour le court et moyen terme. Les techniques développées pour le système peuvent l'être en effet indépendamment des fonctions à réaliser. Cette branche comporte les étapes suivantes:

- La capture des besoins techniques.

- La conception générique.

La branche du milieu: à 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 2 branches. Cette fusion conduit à l'obtention d'un processus en forme de Y. Cette branche comporte les étapes suivantes:

- La conception préliminaire.

- La conception détaillée.

- Le codage.

- L'intégration.

FiGuRE 2- Le processus de développement en Y

4 Un processus de modélisation avec UML

Le processus 2TUP s'appuie sur UML tout au long du cycle de développement, car les différents diagrammes de ce dernier permettent de part leur facilité et clarté, de bien modéliser le système à chaque étape.

« Unified Modeling Language »: UML se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier, concevoir des solutions et communiquer des points de vue. (Pitman, 2006)

UML unifie à la fois les notations et les concepts orientés objet.Il ne s'agit pas d'une simple

notation, mais les concepts transmis par un diagramme ont une sémantique précise et sont porteurs de sens au même titre que les mots d'un langage, c'est pour ça qu'UML est présenté parfois comme une méthode alors qu'il ne l'est absolument pas.

UML unifie également les notations nécessaires aux différentes activités d'un processus de développement et offre, par ce biais, le moyen d'établir le suivi des décisions prises, depuis la définition des besoins jusqu'au codage. (Roques, 2006)

Voici une présentation rapide des différents diagrammes UML qui vont être utilisés tout au long du projet :

- Le diagramme des cas d'utilisation : représente la structure des fonctionnalités nécessaires aux utilisateurs du système. Il est normalement utilisé lors des étapes de capture des besoins fonctionnels et techniques.

- Le diagramme d'activités : représente les règles d'enchaînement des activités et actions dans le système. Il peut être assimilé comme un algorithme mais schématisé.

- Le diagramme de packages : présent depuis UML 2.0, ce diagramme modélise des catégories cohérentes entre elles, pour un souci de partage des rôles. Correspond à l'étape de modélisation des différents scénarios d'un cas d'utilisation.

- Le diagramme de classes : sûrement l'un des diagrammes les plus importants dans un développement orienté objet. Sur la branche fonctionnelle, ce diagramme est prévu pour développer la structure des entités manipulées par les utilisateurs. En conception, le diagramme de classes représente la structure d'un code orienté objet.

- Le diagramme de séquence : représente les échanges de messages entre objets, dans le cadre d'un fonctionnement particulier du système.

- Le diagramme d'états : représente le cycle de vie d'un objet. Il spécifie les états possibles d'une classe et leur enchainement. Ce diagramme est utilisé lors des étapes d'analyse et de conception.

Répartition des tâches

Tâches	Tâches Partielles	Durée	Bentatou	Sahraoui	Errami	Bedjaoui	Durée Totale
Etude préliminaire	Cahier de charge	8	V	V			15
	Messages / Acteurs	4			V
	Modelisation contexte	3				V
Capture des besoins fonctionnels	Identifier C.U	6		V			17
	Organiser C.U	5			V	V
	Identifier C.C	6	V
Capture des besoins techniques	' ·	0	x	x	x	x	0
Découpage en catégories	. .	1	V	V	V	V	1
Developpement du M.S	' ·	7	V		V		7
Developpement du M.D	' .	10		V		V	10
Prototype	' .	12	V	V			12

Deuxième partie

Conception du Logiciel

1 Etude Préliminaire

1.1 Présentation du projet

La pharmacie «EL NouR » est localisé à l'adresse suivante «Bloc Autoconstruction Ain Fezza num 06 CHE», elle est conventionnée auprès de la CASNOS et souhaite se doter d'un système informatique performant afin de:

- Gérer la vente de médicaments destinés aux clients.

- Gérer le stock des médicaments.

- Connaitre les recettes journalières.

1.2 Grands choix techniques

On souhaite utiliser une approche itérative et incrémentale, fondée sur le processus en Y (méthode 2TUP). Apres une première étude menée par les membres de notre équipe, nous avons affranchies le choix d'un certain nombre de technique clés pour ce projet:

- La modélisation objet avec UML.

- Le langage JAVA.

- L'AGL WINDEV.

Logiciel qui sera mis en oeuvre par nos soins aura pour nom PROPHARM

1.3 Recueille des besoins fonctionnels

Un premier tour d'horizon des besoins exprimée par le pharmacien et ses employés a permit d'établir le cahier de charge préliminaire suivant:

1.3.1 Gestion de la vente de médicament

Lorsqu'un client lui présente une ordonnance ou veut acheter un médicament précis, le pharmacien ou un de ses employés doit vérifier la disponibilité de chaque médicament dans le stock, le logiciel doit être capable d'indiquer au pharmacien la quantité de stock restante dans le stock pour chaque médicament demandé par le client ainsi que leur date de péremption. Ce n'est qu'après cette étape de vérification que le pharmacien peut effectuer la vente en saisissant dans le logiciel le nom et la quantité de médicament vendu, ce dernier doit lui retrouver le prix de chaque médicament ainsi que le montent total qui sera encaissé par le pharmacien.

1.3.2 Gestion de stock

Lorsqu'un fournisseur lui livre les médicaments commandés, le propriétaire de la pharmacie (et non ses employés) doit implémenter la base de donnée du logiciel par le nombre de médicament s livrés, leur nom, leur type et leur date de péremption.

1.3.3 Affichage de recettes journalières

A la fin de la journée, juste avant la fermeture, le pharmacien peut consulter PRoPHARM pour connaitre le montant de la recette, ce montant est automatiquement enregistré dans la BDD.

Recueil de besoins opérationnels Sécurité

Lorsqu'il veut accéder à la gestion de stock ou à l'affichage des recettes, le pharmacien doit être reconnu par un nom et un mot de passe. Pour diverses raisons, l'accès à ces deux options ne doit être qu'au propriétaire de la pharmacie (cela peut minimiser le risque de vol de médicament ou d'argent par les employés).

1.4 Identifier les acteurs

1.4.1 L'Employé de la Pharmacie

Le rôle de l'employé limité à la vente et la vérification de la disponibilité d'un ou plusieurs médicaments dans le stock.

1.4.2 Le Pharmacien

Le pharmacien est le patron de la pharmacie, il doit gérer son magasin de la façon la plus fiable possible, pour cela il doit gérer lui-même les commandes de médicament et l'implémentation de la base de données de façon de minimiser les risques de vols ou de pertes de médicaments.

1.5 Identifier les messages

PRoPIIuRi emet:

- La disponibilité d'un médicament ainsi que leur date de péremption. - Le montant total à encaisser à la fin de vente.

- La caractéristique de chaque médicament.

- Les recettes journalières.

PRoPIIuRi reçoit:

- Les caractéristiques de chaque médicament.

- Création, modification, annulation d'une vente.

1.6 Modéliser le contexte

FIGuRE 3 - Diagramme de Contexte Dynamique

FiGuRE 4- Diagramme de Contexte Statique

2 Capture des Besoins Fonctionnels

2.1 Liste préliminaire des Cas d'Utilisation de ProPharm

Cas d'Utilisation	Acteur Principal/Acteur Secondaire	Messages Emis/Reçus Par les Acteurs
Traiter la vente	Pharmacien,Employé	Emet: - Création, modification, ou annulation de vente. - Demande de caractéristique de médicament. Reçoit: - La disponibilité et la date de péremption du médicament. - Montant total à encaisser.
Gérer le Stock	Pharmacien	Emet: - Caractéristique de chaque médicament qui vient d'être acheté par la pharmacie.
Consulter les Recettes	Pharmacien	Emet: - Demande de consultation (journalière, hebdomadaire, mensuelle). Reçoit: - Le montant des recettes

2.2 Description préliminaire des cas d'utilisation

2.2.1 Traiter la Vente

Intention effectuer la vente de médicament, déterminé le montant total de la vente, donner une facture au client.

Actions créer une nouvelle vente, saisir le nom de chaque médicament destiné à la vente ainsi que leur quantité, imprimer une facture au client.

2.2.2 Verifier la Disponibilité et la Validité de chaque Medicament

Intention déterminer si le médicament qui est destiné à la vente n'est pas périmé et déterminer sa disponibilité dans le stock.

Actions saisir le nom de médicament

2.2.3 Gérer le Stock

Intention facilité le traitement de vente et minimiser les risque de vols.

Actions ajouter de nouveaux médicaments à la BDD (nom, prix, caractéristique et éventuellement en enlever ceux qui sont périmés, entrer le mot de passe.

2.2.4 Consulter les Montants des Recettes

Intention connaitre le chiffre d'affaire de la journée, minimiser le risque de vols d'argent de la part des employés.

Actions consulter le chiffre d'affaire de la date en cours ou des dates ultérieurs, entrer le mot de passe.

Maintenant que nous allons identifier les cas d'utilisation et leurs acteurs, nous allons pouvoir les représenter graphiquement sur un diagramme de cas d'utilisations de la façon suivante:

FiGuRE 5 - Diagramme de Cas d'Utilisation

2.3 Décrire les cas d'utilisation

2.3.1 Cas d'Utilisation TRAITER LA VENTE

Scénario d'identification

Titre traiter la vente.

Résumer un client arrive a la pharmacie avec une ordonnance ou la liste de médicament qu'il souhaite achetée, le pharmacien effectue la vente des produits disponibles, à la fin de l'opération le client part avec les médicaments.

Acteurs Pharmacien, Employé (principal), Client (secondaire).

Date de création 21 avril 2009

Version 1.0

Responsable SAmRAou[ Youcef.

Description de scénarios

Pré conditions l'ordinateur est allumé, le pharmacien ou l'employé y est connecté. Scénario nominal

1. Le cas d'utilisation commence quant le client se présente à la pharmacie avec un e ordonnance ou la liste de médicament qu'il souhaite achetés.

2. L'employé vérifie la disponibilité de chaque médicament dans le logiciel ainsi que leur date de péremption.

3. L'employé va chercher les médicaments dont il est question dans le stock.

4. L'employé enregistre le nom de chaque médicament dans le logiciel, s'il y a plus de exemplaire par produit, l'employé indique également la quantité.

5. Le logiciel valide le médicament et détermine son prix, ensuite il affiche la description et le prix du médicament en question.

6. Apres avoir enregistrer tous le produit, l'employé indique que la vente est terminée.

7. Le logiciel calcule et affiche le montant total de la vente.

8. L'employé annonce le montant total au client.

9. Le client effectue le paiement.

10. Le logiciel enregistre la vente effectuée.

11. L'employé demande au client s'il veut une facture détaillée.

12. Le client demande la facture.

13. L'employé imprime la facture et la donne au client au même temps que le médicament.

14. Le client s'en va avec le médicament.

Enchainements alternatifs

A1 demande d'annulation d'article, l'enchainement A1 démarre au point 5 du scenario nominal.

5. L'employé demande d'annulé l'article en question.

6. Le logiciel enlève l'article de la vente en cours.

Le scenario nominal reprend au point « 3 » s'il ya d'autre article, ou de point « 6 » s'il y en a pas.

A2 facture refusée. L'enchainement A1 démarre du point 12 du scénario nominal.

12. le client refuse la facture.

13. l'employé donne au client les médicaments

14. le client s'en va avec les médicaments.

Enchainement d'erreur

E1 annulation de la vente.

L'enchainement E1 du point 3 au point 9 du scenario nominal:

3-9 l'employé annule l'ensemble de la vente et le cas d'utilisation se termine en échec.

FiGuRE 6- Diagramme de séquences du scénario nominal

FiouIe 7 - Diagramme d'Activités

2.3.2 Cas d'utilisation GERER STOCK

Sommaire d'identi~cation Titre gérer le stock

Résumé saisir toutes les caractéristiques des médicaments fournis ainsi que les opérations de mis

à jour.

Acteurs pharmacien.

Date de création 21 avril 2009 Version 1.0

responsable SAiiRAoui Youcef. Description des scénarios

Pré conditions livraison de nouveaux lots de médicaments, péremption des médicaments.

Scénario nominal Ce cas d'utilisation commence lors d'éventuelle modification.

1. Livraison de médicaments.

2. Créer une nouvelle table.

3. Table créée.

4. Saisir les caractéristiques du médicament.

5. Demande de modification (suppression/mise àjour) d'une table.

6. Validation.

Enchainements alternatifs ou d'erreurs

A1 Annulation d'une entrée, l'enchainement A1 démarre au point 3 du scenario nominal.

3. Suppression de l'entrée erronée.

4. Validation. E1 Demande de modification d'une entrée L' enchainement E1 se déclenche après l'étape 3

4. Modification du champ concerné.

5. Validation.

FiGuRE 8 - Diagramme de séquences du scénario nominal

FiouIe 9 - Diagramme d'Activités

2.3.3 Cas d'utilisation CONSULTER RECETTE

Sommaire d'identi~cation Titre consulter la recette Résumé le pharmacien consulte sa recette quotidiennement avant la fermeture

Acteurs pharmaciens

Date de création 21 avril 2009 Version 1.0

responsable SAiiRAoui Youcef. Description des scénarios

Pré conditions l'ordinateur est allumé, le pharmacien est connecté

Scénario nominal

1. Le cas d'utilisation commence quand le pharmacien veut consulter sa recette.

2. Il consulte le journal des ventes.

3. Vérifier s'il ya eu d'éventuelle prélèvement de la caisse ainsi que l'ajustement.

4. Consulter le chiffre d'affaire final.

5. Validation.

6. Imprimer la recette journalière.

Enchainements alternatifs ou d'erreurs

A1 incoherence entre le montant total du journal de vente et le chiffre calculer a la fin, ce cas débute au point 4 du scenario nominal

5. Consultation des détailles des ventes.

6. Identifications des erreurs.

7. Correction des erreurs.

8. Validation de la mise àjour.

9. Consultation de la recette finale.

FIGuRE 10- Diagramme de séquences du scénario nominal

FIGuRE 11 - Diagramme d'Activités

3 Analyse

3.1 Développement du modèle Statique

Le développement du modèle statique constitue la première étape d'analyse Il s'agit d'une activité itérative, fortement couplée avec la modélisation dynamique.

3.2 Développement du modèle Dynamique

Le développement du modèle dynamique constitue la deuxième activité de l'étape d'analyse. Il s'agit d'une activité itérative, fortement couplée avec la modélisation statique.

3.2.1 Traitement de vente

FIGuRE 12- Diagramme de séquences dynamique de traitement de vente

3.2.2 Gestion de stock

FIGuRE 13 - Diagramme de séquences dynamique de gestion de stock (ajout)

FIGuRE 14- Diagramme de séquences dynamique de gestion de stock (suppression)

3.2.3 Consultation de la recette

FIGuRE 15 - Diagramme de séquences dynamique de consultation de recettes

Troisième partie

Conclusion générale

Nous avons tenté à travers ce projet de démontrer l'importance de l'application d'une méthode de développement. Nous pensons aussi que 2TUP pourra être utilisée dans des projets de moyenne à grande envergure. A titre personnel, le bénéfice qu'on en a tiré est l'apprentissage de concepts à la pointe de la technologie et des tendances actuelles dans le monde professionnel. Une recherche profonde a été indispensable pour essayer de comprendre ces concepts là. Nous pouvons citer à ce propos, un excellent livre traitant ce sujet qui s'appelle : UML 2 En Action. Ce projet nous a permis d'enrichir nos connaissances dans des domaines très variés comme : L'Orienté Objet, UML, 2TUP, le langage JAVA... En termes d'évolution, l'application PioPri&ii pourra par la suite être finalisée et adaptée à une utilisation dans une pharmacie.

Références

[1] UML 2 En Action ;De l'Analyse de Besoin à la Conception J2EE ;Pascal Roques,Franck Vallée.3eme edition.