WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Application web. Gestion de pharmacie en Java

( Télécharger le fichier original )
par Leila Amri
Institut supérieur de comptabilité et d'administration des entreprises Tunisie - Licence en informatique de gestion 2009
  

Disponible en mode multipage

REPUBLIQUE TUNISIENNE
MINISTERE DE L'ENSEIGNEMENT SUPERIEUR,
DE LA RECHERCHE SCIENTIFIQUE ET DE LA TECHNOLOGIE
UNIVERSITE DE MANOUBA

Institut Supérieur de Comptabilité et d'Administration des Affaires

Projet de Fin d'Etudes

En vue de l'obtention du diplôme de

Licence

EN

INFORMATIQUE APPLIQUÉE À LA GESTION

Thème : Application Web

Gestion de Pharmacie

Elaboré et soutenu par : Amri Leila Encadré par: Abdallah Jamil

Année universitaire 2009 -2010

Remerciement

Je tiens à exprimer mes remerciements avec un grand plaisir et un grand
respect à mon encadreur Mr Abdallah Jamil, pour Ses conseils, Sa
disponibilité et ses encouragements qui m'ont permis de réaliser ce
travail dans les meilleures conditions.

J'exprime de même ma gratitude à Mr Ben Asker Ahmed. Qui a cru en
moi et qui n'a cessé de me faire profiter de ses précieux conseils et
remarques.

J'adresse aussi mes reconnaissances à tous les professeurs et au corps
administratif de l'Institut Supérieur de Comptabilité et
d'Administration des Affaires (ISCAE) qui depuis quelques années
leurs conseils et leurs connaissances m'ont bien servis.

Je voudrais aussi exprimer ma gratitude envers tous ceux qui m'ont
accordé leur soutien, tant par leur gentillesse que par leur dévouement,
en particulier Mr Rahmoun Mohamed Ali et Mr Ben Zid Jamil.

Je ne peux nommer ici toutes les personnes qui de près ou de loin m'ont
aidé et encouragé mais je les en remercie vivement.

Enfin je tiens à dire combien le soutien quotidien de ma famille a été important tout au long de ces quelques années, je leur dois beaucoup.

Dédicaces

A mes très chers parents

Pour tout l'amour dont vous m'avez entouré, pour tout ce que
vous avez

fait pour moi.

Je ferai de mon mieux pour rester un sujet de fierté à vos yeux
avec
l'espoir de ne jamais vous décevoir.

Que ce modeste travail, soit l'exaucement de vos veux tant
formulés et de
vos prières quotidiennes.

A mes très chers soeurs et freres

Vous occupez une place particulière dans mon coeur. Je vous
dédie ce
travail en vous souhaitant un avenir radieux, plein de
bonheur et de succès.

A mon très cher ami Sedki
En souvenir de nos éclats de rire et des bons moments. En
souvenir de
tout ce qu'on a vécu ensemble. J'espère de tout mon
coeur que notre amitié durera
éternellement.

Leila

Table des matières

Chapitre 1 : Présentation du projet......................................................................

1. Introduction generale ..................................................................................1

2. Presentation institut............................... 3

2.1 Etude et Diplôme.................................................................................. 3

2.2 Les conditions d'acces a l'ISCAE ................................................................ 4

2.3 Activite Academique ................................................................................4

3. Méthodologie adopte ..................................................................................4

4. Organisation de rapport ...............................................................................5

5. Conclusion...............................................................................................5

Chapitre 2 : Définition de besoin et analyse............................................................

1. Introduction .............................................................................................6

2. Description de l'existant ..............................................................................6

2.1 Critique de l'existant ..................................................................................6

2.2 Orientations (Solutions)................ 7

3. Les besoins fonctionnels 8

4. Les besoins non fonctionnels 9

5. Les cas d'utilisation ...................................................................................9 5.1 Definition .............................................................................................9

5.2 Identification des acteurs du systeme .............................................................10
5.3 Description du modele de cas d'utilisation .............................................. 11

5.3.1 Diagramme global des cas d'utilisation ........................... 11

5.3.2 Raffinement des cas d'utilisation 12

6. Conclusion ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~...17

Chapitre 3 : Conception

1. Introduction ............................................................................................18

2. Description du modèle de cas d'utilisation ........................................................18 2.1 Raffinement des cas d'utilisation ..................................................................18

2.1.1 Raffinement du cas d'utilisation << s'identifier >> ..........................................14 2.1.2 Raffinement du cas d'utilisation << gestion des produits >> ...............................19

2.1.3 Raffinement du cas d'utilisation << gestion des fournisseures >> ....................... .21

2.1.4 Raffinement du cas d'utilisation << gestion des alertes>> ............................... 23
2.1.5 Raffinement du cas d'utilisation << gestion des commandes >> ...........................24
2.1.6 Raffinement du cas d'utilisation << gestion des livraisons >> ..............................27

Raffinement du cas d'utilisation << gestion des ordonnaces >> ............................... ..28

Raffinement du cas d'utilisation << gestion des administrations >> ..............................30

Raffinement du cas d'utilisation << gestion des états >> ..........................................31

Raffinement du cas d'utilisation << Statistiques >> .................................................32

3. Les diagrammes de séquence ........................................................................32 3.1 Définition .............................................................................................32

3.2 Diagramme Séquence ..............................................................................33

3.2.1 Diagramme de séquence du cas d'utilisation << s'identifier >> ...........................33

3.2.2 Diagramme de séquence du cas d'utilisation << gestion des médicaments >> ..........33
3.2.3 Diagramme de séquence du cas d'utilisation << gestion des commandes >> ............37
3.2.4 Diagramme de séquence du cas d'utilisation << gestion des livraisons >> ...............39

3.2.5 Diagramme de séquence du cas d'utilisation << gestion des ordonnances >> ...........41
3.2.6 Diagramme de séquence du cas d'utilisation << Statistiques >> ...........................43

4. Le diagramme de Classe .............................................................................44

5. Conclusion .............................................................................................46

Chapitre 4 : Etude technique et implémentation.......................................................

1. Introduction ............................................................................................47

2. Environnement materiel et logiciel .................................................................47 2.1 Environnement materiel ............................................................................47 2.2 Environnement logiciel .............................................................................47 2.2.1 UML ................................................................................................48 2.2.2 IBM Rational Rose Entreprise Edition version 7.0.0.0 .......................................48 2.2.3 Oracle ...............................................................................................48 2.2.4 Eclipse Galileo
....................................................................................49

2.2.5. GlassFish ........................................................................................49

2.2.6 Adobe Flex Builder ..........................................................................49

2.2.7 Les Fichier Jar... .......... 50

3. Presentation de l'application....................................................................... 52

3.1 Structure globale de l'application..................................................................52
3.2 Fonctionnalites de l'application ...................................................................53

4. Conclusion........................................................................................ 76

Conclusion generale 77

AnnexeA.................................................................................................78 AnnexeB.................................................................................................84 AnnexeC.................................................................................................93 AnnexeD.................................................................................................98

Liste des figures

Figure 2.1:Diagramme de cas d'utilisation initial...................................................11

Figure 2.2:Diagramme de cas d'utilisation << s'identifier >>.....................................12

Figure2.3:Diagramme de cas d'utilisation << gestion des médicaments >>....................12 Figure 2.4:Diagramme de cas d'utilisation << Gestion des fournisseurs >>.....................13 Figure 2.5:Diagramme de cas d'utilisation << Gestion des alertes >> .........................13 Figure 2.6:Diagramme de cas d'utilisation << Gestion des commandes >>.....................14

Figure 2.7:Diagramme de cas d'utilisation << Gestion des livraisons>>........................14

Figure 2.8:Diagramme de cas d'utilisation << Ordonnances >>...................................15

Figure 2.9:Diagramme de cas d'utilisation << Gestion des administrations>>................15 Figure 3: Diagramme de cas d'utilisation << Gestion des états >>...............................16 Figure 3.1:Diagramme de cas d'utilisation << Statistique>> .....................................16 Figure 3.2: Diagramme de cas d'utilisation << S'identifier >>....................................18

Figure 3.3:Diagramme de cas d'utilisation << Gestion des produits >> ........................19

Figure 3.4: Diagramme de cas d'utilisation << Gestion des fournisseurs>>................. 21 Figure 3.5: Diagramme de cas d'utilisation << Gestion des alertes>>...........................23 Figure 3.6: Diagramme de cas d'utilisation << Gestion des Commandes >>..................24 Figure 3.7: Diagramme de cas d'utilisation << Gestion des Livraisons>>.......................27

Figure 3.8: Diagramme de cas d'utilisation << Gestion des ordonnances >>....................28 Figure 3.9: Diagramme de cas d'utilisation << Gestion des administrations >> 30

Figure 4 : Diagramme de cas d'utilisation << Gestion des états>>.......................... 31 Figure 4.1: Diagramme de cas d'utilisation << Statistique >>....................................32 Figure 4.2:Diagramme de séquence du cas d'utilisation << S'identifier >>.........................33

Figure 4.3:Diagramme de séquence du cas d'utilisation << Création >>........................33 Figure 4.4:Diagramme de séquence du cas d'utilisation << Modification

>>....................34

Figure 4.5: Diagramme de séquence du cas d'utilisation << Consultation >>...................35

Figure 4.6: Diagramme de séquence du cas d'utilisation << Suppression >>..................36

Figure 4.7: Diagramme de séquence du cas d'utilisation << Création d'une commande >>...37 Figure4.8:Diagramme de séquence du cas d'utilisation<<Consultation d'une commande >>38 Figure 4.9:Diagramme de séquence du cas d'utilisation <<Création d'une livraison >> 39 Figure 5: Diagramme de séquence du cas d'utilisation << Consultation des livraisons >> ~~..40

Figure 5.1:Diagramme de séquence du cas d'utilisation << Valider ordonnance >>....... 41

Figure 5.2:Diagramme de séquence du cas d'utilisation << Consultation des ordonnances >>~..42

Figure 5.3:Diagramme de séquence du cas d'utilisation << Statistiques

>>...........................43

Figure 5.4 : Le Diagramme de classe.......................................................... 44

Figure 5.5 : structure globale de l'application........................................................52 Figure 5.6 : page authentification.................................................................... 54 Figure 5.7 : Menu principal.............................................................................55 Figure 5.8 : Gestion produits ...........................................................................56 Figure 5.9 : Gestion des produits(Consulter) 57 Figure 6 : Gestion des fournisseurs (Ajouter).........................................................58 Figure 6.1 : Gestion des fournisseurs (Consulter)....................................................59 Figure 6.1: Gestion des alertes (Consulter)............................................................60

Figure 6.2 : Gestion commandes (Création)........................................ 61

Figure 6.3 : Gestion commandes (Création d'une ligne de commande) 62

Figure 6.4 : Gestions commandes (Consulter).................................................... 63

Figure 6.5 : Gestion Livraison (Création) 64

Figure 6.6 : Gestion Livraison (Création détail livraison) 65

Figure 6.7 : Gestion livraisons (consultation) 66

Figure 6.8 : Gestion Ordonnance (création)....................................................... 67

Figure 6.9 : Gestion ordonnances (création ligne commande).................................. 68

Figure 7 : Gestion ordonnances (Consulter)..........................................................69

Figure 7.1 : Gestion d'administration et sécurité (Création d'un nouvel utilisateur) 70

Figure 7.2 : Gestion d'administration et sécurité (Création d'un mot de passe)... 71

Figure 7.3 : Gestion Edition des Etat(Consultation) 72

