Wa0044.

1
CHAPITRE 0. INTRODUCTION GENERALE
0.1 PRESENTATION DU CONTEXTE
Le temps passe vite et l'ère de l'industrie cède sa place à l'ère de l'information.
L'information est devenue un élément crucial au cœur des entreprises, des institutions et dans
notre vie quotidienne. Depuis quelques temps, les petites et moyennes entreprises se sont
conscientisées de la valeur ajoutée qu’apporte un système bien informatisé. Le besoin croissant
des décideurs, d'avoir la bonne information au bon moment, trouve satisfaction dans
l'informatique. En effet l'informatisation permet de traiter l'information pour qu'elle soit
présentée à l'utilisateur avec un sens qui lui confère toute sa valeur.
Mais avant d'informatiser il convient de se poser cette question : « Pourquoi veut on

informatiser? » Petit Abir [1] de l’Université de Picardie donne une réponse à cette question.
Cette réponse identifie clairement les objectifs d’une informatisation et les caractérise de la
manière suivante :
 L’amélioration des services aux clients ;

 La maîtrise des coûts ;
 L’amélioration des services aux utilisateurs ;
 L’amélioration des outils de gestion ;
 La réponse à la crise du système manuel.
Néanmoins, au Congo comme dans certains autres pays du tiers monde, la plupart des
entreprises, pharmacies, magasins, institutions et hôpitaux ne sont pas informatisés. Parmi les
pharmacies non informatisées, la pharmacie NEW SIDPHAR ne fait pas l'exception. Elle sera
donc l'objet de notre travail intitulé « CONCEPTION ET REALISATION D'UNE
APPLICATION WEB DE GESTION DES VENTES DES PRODUITS
PHARMACEUTIQUES : CAS DE NEW SIDPHAR».
0.2 CHOIX ET INTERET DU SUJET
0.2.1. Choix du Sujet
Les pharmacies sont parmi les magasins à forte audience. Et vue la complexité de certaines
opérations, particulièrement celles liées à la vente des produits pharmaceutiques, il s'avère
qu'une informatisation ne serait pas de trop.
Les pharmacies contribuent dans l'amélioration des soins de santé et, l’informatisation de ces
dernières ne ferait qu'accroître la qualité des services fournis.
2
0.2.2. Intérêt du sujet
Le présent travail vise la conception et réalisation d'une application web de gestion des ventes
des produits pharmaceutiques dans la pharmacie NEW SIDPHAR. Le produit de ce travail
sera d’une grande utilité pour plusieurs personnes, chacun en ce qui le concerne. Ainsi :
 Intéret Social
• Les pharmaciens de NEW SIDPHAR verront leur travail simplifié car l'application prendra
soin de tous les casse-tête liés aux opérations de vente des médicaments.
• Le gestionnaire de la pharmacie verra également son travail réduit car il aura un contrôle
beaucoup plus élargi sur les ventes effectuées avec moins d’efforts. Des rapports de vente
seront à sa disponibilité au moment voulu.
• Le patron de la pharmacie aura accès à des statistiques qui lui permettront de prendre
facilement des décisions à partir des données collectées par le logiciel au fur du temps. Il verra
la qualité des services fournis par la pharmacie augmentée sans parler des gains économiques
qui pourront être réalisés grâce à un bon service et une bonne gestion des entrées/sorties.
• Pour les clients, le service offert par la pharmacie sera nettement améliorés. Les clients seront
désormais servis plus rapidement.
 Intéret Personnel
 Pour nous : nous avons l'occasion de confronter la théorie à la pratique. Nous nous proposons
de travailler sur une application pour faire face aux défis du monde du business qui vont en
dehors du cadre de la programmation expérimentale qu'on applique en classe. Il faut désormais
faire face à la réalité sur le terrain qui est souvent différente ou ne concorde pas avec ce que
l'on imaginait. ·
 Intéret scientifique
 Pour les étudiants : Ce mémoire est rédigé en pensant aux autres étudiants. Les futurs finalistes
feront sûrement à peu près le même parcours que nous. Ils auront sûrement besoin des
ressources, des guides et, des informations identiques à celles dont nous avons besoin
actuellement. Ils rencontreront probablement des difficultés comme celles que l'on a connues,
c'est pour cela qu'on essaiera de mettre à leurs dispositions les informations dont ils pourraient
avoir besoin. On espère ainsi pouvoir les aider à s’orienter dans leurs recherches.
3
0.4. ETAT DE LA QUESTION
L’état de la question consiste à examiner les résumés des recherches antérieurs existant dans
ce domaine et qui permet au chercheur de situer son apport par rapport à ces travaux. Ceci
l’aidera à recueillir les informations générales utiles pour sa recherche. (Initiation a la
recherche scientifique, 2018)
Apres avoir consulté différents travaux antérieurs, nous avons remarqué que ce travail a déjà
été traité dans le passé mais sous différent angles et contextes.
Nous pouvons citer les travaux des étudiants de ces étudiants :

 NOBLA LUBOYA : Conception et réalisation d’un site web pour la gestion de stock de
produit « Cas de l’Etablissement Dieu est Fidèle. L’étudiant avait constaté que l’entreprise
était en train de grandir mais n’avais pas de système informatique en place d’où il a décidé de
concevoir un système qui permettra de faire une gestion du stock, de gérer la vente, les
achats…
 JEAN PIERRE KILUKA : Conception et implémentation d’un site web pour l’archivage et la
commande en ligne des journaux dans une maison de presse écrite. Ici l’auteur voulais le régler
le problème de la commande manuel des journaux produits par l’éditeur grâce à un site web.
 KATYA MUHABYA : Conception d’un site web pour la gestion d’une boutique « Cas de
l’établissement jésus le rock ». ici l’auteur avait constaté que la boutique n’avait pas un
système en place d’où informations sur la gestion de stock n’était pas bien faite ce qui
engendrait la perte des informations importantes et la recherche difficile des informations.
Notre travail diffère de ces autres travaux par le fait que le nôtre aborde le thème de conception
et réalisation d’une application web de la gestion des approvisionnements d’une pharmacie.
0.3 PROBLEMATIQUE
La problématique est un ensemble des questions des problèmes concernant un domaine de

connaissances ou qui sont posés par une situation. (Larousse)
 Relatif à un problème, à une problématique.

 Qui est difficile à résoudre, à accomplir.
Il n’existe actuellement aucun système automatisé de facturation et

d’enregistrement de ventes dans la pharmacie NEW SIDPHAR. De même, le gérant tient à
jour le stock manuellement et garde les informations dans des fichiers Excel et dans un registre
; cette situation est à l’origine de nombreux problèmes à savoir :
4
 Un mauvais service aux clients (lenteur) : la facturation manuelle conduit souvent à la

lenteur du service car on doit calculer manuellement les coûts des produits achetés.
 Risque de commettre des erreurs de calcul lors de la facturation : pour le cas des ventes
à crédit, les calculs peuvent devenir souvent complexes à cause des réductions
appliquées pour chaque affilié, ce qui peut conduire à des erreurs de calcul.
 Absence de la bonne information au bon moment : le gérant met à jour le stock une
fois la semaine, d’où il en résulte souvent beaucoup d’incohérence entre les
informations dans les fichiers et la réalité.
Ces problèmes nous ont poussés à nous poser les questions suivantes :
 Est-ce que le système d’information en place permet-elle à la pharmacie de bien gérer des
produits?
 Qu’est-ce qu’il faut faire si le système en place ne permet pas de bien faire la gestion de
produits
0.4. HYPOTHESE
Une hypothèse se définit selon le dictionnaire Larousse comme étant une proposition visant à
fournir une explication vraisemblable d’un ensemble de faits, et qui doit être soumis au
contrôle de l’expérience ou vérifiée dans ses conséquences.
Par rapport à notre travail, nous suggérons l’hypothèse suivant :
 La conception et réalisation d’une application web est solution sûr et efficace pour
pallier à ce problème
0.5 METHODOLOGIES ET TECHNIQUES UTILISEES
La méthode désigne l’ensemble des canons guidant ou devant guider le processus de,
production des connaissances scientifiques qui s’agisse d’observation d’expérience, de
raisonnements, ou des calculs théoriques. (Initiation a la recherche scientifique, 2018)
Dans notre travail nous allons utiliser la méthode UP Unified Processus
Le processus unifié (PU), ou « Unified Processus » en anglais, ou « Unified Software

Development Process (USDP) » est une famille des méthodes de développement des logiciels
orientés objet. Elle se caractérise par une démarche itérative et incrémentale, piloté par le cas
d’utilisation et centré sur l’architecture et le modèle UML. (travail, 2008)
Elle définit un processus intégrant toutes les activités de conception et de réalisation au sein
de cycle de développement composée d’une phase de création, d’une phase d’élaboration,
5
d’une phase de construction et d’une phase de transition comprenant chacune plusieurs

interactions.
1.1.1. Technique
 Technique de développement logiciels : qui est une technique consistant à écrire un
code source dans un langage de programmation préalablement choisi. (logiciel, 2019)
 Technique de modélisation : qui est une technique consistant à concevoir un système
logiciel par des modèles abstraits, tout en décrivant leurs interactions afin de les rendre
communicables et compréhensibles aux métiers et aux acteurs systèmes (logiciel G. ,
2018)
0.6 DELIMITATION DU SUJET
• Délimitation dans l'espace : notre travail se limite à la gestion des ventes (Cash et Crédit) des
produits pharmaceutiques. L'application prend soin de mettre à jour le stock des médicaments
à chaque vente mais ne se préoccupe pas beaucoup des détails des procédures liées à la gestion
du stock.
• Délimitation dans le temps : le logiciel que nous nous proposons de mettre en place dans le
cadre de ce mémoire, tient compte des données et des règles de gestion actuelle de la
pharmacie. Nous essayerons de produire un logiciel qui s'adaptera aux changements, sans
toutefois garantir que ces derniers trouvent place dans notre logiciel sans aucune modification.
0.7 SUBDIVISION DU TRAVAIL
Notre travail intitulé : « CONCEPTION ET REALISATION D'UNE APPLICATION

WEB DE GESTION DES VENTES DES PRODUITS PHARMACEUTIQUES : CAS
DE NEW
SIDIPHAR» est articulé autour de 3 chapitres hormis l’introduction et la conclusion.
- Le premier chapitre Cadre conceptuel et considération théorique.
- Le deuxième chapitre .Analyse de l’existant
- Le troisième chapitre Conception du nouveau système
- Le quatrième chapitre : Programmation

6
CHAPITRE I. CADRE CONCEPTUEL ET CONSIDERATION THEORIQUE
I.1. DEFINITION DES CONCEPTS DE BASE LIES AU SUJET.
Nous allons définir tous les concepts clés qui sont lié au sujet
A. Conception
En informatique, le terme "conception" fait référence à l'étape de développement d'un système

