Université de Carthage Institut des Hautes Etudes commerciales Année universitaire : 2010/2011 MÉMOIRE DE PROJET DE FIN D’ETUDES POUR L’OBTENTION DU DIPLÔME DE MASTÈRE PROFESSIONNEL Filière Commerce Electronique Conception et développement d’un Conception et développement d’un site web Marchand pour vente site web Marchand pour vente du matériel informatique en ligne du matériel informatique en ligne Organisme Dirigé par : Mr. Nabil Chaabani (IMS) Mme. Thouraya
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Université de Carthage Institut des Hautes Etudes commerciales
Année universitaire : 2010/2011
MÉMOIRE DE PROJET DE FIN D’ETUDES
POUR L’OBTENTION DU DIPLÔME DE MASTÈRE PROFESSIONNEL
Filière
Commerce Electronique
Conception et développement d’un siteConception et développement d’un site web Marchand pour vente du matérielweb Marchand pour vente du matériel
informatique en ligneinformatique en ligne
Organisme
Réalisé par : Tbini Walid
Dirigé par : Mr. Nabil Chaabani (IMS) Mme. Thouraya Daoues (IHEC) Mr. Melki Sofiene (IHEC)
Abstract: A company that offers products and / or services, always looking to adopt
the best business management in order to compete on the market that is growing
competition.
It is the goal of our project is to develop a website that will allow
electronic commerce to manage orders, customers, products, brands…
Our application also has the objectives: to broaden the scope of
intervention by involving all users in the website, save society's resources (staff
assignments, financing of the commercial approach ...) reduce costs and increase
revenue.
This report describes the analysis, design, and state of the art, directing,
Résumé : Une société qui propose des produits et/ou des services, cherche toujours à
adopter la meilleure gestion commerciale afin de pouvoir rivaliser sur le marché
qui ne cesse d’augmenter la concurrence.
C’est l’objectif de notre projet qui consiste à mettre en place un site web
de commerce électronique qui permettra de gérer les commandes, clients,
produits, marques, factures…etc.
Notre application a aussi pour objectifs : d’élargir le champ d’intervention
en impliquant tout les internautes dans le site web, d’économiser les ressources
de la société (tâches du personnel, financement de la démarche commerciale…
etc.), de réduire les coûts et augmenter les revenus.
Ce rapport décrit l’analyse, la conception, l’état de l’art, la réalisation,
l’implémentation et l’évaluation de l’application.
Mots clés : Panier, catalogue, PHP, gestion des produits, gestion des factures, architecture 3-tiers, achat en ligne, UML, jquery, CSS, HTML…
Dédicaces
A mes très chers parents
Dont leurs mérites, leurs sacrifices, leurs qualités
humaines m’ont permis de vivre ce jour, Les mots me
manquent pour exprimer toute la reconnaissance, la
fierté et le profond amour que je vous porte pour les
sacrifices qu’ils ont consenti pour ma réussite, qu’ils
trouvent ici le témoignage de mon attachement ma
reconnaissance, gratitude et respect, que dieu leur
préservent bonne santé et longue vie. Tous mes
sentiments de reconnaissance pour vous.
A mes frères et sœurs
J’espère atteint le seuil de vos espérances. Que ce travail
soit l’expression de ma profonde affection Je vous
remercie pour le soutient moral et l’encouragement que
vous m’avez accordés .Je vous souhaite tout le bonheur
que vous méritez
En leur souhaitant un brillant avenir.
A mes oncles et ma famille
Que je ne pourrais nommer de peur d’en oublier mon
attachement et mes affections les plus Sincères.
A mes ami(e) s
A tout ceux qui ont su m’apporter aide et soutient aux
moments propices, Je dédie ce travail, reconnaissant et
remerciant chaleureusement.
Remerciement
C’est avec un bonheur au cœur que je consacre ces mots
signe de gratitude et de reconnaissance à tous ceux qui
ont contribué, de prés ou de loin, à la réalisation de ce
projet, qu’ils trouvent ici mon terme les plus sincères de
remerciements
Je remercie tous ceux qui m’ont accueilli bras ouverts au
sein de la société « IMS» spécialement, mon encadreur
Mr Nabil Chaabani.
Mes fortes gratitudes à mes encadreurs à
l’IHEC CARTHAGE : Mr. Melki Sofiene et Mme.
Thouraya Daoues qui m’ont su me mettre sur les railles
de la réussite du projet.
Mon remerciements au personnel et enseignant de l’IHEC
de Carthage pour leur aide durant notre parcours
universitaire.
Table des matières
Introduction…………………………………………………. …………….. 6Chapitre I Présentation générale……………………………………….. 8I.1. Introduction…………………………………………………………... 8I.2. Présentation de l’organisme d’accueil……………………………… 8 I.2.1. Les objectifs d’IMS……………………………………………….. 8 I.2.2. Les produits et les services offerts par IMS………………………. 8I.3. Présentation du sujet………………………………………………... 9I.4. Méthodologie et formalisme adoptés………………………………... 9I.5. Conclusion…………………………………………………………... 12
Chapitre II Analyse des besoins et spécifications…………………….. 13II.1. Introduction………………………………………………………... 13II.2. Objectifs……………………………………………………………. 13II.3. Critique de l’existant………………………………………………. 14II.4. Spécification des exigences………………………………………... 14 II.4.1. Liste des exigences……………………………………………... 15 II.4.1.1. Besoins fonctionnels…………………………………….. 15 II.4.1.2. Besoins non fonctionnels………………………………... 16 II.4.2. Quelques concepts……………………………………………… 16 II.4.3. Scénarios et des cas d’utilisation……………………………….. 17 II.4.3.1. Identification des acteurs………………………………... 17 II.4.3.2. Les diagrammes des cas d’utilisation…………………… 17 II.4.3.2.1. Diagramme de cas d’utilisation globale………………… 18 II.4.3.2.2. Diagramme de cas d’utilisation «Acheté un produit»........ 19 II.4.3.2.3. Diagramme de cas d’utilisation « Gérer produit»……….. 20 II.4.3.3. Les diagrammes de séquence……………………………. 20 II.4.3.3.1. Propriétés du diagramme de séquences…………………. 20 II.4.3.3.2. Diagramme de séquence «Authentification»……………. 21 II.4.3.3.3. Diagramme de séquence «Mise à jour d’un produit»......... 22 II.4.3.3.4. Diagramme de séquence «Ajout d’un nouveau produit»… 24 II.4.3.3.5. Diagramme de séquence «Suppression d’un produit»…… 25 II.4.3.3.6. Diagramme de séquence «Gestion du panier»…………... 27II.5. Conclusion………………………………………………………….. 28
Chapitre III Etat de l’art…………………………………………………. 29III.1. Introduction………………………………………………………….. 29
1
III.2. Architecture de l’application……………………………………….. 29 III.2.1. Architecture de client-serveur……………………………………. 29 III.2.1.1. Présentation……………………………………………….. 29 III.2.1.2. Avantages de l’architecture client-serveur………………... 30 III.2.1.3. Inconvénient de l’architecture client-serveur……………... 30 III.2.2. Architecture 3-tiers……………………………………………….. 31 III.2.2.1. Présentation……………………………………………….. 31 III.2.2.2. Avantages de l’architecture 3-tiers………………………... 32 III.2.2.3. Inconvénient de l’architecture 3-tiers……………………... 32 III.2.3. Architecture N-tiers………………………………………………. 32 III.2.3.1 Présentation………………………………………………... 32 III.2.4. Architecture adoptée……………………………………………… 33III.3. Choix techniques…………………………………………………….. 34 III.3.1. SGBD utilisé ……………………………………………………... 34 III.3.1.1. MySQL ………………………………………………….... 34 III.3.1.1.1. Communication du MySQL avec le serveur web…….. 34 III.3.1.2. Les autres SGBD face à MYSQL : PostgreSQL …………. 34 III.3.1.3. SGBD adoptée (MySQL)…………………………………. 35 III.3.2. Les Langages utilisés……………………………………………... 35 III.3.2.1. Le langage Jquery…………………………………………. 35 III.3.2.2. Le langage PHP…………………………………………… 36 III.3.2.3. Les autres langages face à PHP : ASP…………………….. 36 III.3.2.4. Coopération de PHP et MySQL…………………………... 37III.4. Conclusion…………………………………………………………… 37
Chapitre IV Conception…………………………………………………... 38IV.1. Introduction………………………………………………………….. 38IV.2. Conception de l’application…………………………………………. 38 IV.2.1. Diagramme de classes...………………………………………….. 38IV.3. Conception de la base de données…………………………………... 40 IV.3.1.Passage à un modèle relationnel à partir d’un diagramme de classes.. 40 IV.3.2. Schéma Relationnel de la base de données……………………….. 40IV.4. Conclusion……………………………………………………………. 42
Chapitre V Réalisation et implémentation……………………………….. 43V.1. Introduction…………………………………………………………... 43V.2. Environnement de travail……………………………………………. 43 V.2.1. Environnement matériel…………………………………………... 43 V.2.2. Environnement logiciel……………………………………………… 44V.3. Architecture du Système …………………………………………….. 45 V.3.1. Diagramme de composante……………………………………….. 45
2
V.4. Choix techniques……………………………………………………… 46 V.4.1. Choix du langage………………………………………………….. 46 V.4.2. Choix de la technologie de sécurité……………………………….. 46 V.4.2.1. Protection contre les attaques d’injection SQL……………. 46 V.4.2.2. Les sessions………………………………………………... 46 V.4.2.3. Mécanisme de hachage de mot de passe…………………... 47 V.4.3. Autres choix technologiques……………………………………… 48V.5. Diagramme de GANTT………………………………………………. 48V.6. Phase d’implémentation……………………………………………… 49 V.6.1. Contraintes………………………………………………………… 49 V.6.2. Pratiques adoptées………………………………………………… 50V.7. Phase de tests et validation…………………………………………... 50 V.7.1. Jeux de tests et validation…………………………………………. 51V.8. Conclusion…………………………………………………………….. 53
Chapitre VI Interface de l’application…………………………………... 54VI.1. Introduction………………………………………………………….. 54VI.2. Interface de l’application……………………………………………. 54 VI.2.1. Back-office……………………………………………………….. 54 VI.2.1.1. Page d’authentification……………………………………. 54 VI.2.1.2. Session administrateur…………………………………….. 55 VI.2.1.2.1. Page d’accueil du back-office…………………………. 55 VI.2.1.2.2. Page gestion des produits……………………………... 56 VI.2.1.2.3. Page ajout d’un nouveau produit (pop-up)……………... 56 VI.2.1.2.4. Suppression d’un produit……………………………... 57 VI.2.2. Front-office……………………………………………………….. 58 VI.2.2.1. Page d’accueil du front-office …………………………….. 58 VI.2.2.2. Page gestion de panier…………………………………… .. 60 VI.2.2.3. Page choix de méthode d’expédition……………………... 61 VI.2.2.4. Page choix de méthode de payement……………………… 62 VI.2.2.5. Page confirmation commande……………………………... 63 VI.2.2.6. Page de payement………………………………………….. 64VI.3. Conclusion……………………………………………………………. 66Conclusion générale………………………………………………………….. 67Glossaire……………………………………………………………………… 68Bibliographie et Néographie………………………………………………… 69Annexe………………………………………………………………………... 70
3
Table des figuresListe des figures Titres
Figure I.1 Démarche d’élaboration du projet
Figure I.2 Organigramme de faisabilité du projet
Figure II.1 Diagramme de cas d'utilisation globale
Figure II.2 Diagramme de cas d'utilisation « Acheté un produit »
Figure II.3 Diagramme de cas d'utilisation « gérer les produits »
Figure II.4 Diagramme de séquence « authentification »
Figure II.5 Diagramme de séquence « Mise à jour d’un produit »
Figure II.6 Diagramme de séquence « Ajout d’un nouveau produit »
Figure II.7 Diagramme de séquence « Suppression d’un produit »
Figure II.8 Diagramme de séquence « Gestion du panier »
Figure III.1 Architecture client-serveur
Figure III.2 Architecture 3-tiers
Figure III.3 Architecture N-tiers
Figure IV.1 Diagramme de class
Figure IV.2 Schéma relationnel de la base de données
Figure V.1 Diagramme de composante
Figure V.2 Protection contre les attaques d’injection SQL
Figure V.3 Protection des données avec Les sessions
Figure V.4 Protection de mot de passe avec le mécanisme de hachage
Figure V.5 Script d'appel des plugins de jquery
Figure V.6 Menu slider
Figure V.7 Diagramme de GANTT
Figure V.8 Tableau jeux de tests et validation
Figure VI.1 Page de connexion de l’utilisateur
Figure VI.2 Message d’erreur lorsque le login ou le mot de passe est invalide
4
Figure VI.3 Page d’accueil du back-office
Figure VI.4 Page gestion des produits
Figure VI.5 Page ajout d’un nouveau produit
Figure VI.6 Contrôle de saisie dans l’ajout d’un nouveau produit
Figure VI.7 Supprimer un produit
Figure VI.8 Page d’accueil du back-office
Figure VI.9 Ajout d’un produit au panier
Figure VI.10 Page détails d’un produit
Figure VI.11 Page Gestion du panier
Figure VI.12 Page d’authentification du client
Figure VI.13 Formulaires d’inscription d’un nouveau client
Figure VI.14 Page Choix de méthode d’expédition
Figure VI.15 Formulaire de modification de l’adresse d’expédition
Figure VI.16 Page Choix de méthode de payement
Figure VI.17 Page confirmation de la commande
Figure VI.18 Page de payement
5
Introduction
GénéraleL’évolution du secteur informatique durant ces dernières années a
favorisé l’apparition de nouvelles technologies web qui ont permis d’unir
les différents organismes et les différentes sociétés d’une manière
croissante et remarquable.
Cette évolution prend sa part dans divers secteurs et impose son
existence vue la simplicité des applications facilitant la communication
entre les différents membres des établissements surtout que le facteur
temps joue un rôle très important dans l’évolution de la qualité des
services.
Le secteur du commerce n’a pas échappé à cette vague, en effet ce
secteur a donné naissance à un nouveau secteur dit E-Commerce qui
désigne l’ensemble des échanges numérisés liés à des activités
commerciales.
C’est dans ce contexte que s’inscrit ce projet de fin d’études, dans
lequel nous sommes amenés à réaliser un site web marchand, qui permet
de vendre des ordinateurs en ligne.
Donc, après avoir introduit notre travail de projet de fin d’études,
nous présentons dans un premier chapitre la société IMS qui nous a
accueillis, nous délimitons le cadre général du travail et nous spécifions
notre sujet.
Le deuxième chapitre est consacré à une analyse des besoins qui
s’intéressera aussi bien aux aspects fonctionnels qu’aux aspects non-
fonctionnels liées à notre sujet. Dans ce chapitre nous identifierons les cas
6
d’utilisations ainsi que les diagrammes de séquences décrivant les
scénarios d’utilisation de site web.
Le troisième chapitre est consacré à la conception de notre site web.
Dans ce chapitre nous allons spécifier les différentes classes constituantes
notre system. A partir du diagramme de classe nous dégagerons la
structure de notre base do données.
Dans le quatrième chapitre nous présenterons les outils qui nous
étaient utiles dans l’élaboration de ce travail.
Le cinquième chapitre s’occupera de la réalisation de site web en
passant par l’environnement matériel et logiciel utilisé avec les différentes
techniques de réalisation et de sécurité.
Le dernier chapitre nous donne une vue sur le site web dans son état
final et ce en nous fournissant les différentes IHM.
Pour conclure, nous revenons sur nos apports et perspectives dans la
conclusion de ce projet.
7
Chapitre I. Présentation
Générale
I.1. Introduction
I.2. Présentation de l’organisme d’accueil
La société tunisienne IMS est une société de services et d‘ingénierie informatique
(SSII) spécialisée dans la conception, la réalisation et le développement de tout procédé et
applications informatiques et télécommunications incluant l’aspect logiciel (Software) et
l’aspect matériel (Hardware).
La société IMS est composée par des ingénieurs et des techniciens diplômés des
grandes écoles tunisiennes disposant d’une expérience laborieuse dans le domaine des TIC et
des scientifiques hautement qualifiés.
I.2.1. Les objectifs de IMS
Les objectifs qu’IMS visent à les atteindre sont :
Satisfaction des clients et Anticipation totale de leurs besoins
Développement des relations de partenariat solides avec des sociétés nationales
et internationales.
Satisfaction de ces collaborateurs puisque la relation humaine est son axe
stratégique.
Atteindre une qualité de haut niveau
Renforcer son avancée technologique
Innover toujours en se basant sur des études et des recherches avancées
I.2.2. Les produits et les services offerts par IMS
- La société IMS offre plusieurs types de produits tels que :
CMS ERP /CRM E-Banking E-Portail Formed
- La société IMS offre aussi plusieurs types de service tels que :
Applications Web Web Marketing E-Solution Développement Informatique Outsourcing Réseau ET Télecommunication Assistance Technique
I.3. Présentation du sujet
Le sujet intitulé « Conception et développement d’un site web Marchand pour vendre
du matériel informatique en ligne ». Le travail demandé a pour finalité de créer un site web
marchand destinée à la vente du matériel informatique en ligne, qui est encore au stade de la
recherche, et ce dans l’optique de concevoir et de réaliser une application qui permet de
vendre en ligne, de gérer les commandes, les clients, les factures, et le stock en temps réel.
I.4. Méthodologie et formalise adoptés
La méthodologie, est bien sûr la démarche méthodologique et l’ensemble des modèles
associés mais c’est aussi, en amont mettre à plat la logique applicative : les outils de
modélisation comme Merise ou UML sont donc primordiaux.
Dans ce qui suit, nous allons décrire la démarche de développement et argumenter le
choix d’UML comme langage de modélisation.
UML, est bien connu par les développeurs. Il est souvent utilisé pour la conception et
la représentation graphique (sous forme de diagrammes) de n’importe quelle application de
Outre sa souplesse et son caractère polyvalent, UML, est le mieux adapté aux
développements des applications e-commerce.
La démarche d’élaboration de notre projet s’appuie sur UML qui permettra de
modéliser d’une manière claire et précise la structure et le comportement du système. Cette
démarche est itérative, incrémentale, pilotée par les cas d’utilisation et centrée sur
l’architecture, la figure ci-dessous décrit cette démarche.
Figure I.1 : Démarche d’élaboration du projet
Figure I.2 : Organigramme de faisabilité du projet
Vu que 50% des échecs des projets informatiques proviennent de la spécification, nous
avons donné une attention particulière au maquettage.
Le maquettage est une technique qui permet de surmonter la difficulté de spécification
du logiciel due à la différence de terminologie et au manque de précision dans l'expression
des besoins. Cette activité consiste à dessiner rapidement des écrans du futur système
(maquette).
I.5. Conclusion
Nous avons présenté le cadre du travail au sein de l’entreprise IMS, le sujet ainsi que
les méthodologies utilisées pour concevoir notre site web. Ces éléments seront par la suite les
piliers pour la conception et la mise en place de notre application ils nous ont, en effet, fournis
les grandes lignes du système qui seront par la suite exploitées, détaillées et mises en œuvre
pour la suite du travail.
Dans ce qui suit nous allons effectuer une analyse des besoins et des spécifications du
projet à réaliser ce dont nous allons aborder au cours du prochain chapitre.
Chapitre II. Analyse des besoins
et spécifications
II.1. Introduction
L'identification des besoins est la pierre angulaire de conception et développement des
sites web, car l’analyse des besoins est essentielle à la réussite d'un projet de développement.
En effet cette phase consiste à qualifier les besoins fonctionnels et à analyser l’existant afin
d’obtenir les spécifications et les exigences détaillées techniques.
Dans cette partie, nous avons spécifié les différents besoins fonctionnels et non
fonctionnels requis pour l’implémentation de notre site web et les cas d’utilisations possibles.
Nous allons ensuite passés à la conception de notre site web.
II.2. Objectif
La vente en ligne est une forme de commerce électronique qui a apparut avec le
développement massive des technologies d’informations et qui consiste à réaliser tout les
étapes d’une transaction commercial sur internet.
Dans ce contexte que s’inspire notre travail qui consiste à concevoir et à développer un
site web marchand.
Notre solution aura pour objectif :
Vendre du matériel informatique en ligne.
Contrôle et gestion des différents processus.
Réduire les coûts et augmenter les revenus.
Augmenter le nombre des clients.
II.3. Critique de l’existant
- La vente du matériel informatique se fait d’une manière traditionnel, c'est-à-dire si
les clients veulent acheter du matériel informatique, ils doivent se présenter dans les points de
vente.
- La gestion des ventes, des factures, des produits, des clients…, se fait manuellement et
puis enregistrer sur un ordinateurs dans des fichiers Excel.
La façon de gère et de vendre le matériel informatique engendre les défaillances
suivantes :
Les frais de locations et les frais des personnels qui travaillent dans les
boutiques sont élevée.
Les clients qui viennent pour acheter du matériel informatique n’ont pas une
visibilité totale sur tous les matériels.
Une perte du temps dans la recherche des informations concernant le
matériel informatique.
Le processus de la gestion des ventes du matériel informatique (Ajout,
Modification,… des facteurs, des clients, des produits,…) est long.
Un Manque de publicité.
II.4. Spécification des exigences
Les objectifs de la phase spécification des exigences sont de faciliter la
reconnaissance et la compréhension du lien entre les exigences, de permettre leur priorisation,
et surtout de tracer leur prise en charge dans le projet.
II.4.1. Liste des exigences
II.4.1.1. Besoins fonctionnels :
1 - Besoin de deux interfaces conviviales et interactives, front-office et back-office
puisque le site web est destiné à deux types d’utilisateurs qui sont les internautes, les clients
et le administrateur.
2 - Pour La partie back-office du site :
Besoin d’une page d’authentification pour accéder au back-office.
Besoin de gérer les produits : Consultation, ajout, modification, suppression, recherche des produits, gestion des marques ...
Besoin de gérer les medias : ajout, modification et suppression des medias (Logo, Bannière…).
Besoin de gérer les contacts : consultation et suppression des contacts.
Besoin de gérer le compte d’administrateur : Modifier le login et le mot de passe, ajouter un administrateur…
Besoin de gérer les factures : consultation, recherche, suppression des factures.
Besoin de gérer les clients inscrit dans l’espace clients : informer les clients sur l’avancement de leurs commandes, rechercher des clients, consultation des informations concernant les clients…
Besoin d’un module de newsletter pour communiquer les clients et les internautes sur toutes les nouveautés.
Besoin de gérer les commandes : Ajout, suppression, consultation et recherche des commandes.
Gestion des stocks en temps réel.
3 - Pour la partie front office du site:
Besoin d’un menu qui contient tout les catalogues du matériel informatique.
Besoin d’une page de contact.
Besoin d’une page de paiement.
Besoin d’un espace membre pour nos clients qui contient l’historique des
achats réalisé, toutes les offres spéciales, le suivi de la livraison...
Besoin d’un Moteur de recherche.
Besoin d’une Newsletter.
Besoin d’un Module de partage des produits sur les réseaux sociaux.
Besoin d’un panier pour gérer les quantités des produits acheté.
II.4.1.2 Besoins non fonctionnels :
En plus des besoins fonctionnels cités ci-dessus nous devons tenir compte des
contraintes suivantes :
La satisfaction complète des besoins de tous les utilisateurs.
Simplifier le travail des utilisateurs avec une ergonomie sobre et efficace.
L’implémentation des mesures sécuritaires.
Assurer la Confidentialité des informations.
L'optimisation du code.
L'optimisation des ressources consommées.
La compatibilité avec le matériel existant.
L’application doit assurer la non-répudiation et la traçabilité de l’information.
L’application doit être sécurisée. Un profil d’accès est affecté à chaque
utilisateur.
II.4.2. Quelques concepts
Dans notre site web, nous allons définir les différents types d'utilisateurs qui ont des
droits et des fonctionnalités qui leurs sont propres.
Nous abordons alors notre travail par une identification des acteurs, en fait un acteur
représente un rôle joué par une personne ou par un groupe de personnes qui interagit avec le
système.
Dans notre site web on trouve 3 types d’acteurs : l’internaute, le client, et
l’administrateur du site.
II.4.3. Scénarios et des cas d’utilisation
II.4.3.1 Identification des acteurs :
Les principaux acteurs de notre application sont :
L’administrateur.
Les internautes.
Les clients.
Chaque acteur à ses propres tâches qu’on va les modéliser dans les sections suivantes.
En effet, tous les acteurs passent obligatoirement par deux interfaces qui sont :
- Le back-office : destinée à l’administrateur.
- Le front-office : destinée aux internautes et aux clients.
Espace Administrateur : C’est le back-office de notre site web. Dans cette espace
l’administrateur a le droit d’effectuer toutes sortes d’opérations pour administrer le site tel que
l’ajout, la modification, la suppression, la mise a jour des produits ou des medias, ou des
factures…, définir les droits d’accès, consulter les contacts…
Espace Internaute : C’est le front-office de notre site web. Cette espace est destinée
aux internautes et aux clients qui peuvent naviguer sur le site, effectuer des recherches sur les
marques du matériel informatique proposée, s’inscrire dans la newsletter, faire des achats,
s’inscrire dans l’espace membre, consulter le catalogue…
II.4.3.2 Les diagrammes des cas d’utilisation :
Il s'agit de la solution UML pour représenter le modèle conceptuel, les diagrammes
des cas d’utilisation permettent de décrire l'interaction entre l'acteur et le système.
II.4.3.2.1 Diagramme de cas d’utilisation globale :
Figure II.1 : Diagramme de cas d'utilisation globale
Ce diagramme de cas d’utilisation nous donne une vue globale sur les utilisateurs et
leurs interactions avec les 2 parties du site, le back-office et le front-office.
- l’internaute : son interaction se fait avec le front-office du site soit par la consultation
du contenue du site, la création d’un compte, la recherche …
- le client : c'est un internaute qui s'est transformé en client dés son premier acte
d’achat en ligne, il hérite tout les fonctionnalités de l’internaute (consultation du contenue du
site, la création d’un compte, la recherche …).
- l’administrateur : son interaction se fait avec le back-office du site, son rôle est la
gestion du site (gestion des produits, gestion des medias, gestion des commandes…)
II.4.3.2.2 Diagramme de cas d’utilisation « Acheté un produit »
Figure II.2 : Diagramme de cas d'utilisation « Acheté un produit »
Ce diagramme de cas d’utilisation nous montre l’interaction du client avec le front-
office du site lorsqu’il va acheter un produit. Le client ici peut consulter les produits, gérer
son panier, passer une commande et suivre son avancement après l’authentification.
II.4.3.2.3 Diagramme de cas d’utilisation « Gérer les produits »
Figure II.3: Diagramme de cas d'utilisation « Gérer les produits »
Ce diagramme de cas d’utilisation nous montre comment l’administrateur gère les
produits. Pour gérer un produit, l’administrateur doit tout d’abord s’authentifier, puis il peut
ajouter, modifier, ou supprimer un produit.
II.4.3.3 Les diagrammes de séquence:
II.4.3.3.1 Propriétés du diagramme de séquences :
L’analyse des cas d’utilisation commence par l’élaboration des diagrammes de
séquences avec des objets d’analyses. Les objets d’analyses sont des instances de classes
d’analyses qui représentent les éléments majeurs ayant des comportements et des
responsabilités dans le système.
Les objets de contrôle : ils représentent les activités systèmes. Ces objets dirigent les
activités des objets d’entités et d’interfaces.
Les objets d’entités : ce sont des entités persistantes au système (tel que les tables de
la base de données).
Les objets d’interface : ils représentent l’interface qui est en interaction directe avec
l’utilisateur (exemples : les écrans de saisies).
II.4.3.3.2 Diagramme de séquence « Authentification » :
Titre : S’authentifier.
Résumé : Ce cas d’utilisation permet à l’utilisateur de se connecter au système et de
s’authentifier a travers un profile qui déterminera les rubriques aux quels il a le droit d’y
accéder.
Acteurs : Se sont les différant utilisateurs du système qui sont : l’internaute, le client
et l’administrateur.
Description des scénarios :
1. Pré condition :
Existence d’une interface permettant la saisie d’identificateur ainsi du mot de passe
pour l’utilisateur.
2. Scénario Normal :
L’utilisateur accède au site web
Une interface Homme/Machine est apparue contenant un formulaire
l’authentification.
Saisie du Login et de Mot de Passe.
Le system vérifie l’existence de l’utilisateur.
Le system cherche les rubriques disponibles pour cet utilisateur
Le system affiche les rubriques selon le profil de l’utilisateur connecté.
3. Scénario d’erreur :
Login et Mot de Passe erroné.
Le system indique à l’utilisateur que le Login et le Mot de Passe sont
erronés.
Le system affiche l’échec de la saisie (Le scénario normal reprend au point
1).
Figure II.4 : Diagramme de séquence « Authentification »
II.4.3.3.3 Diagramme de séquence « Mise à jour d’un produit » :
Titre : Mettre à jour un produit.
Résumé : Décrire les étapes à suivre par l’administrateur afin de mettre à jour un
produit.
Acteurs : l’administrateur.
Description des scénarios :
1. Pré condition :
Dans l’interface du back-office on trouve un menu qui contient des modules, on
choisit le module Produits
2. Scénario Normal :
a. L’administrateur entre dans le back-office et choisi le module produits
b. L’écran du produit affiche tout les produits.
c. L’administrateur appuie sur le bouton mise à jour du produit qu’il veut le
modifier.
d. L’écran du produit affiche tout les informations du produit concerné.
e. L’administrateur modifie les informations du produit et valide son choix.
f. Le system enregistre les modifications réalisé par l’administrateur dans la base
de données.
g. L’écran du produit affiche un message de mise à jour avec succès.
3. Scénario d’erreur :
Des Informations erronées ou des champs vides.
L’écran du produit affiche un massage d’erreur qui indique à
l’administrateur que les informations saisis sont erronées ou indique qu’il
y’a des champs vides et qu’il doit les remplis (Le scénario normal reprend
au point 5).
Figure II.5 : Diagramme de séquence « Mise à jour d’un produit »
II.4.3.3.4 Diagramme de séquence « Ajout d’un nouveau produit »:
Titre : Ajouter un nouveau produit.
Résumé : Décrire les étapes à suivre par l’administrateur afin d’ajouter un produit.
Acteurs : l’administrateur.
Description des scénarios :
1. Pré condition :
Dans l’interface du back-office on trouve un menu qui contient des modules, on
choisit le module Produits
2. Scénario Normal :
a. L’administrateur entre dans le back-office et choisi le module produits
b. L’écran du produit affiche tout les produits.
c. L’administrateur appuie sur le bouton ajouter un produit.
d. L’écran du produit affiche un formulaire d’ajout d’un nouveau produit.
e. L’administrateur remplie le formulaire du produit et valide son choix.
f. Le system enregistre le nouveau ajouté par l’administrateur dans la base de
données.
g. L’écran du produit affiche un message d’ajout avec succès.
3. Scénario d’erreur :
Des Informations erronées ou des champs vides.
L’écran du produit affiche un massage d’erreur qui indique à
l’administrateur que les informations saisis sont erronées ou indique qu’il
y’a des champs vides et qu’il doit les remplis(Le scénario normal reprend
au point 4).
Figure II.6 : Diagramme de séquence « Ajout d’un nouveau produit »
II.4.3.3.5 Diagramme de séquence « suppression d’un produit » :
Titre : Supprimer un produit.
Résumé : Décrire les étapes à suivre par l’administrateur afin de supprimer un
produit.
Acteurs : l’administrateur.
Description des scénarios :
1. Pré condition :
Dans l’interface du back-office on trouve un menu qui contient des modules, on
choisit le module Produits
2. Scénario Normal :
a. L’administrateur entre dans le back-office et choisi le module produits
b. L’écran du produit affiche tout les produits.
c. L’administrateur appuie sur le bouton supprimer du produit qu’il veut le
supprimer.
d. L’écran du produit affiche un message qui demande la confirmation de la
suppression.
e. L’administrateur confirme son choix.
f. Le system supprime le produit dans la base de données.
g. L’écran du produit affiche un message de suppression avec succès.
Figure II.7 : Diagramme de séquence « Suppression d’un produit »
II.4.3.3.6 Diagramme de séquence « Gestion du Panier »
Titre : Gérer un panier.
Résumé : Décrire les étapes à suivre par le client afin de gérer son panier lors d’une
opération d’achat.
Acteurs : Le client.
Description des scénarios :
1. Pré condition :
Dans l’interface du front-office on trouve les catalogues des produits offerts, alors il
suffit de choisir le produit à acheter.
2. Scénario Normal :
a. Le client parcoure les catalogues des produits offerts et choisi un produit(s) on
appuyant sur le bouton ajouter au panier.
b. Le produit(s) s’ajout dans le panier.
c. Le client accède à son panier en appuyant sur l’icone panier.
d. Le client peut modifier les quantités des produits dans le panier.
e. Le client peut supprimer des lignes dans le panier.
f. Le client peut passer la commande après avoir terminer la gestion de son
panier.
3. Scénario d’erreur :
Des Informations erronées ou des champs vides.
L’écran du produit affiche un massage d’erreur qui indique au client que
les informations saisis lorsque il a modifié son panier sont erronées, ou
indique qu’il y’a des champs vides et qu’il doit les remplis(Le scénario
normal reprend au point 4).
Figure II.8 : Diagramme de séquence « Gestion du panier »
II.5. Conclusion
Ce chapitre nous a permis de couvrir tous les cas d'utilisations concernant les
différents utilisateurs de notre système et de définir les besoins non fonctionnels à prendre en
considérations afin de satisfaire les utilisateurs. La spécification des besoins étant établie,
nous essayerons dans le chapitre suivant de concevoir clairement les différentes technologies
existantes pouvant être utilisées pour l’élaboration du projet.
Chapitre III. État de l’art
III.1. Introduction
Dans ce chapitre, nous allons détailler les différentes architectures existantes pouvant
être utilisées pour l’élaboration de notre projet, en suite nous allons présenter les différents
moyens techniques qui peuvent être utilisées dans la réalisation de notre projet.
III.2.Architecture de l’application
III.2.1. Architecture client-serveur
III.2.1.1. Présentation :
Les architectures client-serveur constituent une étape importante dans l'évolution des
systèmes d'informations. Ce type d'architecture est constitué uniquement de deux parties: un
client qui gère la présentation et la logique applicative est un serveur qui stocke les données
de façon cohérente et gère éventuellement une partie de la logique applicative. L'interface
entre ces deux parties est classiquement le langage. Dans ce type d'architecture on constate
une certaine indépendance du client par rapport au serveur. La programmation du client peut
s'effectuer sans se préoccuper de la mise en place de la base de données. En particulier, les
questions concernant l'administration des données ne concerneront pas le développeur du
client (dimensionnement des disques, répartition des données sur le système, optimisation des
accès aux données, sauvegarde des données,...).
Figure III.1 : Architecture client-serveur
III.2.1.2. Avantages de l’architecture client-serveur :
Les principaux avantages de l’architecture client-serveur sont :
L'Atomicité : permet à la transaction d'avoir un comportement indivisible; soit
toutes les modifications sur les données effectuées dans la transaction sont
effectives, soit aucune n'est réalisée.
La Cohérence des données de la base est permanente.
L'Isolation des transactions : signifie que les modifications effectuées au cours
d'une transaction ne sont visibles que par l'utilisateur qui effectue cette
transaction.
La Durabilité : elle garantit la stabilité de l'effet d'une transaction dans le
temps, même en cas de problèmes graves tel que la perte d'un disque.
III.2.1.3. Inconvénients de l’architecture client-serveur :
L'architecture client-serveur possède toutefois des inconvénients. Ce sont ces
inconvénients qui poussent les entreprises à utiliser d'autres technologies. Les deux
inconvénients principaux sont la difficulté à gérer correctement les questions de sécurité et le
coût du déploiement.
La sécurité d'un système en architecture client-serveur est gérée au niveau du SGBDR.
Celui-ci contrôle l'accès aux données en attribuant des autorisations d'accès aux différents
utilisateurs du système. Le problème vient du fait que cette attribution de droit ne peut pas
tenir compte des spécificités du logiciel réalisé.
L'autre problème est souvent considéré comme beaucoup plus important par les
entreprises car il est beaucoup plus visible. Il s'agit des durées et coûts de déploiement des
logiciels. En effet un logiciel classique, développé en architecture client-serveur, nécessite
une installation et une éventuelle configuration sur chaque poste utilisateur. Le déplacement
d'un technicien coûte déjà très cher aux entreprises. Mais ce qui reste le plus laborieux est la
nécessité de mettre à jour régulièrement le logiciel. Dans une architecture client-serveur,
chaque mise à jour du logiciel nécessite un nouveau déploiement accompagné de nombreux
coûts.
III.2.2. Architecture 3-tiers:
III.2.2.1 Présentation :
Le principe d'une architecture 3-tiers est relativement simple: il consiste à séparer la
réalisation des trois parties vues précédemment (stockage des données, logique applicative,
présentation). Nous avons déjà pu entrevoir la possibilité de séparer la conception de ces trois
subdivisions, ici il s'agit de séparer leur implantation. Tout comme dans le client-serveur,
cette séparation signifie qu'il est possible de déployer chaque partie sur un serveur
indépendant, toutefois cela n'est pas obligatoire.
La mise en place de ce type d'architecture permet dans tous les cas une plus grande
évolutivité du système. Il est ainsi possible de commencer par déployer les deux serveurs sur
la même machine, puis de déplacer le serveur applicatif sur une autre machine lorsque la
charge devient excessive.
Les éléments permettant la réalisation classique d'un système en architecture 3- tiers
sont les suivants:
Système de gestion de base de données relationnel (SGBDR) pour le stockage
des données,
Serveur applicatif pour la logique applicative,
Navigateur Web pour la présentation.
Figure III.2 : Architecture 3-tiers
III.2.2.2. Avantages de l’architecture 3-tiers :
Les avantages de l'architecture 3-tiers sont principalement au nombre de quatre :
Les requêtes clients vers le serveur sont d'une plus grande flexibilité que dans
celles de l'architecture 2-tiers basées sur le langage SQL.
Cette flexibilité permet à une entreprise d'envisager dans le cadre d'une
architecture 3-tiers une grande souplesse pour l'introduction de toutes
nouvelles technologies.
D'un point de vue développement, la séparation qui existe entre le client, le
serveur et le SGBD permet une spécialisation des développeurs sur chaque
tiers de l'architecture.
Plus de flexibilité dans l'allocation des ressources; la portabilité du tiers serveur
permet d'envisager une allocation et ou modification dynamique aux grés des
besoins évolutifs au sein d'une entreprise.
III.2.2.3. Inconvénients de l’architecture 3-tiers :
Les inconvénients de l’architecture 3-tiers sont :
Les coûts de développements d'une architecture 3-tiers sont plus élevés que
pour du 2-tiers.
Plus de charge sur le serveur et le réseau.
III.2.3. Architecture n-tiers
III.2.3.1. Présentation :
Une architecture n-tiers va plus loin dans le découpage de l'application sur différents
serveurs. Une architecture n-tiers est également appelée architecture distribuée du fait de la
distribution des traitements et des données sur différents serveurs. Le découpage de base du
système reste toujours le même: une partie gestion de données, une partie gestion de la
logique applicative et bien entendu le client assurant la présentation. Toutefois les deux
parties développées coté serveur vont pouvoir être déployées chacune sur plusieurs serveurs.
L'objectif général de ce type d'architecture est de permettre l'évolutivité du système
sous plusieurs aspects: la quantité de données stockée, la disponibilité du serveur, le nombre
d'utilisateurs…
Il existe deux types de répartition possibles dans une architecture distribuée. Il est
possible de répartir les données et de répartir la logique applicative. Chacune de ces deux
répartitions permet de résoudre des problèmes de natures différentes. Elles peuvent donc être
mises en place soit séparément, soit en parallèle sur le même système.
Figure III.3 : Architecture N-tiers
III.2.4. Architecture adoptée
Vu que notre application nécessite un serveur Web pour fonctionner, alors
l’architecture la plus adoptée au système à réaliser est l’architecture 3-tiers. Donc les
éléments qui constituent l’architecture de notre application sont les suivant :
La présentation : C’est la partie la plus immédiatement visible pour l'utilisateur.
On parle d'Interface Homme Machine. En informatique, elle peut être réalisée par
une application graphique ou textuelle ou en WML pour être utilisée par un
téléphone portable.., et pour notre cas il est représentée en HTML pour être
exploitée par un navigateur web.
La logique applicative : 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.
La couche accès aux données : La fonction principale de cette couche est de
gérer les données. La façon dont elle organise, manipule et stocke les données est
transparente vis-à-vis des applications externes et des utilisateurs.