Figure 7.4 : Gestion Edition des Etats (Consultation en PDF) 73

Figure 7.5 : Gestion Edition des Etats (Affichage produit) 74

Figure 7.6: Statistiques 75

Chapitre 1 :

Présentation du projet

1. Introduction Générale

Actuellement, le monde connaît une avance technologique considérable dans tous les secteurs et cela grâce à l'informatique qui est une science qui étudie les techniques du traitement automatique de l'information. Elle joue un rôle important dans le développement de l'entreprise et d'autres établissements.

Avant l'invention de l'ordinateur, on enregistrait toutes les informations manuellement sur des supports en papier ce qui engendrait beaucoup de problèmes tel que la perte de temps considérable dans la recherche de ces informations ou la dégradation de ces dernières. ..Etc.

Ainsi, jusqu'à présent, l'ordinateur reste le moyen le plus sûr pour le traitement et la sauvegarde de l'information. Cette invention à permis d'informatiser les systèmes de données des entreprises, ce qui est la partie essentielle dans leur développement aujourd'hui.

Les pharmacies hospitalières et celles des dispensaires publiques font partie intégrante des établissements que l'informatique pourra beaucoup aider. En effet, la croissance du nombre des médicaments hospitaliers nécessite la mise en place d'une gestion rationnelle prise et rapide, or et jusqu'à ce jour, la manière de gérer manuellement est encore dominante.

On remarque ainsi la mauvaise organisation du travail dans la pharmacie lors de la recherche d'une information ainsi lors de la création des statistiques l'information n'est pas toujours précise ni disponible d'où la nécessité d'introduire l'informatique dans les pharmacies hospitalières.

Vu cet état de fait, mon projet fin d'études a pour objectif de concevoir et mettre en oeuvre une application web interactive, fiable, conviviale et facile à intégrer dans l'environnement de travail des pharmacies assurant la gestion de ces dernières et de suivre les

ordonnances en prenant en considération le type des médicaments sortis à chaque ordonnance et l'état de stock des médicaments, en essayant de trouver les solutions aux problèmes rencontrés lors de l'exécution.

Cette application vise essentiellement à diminuer la complexité des traitements ainsi

que le temps perdu lors de la gestion de stock, en particulier.

2. Présentation de l'institut:

2.1 Historique de l'ISCAE

L'Institut Supérieur de Comptabilité et d'Administration des Entreprises (ISCAE) est un établissement national d'enseignement supérieur rattaché à l'université de la Manouba. L'ISCAE est crée par l'article 73 de la loi n° 58-109 du 31 Décembre 1987 et dont l'application a été ordonnée par le décret N° 88-1648 du 16 Septembre 1988 sous le nom (ISC). L'ISCAE a pris son appellation actuelle par le décret n° 85-2051 du 18 Décembre 1995.

2.2 Etudes et diplômes :

L'ISCAE délivre des licences multiples, des mastères de recherche et professionnels ainsi qu'un doctorat en sciences comptable.

Licence appliquée:

- Informatique Appliqué à la Gestion - Comptabilité

Licence fondamentale:

- Gestion

- Informatique Appliqué à la Gestion Le troisième cycle:

L'offre pédagogique à l'ISCAE ne se limite pas aux diplômes de maîtrise mais s'étend également à des diplômes de troisième cycle, notamment les Mastères en:

- Comptabilité

- Organisation et Système d'Information

Ainsi qu'un Mastère Spécialisé en Gestion des Etablissements Universitaires et un CES de révision comptable.

L'ISCAE est également habilité à délivrer les diplômes de Doctorat et à l'Habilitation Universitaire en Sciences Comptables.

2.3 Les conditions d'accès à l'ISCAE:

- Les bacheliers provenant de différentes filières: littéraires, scientifiques et économiques.

2.4 Activité académique

Afin de répondre aux besoins croissants en experts comptables, l'ISCAE est l'un des centres de formation spécialisée à l'échelle nationale. Cette formation est couronnée par un CES de révision comptable permettant à son titulaire d'exercer sa fonction sous l'égide de l'ordre des experts comptables.

En parallèle à cette activité académique, l'ISCAE participe activement dans les manifestations scientifiques nationales et internationales à travers ses différents départements, le

laboratoire LIGUE et le projet PAQ.

Afin d'assurer une meilleure intégration professionnelle (à travers des stages) et favoriser l'employabilité de ses diplômés, l'ISCAE entretient des relations de partenariat avec les entreprises.

L'ISCAE met à la disposition de ses étudiants un cadre adéquat et des clubs pour exercer leurs activités culturelles et sportives.

3. Méthodologie adoptée :

L'objectif de toute approche de conduite de projet est d'obtenir des résultats fiables. En fait, la fiabilité d'un système dépend de l'approche utilisée. Nous avons adopté pour un processus de développement logiciel appelé Processus Unifié. Le processus unifié est un processus générique qui utilise UML comme langage de modélisation.

Ce processus simplifié aux caractéristiques suivantes :

· Piloté par les cas d'utilisation d'UML

· Ne néglige pas l'analyse et la conception


· Utilise 20% d'UML pour modéliser 80% du système

Le processus simplifié est composé des phases suivantes :

· Étude des besoins

· Analyse

· Conception

· Implémentation

4. Organisation de rapport

Dans ce rapport j'ai commencé par faire une présentation de projet, ainsi le choix méthodologique suivi.

J'ai spécifié par la suite les besoins fonctionnels de l'application, le diagramme du cas d'utilisation général du système.

Par la suite j'ai étudié la partie conception qui contiendra une description détaillée de cas d'utilisation, les diagrammes de séquence ainsi que le diagramme de classe détaillé.

Après avoir achevés la partie conception j'ai définis dans le dernier chapitre l'étude technique en précisons l'outil de travail et la partie implémentation où j'ai illustré quelques interfaces qui donnent une idée sur les fonctionnalités de l'application.

6. Conclusion

Ce chapitre m'a permis d'introduire mon projet, de présenter mon institut et de préciser le travail demandé ainsi que la méthodologie de travail.

L'étude et la spécification des besoins seront décrites dans le chapitre suivant

Chapitre 2 :

Définition des besoins et

analyse

1.

Introduction

Dans ce chapitre je voudrai présenter les principes de fonctionnement du système utilisé. Je commencerai par une description de l'existant puis déterminer les besoins fonctionnels et non fonctionnels du système ensuite définir les acteurs qui interagissent avec le système en utilisant le diagramme des cas d'utilisation.

2. Description de l'existant

 

2.1 Critique de l'existant

L'analyse de l'existant met l'accent sur plusieurs difficultés telles que :

i Le travail de certaines pharmacies hospitalières et celles des dispensaires publics se fait encore manuellement.

i Négligence du facteur temps : le facteur temps est un facteur fondamental pour toutes activités dans le centre médical et vue que les tâches destinées au responsable de pharmacie, pour bien gérer le stock des médicaments, il sera difficile de réussir cette tâche manuellement, aussi bien pour les différentes ordonnances que pour les statistiques qui lui sont associées.

? Mal organisation du travail dans la pharmacie.

i les documents (fiche de produit, bon de commande, bon de livraison, etc.) ne sont pas bien détaillés.

1 Volume important des informations traitées manuellement, ce qui provoque parfois des erreurs dans l'établissement des documents.

1 Recherche difficile sur les registres qui engendre une perte de temps. 1 Insécurité des informations.

1 Possibilité d'erreur dans le remplissage des différents documents et registres. 1 Possibilité d'erreur dans les calculs des statistiques.

1 Nombre important des archives qui engendre une difficulté de stockage. ( Détérioration des archives à force de leur utilisation trop fréquente.

1 Mauvaise codification sur quelques objets dans la gestion d'information.

2.2 Orientations(Solutions) :

Afin de corriger les problèmes présentés ci-dessus, je suis appelé à réaliser cette application qui assure les points suivants :

1 Automatiser les tâches qui se traitent manuellement.

1 Faciliter la recherche et l'accès aux informations.

1 Sauvegarder toutes les données relatives à la gestion des ordonnances sur des supports informatiques ce qui assurera leur sécurité.

1 Minimiser les supports papiers utilisés.

1 Faire toute modification (ajout, suppression, modification) automatiquement. 1 Plus d'organisation dans le travail du responsable de pharmacie.

1 Faciliter la recherche de l'information.

1 Rapidité dans l'établissement des différents documents.

1 Gain de temps dans les calculs des statistiques.

1 Proposer une bonne codification.

3. Les besoins fonctionnels :

Les besoins fonctionnels se rapportent aux fonctionnalités que l'application en question doit offrir pour satisfaire les utilisateurs.

Les fonctionnalités que doit intégrer l'application à développer peuvent être décrites comme suit :

v' Gestion des sécurités : Le Système permet de gérer les droits d'accès de chaque utilisateur ainsi les menus qui seront affichés selon le privilège

v' Gestion des médicaments : Cette opération consiste à suivre l'état du stock à savoir les mouvements réalisés sur le stock (entrée /sortie de médicament, quantité des médicaments dans le stock).

1' Gestion des Commandes : cette opération est établie lorsqu'il y a un besoin de renouveler le stock des médicaments. L'utilisateur doit créer un bon de commande correspondant à ses besoins.

v' Gestion des Livraisons : le système permettra à l'utilisateur de créer un bon de livraison concernant les médicaments livrés (code médicament, la quantité livrée, le prix unitaire, etc..).

1' Gestion des ordonnances : permet de valider les bons des médicaments et de consulter la liste des ordonnances.

1' Statistiques : cette fonction permettra de suivre les différentes statistiques possibles selon le type de produit (Cosmétique, Beauté et Soin, Protection, Divers...)

4. Les besoins non fonctionnels

Les besoins non fonctionnels sont indispensables et permettent l'amélioration de la qualitélogicielle de notre système. Ils agissent comme des contraintes sur les solutions, mais leur

prise en considération fait éviter plusieurs incohérences dans le système. Ce dernier doit répondre aux exigences suivantes :

v' Authentification : le système doit permettre à l'utilisateur de saisir son login et son mot de passe pour accèder au système. Cette opération assure la sécurité du système et limite le nombre des utilisateurs.

v' Ergonomie : le système devra offrir aux utilisateurs une interface qui soit le plus riche possible afin de limiter le nombre d'écrans. Par ailleurs, l'interactivité devra être adaptée (usage du clavier, menu, etc..).

5. Les cas d'utilisation

5.1 Définition

Les cas d'utilisation représentent un élément essentiel de la modélisation orientée objet : ils doivent en principe permettre de concevoir et de construire un système adapté aux besoins de l'utilisateur.

Les cas d'utilisation se déterminent en observant et en précisant, acteur par acteur, les séquences d'interaction -les scénarios- du point de vue de l'utilisateur.

5.2 Identification des acteurs du système

Un acteur représente un rôle joué par une personne ou une chose qui interagit avec un système. En réponse à l'action d'un acteur, le système fournit un service qui correspond à son besoin.

Les différents acteurs définis pour notre système sont les suivants :

v' Pharmacien (principal) : Il s'occupe à la fois de la partie d'ordonnances, de la gestion de médicaments, de la gestion d'achat et de la réalisation des statistiques:

+ Partie ordonnance : recevoir les bons des médicaments provenant des clients

et enregistrer les informations nécessaires pour chaque ordonnance

+ Gestion médicaments : Il a pour rôle d'effectuer le traitement qui touche

directement au stock : demandes des produits, suivi des mouvements et l'état du stock.

+ Gestion d'achat : pour déterminer la quantité de médicament un bon de

commande est préparé, suivi d'un bon de livraison qui peut être associé à une ou plusieurs commandes.

+ Partie statistique : suivre les statistiques des médicaments qui se trouvent dans le stock

v' Fournisseur (secondaire) : Il a pour rôle de fournir les différents produits dont la pharmacie a besoin.

" Client (secondaire): Il peut être soit un employé (identifié par son matricule), soit un dispensaire appartenant au service médical

5.3 Description du modèle de cas d'utilisation

Les diagrammes de cas d'utilisation représentent les cas d'utilisation, les acteurs et les relations entre eux.

5.3.1 Diagramme global des cas d'utilisation

Figure 2.1:Diagramme de cas d'utilisation initial

5.3.2 Raffinement des cas d'utilisations

a) Raffinement du cas d'utilisation << s'identifier >>