informatique où les spécifications et les plans détaillés sont établis avant de procéder à la phase
de mise en œuvre. La conception vise à déterminer comment le système sera structuré,
organisé et fonctionnera pour répondre aux besoins spécifiques des utilisateurs et aux objectifs
du projet. (Mark Johanes, 2008)
La conception englobe plusieurs aspects, tels que l'architecture logicielle, l'interface

utilisateur, la base de données, les algorithmes, les protocoles de communication, la sécurité,
la performance et l'extensibilité du système. Les concepteurs informatiques doivent prendre
en compte ces différents aspects et prendre des décisions éclairées pour créer une solution
technique solide et efficace.
La conception se fait généralement en collaboration avec des développeurs, des analystes et

des utilisateurs finaux. Les concepteurs utilisent des outils et des techniques spécifiques, tels
que les diagrammes de flux, les diagrammes de classe, les prototypes, les maquettes d'interface
utilisateur et les modèles de conception, pour documenter et communiquer leurs idées.
Une conception bien réalisée est essentielle pour garantir la qualité, la fiabilité et la
maintenabilité du système informatique. Une bonne conception permet de minimiser les
erreurs et les problèmes potentiels avant la phase de développement, ce qui peut entraîner des
économies de temps et de ressources.
B. Réalisation
En informatique, le terme "réalisation" est souvent utilisé comme synonyme du terme

"développement". Il fait référence à l'acte de mettre en œuvre concrètement un logiciel, une
application ou un système informatique en suivant les spécifications et les plans établis lors de
la phase de conception. (lemondeinformatique.fr/réalisation, n.d.)
La réalisation consiste à traduire les concepts, les exigences et les spécifications fonctionnelles
en code informatique, en utilisant des langages de programmation, des Framework, des
bibliothèques et d'autres outils appropriés. Les développeurs utilisent leur expertise en
7
programmation pour écrire le code source qui permettra au système de fonctionner

conformément aux attentes.
Au cours de la réalisation, les développeurs suivent généralement des pratiques de

développement telles que la gestion du code source, la collaboration avec d'autres membres de
l'équipe de développement, les tests unitaires et l'intégration continue pour assurer la qualité
du logiciel.
La réalisation peut également impliquer d'autres tâches liées au développement, telles que la
configuration de l'environnement de développement, la mise en place des bases de données,
l'intégration de services externes, la création de l'interface utilisateur, l'optimisation des
performances, la gestion des erreurs, etc.
L'objectif de la réalisation est de créer un logiciel fonctionnel qui répond aux besoins
spécifiques des utilisateurs et aux exigences du projet. Une réalisation réussie nécessite une
bonne compréhension des spécifications, des compétences techniques en programmation et
une attention aux détails pour garantir la qualité et la fiabilité du système final.
C. Application web
Une application web est un type de logiciel qui est accessible via un navigateur web.
Contrairement aux applications traditionnelles qui doivent être installées localement sur un
ordinateur ou un appareil, une application web est hébergée sur un serveur distant et peut être
utilisée à partir de n'importe quel appareil disposant d'une connexion Internet et d'un
navigateur web compatible. (ti-exclusif, n.d.)
Les applications web sont généralement développées en utilisant des technologies web
courantes, telles que HTML (HyperText Markup Language) pour la structure de la page, CSS
(Cascading Style Sheets) pour la présentation visuelle et JavaScript pour la programmation
côté client. Le côté serveur de l'application est souvent développé en utilisant des langages de
programmation tels que Python, PHP, Java, Ruby, etc., et peut interagir avec des bases de
données pour stocker et récupérer des informations.
L'un des avantages clés des applications web est qu'elles sont multiplateformes, ce qui signifie
qu'elles peuvent être utilisées sur différents systèmes d'exploitation tels que Windows, MacOs,
Linux, ainsi que sur des appareils mobiles tels que les smartphones et les tablettes. De plus,
les mises à jour et les améliorations de l'application peuvent être déployées de manière
centralisée sur le serveur, ce qui facilite la maintenance et la mise à jour pour les utilisateurs.
Les applications web offrent également la possibilité de stocker des données sur des serveurs
distants, permettant aux utilisateurs d'accéder à leurs informations et de collaborer avec
8
d'autres utilisateurs à distance. Cela en fait un choix populaire pour les applications nécessitant
une accessibilité à distance, une collaboration en temps réel et des fonctionnalités partagées.
En résumé, une application web est un logiciel accessible via un navigateur web, offrant une
interface utilisateur interactive et permettant aux utilisateurs d'accomplir diverses tâches,
services et fonctionnalités en ligne, sans nécessiter d'installation locale
D. Gestion
En informatique, le terme "gestion" fait référence à la planification, l'organisation, le contrôle

et la supervision des ressources, des processus et des activités liées aux systèmes
informatiques. La gestion en informatique englobe plusieurs aspects, tels que la gestion des
projets, la gestion des ressources, la gestion des services, la gestion des données et la gestion
de la sécurité. (nextimpact, n.d.)
La gestion en informatique comprend les responsabilités suivantes :
Gestion des projets : Il s'agit de planifier, organiser et contrôler les activités liées à la réalisation
d'un projet informatique, en veillant à ce qu'il soit livré dans les délais impartis, respecte les
exigences et soit conforme au budget établi. Cela implique la définition des objectifs,
l'allocation des ressources, la coordination des équipes et le suivi de l'avancement du projet.
Gestion des ressources : Cela concerne la gestion des ressources matérielles et logicielles
nécessaires au bon fonctionnement des systèmes informatiques. Cela comprend l'acquisition,
l'installation, la maintenance, la mise à niveau et le remplacement du matériel et des logiciels,
ainsi que la gestion des licences, des contrats de support et des inventaires.
Gestion des services : Il s'agit de la gestion des services informatiques fournis aux utilisateurs
finaux ou aux clients. Cela implique la planification, la mise en œuvre et l'amélioration des
services informatiques, tels que le support technique, la résolution des incidents, la gestion des
demandes, la gestion des niveaux de service, la gestion des configurations et la gestion des
changements.
Gestion des données : Cela concerne la gestion des données informatiques dans le cadre d'une
organisation. Cela comprend la collecte, le stockage, la sauvegarde, la sécurité, la qualité,
l'intégrité et la disponibilité des données. La gestion des données vise à garantir que les
données sont gérées de manière efficace, cohérente et sécurisée tout au long de leur cycle de
vie
Gestion de la sécurité : Il s'agit de la mise en place de mesures de sécurité pour protéger les
systèmes informatiques contre les menaces internes et externes. Cela comprend la gestion des
9
accès, la gestion des identités, la gestion des pare-feu, la détection des intrusions, la gestion
des vulnérabilités et la gestion des incidents de sécurité.
La gestion en informatique vise à assurer le bon fonctionnement, la disponibilité, la

performance, la sécurité et l'évolutivité des systèmes informatiques au sein d'une organisation.
Elle implique une planification stratégique, une coordination efficace des ressources et une
prise de décision éclairée pour atteindre les objectifs fixés.
E. Etablissement commercial
Un établissement commercial est un lieu physique où des activités commerciales sont menées
pour la vente de biens ou de services. Cela peut inclure une grande variété d'entreprises, telles
que des magasins de détail, des restaurants, des hôtels, des supermarchés, des centres
commerciaux, des salons de beauté, des pharmacies, des stations-service, des cinémas, des
boutiques en ligne avec des entrepôts physiques, et bien d'autres. (wikipedia, n.d.)
Un établissement commercial est un lieu où les clients peuvent se rendre pour acheter des
produits ou utiliser des services. Il peut être situé dans des zones commerciales, des centres
villes, des centres commerciaux ou même fonctionné en ligne. Les établissements
commerciaux fournissent souvent un espace physique où les clients peuvent interagir avec les
produits, recevoir des conseils, effectuer des paiements et bénéficier d'un service client en
direct.
Ces établissements peuvent varier en taille, en nature de l'activité et en offre de produits ou de

services. Certains établissements commerciaux se spécialisent dans des domaines spécifiques,
tels que la vente de vêtements, d'électronique, de nourriture, de meubles, etc. D'autres peuvent
offrir une gamme plus large de produits et de services.
I.2. PRESENTATION DA METHODE UP
Le processus unifié est une famille de méthodes de développement de logiciels orientés objets.
Elle se caractérise par une démarche itérative et incrémentale, pilotée par les cas d'utilisation,
et centrée sur l'architecture et les modèles UML. (Librairie Eryolles, n.d.)
Le processus unifié (PU), ou « unified process (UP) » en anglais, ou « Unified Software

Development Process (USDP) » est une famille de méthodes de développement de logiciels
orientés objets. Elle se caractérise par une démarche itérative et incrémentale, pilotée par les
cas d'utilisation, et centrée sur l'architecture et les modèles UML. Elle définit un processus
intégrant toutes les activités de conception et de réalisation au sein de cycles de développement
10
composés d'une phase de création, d'une phase d'élaboration, d'une phase de construction et
d'une phase de transition, comprenant chacune plusieurs itérations.
 Historique
En 1987, Ivar Jacobson crée la société Objectory AB pour commercialiser une méthode de
développement orientée objets appelée Objectory Process. Cette méthode est issue d'une
approche centrée sur les composants qu'il avait mise au point depuis 1967 au sein de la société
Ericson. Objectory se base sur les cas d'utilisation, un concept dont Jacobson était l'auteur. La
méthode suit alors une démarche systématique visant par une succession de modèles OOSE à
arriver à la réalisation du logiciel. (www.wikipedia.com, n.d.)
En 1992, Grady Booch, employé de la société Rational Software publie la méthode Booch de
développement orientée objets. Celle-ci se compose d'un langage de modélisation graphique,
d'un processus itératif de développement, et d'un ensemble de pratiques recommandées.
En 1995, la société Rational Software acquiert la société Objectory AB et fusionne les deux
méthodes de développement sous l'appellation Rational Objectory Process. La société a
également recruté James Rumbaugh, créateur du langage de modélisation OMT.
En 1999, Jacobson, Booch et Rumbaugh publient « Le processus unifié de développement

logiciel » dans le but de diffuser plus largement au public les idées à la base de RUP. Ils
soulignent qu'il s'agit à la fois d'une unification des approches de développement, et d'une
unification des modèles utilisés, et que le processus intègre un grand nombre de contributions
de spécialistes en méthodologie de Rational Software et de centaines d'autres sociétés.
 Caractéristiques
