|
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 >>
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.
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.
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.
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 +
...).
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.
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 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.
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.
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.
·
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.
·
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
| 