Figure 2.2:Diagramme de cas d'utilisation << s'identifier >>

b) Raffinement du cas d'utilisation << gestion des médicaments >>

Figure2.3:Diagramme de cas d'utilisation << gestion des médicaments >>

<<extend>>

Figure 2.4:Diagramme de cas d'utilisation << Gestion des fournisseurs >>

d) Raffinement du cas d'utilisation << Gestion des alertes >>

Figure 2.5:Diagramme de cas d'utilisation << Gestion des alertes >>

Cotio

Gestion des aertes

Figure 2.6:Diagramme de cas d'utilisation << Gestion des commandes >>

f) Raffinement du cas d'utilisation << Gestion des Livraisons >>


·

Figure 2.7:Diagramme de cas d'utilisation << Gestion des livraisons>>

g) Raffinement du cas d'utilisation << Gestion des Ordonnances>>

Figure 2.8:Diagramme de cas d'utilisation << Gestion des ordonnances>>

h) Raffinement du cas d'utilisation << Gestion des administrations>>

Figure 2.9:Diagramme de cas d'utilisation << Gestion des administrations>>

<<extend

i) Raffinement du cas d'utilisation << Gestion des états>>

Figure 3 : Diagramme de cas d'utilisation << Gestion des états >>

iaue

<<ex

Figure 3.1 : Diagramme de cas d'utilisation << Statistique >>

Consulter liste des medicaments

Statistique

6. Conclusion

j) Raffinement du cas d'utilisation << Statistiques>>

L'étude préalable appelée techniquement ingénierie des exigences ou analyse et spécification des besoins, constitue une phase capitale dans le cas oil toute la suite du projet dépend d'elle, elle doit être faite avec beaucoup de rigueur et plus d'attention pour que le projet réussisse avec un grand succès.

Dans ce chapitre, j'ai exposé les problèmes de la pharmacie et de l'existant, puis j'ai fait les critiques du travail manuel et enfin j'ai fait une approche de solution qui consiste à concevoir et à développer une application qui facilitera les services énumérés précédemment.

Le model global de cas d'utilisation va servir pour entamer l'analyse et la conception des différents cas d'utilisation qui s'effectueront durant la phase suivante qui est la phase de conception.

Chapitre 3:

Conception

1.

Introduction

Dans cette phase, je vais représenter une vue dynamique du système a travers les différents diagrammes de séquences relatifs aux cas d'utilisations.

Enfin, je dégagerai les différentes tables de la base de données via le diagramme de classe.

2. Description du modèle de cas d'utilisation

Les diagrammes de cas d'utilisation représentent les cas d'utilisation, les acteurs et les relations entre eux.

2.1 Raffinement des cas d'utilisations

2.1.1 Raffinement du cas d'utilisation << s'identifier >>

Figure 3.2:Diagramme de cas d'utilisation << s'identifier >>

1' Description du cas d'utilisation << s'authentifier >>

+ Nom du cas : s'authentifier.

+ Acteur initiateur : L'utilisateur.

+ But du cas : un utilisateur entre son login et son mot de passe pour accéder à l'application.

+ Description des scénarios :

1. Le cas d'utilisation commence lorsque l'utilisateur cherche à accéder au système et qu'en contre partie le système lui demande de saisir son login et son mot de passe.

2. L'utilisateur saisit ainsi son login et son mot de passe et valide.

3. Le système affiche le menu principal.

v Post condition : Affichage du menu principal.

2.1.2 Raffinement du cas d'utilisation << Gestion des produits >>

Figure 3.3:Diagramme de cas d'utilisation << Gestion des produits >>

Description du cas d'utilisation << Création >> Nom du cas : Création.

v Acteur initiateur : L'utilisateur (Pharmacien).

v But du cas : Le système permet de créer un nouveau médicament.

v Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande à créer

un nouveau médicament.

2. Le système affiche l'interface appropriée.

td

3. L'utilisateur effectue les opérations de création.

4. Le système enregistre l'opération effectuée.

pon

v Post condition : médicament crée.

1' Description du cas d'utilisation << Modification >>

+ Nom du cas : Modification.

+ Acteur initiateur : L'utilisateur (Pharmacien).

+ But du cas : Le système permettra à l'utilisateur de modifier les données d'un médicament.

+ Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande

de modifier les données d'un médicament.

2. Le système affiche l'interface appropriée.

. 3. L'utilisateur sélectionne le médicament à modifier.

4. L'utilisateur saisit ensuite les nouveaux paramètres et valide.

5. Le système enregistre les modifications.

+ Post condition : médicament modifié.

1' Description du cas d'utilisation << Consultation >>

+ Nom du cas : Consultation.

+ Acteur initiateur : L'utilisateur (Pharmacien).

+ But du cas : Le système permettra à l'utilisateur de visualiser La liste des médicaments.

+ Description des scénarios :

1. Le cas d'utilisation commence lorsque l'utilisateur demande

d'afficher la liste des médicaments.

3. Le système affiche l'interface appropriée.

4. L'utilisateur demande la recherche d'un médicament en cas de besoin.

5. Le système affiche les données concernant le médicament.

1' Description du cas d'utilisation << Suppression >>

+ Nom du cas : Suppression.

+ Acteur initiateur : L'utilisateur (Pharmacien).

+ But du cas : Le système permettra à l'utilisateur de supprimer un médicament de la liste.

+ Description des scénarios :

1. Le cas d'utilisation commence lorsque l'utilisateur demande

La suppression d'un médicament.

2. Le système affiche l'interface appropriée.

3. L'utilisateur sélectionne le médicament à supprimer et valide.

4. Le système supprime le médicament sélectionné.

+ Post condition : médicament supprimé.

2.1.3 Raffinement du cas d'utilisation << Gestion des fournisseurs >> :

<<exten

Figure 3.4:Diagramme de cas d'utilisation << Gestion des fournisseurs >>

1' Description du cas d'utilisation << Création d'un fournisseur >>

+ Nom du cas : Création d'un fournisseur.

+ Acteur initiateur : L'utilisateur (pharmacien).

+ But du cas : Le système permettra à l'utilisateur de créer un nouveau fournisseur.

+ Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande de créer un fournisseur.

2. Le système affiche l'interface appropriée.

3. L'utilisateur saisit les donnés nécessaire et valide.

4. Le système enregistre l'opération effectuée.

+ Post condition : fournisseur crée.

1' Description du cas d'utilisation << Consultation d'un fournisseur >>

+ Nom du cas : Consultation des fournisseurs. + Acteur initiateur : L'utilisateur (pharmacien).

+ But du cas : Le système permettra à l'utilisateur de consulter la liste des

fournisseurs et d'afficher les détails concernant un fournisseur sélectionné. + Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande d'afficher la liste des fournisseurs.

2. Le système affiche l'interface appropriée.

3. L'utilisateur sélectionne le fournisseur à consulter en cas de besoin.

4. Le système affiche les données des fournisseurs.

2.1.4 Raffinement du cas d'utilisation << Gestion des alertes>>

Figure 3.5:Diagramme de cas d'utilisation << Gestion des alertes>>

Description du cas d'utilisation << Création d'une livraison >>

v Nom du cas : Création d'une alerte.

v Acteur initiateur : L'utilisateur (pharmacien).

n

v But du cas : Le système permettra à l'utilisateur de créer une alerte

v Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande de

extend

créer une alerte

2. Le système affiche l'interface appropriée.

3. L'utilisateur saisit les donnés nécessaire et valide.

4. Le système enregistre l'opération effectuée.

v Post condition : alerte crée.

Suppressio

1' Description du cas d'utilisation << Consultation des alertes>>

+ Nom du cas : Consultation des alertes.

+ Acteur initiateur : L'utilisateur (pharmacien).

+ But du cas : Le système permettra à l'utilisateur de consulter la liste des alertes et d'afficher les détails concernant une alerte sélectionnée.

+ Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande d'afficher la liste des alertes.

2. Le système affiche l'interface appropriée.

3. L'utilisateur sélectionne l'alerte à consulter en cas de besoin.

4. Le système affiche les données de l'alerte.

2.1.5 Raffinement du cas d'utilisation << Gestion des commandes >>

 
 
 

on

Figure 3.6:Diagramme de cas d'utilisation << Gestion des commandes >>

<<extend>>

v' Description du cas d'utilisation << Création d'une commande>>

+ Nom du cas : Création d'une commande.

+ Acteur initiateur : L'utilisateur (pharmacien).

+ But du cas : Le système permettra à l'utilisateur de créer une commande

+ Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande de créer une commande.

2. Le système affiche l'interface appropriée.

3. L'utilisateur saisit les donnés nécessaire et valide.

4. Le système enregistre l'opération effectuée.

+ Post condition : commande crée.

1' Description du cas d'utilisation << Modification >>

+ Nom du cas : Modification.

+ Acteur initiateur : L'utilisateur (Pharmacien).

+ But du cas : Le système permettra à l'utilisateur de modifier les données d'une commande.

+ Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande

de modifier les données d'une commande.

2. Le système affiche l'interface appropriée.

. 3. L'utilisateur sélectionne la commande à modifier.

4. L'utilisateur saisit ensuite les nouveaux paramètres et valide.

5. Le système enregistre les modifications.

+ Post condition : commande modifié.

+ Nom du cas : Consultation.

+ Acteur initiateur : L'utilisateur (Pharmacien).

+ But du cas : Le système permettra à l'utilisateur de visualiser La liste des commandes.

+ Description des scénarios :

1. Le cas d'utilisation commence lorsque l'utilisateur demande

d'afficher la liste des commandes.

2. Le système affiche l'interface appropriée.

3. L'utilisateur demande la recherche d'une commande en cas de besoin.

4. Le système affiche les données concernant la commande.

1' Description du cas d'utilisation << Suppression >>

+ Nom du cas : Suppression.

+ Acteur initiateur : L'utilisateur (Pharmacien).

+ But du cas : Le système permettra à l'utilisateur de supprimer une commande de la liste.

+ Description des scénarios :

1. Le cas d'utilisation commence lorsque l'utilisateur demande

La suppression d'une commande.

3. Le système affiche l'interface appropriée.

4. L'utilisateur sélectionne la commande à supprimer et il le valide.

5. Le système supprime la commande sélectionné.

+ Post condition : commande supprimé.

2.1.6 Raffinement du cas d'utilisation << Gestion des livraisons >>

Figure 3.7:Diagramme de cas d'utilisation << Gestion des livraisons >> v' Description du cas d'utilisation << Création d'une livraison>>

+ Nom du cas : Création d'une livraison.

+ Acteur initiateur : L'utilisateur (pharmacien).

+ But du cas : Le système permettra à l'utilisateur de créer une livraison.