Le processus unifié est une méthode de développement de logiciel caractérisée par (Génie
logiciel) :
1. un pilotage par les cas d'utilisation, une démarche centrée sur l'architecture,
2. une approche basée sur les modèles, et en particulier les modèles UML,
3. une approche itérative et incrémentale visant en priorité à réduire les incertitudes.
Le processus unifié répond à la définition d'un processus métier. Il vise ainsi à assurer un cycle
de développement avec des enchainements d'activités systématiques et répétables basés sur
des artefacts bien définis, tout en facilitant l'intégration de nouvelles personnes dans les
équipes. La méthode considère en outre que le produit est constitué non seulement du code,
11
mais aussi de tous les éléments contribuant à la pérennité et aux évolutions ultérieures du
logiciel.
 Cycle de vie des projets
 Cycle de développement: projets, phases et itérations
Le processus unifié est cyclique : il vise par une succession de projets à fournir d'abord une
version viable d'un produit puis des versions publiables successives (« release » en anglais).
(Antoine)
Chaque projet a un cycle de vie en quatre phases, chacune subdivisée en plusieurs itérations:
 une phase création ou de cadrage (« inception» en anglais) vise à définir le produit et les
objectifs du projet;
 une phase d'élaboration vise à clarifier les exigences, à définir l'architecture du produit et à en
valider la faisabilité. Cette phase prévoit ainsi la mise en œuvre d'une version exécutable
constituée d'un squelette du système et démontrant les principaux éléments architecturaux;
 une phase de construction vise à construire et à mettre en œuvre le produit et les livrables
associés;
 une phase de transition vise à livrer, diffuser ou déployer le produit de sorte qu'il soit prêt à
être utilisé. Cette phase inclut la formation des utilisateurs si nécessaire.
Le processus unifié prône une approche pilotée par les risques, en cherchant au travers des
différentes itérations, à lever en priorités les plus grandes incertitudes.
 Enchainements d'activités
Le processus unifié propose les enchainements d'activités suivants, qui peuvent être configurés
selon les besoins du projet (Antoine) :
12
Processus unifié : enchainements d'activités au cours du cycle de vie

 Exigences : recherche des acteurs et des cas d'utilisation, priorisation, description des cas
d'utilisation, prototypage de l'interface utilisateur, et structuration du modèle des cas
d'utilisation ;
 Analyse : analyse de l'architecture, analyse d'un cas d'utilisation, analyse d'une classe, et
analyse d'un package ;
 Conception : conception de l'architecture, conception d'un cas d'utilisation, conception d'une
classe, et conception d'un sous-système ;
 Mise en œuvre (implémentation) : implémentation de l'architecture, intégration du système,
implémentation d'un sous-système, implémentation d'une classe, et exécution de tests unitaires
;
 Test : planification des tests, conception des tests, mise en œuvre des tests, exécution des tests
d'intégration, exécution de tests systèmes, et évaluation des tests.
Le terme « discipline » est également utilisé pour désigner les enchainements génériques.
Contrairement au modèle en cascade qui définit des phases distinctes pour chacun de ces
enchainements d'activités, le processus unifié intègre ces activités au travers des différentes
itérations et phases du projet. Le processus unifié est par ailleurs conçu pour gérer des systèmes
complexes à base de composants. On y retrouve donc des idées du cycle en V comme une
vision architecturale à base de composants, l'intégration du système, et les différents niveaux
de validation, mais sans la contrainte de les organiser en étapes séquentielles.
Le processus unifié définit également des rôles pour les acteurs intervenant pour ces activités
(par exemple architecte, ingénieur composant, designer d'interface utilisateur, etc.). Les
auteurs soulignent néanmoins qu'il s'agit de rôles et non de personnes ; un même membre
d'équipe peut donc cumuler plusieurs rôles. Le processus unifié définit enfin une série
d'artefacts, c'est-à-dire de livrables du projet. (Antoine)
13
 Planification itérative
Le processus unifié préconise une planification itérative dans laquelle « le plan précède l'action
».
Le principe est qu'un plan d'ensemble détermine en fonction de la complexité du projet les
itérations nécessaires pour chaque phase et positionne les phases dans le temps. Ce plan
d'ensemble n'inclut pas de détail par itération. Les itérations sont planifiées de façon
progressive au cours de l'avancement du projet. L'itération en cours est planifiée en détail
lorsqu'elle démarre, avec un calendrier et un objectif de contenu (cas d'utilisation à traiter,
changements à apporter aux livrables des itérations précédentes, composants à réaliser...). Le
plan de l'itération suivante est préparé lorsque les éléments en sont connus. Il est ainsi tout
d'abord estimé dans les grandes lignes, puis affiné en fonction des informations découvertes
lors de l'itération en cours.
Dans le cas particulier de la phase de création, le contour du projet est en général trop incertain
pour permettre une planification réaliste. Le plan de la première itération de cette phase doit
donc être considéré comme une tentative de plan qui doit être ajustée si nécessaire. A l'issue
de cette phase, la faisabilité du développement est établie et le plan d'ensemble correspondant
à la vision du projet peut être produit. (Antoine)
 Fonctionnement
Phases et itérations d'un projet de développement
Le pilotage par les cas d'utilisation utilise les diagrammes de cas d'utilisation (DCU) complétés
par des descriptions textuelles. À partir des DCU, on tire les modèles d’analyse, de conception,
de déploiement, d'implémentation et de test. De ces modèles émergent l'architecture du
système. Une approche systématique est par ailleurs proposée pour déduire des cas d'utilisation
des classes d'analyses puis de conception selon le schéma entités contrôle-frontières. Ce sont
aussi les cas d’utilisation qui vont permettre l’élaboration des scénarios de tests puisque le
nouveau logiciel devra permettre de réaliser les cas d’utilisation prévus. Les DCU sont ainsi
14
les modèles qui garantissent la cohérence du processus du développement en servant de fil

conducteur à l'ensemble des activités. (Salbatier)
Les activités de modélisation reposent sur UML. Ce langage de modélisation couvre les
aspects structurels et dynamiques de l'architecture et de la conception des logiciels. Il facilite
une modélisation par composants en utilisant une approche orientée objets. Les créateurs
d'UML sont d'ailleurs à l'origine du processus unifié, qui devait compléter UML par une
démarche de développement complète et générique.
L’architecture du système est conçue dès le départ de façon très pragmatique[réf. nécessaire] : elle
est adaptée au contexte de travail, aux besoins de l’utilisateur, aux possibilités de réutilisation
de bibliothèques ou de « briques » préexistantes. L’élaboration de l’architecture est d’abord
grossière et indépendante des cas d’utilisation (on veillera cependant à ce qu’elle n’empêche
pas leur réalisation) puis, un sous-ensemble de fonctions essentielles est identifié et
l’architecture est reprise et détaillée suivant cet ensemble. De la spécification à la précision
des cas[pas clair], l’architecture évolue, incluant finalement de nouveaux cas, ainsi de suite,
jusqu’à ce que l’architecture ait atteint un niveau de développement suffisamment élevé et
stable pour donner lieu au développement d’un prototype qui sera présenté au client achevant
ainsi une itération.
Une itération est une succession d'enchainements d'activités. Un incrément est une avancée
dans les stades de développement. À chaque itération on retrouve les activités de spécification
des besoins, de conception, jusqu’au prototypage exécutable. Une nouvelle itération, par
exemple après démonstration du prototype aux utilisateurs, reprendra la spécification en la
précisant ou la corrigeant, puis reprenant l’élaboration, etc.
Les incréments sont définis par le projet, et chaque incrément va ajouter de nouvelles
fonctionnalités. Les incréments peuvent suivre les différents cas d’utilisation par exemple. La
difficulté résidera dans le fait de combiner finalement les sous-projets ou incréments ensemble
et de respecter leurs interdépendances et la cohérence générale du produit envisagé. C’est donc
également un développement sous forme de composants qui est proposé. Il utilisera au mieux
les apports des technologies objets.
PU intègre les deux visées dans le but de minimiser les risques de contre-sens par rapport aux
besoins ainsi que le risque de développements infinis, indéfinis, mal définis ou inachevés : Ici
l’utilisateur peut corriger lui-même, sur les prototypes, la tournure que prend le
développement. Dès le début, des résultats tangibles sont obtenus même s’ils ne sont que
prototypiques. Certaines implémentations de PU considèrent d’ailleurs les prototypes comme
des versions à part entière du système final. Les fonctions subalternes peuvent très bien, dans
15
une telle optique, être abandonnées en cours de route pour des questions de coûts ou de délais
par exemple. Enfin, si les besoins utilisateurs changent en cours de développement, cette
évolution peut être, dans une certaine mesure, intégrée. Ce n’est pas le cas dans le cadre d’un
développement séquentiel.
I.3. PRESENTATION DES ARCHITECTURES APPLICATVES
L’architecture applicative logicielle décrit d’une manière symbolique et schématique les

différents éléments d’un ou de plusieurs systèmes informatiques, leurs interrelations et leurs
interactions. Contrairement aux spécifications produites par l’analyse fonctionnelle, le modèle
d'architecture, produit lors de la phase de conception, ne décrit pas ce que doit réaliser un
système informatique mais plutôt comment il doit être conçu de manière à répondre aux
spécifications. L’analyse décrit le « quoi faire » alors que l’architecture décrit le « comment
le faire ». (Josey, 10 juillet 2014)
a. Contexte et motivation
La phase de conception logicielle est l'équivalent, en informatique, à la phase de conception
en ingénierie traditionnelle (mécanique, civile ou électrique) ; cette phase consiste à réaliser
entièrement le produit sous une forme abstraite avant la production effective. Par contre, la
nature immatérielle du logiciel (modelé dans l'information et non dans la matière), rend la
frontière entre l'architecture et le produit beaucoup plus floue que dans l'ingénierie
traditionnelle. L'utilisation d'outils CASE (Computer-aided software engineering) ou bien la
production de l'architecture à partir du code lui-même et de la documentation système
permettent de mettre en évidence le lien étroit entre l'architecture et le produit.
L'architecture logicielle constitue le plus gros livrable d'un processus logiciel après le produit
(le logiciel lui-même). En effet, la phase de conception devrait consommer autour de 40 % de
l'effort total de développement et devrait être supérieure ou égale, en effort, à la phase de
codage mais il peut être moindre. L'effort dépend grandement du type de logiciel développé,
de l'expertise de l'équipe de développement, du taux de réutilisation et du processus logiciel.
Les deux objectifs principaux de toute architecture logicielle sont la réduction des coûts et
l'augmentation de la qualité du logiciel ; la réduction des coûts est principalement réalisée par
la réutilisation de composants logiciels et par la diminution du temps de maintenance
(correction d'erreurs et adaptation du logiciel). La qualité, par contre, se trouve distribuée à
travers plusieurs critères ; la norme ISO/IEC 25010 est un exemple d'un tel ensemble de
critères.
b. Critères de qualité logicielle
- L'interopérabilité extrinsèque exprime la capacité du logiciel à communiquer et à utiliser les
ressources d'autres logiciels comme les documents créés par une certaine application.
16
- L'interopérabilité intrinsèque exprime le degré de cohérence entre le fonctionnement des

commandes et des modules à l'intérieur d'un système ou d'un logiciel.
- La portabilité exprime la possibilité de compiler le code source et/ou d'exécuter le logiciel sur
des plates-formes (machines, systèmes d'exploitation, environnements) différentes.
- La compatibilité exprime la possibilité, pour un logiciel, de fonctionner correctement dans un
environnement ancien (compatibilité descendante) ou plus récent (compatibilité ascendante).
- La validité exprime la conformité des fonctionnalités du logiciel avec celles décrites dans le
cahier des charges.
- La vérifiabilité exprime la simplicité de vérification de la validité.
- L'intégrité exprime la faculté du logiciel à protéger ses fonctions et ses données d'accès non
autorisés.
- La fiabilité exprime la faculté du logiciel à gérer correctement ses propres erreurs de
fonctionnement en cours d'exécution.
- La maintenabilité exprime la simplicité de correction et de modification du logiciel, et même,
parfois, la possibilité de modification du logiciel en cours d'exécution.
- La réutilisabilité exprime la capacité de concevoir le logiciel avec des composants déjà conçus
tout en permettant la réutilisation simple de ses propres composants pour le développement
d'autres logiciels.
- L'extensibilité exprime la possibilité d'étendre simplement les fonctionnalités d'un logiciel
sans compromettre son intégrité et sa fiabilité.
- L'efficacité exprime la capacité du logiciel à exploiter au mieux les ressources offertes par la
ou les machines où le logiciel sera implanté.
- L'autonomie exprime la capacité de contrôle de son exécution, de ses données et de ses
communications.
- La transparence exprime la capacité pour un logiciel de masquer à l'utilisateur (humain ou
machine) les détails inutiles à l'utilisation de ses fonctionnalités.
- La composabilité exprime la capacité pour un logiciel de combiner des informations provenant
de sources différentes.
- La convivialité décrit la facilité d'apprentissage et d'utilisation du logiciel par les usagers.
17
c. Diminution de la dégradation du logiciel
Graphique de dégradation du logiciel en fonction de l'architecture ; source : togaf/andrew josey et al.

Une architecture faible ou absente peut entraîner de graves problèmes lors de la maintenance
du logiciel. En effet, toute modification d'un logiciel mal architecturé peut déstabiliser la
structure de celui-ci et entraîner, à la longue, une dégradation (principe d'entropie du logiciel).
L'architecte informatique devrait donc concevoir, systématiquement, une architecture
maintenable et extensible.
Dans les processus itératifs comme le processus unifié, la gestion des changements est
primordiale. En effet, il est implicitement considéré que les besoins des utilisateurs du système
peuvent changer et que l'environnement du système peut changer. L'architecte informatique a
donc la responsabilité de prévoir le pire et de concevoir l'architecture en conséquence ; la plus
maintenable possible et la plus extensible possible.
d. Les modèles d'architecture
Un modèle de conception (ou d'architecture) est composé d'un ensemble de points de vue,
chacun étant composé d'un ensemble de différentes sortes de diagrammes. Il propose
également des moyens pour lier les différentes vues et diagrammes les uns aux autres de
manière à naviguer aisément, il s'agit des mécanismes de traçabilité architecturale. La
traçabilité doit également s'étendre aux spécifications systèmes et même jusqu'aux besoins que
ces spécifications comblent. La devise des trois pères fondateurs d'UML est « Centré sur
l'architecture, piloté par les cas d'utilisation et au développement itératif et incrémentiel ».
Cette devise indique clairement qu'aucune décision architecturale ne doit être prise sans que
celle-ci ne soit dirigée (pilotée) par la satisfaction des spécifications systèmes (cas
d'utilisation).
- Le modèle conventionnel
18
Modèles d'analyse et d'architecture centrées sur les données avec traçabilité.

Ce diagramme décrit, à gauche, les spécifications systèmes qui sont également représentées
par des diagrammes (Entités-Relations, Flux de données, États Transitions). Et à droite, nous
avons les différentes activités de conception prenant comme intrants les livrables de la phase
d'analyse. Nous voyons que l'architecture logicielle traditionnelle nécessiterait de produire au
moins quatre vues distinctes : une architecture des données (conception des données), une
architecture fonctionnelle et/ou modulaire (conception architecturale), une autre architecture
fonctionnelle et/ou modulaire pour les interfaces utilisateurs (conception des interfaces) et une
architecture détaillée (ordinogrammes, états transitions) des différents modules (conception
des composants).
La pyramide exprime que chaque couche est bâtie sur la précédente.
- Le modèle des 4 + 1 vues
Modèle d'architecture de Philippe Kruchten (modèle des 4 + 1 vues)

Le modèle de Kruchten dit modèle des 4 + 1 vues est celui adopté dans le processus unifié. Ici
encore, le modèle d'analyse, baptisé vue des cas d'utilisation, constitue le lien et motive la
création de tous les diagrammes d'architecture.
e. Modèles structurels
Un modèle structurel d'une architecture se focalise sur la décomposition d'un système en un
ensemble d'éléments interconnectés plus simples. Un système peut ainsi être décomposé en
sous-systèmes, puis en modules ou composants, et en éléments plus simples. La modélisation
19
UML permet cette vision structurelle par des diagrammes de déploiement, des diagrammes de
composants, des diagrammes de structure composite, des diagrammes de paquetage, et des
diagrammes de classe. La modélisation C4 permet la visualisation de la décomposition en
systèmes, en conteneurs (c'est-à-dire en sous-système exécutable qui peut être déployé de
façon indépendante) et en composants.
- Architecture en appels et retours
L'architecture en appels et retours est basée sur le raffinement graduel proposé par Niklaus
Wirth. Cette approche, également appelée décomposition fonctionnelle, consiste à découper
une fonctionnalité en sous-fonctionnalités qui sont également divisées en sous-sous-
fonctionnalités et ainsi de suite ; la devise diviser pour régner est souvent utilisée pour décrire
cette démarche.
- Architecture en couches
La conception de logiciels nécessite de recourir à des bibliothèques. Une bibliothèque très
spécialisée utilise des bibliothèques moins spécialisées qui elles-mêmes utilisent des
bibliothèques génériques. De plus, comme nous l'avons déjà mentionné, le développement
efficace de composants réutilisables nécessite de créer une bibliothèque logicielle ;
l'architecture en couches est la conséquence inéluctable d’un tel approche.
- Architecture centrée sur les données
Dans l'architecture centrée sur les données, un composant central (SGBD, Datawarehouse,
Blackboard) est responsable de la gestion des données (conservation, ajout, retrait, mise à jour,
synchronisation…). Les composants périphériques, baptisés clients, utilisent le composant
central, baptisé serveur de données, qui se comporte, en général, de façon passive (SGBD,
Datawarehouse). Un serveur passif ne fait qu'obéir aveuglément aux ordres alors qu'un serveur
actif (Blackboard) peut notifier un client si un changement aux données qui le concerne se
produit.
Cette architecture sépare clairement les données (serveurs) des traitements et de la présentation
(clients) et permet ainsi une très grande intégrabilité, en effet, des clients peuvent être ajoutés
sans affecter les autres clients. Par contre, tous les clients sont dépendants de l'architecture des
données qui doit rester stable et qui est donc peu extensible.
- Architecture en flot de données
L'architecture en flot de données est composée de plusieurs composants logiciels reliés entre
eux par des flux de données. L'information circule dans le réseau et est transformée par les
différents composants qu'elle traverse. Lorsque les composants se distribuent sur une seule
ligne et qu'ils ne font que passer l'information transformée à leur voisin, on parle alors
d'architecture par lot (batch). Si les composants sont répartis sur un réseau informatique et
20
qu'ils réalisent des transformations et des synthèses intelligentes de l'information, on parle

alors d'architecture de médiation. Les architectures orientées évènements font également partie
de cette catégorie.
- Architecture orientée objets
Les composants du système (objets) intègrent des données et les opérations de traitement de
ces données. La communication et la coordination entre les objets sont réalisées par un
mécanisme de passage de messages. L'architecture orientée objets est souvent décrite par les
trois piliers : encapsulation, héritage et polymorphisme. L'encapsulation concerne
l'architecture détaillée de chaque objet, les données étant protégées d'accès direct par une
couche d'interface.
- Architecture orientée agents
L'architecture orientée agents correspond à un paradigme où l'objet, de composant passif,
devient un composant projectif :
En effet, dans la conception objet, l'objet est essentiellement un composant passif, offrant des
services, et utilisant d'autres objets pour réaliser ses fonctionnalités ; l'architecture objet n'est
donc qu'une extension de l'architecture en appels et retours, le programme peut être écrit de
manière à demeurer déterministe et prédictible.
I.4. PRESETTATION DES SYSTEMES DE GESTIONS DE BASES DES DONNEES
Un système de gestion de base de données (abr. SGBD) est un logiciel système servant à
stocker, à manipuler ou gérer, et à partager des données dans une base de données, en
garantissant la qualité, la pérennité et la confidentialité des informations, tout en cachant la
complexité des opérations. (Nicolas, 20 juin 2006)
Un SGBD (en anglais DBMS pour database management system) permet d'inscrire, de
retrouver, de modifier, de trier, de transformer ou d'imprimer les informations de la base de
données.
a. Fonctionnalités
Un SGBD permet d'enregistrer des données, puis de les rechercher, de les modifier et de créer
automatiquement des comptes rendus (anglais report) du contenu de la base de données. Il
permet de spécifier les types de données, la structure des données contenues dans la base de
données, ainsi que des règles de cohérence telles que l'absence de redondance.
b. Typologie
Selon leur construction et les possibilités qu'ils offrent, les SGBD peuvent être dits
hiérarchiques, en réseau, relationnels, orientés objet, objet-relationnels, XML/RDF ou mixtes
:
21
- hiérarchique : une base de données hiérarchique est une base de données dont le système de
gestion lie les enregistrements dans une structure arborescente où chaque enregistrement n'a
qu'un seul possesseur. Elle a été utilisée dans les premiers systèmes de gestion de base de
données de type mainframe et a été inventée par la NASA ;
- réseau : le modèle de base de données en réseau permet à chaque enregistrement d'avoir
plusieurs enregistrements parents et enfants, formant ainsi une structure de graphe généralisée
et offrant une modélisation plus naturelle des entités que le modèle relationnel.
Modèle de données relationnel.

- relationnel : selon ce modèle, les données sont placées dans des tables avec lignes et colonnes
et n'importe quelle donnée contenue dans la base de données peut être retrouvée à l'aide du
nom de la table, du nom de la colonne et de la clé primaire.
- orienté objet et objet-relationnel : les SGBD orientés objet sont un sujet de recherche depuis
1980, lorsque sont apparus les premiers langages de programmation orientée objet. Ils sont
destinés à offrir les fonctionnalités des SGBD à des langages orientés objet et permettre le
stockage persistant des objets.
- à base de XML ou RDF : une base de données XML Native (NXD en anglais) est une base
de données qui s'appuie sur le modèle de données fourni par XML. Elle utilise typiquement
des langages de requête XML comme XPath ou XQuery. Une extension possible est une base
RDF, avec le langage d'interrogation SPARQL ;
- mixte : de tels SGBD utilisent les différents paradigmes évoqués ci-dessus.
De plus, les SGBD peuvent être distribués, centralisés ou embarqués et peuvent être spatiaux
:
- centralisé ou distribué : un SGBD est dit centralisé lorsque le logiciel contrôle l'accès à une
base de données placée sur un ordinateur unique. Il est dit distribué lorsqu'il contrôle l'accès à
des données qui sont dispersées entre plusieurs ordinateurs.
- embarqué : une base de données embarquée (anglais embedded) est un SGBD sous forme de
composant logiciel qui peut être incorporé dans un logiciel applicatif.
22
- spatial : les applications informatiques telles que les systèmes d'information géographiques et
les outils de conception assistée par ordinateur utilisent des SGBD de type spatial.
c. Quelques Systèmes de gestion des bases de données

Nom SGBD Année Éditeur Caractéristiques type de
logiciel
Ingres 1974 Ingres relationnel, spatial, serveur
Corporation centralisé,
distribué
Caché 1997 InterSystems objet, pour serveur
entreprises,
distribué
MariaDB 2009 Monty serveur
Program Ab
MaxDB [44], [45] 1977 SAP AG et objet-relationnel, composant
MySQL AB pour entreprises et logiciel
groupes de travail,
centralisé
Microsoft Access 1992 Microsoft relationnel, pour L4G
particuliers et
groupes de
travail
Microsoft SQL 1989 Microsoft entreprises, serveur
Server groupes de travail,
particuliers,
relationnel,
distribué
MySQL 1995 Oracle centralisé, serveur
Corporation embarqué,
et MySQL distribué, pour
AB entreprises,
groupes de travail
et particuliers
Oracle 1979 Oracle entreprises, serveur
Database Corporation groupes de travail,
particuliers,
relationnel, spatial,
distribué
CHAPITRE 2. PRESENTATION DE LA PHARMACIE NEW SIDIPHAR ET ANALYSE
DU METIER
I.1 Présentation de new Sidiphar
NEW SIDPHAR est une pharmacie de vente des produits pharmaceutique. Localisée à
Lubumbashi, Commune de Lubumbashi, Numéro 2914avenue Mpolo ; la pharmacie collabore,
au moment de la rédaction de notre mémoire, avec le responsable de la pharmacie. Elle a
pour mission la fourniture des produits pharmaceutiques à une grande partie de la population
à un prix abordable contribuant ainsi à l'amélioration des services de santé. La collaboration
avec des assureurs affirme sa volonté de permettre à la population d’obtenir des produits
pharmaceutiques dont ils ont besoin et à des prix accessibles.
I.2 Analyse du métier
Les visites et les interviews conduites à la pharmacie NEW SIDPHAR nous ont permis de
constater l’existence d’un service d'accueil, qui est aussi le service de vente, qui possède deux
ordinateurs tournant sous Windows 7 avec les logiciels de la suite Microsoft Office. Chacun
de ces deux ordinateurs possèdent une petite imprimante HP mini
Le service de gestion possède également un ordinateur tournant sous Windows 7. Ces trois
ordinateurs sont reliés entre eux grâce à un Switch formant ainsi un petit réseau local poste à
poste.
Une autre Imprimante HP Laser Jet est partagé en réseaux pour une impression format A4.
Les employés nous ont affirmé qu’avant, ils possédaient un logiciel de gestion qui n'est plus
d'usage à cause de son instabilité et son inefficacité. Ce qui explique la présence des
imprimantes mini pour l'impression des factures. Il ne nous a malheureusement pas été possible
de vérifier cette affirmation car nous n’avons pas eu l'occasion de voir/d'utiliser ce logiciel (car
il n’existe plus), et de l'analyser en détail.
L'analyse de matériel informatique que possède la pharmacie se résume dans le tableau Suivant:
Matériel Quantité Système Composant
d'Exploitation Logiciel utilisé
Microsoft Office
Ordinateur 3 Windows XP
2007
Switch 1 - -
Imprimante HP 2 - -
Mini
Imprimante HP 1 - -
Laser
Jet
Tableau 1 : Matériel Informatique de la Pharmacie New Sidiphar
L'abandon de l’ancien logiciel fait que NEW SIDIPHAR gère maintenant ses informations
grâce aux registres et au logiciel Microsoft Excel. Il dispose d'une base de données (dans Excel)
contenant le nom des médicaments, les prix et les quantités dont ils disposent. Le gérant se
charge de la lourde tâche de tenir à jour les données en consultant les factures des ventes
effectuées chaque jour.
La pharmacie travaille avec des partenaires (assureurs) dont Mutuelle et Jubilée Insurance à
l'heure de l'écriture de ce Tfc. Ces partenaires fournissent un catalogue des médicaments qu'ils
offrent à leurs clients. La vente des médicaments s'effectue selon les procédures de gestion
décrites ci-après.
I.2.1 Description des procédures de gestion
La pharmacie NEW SIDIPHAR collabore actuellement avec la Mutuelle et la
Jubilée Insurance, deux compagnies d'assurance œuvrant au Burundi. Les affiliés de ces
assureurs peuvent acheter des médicaments à un prix préférentiel selon le contrat établit entre
leurs assureurs et NEW SIDPHAR.
 La Mutuelle:
· fournit la liste des médicaments qu'elle offre à ses affiliés ;

· propose le prix qu'il achètera chacun des médicaments qu'il offre à ses affiliés. Ces prix
sont discutables au moment de la signature du contrat de partenariat ;
· fournit aussi le pourcentage qu'il couvre pour chaque produit acheté. En général, les
spécialités sont couvertes à 70% tandis que les génériques sont couverts à 80% ;
· fournit une information supplémentaire indiquant les conditions dans lesquels un

médicament peut être attribué. Ces mentions sont expliquées dans le tableau ci-dessous :
code Nom Type Générique Prix en Réduction

médicament en
Fbu
%
87 Quinine* Générique - 3000 80
32 Captopril Spécialité Arnolol 7000 70

(S)
74 Arnolol Générique - 4000 80
Tableau 2 : Les mentions de l’assureur Mutuelle.
Les informations fournies par la Mutuelle aux pharmacies partenaires
Légende Signification Description
* À se référer au
Pour avoir ce médicament le client doit d'abord se référer
siège
au siège de la Mutuelle.
** Produits Ce médicament est attribué uniquement

hospitalier aux personnes hospitalisées.
*** Fiche exigée Pour obtenir ce médicament, le client se présente

obligatoirement avec une fiche fournie par la mutuelle.
S Spécialité Si un client veut une spécialité d'un médicament mais
remboursable qu’il n'est pas offert, la Mutuelle se contentera de payer
à hauteur la somme du générique correspondant. Le client devra
de son alors payer la différence pour obtenir la spécialité
générique. souhaitée.
Tableau 3: Informations fournies par la Mutuelle aux pharmacies partenaires
Les données reprises dans le tableau ci-haut vont nous permettre d'analyser et de comprendre
les informations fournies par la Mutuelle. Prenons l'exemple de la première ligne : Il est indiqué
que la Quinine est un médicament de type générique et s'achète 30000 FC avec une réduction
de 80 %. C’est à dire que les clients vont payer 20 % soit 6000 FC et la Mutuelle payera le
reste soit 24000 FC. L'étoile à côté de Quinine indique que pour obtenir le médicament il faut
se référer au siège. La colonne générique est vide car le médicament est lui-même générique.
Cette colonne est intéressante lorsqu'il s'agit d'une spécialité comme c'est le cas de la deuxième
ligne. Dans la deuxième ligne, on trouve que Captopril est une spécialité qui s'achète à 70000
FC avec une couverture de 70 % et qu’il a comme générique Arnolol qui s'achète 40000 FC
avec une couverture de 80 %. Le (S) se trouvant devant captopril indique une information
intéressante. Il indique que pour ce médicament, Mutuelle ne remboursera que le prix de son
générique. Donc si un client veut ce médicament, il devra payer lui-même la différence.
La Jubilée Insurance procède de la même façon. Comme la Mutuelle, elle propose des prix
pour les médicaments qu'elle offre à leurs affiliés. Mais contrairement à la Mutuelle qui
n’assure que les fonctionnaires de la fonction publique, Jubilée Insurance assure plusieurs
entreprises et/ou des personnes. Elle fournit donc à la pharmacie la liste des personnes et/ou
entreprises assurées et chacun possède une marge de couverture particulière selon le contrat.
Ci-dessous le type d’informations fournies par Jubilée Insurance.
Assurés Réduction
Leo 100%
Smart 80%
Minani Jean 70%

Tableau 4: Informations fournies par la Jubilée Insurance Company
Selon le tableau ci-dessus signifie que les employés de Leo sont totalement couverts, par
conséquent ils peuvent prendre des médicaments gratuitement. Ceux de Smart sont couverts à
80%, alors que ceux Minani Jean sont couverts à 70%.
Jubilée Insurance fournit également la liste des médicaments comme le fait la Mutuelle, dont
l’exemple est repris dans le tableau ci-dessous:
code Nom Type Générique Prix

médicament
87 Quinine Générique - 3500
32 Captopril Spécialité Arnolol 7500
74 Arnolol Générique - 4500
Tableau 5 : Médicaments fournis par la Jubilée Insurance Company
Tout comme la Mutuelle, les données ci-dessus sont fictives. La colonne réduction n'est plus
nécessaire car cela dépend dans ce cas du client et non pas du médicament. Les listes fournies
par la Jubilée Insurance peuvent également comporter une mention (N) qui veut dire non
attribuée.
Dans les deux cas, le client paie sa part s'il n'est pas totalement couvert et obtient une facture
après avoir complété un formulaire spécifique à chaque assureur. C'est ce formulaire qui va
être envoyé vers l'assureur à la fin du mois pour qu’il rembourse à la pharmacie la partie
couverte. Le formulaire contient les informations sur le client, les médicaments qu'il a pris, la
somme qu'il a payé ainsi que la somme que l'assureur doit payer.
La pharmacie vend également des médicaments à des personnes non assurés par une
compagnie d'assurance. Dans ce cas, c’est la procédure standard de toute vente qui est
appliquée. Un client achète selon le prix fixé et paie cash. Il reçoit en retour les médicaments
et un reçu.
I.3 Critique de l’existant
La procédure de vente des médicaments est actuellement manuelle. Bien que le gestionnaire
essaie de tenir à jour le stock grâce aux logiciels de la suite Microsoft Office
(Microsoft Access), ceci se révèle être une lourde tâche qui l’oblige à parcourir tous les reçus,
comptabiliser les médicaments sortis par jour, et mettre à jour le fichier. C'est une lourde tâche
qui conduit souvent à des erreurs et une perte énorme de temps. La vente, quant à elle, est
complètement manuelle. Le pharmacien doit d'abord aller vérifier si le médicament existe en
stock, d’où une perte de temps et un mauvais service fourni aux clients (lenteur).
Plus ennuyant encore, à chaque fois qu'un client veut acheter des médicaments, le vendeur
est obligé de calculer la somme qu'il doit payer, soit à la main, soit à la calculatrice. La
procédure devient vite fastidieuse. Voyons cela dans un cas concret :
Un client, affilié de la mutuelle veut acheter un médicament “X”. Le pharmacien regarde

d'abord sur la liste si ce médicament est attribué par la Mutuelle, il doit vérifier en plus que ce
médicament est disponible en stock. Une fois les deux conditions remplies, il va regarder le
pourcentage couvert par la Mutuelle pour le médicament demandé et calculer la part que le
client doit payer cash (comptant) pour avoir le médicament.
Supposons que le médicament “X” demandé par le client est une spécialité remboursable à
titre générique, la mutuelle n'offre pas le médicament “X” directement. Il propose de payer
pour le client un médicament “Y”, qui est son générique, et le client se charge de payer la
différence. Concrètement c'est ce qui suit :
Si le médicament (Spécialité) X s'achète 50000 FC et que le médicament Y (Son générique)

s'achète 30000FC, la Mutuelle se propose de payer 70% du médicament “Y”, soit
21000 FC. Pour que le client puisse obtenir le Médicament X, il devra d’abord payer la
différence entre 50000 FC et 21000 FC, soit 29000 FC (50000 FC – 21000 FC = 29000 FC).
Considérons le temps que le pharmacien a mis pour trouver toutes ces informations, sans
oublier le risque d'erreur en faisant les calculs. Si un autre client ayant une urgence était entré
deux minutes après, il serait probablement déjà parti suite à la lenteur du service.
Du côté du pharmacien, effectuer cette opération dix fois successives conduit vite à un vrai
casse-tête, et des fois à des erreurs de calcul. C'est dans cette situation qu'on réalise le besoin
d’un outil spécialisé qui automatise ces tâches est nécessaire.
I.4 Solutions proposées
Pour pallier aux problèmes cités ci-haut, nous proposons la mise en place d’un outil capable
de résoudre les défis liés à la gestion des ventes effectuées dans la pharmacie New
SIDPHAR.
La dite solution consiste en la création d'une application informatique assurant la liste non
exhaustive de fonctionnalités suivantes :
 Calculer automatiquement les prix des médicaments selon le type d’achat ;

 Enregistrer et imprimer automatiquement des factures pour les clients ;
 Enregistrer et imprimer au besoin des factures pour les assureurs ;
 Tenir à jour automatiquement le stock des médicaments après chaque vente ;
 Fournir des rapports des ventes effectuées quotidiennement et mensuellement ;
 Envoi des notifications en cas de baisse ou expiration d’un produit dans le stock ;
 Effectuer et réceptionner des commandes auprès des fournisseurs ;
 Payement des fournisseurs.
L’introduction brève de la pharmacie New SIDPHAR et l’analyse de son mode de

fonctionnement, faits dans ce deuxième chapitre, nous ont permis de découvrir les problèmes
de gestion que la pharmacie rencontre. Ainsi, nous avons proposés la réalisation d’une
application web de gestion des ventes des produits pharmaceutiques comme une solution
pouvant répondre aux problèmes identifiés. Dans le chapitre suivant, nous nous proposons de
parler des technologies web qui sont la clé de la solution que nous suggérons.
CHAPITRE III : CONCEPTION DU SYSTEME
II.1. Définition :
Dans ce chapitre, il s’agit de mettre en place notre système d’information grâce aux
notions vues précédemment
II.2 Modélisation du nouveau Système
Dans cette partie, nous mettons en pratique la théorie UML annoncé plus haut, en
modélisant notre nouveau système. Il existe plusieurs logiciels permettant de modéliser en UML.
Nous avons choisi DIA. Il est gratuit et possède des extensions pour générer automatiquement des
codes (JAVA, PHP, C#, C++,..) correspondant à notre modélisation.
II.2.1 Démarche de développement
UML n’est qu’un langage de modélisation et non une méthode. Nous n’avons,
jusqu’aujourd’hui, pas une démarche unifiée mettant en œuvre UML pour construire les modèles ou
conduire un projet. Cependant les auteurs d’UML, ont décrit, dans un ouvrage « Le Processus unifié
de développement logiciel », le processus unifié (Unified Process) qui doit être associé à UML.
Il existe deux principaux processus de développement objet qui ont été associés à
UML à savoir l’UP (Unified Process) et le RUP (Rational Unified Process). Dans le cadre de ce
mémoire, nous n’allons pas donner une présentation détaillée d’UP. Cependant, il nous est paru
intéressant de dégager les idées fondatrices d’U.P dans le cadre d’une présentation générale.
II.2.2 Les principes d’UP
Le processus de développement UP, associé à UML, met en œuvre les principes suivants :
 Processus guidé par les cas d’utilisation
L’orientation forte donnée par UP est de montrer que le système à construire se définit
d’abord avec les utilisateurs. Les cas d’utilisation permettent d’exprimer les interactions du système
avec les utilisateurs, donc de capturer les besoins. Une seconde orientation est de montrer comment
les cas d’utilisation constituent un vecteur structurant pour le développement et les tests du système.
Ainsi le développement peut se décomposer par cas d’utilisation et la réception du logiciel sera, elle
aussi, articulée par cas d’utilisation.
 Processus itératif et incrémental
Ce type de démarche étant relativement connu dans l’approche objet, il paraît naturel
que U.P préconise l’utilisation du principe de développement par itérations successives.
Concrètement, la réalisation de maquette et prototype constitue la réponse pratique à ce principe. Le
développement progressif, par incrément, est aussi recommandé en s’appuyant sur la décomposition
du système en cas d’utilisation. Les avantages du développement itératif se caractérisent comme suit
:
- les risques sont évalués et traités au fur et à mesure des itérations ;
- les premières itérations permettent d’avoir un feed-back des utilisateurs ;
- les tests et l’intégration se font de manière continue ;
- les avancées sont évaluées au fur et à mesure de l’implémentation.
 Processus centré sur l’architecture
Les auteurs d’UP mettent en avant la préoccupation de l’architecture du système dès
le début des travaux d’analyse et de conception. Il est important de définir le plutôt possible, même
à grandes mailles, l’architecture type qui sera retenue pour le développement, l’implémentation et
ensuite le déploiement du système. Le vecteur des cas d’utilisation peut aussi être utilisé pour la
description de l’architecture.
 Processus orienté par la réduction des risques
L’analyse des risques doit être présente à tous les stades de développement d’un
système. Il est important de bien évaluer les risques des développements afin d’aider à la bonne prise
de décision. Du fait de l’application du processus itératif, UP contribue à la diminution des risques
au fur et à mesure du déroulement des itérations successives.
Ces principes sont à la base du processus unifié décrit par les auteurs d’UML. Ce sont
ces mêmes principes qui nous ont guidés dans le processus de conception de notre application.
 Spécifications des besoins fonctionnels et non fonctionnels
- Les besoins fonctionnels
Les besoins fonctionnels se rapportent aux fonctionnalités que l'application doit offrir pour satisfaire
les utilisateurs. Les fonctionnalités que doit intégrer l'application à développer sont :
 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, liste de médicaments en vois de rupture ou de péremption).
 Gestion des commandes : cette opération est établie lorsqu'il y a un besoin de renouveler le stock
des médicaments. L'utilisateur peut créer un bon de commande correspondant à ses besoins ou se
référer directement à la liste des produits en rupture dans le stock.
 Gestion des ventes: cette opération consiste à réaliser une vente sur l’application.
- 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 :
 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.
 Ergonomie : le système devra offrir aux utilisateurs une interface qui soit la plus riche possible
afin de limiter le nombre d'écrans. Par ailleurs, l'interactivité devra être adaptée (usage du clavier,
menu, etc..).
 Fiabilité : le système doit être fiable (l’utilisateur doit avoir confiance en la qualité de son produit,
pour mieux s’occuper du malade tant le domaine est sensible).
 Accessibilité: l’application doit être mobile c’est à dire que le gérant où le pharmacien peuvent
accéder à cette dernière et avoir le même service en dehors de la pharmacie.
II.2.3 Diagramme de CAS d’utilisation
Conformément aux processus de développement Unifié U.P, la première étape dans

l’élaboration de nos différents diagrammes UML commence par l’élaboration du diagramme de cas
d’utilisation. Ce dernier va nous guider dans l’élaboration des autres diagrammes.
Les différents acteurs intervenant dans notre système sont :
 Caissier : il (Elle) accueille les clients, regarde si les médicaments souhaités sont disponibles
et peut également les vendre ;
 Pharmacien : comme le réceptionniste, il peut vendre les médicaments et donner des
prescriptions de prise de médicaments si nécessaire ;
 Gérant : il gère la pharmacie, contrôle le stock, s’assure que les médicaments sont disponible
en stock, passe des commandes si nécessaire et, fournit des rapports au patron ;
 Patron : il contrôle et assure le bon fonctionnement de la pharmacie.
Les diagrammes de cas d’utilisation, que nous avons établi, sont représentés ci-dessous.
A. Diagramme de cas d’utilisation de l’employer :
Le diagramme ci-dessous représente les cas d’utilisations identifies pour l’employer.
Figure 1 : Diagramme de cas d’utilisation de l’employer.
B. Diagramme de cas d’utilisation du gérant :
Le diagramme ci-dessous représente les cas d’utilisations identifies pour le gérant.

Figure 2 : Diagramme de cas d’utilisation du gérant
C. Diagramme de cas d’utilisation global :
Le diagramme de cas d’utilisation global représente les différentes fonctions de notre application
autour des quelles, sont érigées les besoins et les exigences des différents acteurs qui interagiront au
sein même du système.
Figure 3 : Diagramme global de cas d’utilisations.

II.2.2.1. Description textuelle de chaque cas d’utilisation
Cas d’utilisation N°1 : Authentification
Acteur Gérant/ Employer

principal
Objectif S’authentifier avant d’accéder à la page d’accueil de l’application.
Préconditions Avoir une connexion internet et un navigateur.
Scénarios L’utilisateur se connecte à internet, lance l’application web via un navigateur web.
Le système demande à l’utilisateur de s’authentifier.
L’utilisateur saisit son nom et son mot de passe.
Le système vérifie la conformité des informations saisies en envoyant une requête
aux serveurs.
La requête est vérifié par le serveur et envois une réponse favorable.
L’utilisateur accède au menu principal.
Alternative En cas de réponse défavorable du serveur, le système affiche un message d’erreur en

cas d’erreur de saisie ou bien d’un champ incomplet (retour à 2).
Tableau 1 : Description textuelle du cas d’utilisation Authentification.
Cas d’utilisation N°2: Gérer le stock
Acteur principal Gérant/ Employer
Objectif Enregistrer un produit dans le stock existant.
Précondition Authentification
Scénario L’utilisateur saisie le nom du produit et tous ces caractéristiques (numéros de lot,
date d’expiration, quantité…), puis clique sur enregistrer.
Le système envois la requête au serveur.
Après le traitement des données par le serveur, il envoie un message au système.
Le système affiche à l’écran la réponse du serveur
Alternative Le système affiche un message d’erreur en cas d’une erreur de saisie

ou bien d’un champ incomplet (retour a -1-).
Tableau 3 : Description textuelle du cas d’utilisation gérer le stock.
Cas d’utilisation N°3: Gérer les ventes
Acteur principal Gérant/Employer
Objectif Enregistrer une vente de produit/Imprimer la facture si besoin.
Préconditions Authentification.
Scénario 1. L’utilisateur saisie le nom du produit dans la barre de recherche de

produit puis sélectionne le bon produit ajoute la quantité et clique sur
enregistrer.
2. Une requête est envoyée au serveur pour traitement.
3. Le serveur envoie un message de succès à l’interface de l’utilisateur.
Alternative Le système affiche un message d’erreur en cas d’une erreur de saisie ou bien
d’un champ incomplet (retour a -1-).
Tableau 4 : Description textuelle du cas d’utilisation gérer la vente.

Cas d’utilisation N°4 : Gérer les utilisateurs
Acteur principal Gérant.
Objectif Enregistrer un utilisateur.
Préconditions Authentification.
Scénario 1. Le gérant accède à l’interface gérer les utilisateurs puis clique sur
ajouter un utilisateur et enfin saisit le formulaire d’ajout et clique sur
enregistrer.
3. Le serveur envoie un message de succès à l’interface de l’utilisateur.
Alternative Le système affiche un message d’erreur en cas d’une erreur de saisie ou bien
d’un champ incomplet (retour a -1-).
Tableau 5 : Description textuelle du cas d’utilisation gérer les utilisateurs.
Cas d’utilisation N°5 : Gérer les ruptures

Acteur principal Gérant
Objectif Formuler un bon de commande/ accéder à la liste de produit en rupture.
Préconditions Authentification
Scénario 1. Le gérant accède à l’interface gérer les ruptures.

2. Le gérant demande a accédé à la liste des produit en rupture.
4. Le serveur envois la liste des produits en voit de rupture et l’interface
l’affiche à l’écran.
5. Le gérant peut formuler le bon de commande :
• Saisie des produits et leurs quantités par le gérant qui ajoute au bon de
commande.
• A la fin de sa saisie il peut enregistrer
• Une requête est envoyée au serveur pour traitement.
• Le serveur repend par un message de succès.
Alternative Le système affiche un message d’erreur en cas d’une erreur de saisie ou bien d’un
champ incomplet (retour a -5-).
Tableau 6 : Description textuelle du cas d’utilisation gérer les ruptures.
Cas d’utilisation N°6 : consulter l’état des ventes
Gérant
Acteur principal
Objectif Accéder aux nombreuses listes (liste des produits vendus)
Préconditions Authentification
Scénario 1. Le gérant demande le formulaire de consultation.

2. Le système affiche le formulaire.
3. Le gérant demande de consulter une des listes (listes des produits, périmés
et vendus ou au facture).
5. Le serveur répond et le système affiche la liste demandé.
Alternative Coupure internet/ou problème technique (réactualiser la page/ou vérifié

connexion internet).
Tableau 7: Description textuelle du cas d’utilisation consulter l’état des ventes
II.2.4 Diagramme de séquence pour chaque cas d’utilisation
 Diagramme de séquence N°1 : cas d’utilisation Authentification :
Lorsque l’utilisateur (Gérant, Employer) veux accéder à notre application web, il sera obligé de
s’authentifier avant d’y accéder en saisissant son identifiant et mot de passe, après la saisie le système
envois une requête au serveur pour traiter les informations envoyées, si les informations sont correcte
l’utilisateur accédera à sa session sinon un message d’erreur sera affiché et reconduira l’utilisateur à
la page authentification.
Figure 4 : Diagramme de séquence du cas d’utilisation (Authentification).
 Diagramme de séquence N°2 : cas d’utilisation Gérer la vente :
Lorsque l’utilisateur (Gérant, Employer) a accédé à l’application il lui sera possible d’effectuer
une vente en cliquant sur gestion de vente, après le clique il pourra enregistrer une vente de
produit en introduisant les champs requis et en cliquant sur enregistrer le système envois la
requête au serveur qui lui enregistre les données et envoie un message de succès ou sinon un
message d’erreur sera affiché si il manque un champ.
Figure 5 : Diagramme de séquence du cas d’utilisation (Gérer la vente).
 Diagramme de séquence N°3: cas d’utilisation Gérer le stock
Lorsque l’utilisateur (Gérant, Employer) veux gérer le stock c’est à dire enregistrer un arrivage de
médicament, il doit tout d’abord cliquer sur gestion de stock puis ajouter un produit au stock, pour
ensuite remplir les champ requis et enfin envoyer les données au serveur pour les enregistrer. Après
traitement du serveur un message de succès ou d’erreur sera envoyé.
Figure 6 : Diagramme de séquence du cas d’utilisation (Gérer le stock).
 Diagramme de séquence N°4: cas d’utilisation Gérer les utilisateurs :
Lorsque le gérant veut gérer les utilisateurs il doit tout d’abord accéder à la gestion des
utilisateurs puis rechercher un utilisateur donné pour le modifier.
Après ça recherche le gérant n’a qu’à cliquer sur modifier et remplir les champs requis
et envoyer au serveur pour traitement et enregistrement. Un message d’erreur est
envoyé en cas de champ incomplet sinon un message de succès.
Figure 7 : Diagramme de séquence du cas d’utilisation (Gestion des utilisateurs).
 Diagramme de séquence N°5: cas d’utilisation Gérer les ruptures :

Lorsque le gérant veut passer une commande au fournisseur il pourra formuler un bon de
commande via notre application web. En effet, il doit accéder au formulaire gestion des ruptures
et cliquer sur formuler le bon de commande puis remplir les champs requis et envoyé les données
saisie au serveur pour traitement. Un message de validation serra affiché, l’employé pourra
consulter le bon de commande et commander par téléphone sinon un message d’erreur serra
envoyé par le serveur et le gérant devra corriger son erreur.
Figure 8 : Diagramme de séquence du cas d’utilisation (gérer les ruptures).
 Diagramme de séquence N°6: cas d’utilisation Gérer les échanges :
Quand le gérant veux rechercher un échange de produit, il doit accéder à la rubrique gérer les échange
et demander le formulaire de recherche puis remplir les champs requis et envoyé les donnée au
serveur pour qu’il puisse rechercher et envoyer le but de la rechercher au gérant sinon un message
d’erreur sera envoyé.
Figure 9 : Diagramme de séquence du cas d’utilisation (gérer les échanges).
lOMoAR cPSD| 2894364
 Diagramme de séquence N°7: cas d’utilisation consulter l’état des ventes :
Lorsque le gérant veut consulter l’une des nombreuses listes de notre application, il doit tout d’abord
accéder à la rubrique état des ventes ou il pourra sélectionner une des listes (liste des ventes).
Le serveur envois les données requises dès que la requête d’affichage fini son traitement.
Figure 10 : Diagramme de séquence du cas d’utilisation (État des ventes).
II.2.6. Diagramme des classes participantes

Le diagramme des classes participantes est important puisqu’il permet de faire la jointure entre,
d’une part, les cas d’utilisation, les modèles de la couche métier et l’interface avec l’utilisateur. Il
semble particulièrement important pour guider la phase de production du livrable final.
a. Diagramme de classe participante : s’authentifier
b. Diagramme de classe participante gérer stock
c. Diagramme de classe gérer vente
d. Diagramme de classe participante gérer utilisateur

II.2.6 Diagramme de classe conception
Le diagramme de classes est sans doute le diagramme le plus important à représenter pour les
méthodes d’analyse orientées objet. En effet, il permet de spécifier QUI intervient à l’intérieur du
système.
Un diagramme de classes fait abstraction des aspects dynamiques et temporels du système, il va

permet de représenter une vue statique du système d’information. Il s’agit plutôt des relations entre
les classes, des services rendus et utilisés par chacune d’elles et de l’articulation de l’ensemble [8].
Figure 11 : Diagramme de classes.
 Le modèle relationnel :
Le concepteur d’une base de données relationnelle doit élaborer un schéma relationnel de la base de
données.
Cette activité consiste à définir toutes les relations de la base de données et leurs attributs.
 Règles de passage au modèle relationnel:

Les règles utilisées pour le passage du diagramme de classes de notre application web au modèle
Relationnel sont les suivantes :
 Toute entité devient une relation ayant pour clé primaire son identifiant [9].
 Chaque propriété se transforme en attribut [9].
 Toute association non hiérarchique (de type [n, n] ou de dimension > 2) devient une
relation.
 La clé primaire est formée par la concaténation (juxtaposition) de l'ensemble des
identifiants des entités reliées.
 Toutes les propriétés éventuelles deviennent des attributs qui ne peuvent pas faire partie de
la clé [9].
 Modèle relationnel:
Après avoir appliqué les règles de passage cité précédemment, nous avons abouti au schéma
relationnel de la base de données suivant :
Utilisateur (Id, Nom, Prénom, Mot de passe, Type),
Produits (N_lot, Nom_c, EXP, PPA, Qte, Dosage, Conditionnement),
Vente (Id_V, Nom_C, Qte, Ppa, Total),
Échange (Id_Echange, Id_ph, Nom_ph, Type, Produit, #Id_gérant),
Bon de commande (Id_bon, date_bon, #Id_gérant)
Échanger (#N_lot, #Id_Echange, #d_ph, Produit, Type),
Vendre (#N_lot, #Id_V),
Enregistrer (#id, #Id_v),
Consulter (#Id, #Id_bon)
Enregistrer (#Id, #N_lot).
II.2.7 Diagramme de déploiement
Enfin, nous terminons notre modélisation avec le diagramme de déploiement qui

décrit l’architecture physique de notre application.
Dans ce chapitre, nous avons modélisé notre système selon les analyses que nous avons effectué
dans le Chapitre précédant.
Le prochain chapitre est un complément de celui-ci mais en des termes plus techniques. Nous
décrirons des techniques plus efficaces d’organiser nos classes en suivant des architectures
approuvés de la programmation orientée objet (design patterns).
CHAPITRE IV : PROGRAMMATION
Le grand moment est venu pour présenter la concrétisation des analyses et des théories énoncées
plus haut. Le produit final auquel nous avons abouti à la fin de ce travail est présenté
sommairement dans les captures d’écrans ci-dessous.
Dans ce chapitre dédier à l’étude technique et à l’implémentation, nous avons commencé à définir
les outils de développent utiliser pour l’implémentation de notre application. Ensuite nous passerons
à la présentation de l’application puis on finira par une conclusion.
A. Application web :
Une application web désigne un logiciel applicatif hébergé sur un serveur et accessible via un
navigateur web. Contrairement à un logiciel traditionnel, l’utilisateur d’une application web n’a pas
besoin de l’installer sur son ordinateur. Il lui suffit de se connecter à l’application à l’aide de son
navigateur [10].
 Avantages d’une application web :

1. Accès universel depuis n’importe quel type de poste : PC, portables, téléphone mobile,
tablette ;
2. Aucune incompatibilité de système d’exploitation (il suffit d’avoir un navigateur) ;
3. Travailler depuis n’importe quel endroit de la planète ;
4. Les données sont centralisées ;
5. Les données sont disponibles 24h sur 24 et 7j sur 7 ;
6. Aucun risque de perte de données.
B. Outils de développement :
 Développement des diagrammes :
Pour Réaliser les diagrammes UML qui ont servis à modélisé notre application web, nous avons
utilisé un logiciel et une application web de développement de diagramme, qui sont:
 Umbrello est un outil de modélisation de langage de modélisation unifiée (UML) et un générateur

de code. Développer par KDE sous linux.
Il peut créer des diagrammes de logiciels et d'autres systèmes dans le format UML standard de
l'industrie, et peut également générer du code à partir de diagrammes UML dans une variété de
langages de programmation.
Draw.io est une application web de création de diagramme compatible avec Google drive et
complètement gratuite, elle permet de dessiner des diagrammes UML en ligne via un navigateur
(sou protocole http).
 NetBeans :
NetBeans est un environnement de développement intégré (EDI), placé en Open Source par Sunen
juin 2000. En plus de Java, NetBeans permet également de supporter différents autres langages,
comme C, C+, JavaScript, PHP, HTML. Il comprend toutes les caractéristiques d'un IDE moderne
(éditeur en couleur, projets multi-langage, refactoring, éditeur graphique d'interfaces et de pages
Web).
Conçu en Java, NetBeans est disponible sous Windows, Linux, Solaris, Mac OS X ou sous une
version indépendante des systèmes d'exploitation (requérant une machine virtuelle Java) [12].
 PhpMyAdmin :
PhpMyAdmin est un outil logiciel gratuit écrit en PHP, destiné à gérer l'administration de MySQL
sur le Web. PhpMyAdmin prend en charge une large gamme d'opérations sur MySQL et MariaDB.
Les opérations fréquemment utilisées (gestion des bases de données, des tableaux, des colonnes, des
relations, des index, des utilisateurs, des autorisations, etc.) peuvent être effectuées via l'interface
utilisateur, alors que vous avez toujours la possibilité d'exécuter directement une instruction SQL.
 MYSQL :
MySQL est une base de données relationnelle libre qui a vu le jour en 1995 et très employée sur le
Web, souvent en association avec PHP (langage) et Apache (serveur web). MySQL fonctionne
indifféremment sur tous les systèmes d’exploitation (Windows, Linux, Mac OS notamment). Le
principe d’une base de données relationnelle est d’enregistrer les informations dans des tables qui
représentent des regroupements de données par sujets (table des produits, table d’utilisateur par
exemple).Les tables sont reliées entre elles par des relations [14].
 Mozilla Firefox :
Mozilla Firefox est un navigateur web libre et gratuit, développé et distribué par la Mozilla
Fondation avec l’aide de milliers de bénévoles grâce aux méthodes de développement du logiciel
libre (open source) et à la liberté du code source [15].
C. Langage de programmation :
 PHP :
PHP signifie Personal Home Page, c’est un langage incrusté au HTML et interprété ou compilé côté
serveur. Il dérive du C et du Perl dont il reprend la syntaxe.
Ce langage est principalement utilisé pour produire un site web dynamique. Il est courant que ce
langage soit associé à une base de données, tel que MySQL.
Exécuté du côté serveur (l'endroit où est hébergé le site) il n'y a pas besoin aux visiteurs d'avoir des
logiciels ou plugins particulier.
Comme il supporte tous les standards du web et qu’il est gratuit, il s’est rapidement répandu sur la
toile. PHP peut être installé sur les principaux serveurs web du marché.
Néanmoins, les web masters qui souhaitent développer un site en PHP doivent s'assurer que
l'hébergeur prend en compte ce langage. Lorsqu'une page PHP est exécutée par le serveur, alors
celui-ci renvois généralement au client (aux visiteurs du site) une page web qui peut contenir du
HTML, XHTML, CSS [16].
D. Framework :
Un Framework est, comme son nom l'indique en anglais, un "cadre de travail". L'objectif d'un
Framework est généralement de simplifier le travail des développeurs informatiques, en leur offrant
une architecture "prête à l'emploi" et qui leur permette de ne pas repartir de zéro à chaque nouveau
projet. Il constitue une base cohérente et regroupe en général les fondations d’un logiciel
informatique ou d’une application web [17].
3.7) Architecture global de l’application:
Figure 3.1: Représentation de l’architecture globale de l’application.
E. Représentation des interfaces de l’application :

 Interface d’Authentification :
Les membres du personnel doivent impérativement se connecter à leur session via cette interface.
 Interface de création de Produit :
Cette figure représente l’interface de création d’un produit c’est à dire l’ajout au stock d’un produit
pharmaceutique.
 Interface Bon de sortie produit :
Cette capture représente l’interface de recherche de produit existant dans le stock.

 Interface de produit stock :

 Interface produit retournés :

Wa0044.

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Wa0044.

Transféré par

Droits d'auteur :

Formats disponibles

1

CHAPITRE 0. INTRODUCTION GENERALE

0.1 PRESENTATION DU CONTEXTE

Le temps passe vite et l'ère de l'industrie cède sa place à l'ère de l'information.

Mais avant d'informatiser il convient de se poser cette question : « Pourquoi veut on

 L’amélioration des services aux clients ;

0.2 CHOIX ET INTERET DU SUJET

0.2.1. Choix du Sujet

0.2.2. Intérêt du sujet

0.4. ETAT DE LA QUESTION

Nous pouvons citer les travaux des étudiants de ces étudiants :

La problématique est un ensemble des questions des problèmes concernant un domaine de

 Relatif à un problème, à une problématique.

Il n’existe actuellement aucun système automatisé de facturation et

 Un mauvais service aux clients (lenteur) : la facturation manuelle conduit souvent à la

Par rapport à notre travail, nous suggérons l’hypothèse suivant :

0.5 METHODOLOGIES ET TECHNIQUES UTILISEES

Dans notre travail nous allons utiliser la méthode UP Unified Processus

Le processus unifié (PU), ou « Unified Processus » en anglais, ou « Unified Software

d’une phase de construction et d’une phase de transition comprenant chacune plusieurs

0.6 DELIMITATION DU SUJET

0.7 SUBDIVISION DU TRAVAIL

Notre travail intitulé : « CONCEPTION ET REALISATION D'UNE APPLICATION

SIDIPHAR» est articulé autour de 3 chapitres hormis l’introduction et la conclusion.

- Le premier chapitre Cadre conceptuel et considération théorique.

- Le deuxième chapitre .Analyse de l’existant

- Le troisième chapitre Conception du nouveau système

- Le quatrième chapitre : Programmation

CHAPITRE I. CADRE CONCEPTUEL ET CONSIDERATION THEORIQUE

I.1. DEFINITION DES CONCEPTS DE BASE LIES AU SUJET.

En informatique, le terme "conception" fait référence à l'étape de développement d'un système

La conception englobe plusieurs aspects, tels que l'architecture logicielle, l'interface

La conception se fait généralement en collaboration avec des développeurs, des analystes et

En informatique, le terme "réalisation" est souvent utilisé comme synonyme du terme

programmation pour écrire le code source qui permettra au système de fonctionner

Au cours de la réalisation, les développeurs suivent généralement des pratiques de

En informatique, le terme "gestion" fait référence à la planification, l'organisation, le contrôle

La gestion en informatique comprend les responsabilités suivantes :

La gestion en informatique vise à assurer le bon fonctionnement, la disponibilité, la

Ces établissements peuvent varier en taille, en nature de l'activité et en offre de produits ou de

I.2. PRESENTATION DA METHODE UP

Le processus unifié (PU), ou « unified process (UP) » en anglais, ou « Unified Software

En 1999, Jacobson, Booch et Rumbaugh publient « Le processus unifié de développement

3. une approche itérative et incrémentale visant en priorité à réduire les incertitudes.

 Cycle de vie des projets

 Cycle de développement: projets, phases et itérations

Processus unifié : enchainements d'activités au cours du cycle de vie

Phases et itérations d'un projet de développement

les modèles qui garantissent la cohérence du processus du développement en servant de fil

I.3. PRESENTATION DES ARCHITECTURES APPLICATVES

L’architecture applicative logicielle décrit d’une manière symbolique et schématique les

- L'interopérabilité intrinsèque exprime le degré de cohérence entre le fonctionnement des

c. Diminution de la dégradation du logiciel

Graphique de dégradation du logiciel en fonction de l'architecture ; source : togaf/andrew josey et al.

Modèles d'analyse et d'architecture centrées sur les données avec traçabilité.

Modèle d'architecture de Philippe Kruchten (modèle des 4 + 1 vues)

qu'ils réalisent des transformations et des synthèses intelligentes de l'information, on parle

Modèle de données relationnel.

c. Quelques Systèmes de gestion des bases de données

I.1 Présentation de new Sidiphar

I.2 Analyse du métier

Tableau 1 : Matériel Informatique de la Pharmacie New Sidiphar

I.2.1 Description des procédures de gestion