Création

+ Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande de créer une livraison.

2. Le système affiche l'interface appropriée.

3. L'utilisateur saisit les donnés nécessaire et valide.

4. Le système enregistre l'opération effectuée.

+ Post condition : livraison crée.

C lt ti

+ Nom du cas : Consultation.

+ Acteur initiateur : L'utilisateur (Pharmacien).

+ But du cas : Le système permettra à l'utilisateur de visualiser La liste des livraisons.

+ Description des scénarios :

1. Le cas d'utilisation commence lorsque l'utilisateur demande

d'afficher la liste des livraisons.

2. Le système affiche l'interface appropriée.

3. L'utilisateur demande la recherche d'une livraison en cas de besoin.

4. Le système affiche les données concernant la livraison. 2.1.7 Raffinement du cas d'utilisation << Gestion des ordonnances >>

an

Figure 3.8:Diagramme de cas d'utilisation << Gestion des ordonnances >>

<<extend>>

v' Description du cas d'utilisation << Consultation des ordonnances >>

+ Nom du cas : Consultation des ordonnances. + Acteur initiateur : L'utilisateur (pharmacien).

+ But du cas : Le système permettra à l'utilisateur de consulter la liste des

ordonnances et d'afficher les détails concernant une ordonnance

sélectionné.

+ Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande d'afficher la liste des ordonnances.

2. Le système affiche l'interface appropriée.

3. L'utilisateur sélectionne l'ordonnance à consulter en cas de besoin.

4. Le système affiche les données de l'ordonnance. + Post condition : l'ordonnance est affichée.

1' Description du cas d'utilisation << Valider ordonnance >>

+ Nom du cas : Valider ordonnance.

+ Acteur initiateur : L'utilisateur (pharmacien).

+ But du cas : Le système permettra à l'utilisateur d'enregistrer les donnés concernant l'ordonnance (nom client, date, description et nom du médecin)

+ Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande d'effectuer les opérations d'enregistrement.

2. Le système affiche l'interface appropriée.

3. L'utilisateur saisie les donnés nécessaire et valide.

4. Le système enregistre l'opération effectuée.

+ Post condition : l'ordonnance est validée.

2.1.8 Raffinement du cas d'utilisation << Gestion des administrations>>

Figure 3.9:Diagramme de cas d'utilisation << Gestion des administrations >> Description du cas d'utilisation << Ajouter >>

v Nom du cas : Ajouter.

v Acteur initiateur : L'utilisateur (Pharmacien).

Ajoter privilége et un mt de

v But du cas : Le système permet de créer un nouveau privilège et un mot de passe.

v Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande à créer passe un nouveau privilège et un mot de passe.

1. Le système affiche l'interface appropriée.

2. L'utilisateur effectue les opérations de création.

3. Le système enregistre l'opération effectuée.

passe

v Post condition : un nouveau privilège et un mot de passe sont crée.

Description du cas d'utilisation << Modification >>

v Nom du cas : Modification.

v Acteur initiateur : L'utilisateur (Pharmacien).

v But du cas : Le système permettra à l'utilisateur de modifier les privilèges ou les mots de passe des utilisateurs.

v Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande

de modifier les privilèges ou les mots de passe des utilisateurs. 2. Le système affiche l'interface appropriée.

. 3. L'utilisateur sélectionne l'utilisateur à modifier.

4. L'utilisateur saisit ensuite les nouveaux paramètres et valide.

5. Le système enregistre les modifications.

v Post condition : les privilèges ou les mots de passe des utilisateurs sont modifiés.

2.1.9 Raffinement du cas d'utilisation << Gestion des états>>

<<extend>>

Figure 4:Diagramme de cas d'utilisation << Gestion des états >>

Consulter lste des produits

Gti d tt

Description du cas d'utilisation << Consulter liste des produits >>

v Nom du cas : Consulter liste des produits.

v Acteur initiateur : L'utilisateur (pharmacien).

v But du cas : Le système permettra à l'utilisateur de consulter la liste des produits et d'afficher les détails concernant un produit sélectionné.

v Description des scénarios:

1.

Le cas d'utilisation commence lorsque l'utilisateur demande d'afficher la liste des produits.

2. Le système affiche l'interface appropriée.

3. L'utilisateur sélectionne la liste à consulter en cas de besoin.

4. Le système affiche la liste des produits.

+ Post condition : la liste des produits est affichée.

2.1.10 Raffinement du cas d'utilisation << Statistique>>

Figure 4.1:Diagramme de cas d'utilisation << Statistique>> 1' Description du cas d'utilisation << Statistique >>

C

+ Nom du cas : Statistique.

+ Acteur initiateur : L'utilisateur (pharmacien).

+ But du cas : Le système permettra à l'utilisateur d'afficher la statistique des médicaments en stock.

+ Description des scénarios:

1. Le cas d'utilisation commence lorsque l'utilisateur demande de consulter la table de statistique.

2. Le système affiche l'interface appropriée.

+ Post condition : Statistique des produits est affichée.

3. Les diagrammes de séquence :

3.1 Definition :

Les diagrammes de séquence montrent des interactions entre objets selon un point de vue
temporel. Le contexte des objets n'est pas représenté de manière explicite comme dans les

diagrammes de collaboration. La représentation se concentre sur l'expression des

interactions.

Un diagramme de séquence représente une interaction entre objets en insistant sur la

chronologie des envois de messages. La notation est dérivée des « Object Message Séquence du Siemens Pattern Group ».

3.2 Diagramme Séquence

3.2.1 Diagramme de séquence du cas d'utilisation << S'identifier >>

Figure 4.2: Diagramme de séquence du cas d'utilisation << S'identifier >> 3.2.2 Diagramme de séquence du cas d'utilisation << Gestion des médicaments >> 1' Diagramme de séquence du cas d'utilisation << Creation >>

cher interfa

Figure 4.3: Diagramme de séquence du cas d'utilisation << Création >> + Diagramme de séquence du cas d'utilisation << Modification >>

Figure 4.4: Diagramme de séquence du cas d'utilisation << Modification >>

1' Diagramme de séquence du cas d'utilisation << Consultation >>

nee

caments(

Figure 4.5: Diagramme de séquence du cas d'utilisation << Consultation >>

1' Diagramme de séquence du cas d'utilisation << Suppression >>

rface( )

Figure 4.6: Diagramme de séquence du cas d'utilisation << Suppression >>

3.2.3 Diagramme de séquence du cas d'utilisation << Gestion des commandes >> 1' Diagramme de séquence du cas d'utilisation << Création d'une commande >>

command

Figure 4.7: Diagramme de séquence du cas d'utilisation << Création d'une commande >>

1' Diagramme de séquence du cas d'utilisation << Consultation des commandes >>

Mise_A_Jour_BD

Afficer Operaton reussie

Figure 4.8: Diagramme de séquence du cas d'utilisation << Consultation des commandes >>

3.2.4 Diagramme de séquence du cas d'utilisation << Gestion des livraisons >>

Diagramme de séquence du cas d'utilisation << Création d'une livraison >>

Livraison Table Ligne Livr

Figure 4.9: Diagramme de séquence du cas d'utilisation << Création d'une livraison >>

Diagramme de séquence du cas d'utilisation << Consultation des livraisons >>

ons()

Figure 5: Diagramme de séquence du cas d'utilisation << Consultation des livraisons >>

Seectionne Livaison()

3.2.5 Diagramme de séquence du cas d'utilisation << Gestion des ordonnances >> 1' Diagramme de séquence du cas d'utilisation << Valider ordonnance >>

nces

Gestionnair

Figure 5.1:Diagramme de séquence du cas d'utilisation << Valider ordonnance >>

saisie date)

1' Diagramme de séquence du cas d'utilisation << Consultation des ordonnances >>

Figure 5.2:Diagramme de sequence du cas d'utilisation << Consultation des ordonnances>>

3.2.6 Diagramme de séquence du cas d'utilisation << Statistiques >>

1' Diagramme de séquence du cas d'utilisation << Statistiques >>

statistiqu

Figure 5.3: Diagramme de séquence du cas d'utilisation << Statistiques >>

4. Le diagramme de Classes

Le diagramme de classes exprime de manière générale la structure statique d'un système en termes de classes et de relations entre les classes. Une classe permet de décrire un ensemble d'objets (attributs et comportement), tandis qu'une relation ou association permet de faire apparaitre des liens entre ces objets. Un diagramme de classes fait abstraction des aspects dynamiques et temporels : il permet de modéliser les vues statiques du système. Le diagramme de classes est le point central dans un développement oriente objet. En analyse, il a pour objectif de décrire la structure des entités manipulées par les utilisateurs. En conception, le diagramme de classes représente la structure d'un code oriente objet ou, a un niveau de détail plus important, les modules du langage de développement. Le diagramme de classes met en oeuvre des classes, contenant des attributs et des opérations, relies par des associations ou des généralisations.

Le diagramme représenté ci-dessous représente des tables objets :

Figure 5.4: Le Diagramme de classe

6. Conclusion

Durant cette phase, j'ai achevé l'analyse de tous les cas d'utilisations via la description des différents diagrammes de séquences, de cas d'utilisation et l'exposition du diagramme de classe J'ai entamerai dans la prochaine phase, la construction du système en présentant l'environnement technique, et une description des différentes interfaces de l'application.

Chapitre 4:

Etude technique

et

implémentation

1.

Introduction

Dans ce chapitre je vais s'intéresser à la présentation de l'environnement matériel et logiciel utilisés pour assurer la réalisation de l'application.

Il s'agit en plus de décrire les étapes de mise en oeuvre de l'application ainsi que les différentes interfaces permettant l'interaction entre l'utilisateur et le système à développer et décrivant les différentes phases suivies pour la réalisation.

2. Environnement matériel et logiciel :

 

2.1 Environnement matériel :

Pendant la phase de documentation, de spécification des besoins, de conception et de développement, j'ai servis d'un PC ayant les caractéristiques suivantes :

v' Processeur Intel® Pentium® Dual CPU T

v' 3070 MB de mémoire vive.

v' Disque dur de capacité 78 Go .

v' Système d'exploitation Microsoft Windows XP Professionnel.

2.2 Environnement logiciel

 

Je présenterai dans ce paragraphe les différents logiciels utilisés pour la réalisation de ce projet regroupé par catégorie d'utilisation.

2.2.1 UML

UML est l'Unified Modeling Language standardisé par l'OMG (ObjectManagement Group).
Ce n'est pas une méthode, il ne donne pas de solution pour la mise en oeuvre d'un projet. C'est

avant tout un formalisme graphique issu de notations employées dans différentes méthodes

objets.

2.2.2 IBM Rational Rose Entreprise Edition

Rational Rose est un logiciel qui permet de représenter les différents produits de l'analyse et de la conception orientée objet. Il permet de représenter les notations du langage de modélisation unifié, les notations de la méthode Booch et celles de la méthode OMT.

2.2.3 SGBD ORACLE :

 

Développé à la fin des années 1970, Oracle est un système de gestion de bases de données relationnelle. Il permet la gestion de basse de données relationnelles réparties sur un réseau hétérogène en architecture client/serveurs.

Le choix du SGBD s'est porté sur Oracle pour bénéficier de ses avantages et caractéristiques à savoir :

+ Portabilité : En effet Oracle est supporté par la majorité des systèmes d'exploitation figurant sur le marché (il tourne sur plus de 60 plates-formes différentes) et comme mon objectif est de développer une application sur le contrôle des lieux publics qui peut être hébergé sur un serveur tournant sur plusieurs postes.

+ Performance : Le SGBD Oracle offre de bonnes performances et des outils permettant de les mesurer et de les contrôler grâce à des paramètres de configuration. Des processus d'optimisation en temps réel des requêtes complexes sont aussi présents.

Les données peuvent être indexées de manière souple, dynamique et complète.

+ Sécurité : La disponibilité, la confidentialité, la cohérence et la surveillance des données qu'il gère.

2.2.4 Eclipse Galileo

 

Eclipse Galileo est un environnement de développement intégré libre (le terme Eclipse désigne également le projet correspondant, lancé par IBM) extensible, universel et polyvalent, permettant potentiellement de créer des projets de développement mettant en oeuvre n'importe quel langage de programmation Eclipse est principalement écrit en Java (à l'aide de la bibliothèque graphique SWT, d'IBM), et ce langage, grâce à des bibliothèques spécifiques, est également utilisé pour écrire des extensions.

La spécificité d'Eclipse Galileo vient du fait de son architecture totalement développée autour de la notion de plug-in (en conformité avec la norme OSGi) : toutes les fonctionnalités de cet atelier logiciel sont développées en tant que plug-in.

2.2.5 GlassFish

 

GlassFish est le nom du serveur d'applications Open Source Java EE 5 et qui sert de fondation au produit Sun Java System Application Server1 de Sun Microsystems. Sa partie Toplink persistance provient d'Oracle. C'est la réponse aux développeurs Java désireux d'accéder aux sources et de contribuer au développement des serveurs d'applications de nouvelle génération de Sun.

GlassFish est sous double licence CDDL et GPLv2 et il est certifié Java EE 5 (EJB3 + JPA + JSF + JAX-WS 2.x + ...).

2.2.5 Adobe Flex Builder

 

Flex est une solution de développement créée par Macromedia en 2004 puis reprise par Adobe en 2006, permettant de créer et de déployer des applications Internet

riches (RIA) multi plates-formes grâce à la technologie Flash et particulièrement son lecteur. Son modèle de programmation fait appel à MXML (basé sur XML) et ActionScript 3.0, reposant sur ECMAScript.

La technologie Flex produit un fichier .swf intégré dans une page html. La richesse de l'interface graphique ainsi générée a le désavantage comme toutes applets de générer ici un fichier .swf sur le serveur un peu long à télécharger dans le poste client lors du chargement de la page.

2.2.6 Les Fichier Jar

 

En informatique, un fichier JAR (Java ARchive) est un fichier ZIP utilisé pour distribuer un ensemble de classes Java. Ce format est utilisé pour stocker les définitions des classes, ainsi que des métadonnées, constituant l'ensemble d'un programme.

Les fichiers JAR sont créés et extraits à l'aide de la commande jar incluse dans le JDK. On peut cependant renommer les fichiers .jar avec l'extension.zip et les manipuler avec les outils ZIP. La classe Java JarFile du package java.util.jar hérite de ZipFile.

Un fichier JAR peut contenir un fichier manifeste, situé dans le chemin METAINF/MANIFEST.MF. Les données du fichier manifesté spécifient comment le fichier JAR sera utilisé. Les fichiers JAR sont destinés à être exécutés comme des programmes indépendants, dont une des classes est la classe principale. Le fichier manifeste peut comporter la déclaration suivante :

Pour exécuter un tel fichier JAR, il faut entrer la ligne de commande suivante :

Formats connexes

· Les fichiers Open Document sont des archives JAR contenant des fichiers XML et d'autres objets ;

· Les fichiers WAR (Web Application aRchive) sont des archives JAR contenant des
fichiers XML, des classes Java, des JSP et d'autres objets pour les applications Web ;

· Les fichiers EAR (Enterprise Application aRchive) sont des archives JAR contenant des fichiers XML, des classes Java et d'autres objets pour les applications d'entreprise ;

· Les fichiers RAR (Resource Adapter aRchive) sont des archives JAR contenant des fichiers XML, des classes Java et d'autres objets pour l'architecture de connecteurs (JCA) de la plateforme J2EE;

Java Development Kit (JDK) :

 
 

C'est un kit de développement java qui fournit les outils au packages nécessaire pour le développement et le test de programmes écrits dans le langage de développement JAVA.

Gestion
produit

Gestion
fournisseu
r

3. Présentation de l'application

Dans cette partie, je présente les principales fonctionnalités de mon application à travers les interfaces réalisées.

3.3 Structure globale de l'application

Gestion
alerte

Gestion
commande

55 t

Authentification

Menu principale

Gestion
livraison

l b

Gestion
ordonnanc

e l'appliat

e

Gestion
sécurité

Gestion Statistique

des états

3.4 Fonctionnalités de l'application

 

? Page d'authentification

Un utilisateur ne pourra accéder au système que s'il s'identifie en indiquant son nom et son mot de passe. Une fois l'utilisateur s'est authentifié, selon son niveau d'accès une page écran lui sera affichée présentant plusieurs choix :

+ Gestion Produit

+ Gestion Fournisseur + Gestion Alerte

+ Gestion Commande + Gestion Livraison

+ Gestion Ordonnances

+ Gestion d'administration et sécurité + Edition des Etats

+ Statistiques

Figure 5.6 page authentification

i Menu principal

Cette interface représente la page d'accueil de notre application offrant à l'utilisateur les 9 principaux choix .J'ai veillé a ce que les interfaces soient assez conviviales: le choix des couleurs, l'ergonomie et la clarté du contenu permettent de faciliter son exploitation par l'utilisateur.

Menu Principal

Figure 5.7 menu principal ? Fenêtre Gestion Produit

Figure 5.8 Gestion des produits(Ajouter)

Cette interface permet a l'utilisateur d'ajouter un médicament selon le type de produit (Cosmétique, Beauté et soin, Bébé, Protection, Santé et nature, Forme et énergie, Divers...)

Figure 5.9 Gestion des produits(Consulter)

Cette interface permet à l'utilisateur de visualiser les différents détails concernant la liste des
produits (Référence, description, Stock min, Prix unitaire, Type produit, Stock

disponible). Il suffit de faire un simple clic sur l'icône pour voir les détails dans le

tableau Informations.

Cette interface offre aussi une barre à outils dans laquelle en peut soit :

+ Chercher des médicaments selon un critère bien défini (référence, prix unitaire, type produit) ;

+ Effectuer des opérations de mise à jour (ajouter, modifier, supprimer) ; + Afficher la liste des médicaments.

v' Fenêtre Gestion des fournisseurs

Figure6 : Gestion des fournisseurs (Ajouter)

Cette interface permet de saisir les différents détails concernant un fournisseur. Chaque fois qu'on veut ajouter un fournisseur, une liste est disponible dans le tableau Liste Fournisseur pour faciliter la tache à l'utilisateur.

Figure 6.1 Gestion des fournisseurs (Consulter)

Cette interface permet d'afficher la liste des fournisseurs qui travaillent en collaboration avec la pharmacie.

v' Fenêtre Gestion des Alertes

Figure 6.2 Gestion des alertes (Consulter)

Cette interface permet d'afficher les produits qui atteignent la quantité minimale.

v' Fenêtre Gestion Commandes

Figure 6.3 gestion commandes (Création)

Cette interface permet de saisir les différents détails concernant une commande. Chaque fois qu'on veut ajouter une commande, une liste des fournisseurs est disponible dans le Combo Box pour faciliter la tache à l'utilisateur.

Figure 6.4 gestion commandes (Création d'une ligne de commande)

Cette interface permet à l'utilisateur de créer les lignes commandes pour une commande sélectionnée.

Figure 6.5 Gestions commandes (Consulter)

Cette interface affiche une liste de commande

? Fenêtre Gestion des livraisons

Figure 6.6 gestion Livraison (Création)

Cette interface permet d'ajouter un bon de livraison .On peut remarquer que la saisie du code de livraison est un obligataire.

Figure 6.7 gestion Livraison (Création détail livraison)

Cette interface permet de saisir la quantité à livrer et le référence de produit

Figure 6.8 gestion livraisons (consultation)

Cette interface permet à l'utilisateur de consulter les lignes livraisons pour une livraison sélectionnée.

? Fenêtre Gestion des Ordonnances

Figure 6.9 gestion Ordonnance (création )

Cette interface est celle des ordonnances, a partir de laquelle on peut ajouter un ou plusieurs bons d'ordonnances.

Figure 7 gestion ordonnances (création ligne commande)

Cette interface permet de saisir la référence de produit et la quantité désirée.

Figure 7.1 gestion ordonnances (Consulter)

Cette interface permet d'afficher tous les ordonnances.

+ Fenêtre Gestion d'administration et sécurité

Figure 7.2 gestion d'administration et sécurité (Création d'un nouvel utilisateur)

Cette interface permet de créer un nouveau utilisateur et de le donner un type de privilège (Administrateur ou simple utilisateur)

Figure 7.3 gestion d'administration et sécurité (Création d'un mot de passe)

Cette interface permet de créer un mot de passe pour chaque utilisateur afin d'assurer la sécurité de système

+ Fenêtre Gestion Edition des Etats

Figure 7.4 Gestion Edition des Etats (Consultation)

Cette interface permet d'afficher la liste des produits en stock .

Figure 7.5 Gestion Edition des Etats (Consultation en PDF)

Cette interface permet de choisir le format de liste de produit que l'utilisateur veux l'afficher.

Figure 7.6 Gestion Edition des Etats (Affichage produit)

Cette interface permet d'afficher la liste de produit en format choisi par l'utilisateur dans l'étape précédente.

v' Statistiques

Figure 7.7 Statistiques

Cette interface permet de donner la quantité des médicaments en stock selon leur type (Cosmétique, protection, Beauté et Soin...)

4. Conclusion

Tout au long de ce chapitre, j'ai présenté les différents outils de travail, les principales interfaces relatives aux principales fonctionnalités de mon système.

A la fin de cette phase, j'ai obtenu une version provisoire de mon application testée et corrigée.

 

Conclusion et perspective

Rappelons que l'objectif de ce travail était d'informatiser l'activité de gestion du système d'informations des pharmacies hospitalières et des dispensaires publiques. Pour cela, j'ai réalisé une application interactive permettant de gérer les différents traitements de cette activité et de satisfaire les besoins des différents utilisateurs impliqués dans ce processus de gestion.

Mon travail est débuté par la compréhension du contexte de mon projet. Ensuite, j'ai réalisé une étude de l'existant concernant les applications de gestion des activités de la pharmacie, ce qui m'a permis de fixer les anomalies à éviter et les objectifs à réaliser pour avoir un système satisfaisant. Puis, j'ai passé à la l'étude conceptuelle de mon application selon une approche orientée objet tout en se basant sur le langage UML. Par la suite, j'ai effectué le codage et l'implémentation de l'application. Enfin j'ai effectué les tests nécessaires pour valider mon application.

Ce projet a été très bénéfique pour moi car il m'a permis de renforcer et enrichir mes connaissances théoriques dans le domaine de la conception, et de mettre en application mes connaissances acquises le long de mes études. Il m'a encore donné l'occasion de maîtriser le langage de programmation Java, la base de données oracle et de me familiariser avec la conduite des projets informatiques.

En plus, ce projet était une bonne occasion pour réaliser un travail très concret, avec des objectifs clairs et bien définis et de se familiariser avec l'environnement du travail et de la vie professionnelle.

En perspective, mon application peut être améliorée en ajoutant d'autres fonctionnalités comme (Gestion des Statistique par agent, Gestion des statistique par période...). J'aurai pu aussi rendre mon application générique à travers le web. Et pour faciliter l'utilisation, je peux développer une application avec un « Help », une assistance et une démo.

Les concepts de base

I- Environnement de développement

Annexe

A

Eclipse Galileo

 
 

Eclipse c'est quoi ?

Eclipse Galileo est un puissant (open source), extensible IDE (Integrated Development Environment) pour construire des applications d'usage général. C'est un environnement de développement intégré dont le but est de fournir une plate-forme modulaire pour permettre de réaliser des développements informatiques. Eclipse utilise le concept de modules nommés "plug-ins" dans son architecture, son noyau de la plate-forme nommé "Runtime", tout le reste de la plate-forme est développé sous la forme de plug-ins.

Il offre aux développeurs plusieurs fonctionnalités telles que :

- Supporte le développement d'application visuelle (GUI) et non visuelle. - Supporte plusieurs types de langages tels que Java, Html, XML, C++...

- Peut intégrer d'autres logiciels.

Figure 1 : Squelette de la plateforme Eclipse

1. Architecture :

La base de cet environnement de développement intégré est l'Eclipse Platform, composée de :

· Platform Runtime démarrant la plateforme et gérant les plug-ins

· SWT, la bibliothèque graphique de base de l'EDI

· JFace, une bibliothèque graphique de plus haut niveau basée sur SWT

· Eclipse Workbench, la dernière couche graphique permettant de manipuler des composants, tels que des vues, des éditeurs et des perspectives.

Ces composants de base peuvent être réutilisés pour développer des clients lourds indépendants d'Eclipse grâce au projet Eclipse RCP (Rich Client Platform).

L'ensemble des outils de développement Java sont ensuite ajoutés en tant que plugins, regroupés dans le projet Java Development Tools (JDT). Ces plugins sont architecturés selon les recommandations de OSGi.

II- Les technologies mise en oeuvre

Introduction

Dans le présent chapitre, Je détaille les technologies qui concernent la connexion avec la base et la persistance des données. Je m'intéresse tout d'abord à l'API JDBC destinée à la connexion avec la base de données et l'outil « Hibernate » comme outil de persistance de ces données.

II-1- Les technologies d'accès aux données

1-1 Java Data Base Connectivity

JDBC (Java Database Connectivity) est une API permettant de travailler avec des bases de données relationnelles. Elle permet d'envoyer des requêtes SQL à une base, de récupérer et d'exploiter le résultat ainsi que d'obtenir des informations sur la base elle même et les tables qu'elle comporte.

Le code Java utilisant l'API JDBC est indépendant de la base elle même grâce à l'utilisation des pilotes spécifiques fournis par les vendeurs. On distingue quatre types de pilote JDBC :

i. Le pont JDBC/ODBC (Open DataBase Connectivity) : Le driver accède au SGBDR (système de gestion de base de données relationnelles) à travers un pont JDBC-ODBC. En fait tous les appels JDBC sont traduits en appels ODBC. C'est une solution intéressante lorsque le système de gestion de base de données ne fournit pas un pilote java spécifique pour l'accès à la base de données. Les pilotes de ce type ne sont pas performants à cause de la lenteur de l'API ODBC.

ii. Driver Java ou driver d'API natif : Le driver convertit directement les appels JDBC en appels Client pour les API Oracle, Sybase, Informix, . .C'est un pilote fourni par les constructeurs et généralement payant. Du point de vue performance, il est rapide.

iii. Driver Java à protocole natif : Il interagit avec un API réseau générique et communique avec une application intermédiaire présente sur le serveur. Les appels JDBC sont traduits en appels réseau indépendants des systèmes de gestion de base de données qui seront ensuite traduits par le serveur en appels propres au système de gestion de base de données.

iv. Driver Java natif : Il est capable de communiquer directement avec le système de gestion de base de données. C'est un pilote écrit entièrement en Java implémentant un protocole de communication spécifique au système de gestion de base de données. C'est le driver le plus intéressant en termes de faciliter, d'utilisation et de performance

1-2 Hibernate

Travailler dans les deux univers de l'orienté objet et de la base de données relationnelle peut être lourd et coûteux en temps. En effet il est plus désireux de travailler avec des objets ayant des comportements que de travailler avec des lignes et des colonnes de données, c'est pour cela qu'on a souvent recours à une couche pour faire le lien entre la représentation objet des données et la représentation relationnelle basée sur le standard SQL. Ainsi, Hibernate se

propose de joindre ces deux univers et représente la solution intéressante à ce problème, permettant de gérer la persistance des données selon une architecture adaptable avec n'importe quel système de gestion de bases de données.

1-2-1 Description

Hibernate est un outil qui Automatise ou facilite la correspondance entre des données stockées dans des objets et une base de données relationnelle, Le plus souvent les données sont décrites dans des fichiers de configuration (généralement XML). En effet, Hibernate se charge de la recherche et l'enregistrement des données associées à un objet dans une base de données et la détection des modifications apportées à un objet pour les enregistrer en optimisant les accès à la base. Hibernate propose une technique standard de configuration de n'importe quel système de gestion de base de données et assure la correspondance de type entre Java et SQL.

On peut donc voir Hibernate comme une surcouche fine de JDBC qui lui ajouterait une dimension objet.

Fig 1 : Description de Hibernate

1-2-2 Avantages

Hibernate nous évite l'écriture de code répétitif, inintéressant et source d'erreurs difficiles à déceler, de plus on peut avoir un gain de 30 à 40 % du nombre de lignes de certains projets. D'autre part cet outil améliore la portabilité du code pour des changements de système de gestion de base de données et facilite le travail du développeur qui pense en termes d'objet et

pas en termes de lignes de tables. En effet sans outil ORM le développeur peut hésiter à concevoir un modèle objet « fin » afin d'éviter du codage complexe pour la persistance

1-2-1 Architecture

Application

Objet

Persistant

SessionFactory

Session

Transaction

TransactionFactory

Connection
Provider

JNDI JDBC JTA

Base de données

Fig 2 : Architecture de Hibernate

1' SessionFactory: Un cache threadsafe (permanent) des mappings vers une (et une seule) base de données. Une fabrique (factory) de Session et un client de ConnectionProvider. Peut contenir un cache optionnel de données (de second niveau) qui est réutilisable entre les différentes transactions.

1' Session: Un objet mono-threadé, a durée de vie courte, qui représente une conversation entre l'application et l'entrepôt de persistance. Encapsule une connexion JDBC, fabrique des objets Transaction. Contient un cache (de premier niveau) des objets persistants, ce cache est obligatoire. Il est utilisé lors de la navigation dans le graphe d'objets ou lors de la récupération d'objets par leur identifiant.

1' Transaction: Un objet mono-threadé à vie courte utilisé par l'application pour définir une unité de travail atomique Une Session peut fournir plusieurs Transactions dans certains cas. Toutefois, la délimitation des transactions, via l'API d'Hibernate ou par la Transaction sous-jacente, n'est jamais optionnelle!

1' ConnectionProvider: Une fabrique de (pool de) connexions JDBC c'est à dire gérer la file d'attente pour les connexions à la base

1' TransactionFactory: c'est une fabrique des instances de Transaction.

Unified Modeling Language

et Processus unifié

Annexe

B

I- UML

A l'origine de cette nouvelle notation se trouve l'OMG (Object Management Group) qui partait du constat suivant :

v' les méthodes fonctionnelles ne permettaient pas d'exploiter le développement objet. Le mélange de plusieurs paradigmes n'est ni commode, ni naturel.

v' Le grand nombre de méthodes n'aidaient pas le choix des utilisateurs.

Les méthodes suivantes sont à la base d'UML :

v' OMT (Object Modeling Technique) conçue par James Rumbaugh.

v' OOD (Object Oriented Design) conçue par Grady Booch.

v' OOSE (Object Oriented Software Engineering) conçue par Ivar Jacobson.

Il faut insister sur le fait qu'UML n'est pas une méthode mais une notation. Il est donc possible d'utiliser la notation UML avec une démarche de conception inspirée d'OMT.

La première version d'UML est sortie le 17 janvier 1997. Entre temps des partenaires importants sont venus collaborer à la mise en oeuvre de cette notation : IBM, DEC, Microsoft, Rational Rose Software, Oracle, Unisys).

1. Principes

UML se veut être une notation simple, précise, et homogène, permettant un bon rendu visuel. Elle décrit le réalisé plutôt que le processus de réalisation.

UML préconise de séparer les aspects fonctionnels, technologiques et architecturaux.

Pour la compréhension entre les différents acteurs d'un projet UML propose des diagrammes qui vont permettre d'éclaircir les spécifications.

Enfin, pour répondre à l'évolution rapide des applications, il faut pouvoir facilement effectuer un retour sur chaque phase du cycle de développement. Le cycle de vie objet qui, itératif et incrémental, permet d'effectuer ce retour.

Pour la définition des systèmes, UML définit plusieurs modèles :

> modèle de classe qui capture la structure statique.

> modèle des états qui exprime le comportement dynamique des objets.

> modèle des cas d'utilisation qui décrit les besoins de l'utilisateur.

> modèle d'interaction qui décrit les scénarios et les flots de messages

> modèle de réalisation qui montre les unités de travail.

> modèle de déploiement qui précise la répartition du processus.

Les modèles sont regardés par les utilisateurs au moyen de vues graphiques qui peuvent être soit statiques, soit dynamique.

Vues statiques :

+ Diagramme de classes : structure statique en termes de classes et de relations. + Diagramme d'objets : instanciation des diagrammes de classes.

+ Diagramme de déploiement : les composants sur les dispositifs matériels. + Diagramme de composants : composants physiques d'une application.

+ Vues dynamiques :

+ Diagramme des activités : comportement d'une opération en termes d'actions.

+ Diagramme des cas d'utilisation : fonctions du système du point de vue l'utilisateur. + Diagramme de collaboration : représentation spatiale des objets, des liens et des

interactions.

+ Diagramme d'états transitions : comportement d'une classe en terme d'état.

+ Diagramme de séquence : représentation temporelle des objets et de leurs interactions.

2. Diagrammes UML et notations 2.1. Diagramme des cas d'utilisation

Ils décrivent sous la forme d'actions et de réactions le comportement d'un système du point de vue de l'utilisateur et donc le caractère fonctionnel des objets. Les besoins de chaque acteur déterminent l'ensemble des besoins d'un système. La description des cas d'utilisation développeur. Le cas d'utilisation décrit le quoi et le quoi faire et non le comment qui relève de la conception. Il comprend les acteurs, le système, et les cas d'utilisation eux-mêmes.

Les acteurs sont représentés par des petits personnages, les cas d'utilisation par des ellipses. Un acteur est une personne qui interagit avec un système en échangeant de l'information (en entrée et en sortie).

Délimite le système ; ils seront utilisés tout au long du cycle de vie du projet. C'est un document très important qui sert de contrat entre la personne qui a fait l'analyse et le

a Fig 1 : Représentation d'un cas d'utilisation classe

2.2. Diagramme de classe

Un diagramme de classes montre la structure statique d'un système. Il permet la visualisation des classes et des relations entre elles.

Son but est d'expliquer ce qu'il faut réaliser plutôt que d'expliquer comment le réaliser.

Fig 2 : Représentation d'une classe

3 niveaux de visibilités pour les attributs et les opérations :

> public : qui rend l'élément visible à tous les clients de la classe (symbole : caractère +)

> privé : qui rend l'élément visible à la seule classe (-)

> protégé : qui rend l'élément visible aux sous-classes (#).

Les associations

Elles représentent des relations structurelles entre classes d'objets. Elles peuvent être nommées (souvent par une forme verbale). Le nommage rend l'association plus dynamique. En précisant des rôles, il est possible de le rendre plus statique.

Chaque rôle d'une association porte une indication de multiplicité qui montre combien Rô1 Rô2

d`objets de la classe considérée peuvent être liées à un objet de l'autre classe.

- 1..1 : un et un seul

- 0..1 : zéro ou un

- M..N : de M à N

- « * » : de zéro à plusieurs - 0..* : de zéro à plusieurs - 1..* : de un à plusieurs

Fig 3 : Représentation d'une association

Les agrégations

Une des extrémités d'une association joue un rôle plus important :

> une classe fait partie d'une autre classe.

> les valeurs et attributs d'une classe se propagent dans les valeurs et attributs d'une

Classe2

autre classe.

> l'agrégation ne concerne qu'un seul rôle de l'association.

La composition est une agrégation particulière qui met en valeur l'idée de contenance (traduction des notions « est composé de » ou « est parti de »).

Fig 4 : Représentation d'une relation d'agrégation

La généralisation (héritage) :

La généralisation s'opère entre un élément plus général et un élément plus spécifique. Elle s'applique plus particulièrement aux classes, aux paquetages et aux cas d'utilisation.

La généralisation signifie : est un ou une sorte de. Les attributs, les opérations et les contraintes sont hérités intégralement dans les sous-classes. L'héritage est plus facilement utilisé au niveau de la programmation.

Fig 5 : Représentation d'une relation d'héritage

2.3. Diagramme d'objets

Les diagrammes d'objets sont des cas illustrés des diagrammes de classe. Selon un contexte,

sse file1

ils montrent la relation entre les objets. Deux compartiments permettent de les décrire. Le

Classe fle2

premier qui représente les instances de classe qui sont soulignées. Le deuxième décrit les attributs. Les objets sont reliés par des liens qui sont des instances des relations. Le diagramme d'objet est plus « parlant » qu'un diagramme de classe. Les associations réflexives sont représentées par une boucle qui relie l'objet à lui méme. Les valeurs des clés de restriction des associations peuvent également être ajoutées dans les diagrammes d'objets.

2.4. Diagramme des séquences

Les diagrammes de séquence montrent des interactions entre objets selon un point de vue temporel. La représentation se concentre sur l'expression des interactions. Un objet est représenté par un rectangle et une barre verticale appelée ligne de vie de l'objet. Les objets communiquent en échangeant des messages représentés par des flèches horizontales, orientées de l'émetteur du message vers le destinataire. L'ordre d'envoi des messages est montré par la position sur l'axe vertical. En modélisation objet, les diagrammes de séquence s'utilisent de deux manières bien différentes, selon la phase du cycle de vie et le niveau de détail désiré. La première utilisation sert à la documentation des cas d'utilisation ; elle se concentre sur la description de l'interaction (terme proche de l'utilisateur, sans entrer dans les détails de la synchronisation). La deuxième utilisation permet la représentation précise des interactions entre objets.

2.5. Diagramme de collaboration

Les diagrammes de collaboration sont une extension des diagrammes d'objet. Ils montrent les interactions entre objets et visent à représenter du point de vue statique et dynamique les objets impliqués dans la mise en place d'une fonction applicative. Le formalisme utilisé pour décrire le contexte est celui des modèles objets ; celui utilisé pour décrire les interactions est celui des scénarios. Les messages qui se déroulent de façon séquentielle sont numérotés car le temps n'est pas représenté de manière implicite.

2.6. Diagramme d'états-transitions

Un diagramme d'états fait intervenir des événements et des états, il est donc composé d'un ensemble de transitions. Il est propre à une classe donnée : ce diagramme décrit les états des objets de cette classe, les événements auxquels ils réagissent et les transitions qu'ils effectuent.

2.7. Diagramme d'activités

Ce sont des variantes des diagrammes d'états-transitions. Ils servent à représenter le comportement interne d'une méthode ou d'un cas d'utilisation. L'intérêt est d'avoir une représentation simplifiée des activités. L'activité apparaît comme un stéréotype d'état. Elle est représentée par un rectangle arrondi (plus large que les états). Les activités peuvent être regroupées par objet (découpage vertical). Il est possible de voir clairement les relations entre objets. Il est également possible de représenter les activités comme dans un diagramme de séquence. Les activités apparaissant alors sur la ligne de vie des objets.

2.8. Diagramme de composants

Il permet de décrire :

? les modules qui décrivent l'interface de la classe et sa réalisation.

? les dépendances entre composants (ex. : l'ordre de compilation des composants et les relations entre composants).

> les programmes principaux

> les sous-programmes spécifiques (non rattachés à des classes).

? les sous-systèmes (environnement de compilation).

2.9. Diagramme de déploiement

Ce diagramme décrit l'interaction entre les programmes exécutables et les environnements matériels.

II- Processus unifié

Pour définir le processus unifié, nous allons simplement définir les deux termes qui le composent :

· Processus : suite continue d'opérations constituant la manière de

fabriquer1. En d'autres termes, c'est une succession de taches dans le but d'accomplir un travail, un projet.

· Unifié : participe passé du verbe unifier, Etre amené à l'unité, se fondre en un tout2. En fait, les méthodes d'analyse et de conception orientées objet, étaient variées jusqu'à ce que Rambaugh, Jackobson et Boosh eut l'idée de les unifier.

Le processus unifié s'appuie sur les principes suivants :

ü Piloté par les cas d'utilisation : comme nous avons déjà vu, un cas d'utilisation représente une fonctionnalité qui satisfait un besoin d'un utilisateur. Le processus suit une voie spécifique, en procédant par une série d'enchaînement d'activités, dérivées d'un cas d'utilisation. Un cas d'utilisation est analysé, conçu, implémenté et enfin testé.

ü Centré sur l'architecture : l'architecture logicielle représente les aspects statiques et dynamiques du système. L'architecture émerge des besoins de l'entreprise, tels qu'ils sont exprimés par les utilisateurs et reflétés par les cas d'utilisation. l'architecture propose une vue d'ensemble de la conception faisant ressortir les caractéristiques essentielles en laissant de côté les détails secondaires. Il faut noter que tout produit est à la fois forme et fonction. L'une ou l'autre isolément ne saurait suffire. Les cas d'utilisation et l'architecture doivent s'équilibrer pour créer un produit réussi

ü Itératif et incrémental : vu que les projets à réaliser sont de plus en plus complexes et grands, l'idée est de découper le travail en mini projets. Chacun d'entre eux représente une itération qui donne lieu à un incrément. Les itérations désignent des étapes de l'enchaînement d'activités, tandis que les incréments correspondent à des stades de développement du produit

ü Les phases du processus unifié : le processus unifié se déroule en quatre phases, incubation, élaboration, construction et transition. Chaque phase répète un nombre de fois une série d'itérations. Et chaque itération est composée de cinq activités : capture des besoins, analyse, conception, implémentation et test.

Fig 6 : Les cinq activités se déroulant dans chaque phase.

v' Inception (Incubation): c'est la première phase du processus unifié. Il

s'agit de délimiter la portée du système, c à d tracer ce qui doit figurer à l'intérieur du système et ce qui doit rester à l'extérieur, identifier les acteurs, lever les ambiguïtés sur les besoins et les exigences nécessaires dans cette phase. Il s'agit aussi d'établir une architecture candidate, c à d que pour une première phase, on doit essayer de construire une architecture capable de fonctionner. Dans cette phase, il faut identifier les risques critiques susceptibles de faire obstacles au bon déroulement du projet.

v' Elaboration : c'est la deuxième phase du processus. Après avoir compris le

système, dégagé les fonctionnalités initiales, précisé les risques critiques, le travail à accomplir maintenant consiste à stabiliser l'architecture du système. Il s'agit alors de raffiner le modèle initial de cas d'utilisation, voire capturer de nouveaux besoins, analyser et concevoir la majorité des cas d'utilisation formulés, et si possible implémenter et tester les cas d'utilisation initiaux.

v' Construction : dans cette phase, il faut essayer de capturer tous les besoins

restants car il n'est pratiquement plus d'utilisation. A la fin de cette phase, les
développeurs doivent fournir une version exécutable du système.possible de le faire

dans la prochaine phase. Ensuite, continuer l'analyse, la conception et surtout l'implémentation de tous les cas

v' Transition : c'est la phase qui finalise le produit. Il s'agit au cours de cette

phase de vérifier si le système offre véritablement les services exigés par les utilisateurs, détecter les défaillances, combler les manques dans la documentation du logiciel et adapter le produit à l'environnement (mise en place et installation.

Architecture 3 -Tiers

Annexe

C

I- Introduction :

Il est évident que les méthodes et les outils choisis pour concevoir et développer une application doivent être en fonction de l'environnement et du domaine d'application de celleci. Cela est bien expliqué par le génie logiciel.

Dans ce chapitre je va mettre l'accent sur les avantages de l'approche orienté objet, les architectures n-tiers et l'approche du Model View Control (MVC) et en dernier lieu justifier notre choix sur les méthodes et outils à appliquer pour faciliter notre tache.

III- Avantage de l'approche orienté objet :

Parmi les avantages de cette approche, on peut citer : la réutilisabilité des éléments (objets), l'avantage d'utiliser un objet de base afin de produire un autre qui peut être une amélioration de cet objet (phénomène d'héritage), etc.

L'objet est le coeur de cette approche. Tout objet donné possède deux caractéristiques :

? Son état courant (attributs)

? Son comportement (méthodes)

En approche orientée objet on utilise le concept de classe, celle-ci permet de regrouper des objets de même nature.

Une classe est un moule (prototype) qui permet de définir les attributs (champs) et les méthodes (comportement) à tous les objets de cette classe.

> J2EE :

(Java 2 Entreprise Edition) représente essentiellement des applications d'entreprise. Gela inclut le stockage sécurisé des informations, ainsi que leur manipulation et leur traitement. Ges applications peuvent avoir des interfaces utilisateurs multiples, par exemple une interface Web pour les clients, accessible sur Internet et une interface graphique déployée sur les ordinateurs de l'entreprise sur le réseau privé de celle-ci. J2EE offre un ensemble de composants standardisés facilitant le déploiement des applications, des interfaces définissant la façon dont les modules logiciels peuvent être interconnectés, et les services standards, avec leur protocole associé, grâce auxquels ces modules peuvent communiquer.

III- Architecture 3-tiers :

L'architecture 3-tiers ou architecture à trois niveaux est l'application du modèle plus général qu'est le multi-tiers. L'architecture logique du système est divisée en trois niveaux ou couches :

· couche présentation

· couche métier

· couche accès aux données

G'est une extension du modèle client/serveur. 1. Définition et concepts :

L'architecture 3-tier (de l'anglais tier signifiant étage ou niveau) est un modèle logique d'architecture applicative qui vise à séparer très nettement trois couches logicielles au sein d'une même application ou système, à modéliser et présenter cette application comme un empilement de trois couches, étages, niveaux ou strates dont le rôle est clairement défini :

· la présentation des données : correspondant à l'affichage, la restitution sur le poste de travail, le dialogue avec l'utilisateur ;

· le traitement métier des données : correspondant à la mise en oeuvre de l'ensemble des règles de gestion et de la logique applicative ;

· enfin l'accès aux données persistantes (persistence en anglais) : correspondant aux
données qui sont destinées à être conservées sur la durée, voire de manière définitive.

Dans cette approche, les couches communiquent entre elles au travers d'un « modèle d'échange », et chacune d'entre elles propose un ensemble de services rendus. Les services d'une couche sont mis à disposition de la couche supérieure. On s'interdit par conséquent qu'une couche invoque les services d'une couche plus basse que la couche immédiatement inférieure ou plus haute que la couche immédiatement supérieure (chaque niveau ne communique qu'avec ses voisins immédiats).

Le rôle de chacune des couches et leur interface de communication étant bien définis, les fonctionnalités de chacune d'entre elles peuvent évoluer sans induire de changement dans les autres couches. Cependant, une nouvelle fonctionnalité de l'application peut avoir des répercussions dans plusieurs d'entre elles. Il est donc essentiel de définir un modèle d'échange assez souple, pour permettre une maintenance aisée de l'application.

Ce modèle d'architecture 3-tiers a pour objectif de répondre aux préoccupations suivantes :

· allègement du poste de travail client (notamment vis-à-vis des architectures classiques client-serveur de données -- typiques des applications dans un contexte Oracle/Unix) ;

· prise en compte de l'hétérogénéité des plates-formes (serveurs, clients, langages, etc.) ;

· introduction de clients dits « légers » (plus liée aux technologies Intranet/HTML qu'au 3 tiers proprement dit) ;


· amélioration de la sécurité des données, en supprimant le lien entre le client et les données. Le serveur a pour tâche, en plus des traitements purement métiers, de vérifier l'intégrité et la validité des données avant de les envoyer dans la couche de données.

· et enfin, meilleure répartition de la charge entre différents serveurs d'application.

· Précédemment, dans les architectures client-serveur classiques, les couches présentation et traitement étaient trop souvent imbriquées. Ce qui posait des problèmes à chaque fois que l'on voulait modifier l'IHM1 du système.

L'activation à distance (entre la station et le serveur d'application) des objets et de leurs méthodes (on parle d'invocation) peut se faire au travers d'un ORB (avec le protocole IIOP ou au moyen des technologies COM/DCOM de Microsoft ou encore avec RMI en technologie J2EE). Cette architecture ouverte permet également de répartir les objets sur différents serveurs d'application (soit pour prendre en compte un existant hétérogène, soit pour optimiser la charge).

Il s'agit d'une architecture logique qui se répartit ensuite selon une architecture technique sur différentes machines physiques, bien souvent au nombre de 3, 4 ou plus. Une répartition de la charge doit dans ce cas être mise en place.

2. Les trois couches :

 
 

a. Couche Présentation (premier niveau) :

Elle correspond à la partie de l'application visible et interactive avec les utilisateurs. On parle d'Interface Homme Machine. En informatique, elle peut être réalisée par une application graphique ou textuelle. Elle peut aussi être représentée en HTML pour être exploitée par un navigateur web ou en WML pour être utilisée par un téléphone portable.

On conçoit facilement que cette interface peut prendre de multiples facettes sans changer la finalité de l'application. Dans le cas d'un système de distributeurs de billets, l'automate peut être différent d'une banque à l'autre, mais les fonctionnalités offertes sont similaires et les services identiques (fournir des billets, donner un extrait de compte, etc.).

Toujours dans le secteur bancaire, une même fonctionnalité métier (par exemple, la
commande d'un nouveau chéquier) pourra prendre différentes formes de présentation selon

qu'elle se déroule sur Internet, sur un distributeur automatique de billets ou sur l'écran d'un chargé de clientèle en agence.

La couche présentation relaie les requêtes de l'utilisateur à destination de la couche métier, et en retour lui présente les informations renvoyées par les traitements de cette couche. Il s'agit donc ici d'un assemblage de services métiers et applicatifs offerts par la couche inférieure.

b. Couche Métier / Business (second niveau) :

Elle correspond à la partie fonctionnelle de l'application, celle qui implémente la « logique », et qui décrit les opérations que l'application opère sur les données en fonction des requêtes des utilisateurs, effectuées au travers de la couche présentation.

Les différentes règles de gestion et de contrôle du système sont mises en oeuvre dans cette couche.

La couche métier offre des services applicatifs et métier à la couche présentation. Pour fournir ces services, elle s'appuie, le cas échéant, sur les données du système, accessibles au travers des services de la couche inférieure. En retour, elle renvoie à la couche présentation les résultats qu'elle a calculés.

d. Couche Accès aux données (troisième niveau) :

Elle consiste en la partie gérant l'accès aux gisements de données du système. Ces données peuvent être propres au système, ou gérées par un autre système. La couche métier n'a pas à s'adapter à ces deux cas, ils sont transparents pour elle, et elle accède aux données de manière uniforme (couplage faible).

Annexe

D

Langages Utilisé

I. Java :

C'est un langage de programmation orienté objet, développé par Sun Microsystems. Il permet de créer des logiciels compatibles avec de nombreux systèmes d'exploitation (Windows, Linux, Macintosh, Solaris). Java donne aussi la possibilité de développer des programmes pour téléphones portables et assistants personnels. Enfin, ce langage peut-être utilisé sur internet pour des petites applications intégrées à la page web (applet) ou encore comme langage serveur (jsp).

1. Les avantages de Java :

L'un des avantages évidents de ce langage est une bibliothèque d'exécution qui se veut indépendante de la plateforme: en théorie, il vous est possible d'utiliser le même code pour Windows 95/98/NT, Solaris UNIX Macintosh, etc. Cette propriété est indispensable pour une programmation sur Internet (cependant, par rapport à la disponibilité sur Windows et Solaris les implémentations sur d'autres plates-formes ont toujours un léger décalage).

a. Architecture classique avec un bytecode différent pour chaque processeur.

b. Architecture Java, le bytecode passe par l'intermédiaire d'un interpréteur.

2. Caractéristiques

Les créateurs de Java ont écrit un livre blanc qui présent les caractéristiques fondamentales de Java. Ce livre est articulé autour des 11 termes suivants :

> Distribué

Java possède une importante bibliothèque de routines permettant de gérer les protocoles TCP/IP tels que HTTP et FTP. Les applications Java peuvent charger et accéder à des sur Internet via des URL avec la même facilité qu'elles accèdent à un fichier local sur le système. « Nous avons trouvé que les fonctionnalités réseau de Java sont à la fois fiables et d'utilisation aisée. Toute personne ayant essayé de faire de la programmation pour Internet avec un autre langage se réjouira de la simplicité de Java lorsqu'il s'agit de mettre en oeuvre des tâches lourdes, comme l'ouverture d'une connexion avec un socket. De plus, Java rend plus facile l'élaboration des scripts CGI (Common Gateway Interface), et un mécanisme élégant, nommé servlet, augmente considérablement l'efficacité du traitement côté serveur, assuré par Java. De

nombreux serveurs Web, parmi les plus courants, supportent les servlets. Le mécanisme
d'invocation de méthode à distance (RMI) autorise la communication entre objets distribués. »

> Fiabilité

Java a été conçue pour que les programmes qui l'utilisent soient fiables sous différents aspects. Sa conception encourage le programmeur à traquer préventivement les éventuels problèmes, à lancer des vérifications dynamiques en cours d'exécution et à éliminer les situations génératrices d'erreurs... La seule et unique grosse différence entre C++ et Java réside dans le fait que ce dernier intègre un modèle de pointeur qui écarte les risques d'écrasement de la mémoire et d'endommagement des données.

> Orienté objet

Pour rester simples, disons que la conception orientée objet est une technique de programmation qui se concentre sur les données (les objets) et sur les interfaces avec ces objets. Pour faire une analogie avec la menuiserie, on pourrait dire qu'un menuisier "orienté objet "s'intéresse essentiellement à la chaise l'objet qu'il fabrique et non à sa conception (le "comment"). Par opposition, le menuisier "non orienté objet " penserait d'abord au comment.

II. Langage SQL :

 

Le langage SQL (Structured Query Language) peut être considéré comme le langage d'accès normalisé aux bases de données.

Il est aujourd'hui supporté par la plus part des produits commerciaux aussi bien par les systèmes de gestion de bases de données micro comme Access que par les produits plus professionnels tels qu'Oracle ou Sybase.

Le succès du langage SQL est du essentiellement à sa simplicité et au fait qu'il s'appuie sur le schéma conceptuel pour énoncer des requêtes en laissant le SGBD responsable de la stratégie d'exécution.

Le langage SQL propose un langage de requêtes en laissant le SGBD responsable de la stratégie d'exécution. Le langage SQL propose un langage de requêtes ensembliste.

Le langage SQL comporte :

-Un langage de Définition des Données (LDD) qui permet de définir des relations, des vues externes et des contraintes d'intégrité.

-Un langage de Manipulation de Données (LMD) qui permet d'interroger une base de données sous forme déclarative sans se préoccuper de l'organisation physique de données.

-Un langage de Contrôle des Données (LDD) qui permet de contrôler la sécurité et les accès aux données.

Bibliographie

 

·

PASCAL ROQUES, FRANCK VALLEE « UML en action : De l'analyse des besoins à la conception en java » Edition : Eyrolles, Tsoft 2006, 328p.

· Le langage Java, K. Arnold et al, International Thomson Publishing Présentation guidée claire du langage, très bonne explication des concepts de Java, 250F env.

Nétographie

 
 

·

http://www.hibernate.org

· http://www.commentcamarche.net

· http://www.wikipedia.fr

· http://www.developpez.com/

· http://uml.free.fr

· http://fr.wikipédia.org

· http://www.cnam.nat.tn/espace-prof.htm

Résumé:

Ce projet consiste à développer une application permettant à la pharmacie de gérer le stock des médicaments, les ordonnances ainsi que le processus d'achat : commande et livraison.

L'environnement de mon projet est Eclipse Galileo. J'ai eu recoure, le long de ce projet au concept UML de conception. Le syst~me a été développé à l'aide du langage Java, utilisant comme base de données Oracle.

Mots clés:

Gestion des médicaments, Gestion d'ordonnances, Java., Oracle.

íÎHÊ

ÒJÊ ãiÙæ æ ,ÊíæÏáÇ äæÔÎ~ ÉÑÇÏÅ åT Ê~~Ð~p Ç åIãí ÞIÈ~Ê ÒíllÊ í ÇÐå íÚæÒÔ~ áËã~í

. ÚíÓ~~~Ç æ ÈáT Ç :ÁÇÒÔ~Ç Ê~áãÚ æ Ê(È3 Ç Ê~ÕIÇ í

ã~Ùì~Ç ËÑ~Ø . "L0U " ã~Ùæ ìáÚ íËÍ~ Êá~Ø ËÐã~ÚÇ ÐÞ~ æ " o eliSac eslilcE "~å íáãÚ Ñ~ØÅ äÅ

. Oracle Ë171I~ ìáÚ ß~Ðß ËÐã~ÚÇ æ « Java» æÞ

Java, Oracle" Ê~ÈI Ç Ë~TÕI~Ç í ÒJ~~Ç ,ÊíæÏáÇ í ÒJ~~Ç :ÍíÊ~ãáÇ Ê ãHß

Abstract:

This project consists in developing an application enabling the chemist to run their drug storage, the medical prescriptions as well as the purchase process: orders and deliveries.

The environment of my project is Eclipse Galileo. All this project long, I've used the concept UML design.

The system has been realized with java language using oracle as data basis.

Key words: management medicines, management ordonnances, Java, Oracle






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy