Rapport Final Walid

Télécharger au format doc, pdf ou txt
Télécharger au format doc, pdf ou txt
Vous êtes sur la page 1sur 78

Carthage commerciales

Universit de Institut des Hautes Etudes

MMOIRE DE PROJET DE FIN DETUDES POUR LOBTENTION DU DIPLME DE MASTRE PROFESSIONNEL


Filire

Commerce Electronique

Conception et dveloppement dun site web Marchand pour vente du matriel informatique en ligne
Organisme

Dirig parpar : Ralis : Mr. Nabil Chaabani (IMS) Tbini Walid Mme. Thouraya Daoues (IHEC) Mr. I.1.1. Melki Sofiene (IHEC)

Anne universitaire : 2010/2011

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, implementing and evaluating the application.

Key-Words: Cart, catalog, PHP, product management, invoice management, 3-tier architecture, online shopping, UML, jquery, CSS, HTML...

Rsum :

Une socit 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 daugmenter la concurrence. Cest lobjectif de notre projet qui consiste mettre en place un site web de commerce lectronique qui permettra de grer les commandes, clients, produits, marques, facturesetc. Notre application a aussi pour objectifs : dlargir le champ dintervention en impliquant tout les internautes dans le site web, dconomiser les ressources de la socit (tches du personnel, financement de la dmarche commercialeetc.), de rduire les cots et augmenter les revenus. Ce rapport dcrit lanalyse, la conception, ltat de lart, la ralisation, limplmentation et lvaluation de lapplication.

Mots cls : Panier, catalogue, PHP, gestion des produits, gestion des factures, architecture 3tiers, achat en ligne, UML, jquery, CSS, HTML

Ddicaces
A mes trs chers parents Dont leurs mrites, leurs sacrifices, leurs qualits humaines mont 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 quils ont consenti pour ma russite, quils trouvent ici le tmoignage de mon attachement ma reconnaissance, gratitude et respect, que dieu leur prservent bonne sant et longue vie. Tous mes sentiments de reconnaissance pour vous. A mes frres et surs Jespre atteint le seuil de vos esprances. Que ce travail soit lexpression de ma profonde affection Je vous remercie pour le soutient moral et lencouragement que vous mavez accords .Je vous souhaite tout le bonheur que vous mritez En leur souhaitant un brillant avenir.

A mes oncles et ma famille Que je ne pourrais nommer de peur den oublier mon attachement et mes affections les plus Sincres.

A mes ami(e) s A tout ceux qui ont su mapporter aide et soutient aux moments propices, Je ddie ce travail, reconnaissant et remerciant chaleureusement.

Remerciement
Cest avec un bonheur au cur que je consacre ces mots signe de gratitude et de reconnaissance tous ceux qui ont contribu, de prs ou de loin, la ralisation de ce projet, quils trouvent ici mon terme les plus sincres de remerciements

Je remercie tous ceux qui mont accueilli bras ouverts au sein de la socit IMS spcialement, mon encadreur Mr Nabil Chaabani. Mes fortes gratitudes mes encadreurs lIHEC CARTHAGE : Mr. Melki Sofiene et Mme. Thouraya Daoues qui mont su me mettre sur les railles de la russite du projet. Mon remerciements au personnel et enseignant de lIHEC de Carthage pour leur aide durant notre parcours universitaire.

Table des matires


Introduction. .. 6 Chapitre I Prsentation gnrale.. 8 I.1. Introduction... 8 I.2. Prsentation de lorganisme daccueil 8 I.2.1. Les objectifs dIMS.. 8 I.2.2. Les produits et les services offerts par IMS. 8 I.3. Prsentation du sujet... 9 I.4. Mthodologie et formalisme adopts... 9 I.5. Conclusion... 12 Chapitre II Analyse des besoins et spcifications.. 13 II.1. Introduction... 13 II.2. Objectifs. 13 II.3. Critique de lexistant. 14 II.4. Spcification 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. Scnarios et des cas dutilisation.. 17 II.4.3.1. Identification des acteurs... 17 II.4.3.2. Les diagrammes des cas dutilisation 17 II.4.3.2.1. Diagramme de cas dutilisation globale 18 II.4.3.2.2. Diagramme de cas dutilisation Achet un produit........ 19 II.4.3.2.3. Diagramme de cas dutilisation Grer produit.. 20 II.4.3.3. Les diagrammes de squence. 20 II.4.3.3.1. Proprits du diagramme de squences. 20 II.4.3.3.2. Diagramme de squence Authentification. 21 II.4.3.3.3. Diagramme de squence Mise jour dun produit......... 22 II.4.3.3.4. Diagramme de squence Ajout dun nouveau produit 24 II.4.3.3.5. Diagramme de squence Suppression dun produit 25 II.4.3.3.6. Diagramme de squence Gestion du panier... 27 II.5. Conclusion.. 28 Chapitre III Etat de lart. 29 III.1. Introduction.. 29 III.2. Architecture de lapplication.. 29
1

III.2.1. Architecture de client-serveur. 29 III.2.1.1. Prsentation.. 29 III.2.1.2. Avantages de larchitecture client-serveur... 30 III.2.1.3. Inconvnient de larchitecture client-serveur... 30 III.2.2. Architecture 3-tiers.. 31 III.2.2.1. Prsentation.. 31 III.2.2.2. Avantages de larchitecture 3-tiers... 32 III.2.2.3. Inconvnient de larchitecture 3-tiers... 32 III.2.3. Architecture N-tiers. 32 III.2.3.1 Prsentation... 32 III.2.4. Architecture adopte 33 III.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 adopte (MySQL). 35 III.3.2. Les Langages utiliss... 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. Coopration de PHP et MySQL... 37 III.4. Conclusion 37 Chapitre IV Conception... 38 IV.1. Introduction.. 38 IV.2. Conception de lapplication. 38 IV.2.1. Diagramme de classes..... 38 IV.3. Conception de la base de donnes... 40 IV.3.1.Passage un modle relationnel partir dun diagramme de classes.. 40 IV.3.2. Schma Relationnel de la base de donnes.. 40 IV.4. Conclusion. 42 Chapitre V Ralisation et implmentation.. 43 V.1. Introduction... 43 V.2. Environnement de travail. 43 V.2.1. Environnement matriel... 43 V.2.2. Environnement logiciel 44 V.3. Architecture du Systme .. 45 V.3.1. Diagramme de composante.. 45 V.4. Choix techniques 46 V.4.1. Choix du langage.. 46
2

V.4.2. Choix de la technologie de scurit.. 46 V.4.2.1. Protection contre les attaques dinjection SQL. 46 V.4.2.2. Les sessions... 46 V.4.2.3. Mcanisme de hachage de mot de passe... 47 V.4.3. Autres choix technologiques 48 V.5. Diagramme de GANTT. 48 V.6. Phase dimplmentation 49 V.6.1. Contraintes 49 V.6.2. Pratiques adoptes 50 V.7. Phase de tests et validation... 50 V.7.1. Jeux de tests et validation. 51 V.8. Conclusion.. 53 Chapitre VI Interface de lapplication... 54 VI.1. Introduction.. 54 VI.2. Interface de lapplication. 54 VI.2.1. Back-office.. 54 VI.2.1.1. Page dauthentification. 54 VI.2.1.2. Session administrateur.. 55 VI.2.1.2.1. Page daccueil du back-office. 55 VI.2.1.2.2. Page gestion des produits... 56 VI.2.1.2.3. Page ajout dun nouveau produit (pop-up)... 56 VI.2.1.2.4. Suppression dun produit... 57 VI.2.2. Front-office.. 58 VI.2.2.1. Page daccueil du front-office .. 58 VI.2.2.2. Page gestion de panier .. 60 VI.2.2.3. Page choix de mthode dexpdition... 61 VI.2.2.4. Page choix de mthode de payement 62 VI.2.2.5. Page confirmation commande... 63 VI.2.2.6. Page de payement.. 64 VI.3. Conclusion. 66 Conclusion gnrale.. 67 Glossaire 68 Bibliographie et Nographie 69 Annexe... 70

Table des figures


Liste des figures Titres

Figure I.1 Figure I.2 Figure II.1 Figure II.2 Figure II.3 Figure II.4 Figure II.5 Figure II.6 Figure II.7 Figure II.8 Figure III.1 Figure III.2 Figure III.3 Figure IV.1 Figure IV.2 Figure V.1 Figure V.2 Figure V.3 Figure V.4 Figure V.5 Figure V.6 Figure V.7 Figure V.8 Figure VI.1 Figure VI.2 Figure VI.3 Figure VI.4 Figure VI.5 Figure VI.6 Figure VI.7 Figure VI.8 Figure VI.9 Figure VI.10 Figure VI.11 Figure VI.12 Figure VI.13 Figure VI.14 Figure VI.15 Figure VI.16

Dmarche dlaboration du projet Organigramme de faisabilit du projet Diagramme de cas d'utilisation globale Diagramme de cas d'utilisation Achet un produit Diagramme de cas d'utilisation grer les produits Diagramme de squence authentification Diagramme de squence Mise jour dun produit Diagramme de squence Ajout dun nouveau produit Diagramme de squence Suppression dun produit Diagramme de squence Gestion du panier Architecture client-serveur Architecture 3-tiers Architecture N-tiers Diagramme de class Schma relationnel de la base de donnes Diagramme de composante Protection contre les attaques dinjection SQL Protection des donnes avec Les sessions Protection de mot de passe avec le mcanisme de hachage Script d'appel des plugins de jquery Menu slider Diagramme de GANTT Tableau jeux de tests et validation Page de connexion de lutilisateur Message derreur lorsque le login ou le mot de passe est invalide Page daccueil du back-office Page gestion des produits Page ajout dun nouveau produit Contrle de saisie dans lajout dun nouveau produit Supprimer un produit Page daccueil du back-office Ajout dun produit au panier Page dtails dun produit Page Gestion du panier Page dauthentification du client Formulaires dinscription dun nouveau client Page Choix de mthode dexpdition Formulaire de modification de ladresse dexpdition Page Choix de mthode de payement 4

Figure VI.17 Figure VI.18

Page confirmation de la commande Page de payement

Introduction Gnrale
Lvolution du secteur informatique durant ces dernires annes a favoris lapparition de nouvelles technologies web qui ont permis dunir les diffrents organismes et les diffrentes socits dune manire 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 diffrents membres des tablissements surtout que le facteur temps joue un rle trs important dans lvolution de la qualit des services. Le secteur du commerce na pas chapp cette vague, en effet ce secteur a donn naissance un nouveau secteur dit E-Commerce qui dsigne lensemble des changes numriss lis des activits commerciales. Cest dans ce contexte que sinscrit ce projet de fin dtudes, dans lequel nous sommes amens raliser un site web marchand, qui permet de vendre des ordinateurs en ligne. Donc, aprs avoir introduit notre travail de projet de fin dtudes, nous prsentons dans un premier chapitre la socit IMS qui nous a accueillis, nous dlimitons le cadre gnral du travail et nous spcifions notre sujet. Le deuxime chapitre est consacr une analyse des besoins qui sintressera aussi bien aux aspects fonctionnels quaux aspects nonfonctionnels lies notre sujet. Dans ce chapitre nous identifierons les cas

dutilisations ainsi que les diagrammes de squences dcrivant les scnarios dutilisation de site web. Le troisime chapitre est consacr la conception de notre site web. Dans ce chapitre nous allons spcifier les diffrentes classes constituantes notre system. A partir du diagramme de classe nous dgagerons la structure de notre base do donnes. Dans le quatrime chapitre nous prsenterons les outils qui nous taient utiles dans llaboration de ce travail. Le cinquime chapitre soccupera de la ralisation de site web en passant par lenvironnement matriel et logiciel utilis avec les diffrentes techniques de ralisation et de scurit. Le dernier chapitre nous donne une vue sur le site web dans son tat final et ce en nous fournissant les diffrentes IHM. Pour conclure, nous revenons sur nos apports et perspectives dans la conclusion de ce projet.

Chapitre I.

Prsentation Gnrale

I.1. I.2.

Introduction Prsentation de lorganisme daccueil

La socit tunisienne IMS est une socit de services et dingnierie informatique (SSII) spcialise dans la conception, la ralisation et le dveloppement de tout procd et applications informatiques et tlcommunications incluant laspect logiciel (Software) et laspect matriel (Hardware). La socit IMS est compose par des ingnieurs et des techniciens diplms des grandes coles tunisiennes disposant dune exprience laborieuse dans le domaine des TIC et des scientifiques hautement qualifis.

I.2.1. Les objectifs de IMS


Les objectifs quIMS visent les atteindre sont :

Satisfaction des clients et Anticipation totale de leurs besoins Dveloppement des relations de partenariat solides avec des socits nationales
et internationales.

Satisfaction de ces collaborateurs puisque la relation humaine est son axe


stratgique.

Atteindre une qualit de haut niveau Renforcer son avance technologique Innover toujours en se basant sur des tudes et des recherches avances

I.2.2. Les produits et les services offerts par IMS

- La socit IMS offre plusieurs types de produits tels que : CMS ERP /CRM E-Banking E-Portail Formed

- La socit IMS offre aussi plusieurs types de service tels que : Applications Web Web Marketing E-Solution Dveloppement Informatique Outsourcing Rseau ET Tlecommunication Assistance Technique

I.3.

Prsentation du sujet

Le sujet intitul Conception et dveloppement dun site web Marchand pour vendre du matriel informatique en ligne . Le travail demand a pour finalit de crer un site web marchand destine la vente du matriel informatique en ligne, qui est encore au stade de la recherche, et ce dans loptique de concevoir et de raliser une application qui permet de vendre en ligne, de grer les commandes, les clients, les factures, et le stock en temps rel.

I.4.

Mthodologie et formalise adopts

La mthodologie, est bien sr la dmarche mthodologique et lensemble des modles associs mais cest aussi, en amont mettre plat la logique applicative : les outils de modlisation comme Merise ou UML sont donc primordiaux. Dans ce qui suit, nous allons dcrire la dmarche de dveloppement et argumenter le choix dUML comme langage de modlisation. UML, est bien connu par les dveloppeurs. Il est souvent utilis pour la conception et la reprsentation graphique (sous forme de diagrammes) de nimporte quelle application de manire dtaille (lments, paramtres, fonctions, etc.) Outre sa souplesse et son caractre polyvalent, UML, est le mieux adapt aux dveloppements des applications e-commerce.

La dmarche dlaboration de notre projet sappuie sur UML qui permettra de modliser dune manire claire et prcise la structure et le comportement du systme. Cette dmarche est itrative, incrmentale, pilote par les cas dutilisation et centre sur larchitecture, la figure cidessous dcrit cette dmarche.

Figure I.1 : Dmarche dlaboration du projet

Figure I.2 : Organigramme de faisabilit du projet

Vu que 50% des checs des projets informatiques proviennent de la spcification, nous avons donn une attention particulire au maquettage. Le maquettage est une technique qui permet de surmonter la difficult de spcification du logiciel due la diffrence de terminologie et au manque de prcision dans l'expression des besoins. Cette activit consiste dessiner rapidement des crans du futur systme (maquette).

I.5.

Conclusion

Nous avons prsent le cadre du travail au sein de lentreprise IMS, le sujet ainsi que les mthodologies utilises pour concevoir notre site web. Ces lments 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 systme qui seront par la suite exploites, dtailles et mises en uvre pour la suite du travail. Dans ce qui suit nous allons effectuer une analyse des besoins et des spcifications du projet raliser ce dont nous allons aborder au cours du prochain chapitre.

apitre II.

Analyse des besoins et spcifications

II.1. Introduction

L'identification des besoins est la pierre angulaire de conception et dveloppement des sites web, car lanalyse des besoins est essentielle la russite d'un projet de dveloppement. En effet cette phase consiste qualifier les besoins fonctionnels et analyser lexistant afin dobtenir les spcifications et les exigences dtailles techniques. Dans cette partie, nous avons spcifi les diffrents besoins fonctionnels et non fonctionnels requis pour limplmentation de notre site web et les cas dutilisations possibles. Nous allons ensuite passs la conception de notre site web.

II.2. Objectif
La vente en ligne est une forme de commerce lectronique qui a apparut avec le dveloppement massive des technologies dinformations et qui consiste raliser tout les tapes dune transaction commercial sur internet. Dans ce contexte que sinspire notre travail qui consiste concevoir et dvelopper un site web marchand. Notre solution aura pour objectif :

Vendre du matriel informatique en ligne.


Contrle et gestion des diffrents processus. Rduire les cots et augmenter les revenus. Augmenter le nombre des clients.

II.3. Critique de lexistant


- La vente du matriel informatique se fait dune manire traditionnel, c'est--dire si les clients veulent acheter du matriel informatique, ils doivent se prsenter 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 faon de gre et de vendre le matriel informatique engendre les dfaillances suivantes :

Les frais de locations et les frais des personnels qui travaillent dans les
boutiques sont leve.

Les clients qui viennent pour acheter du matriel informatique nont pas une
visibilit totale sur tous les matriels.

Une perte du temps dans la recherche des informations concernant le matriel


informatique.

Le processus de la gestion des ventes du matriel informatique (Ajout,


Modification, des facteurs, des clients, des produits,) est long. Un Manque de publicit.

II.4. Spcification des exigences


Les objectifs de la phase spcification des exigences sont de faciliter la reconnaissance et la comprhension 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 dutilisateurs qui sont les internautes, les clients et le administrateur. 2 - Pour La partie back-office du site :

Besoin dune page dauthentification pour accder au back-office.

Besoin de grer les produits : Consultation, ajout, modification, suppression,


recherche des produits, gestion des marques ...

Besoin de grer les medias : ajout, modification et suppression des medias (Logo, Bannire).

Besoin de grer les contacts : consultation et suppression des contacts.

Besoin de grer le compte dadministrateur : Modifier le login et le mot de passe, ajouter un administrateur

Besoin de grer les factures : consultation, recherche, suppression des factures.

Besoin de grer les clients inscrit dans lespace clients : informer les clients sur lavancement de leurs commandes, rechercher des clients, consultation des informations concernant les clients

Besoin dun module de newsletter pour communiquer les clients et les internautes sur toutes les nouveauts.

Besoin de grer les commandes : Ajout, suppression, consultation et recherche des commandes.

Gestion des stocks en temps rel.

3 - Pour la partie front office du site:

Besoin dun menu qui contient tout les catalogues du matriel informatique. Besoin dune page de contact. Besoin dune page de paiement. Besoin dun espace membre pour nos clients qui contient lhistorique des achats
ralis, toutes les offres spciales, le suivi de la livraison...

Besoin dun Moteur de recherche. Besoin dune Newsletter. Besoin dun Module de partage des produits sur les rseaux sociaux.
Besoin dun panier pour grer les quantits des produits achet.

II.4.1.2

Besoins non fonctionnels :

En plus des besoins fonctionnels cits ci-dessus nous devons tenir compte des contraintes suivantes : La satisfaction complte des besoins de tous les utilisateurs. Simplifier le travail des utilisateurs avec une ergonomie sobre et efficace. Limplmentation des mesures scuritaires. Assurer la Confidentialit des informations. L'optimisation du code. L'optimisation des ressources consommes. La compatibilit avec le matriel existant. Lapplication doit assurer la non-rpudiation et la traabilit de linformation.

Lapplication doit tre scurise. Un profil daccs est affect chaque


utilisateur.

II.4.2.

Quelques concepts

Dans notre site web, nous allons dfinir les diffrents types d'utilisateurs qui ont des droits et des fonctionnalits qui leurs sont propres. Nous abordons alors notre travail par une identification des acteurs, en fait un acteur reprsente un rle jou par une personne ou par un groupe de personnes qui interagit avec le systme.

Dans notre site web on trouve 3 types dacteurs : linternaute, le client, et ladministrateur du site.

II.4.3.
I.1.1.1

Scnarios et des cas dutilisation


Identification des acteurs :

Les principaux acteurs de notre application sont :

Ladministrateur. Les internautes. Les clients.


Chaque acteur ses propres tches quon va les modliser dans les sections suivantes. En effet, tous les acteurs passent obligatoirement par deux interfaces qui sont : - Le back-office : destine ladministrateur. - Le front-office : destine aux internautes et aux clients. Espace Administrateur : Cest le back-office de notre site web. Dans cette espace ladministrateur a le droit deffectuer toutes sortes doprations pour administrer le site tel que lajout, la modification, la suppression, la mise a jour des produits ou des medias, ou des factures, dfinir les droits daccs, consulter les contacts Espace Internaute : Cest le front-office de notre site web. Cette espace est destine aux internautes et aux clients qui peuvent naviguer sur le site, effectuer des recherches sur les marques du matriel informatique propose, sinscrire dans la newsletter, faire des achats, sinscrire dans lespace membre, consulter le catalogue

II.4.3.1

Les diagrammes des cas dutilisation :

Il s'agit de la solution UML pour reprsenter le modle conceptuel, les diagrammes des cas dutilisation permettent de dcrire l'interaction entre l'acteur et le systme.

II.4.3.2.1

Diagramme de cas dutilisation globale :

Figure II.1 : Diagramme de cas d'utilisation globale Ce diagramme de cas dutilisation nous donne une vue globale sur les utilisateurs et leurs interactions avec les 2 parties du site, le back-office et le front-office. - linternaute : son interaction se fait avec le front-office du site soit par la consultation du contenue du site, la cration dun compte, la recherche - le client : c'est un internaute qui s'est transform en client ds son premier acte dachat en ligne, il hrite tout les fonctionnalits de linternaute (consultation du contenue du site, la cration dun compte, la recherche ). - ladministrateur : son interaction se fait avec le back-office du site, son rle est la gestion du site (gestion des produits, gestion des medias, gestion des commandes)

II.4.3.2.2

Diagramme de cas dutilisation Achet un produit

Figure II.2 : Diagramme de cas d'utilisation Achet un produit Ce diagramme de cas dutilisation nous montre linteraction du client avec le frontoffice du site lorsquil va acheter un produit. Le client ici peut consulter les produits, grer son panier, passer une commande et suivre son avancement aprs lauthentification.

II.4.3.2.3

Diagramme de cas dutilisation Grer les produits

Figure II.3: Diagramme de cas d'utilisation Grer les produits Ce diagramme de cas dutilisation nous montre comment ladministrateur gre les produits. Pour grer un produit, ladministrateur doit tout dabord sauthentifier, puis il peut ajouter, modifier, ou supprimer un produit.

Les diagrammes de squence:


II.4.3.3.1 Proprits du diagramme de squences :
Lanalyse des cas dutilisation commence par llaboration des diagrammes de squences avec des objets danalyses. Les objets danalyses sont des instances de classes danalyses qui reprsentent les lments majeurs ayant des comportements et des responsabilits dans le systme.

Les objets de contrle : ils reprsentent les activits systmes. Ces objets dirigent les
activits des objets dentits et dinterfaces.

Les objets dentits : ce sont des entits persistantes au systme (tel que les tables de la
base de donnes).

Les objets dinterface : ils reprsentent linterface qui est en interaction directe avec
lutilisateur (exemples : les crans de saisies).

II.4.3.3.2 Diagramme de squence Authentification :


Titre : Sauthentifier. Rsum : Ce cas dutilisation permet lutilisateur de se connecter au systme et de sauthentifier a travers un profile qui dterminera les rubriques aux quels il a le droit dy accder. Acteurs : Se sont les diffrant utilisateurs du systme qui sont : linternaute, le client et ladministrateur.

Description des scnarios : 1. Pr condition :


Existence dune interface permettant la saisie didentificateur ainsi du mot de passe pour lutilisateur. 2. Scnario Normal :

Lutilisateur accde au site web Une interface Homme/Machine est apparue contenant un formulaire
lauthentification. Saisie du Login et de Mot de Passe. Le system vrifie lexistence de lutilisateur. Le system cherche les rubriques disponibles pour cet utilisateur Le system affiche les rubriques selon le profil de lutilisateur connect. Login et Mot de Passe erron. Le system indique lutilisateur que le Login et le Mot de Passe sont errons.

3. Scnario derreur :

Le system affiche lchec de la saisie (Le scnario normal reprend au point


1).

Figure II.4 : Diagramme de squence Authentification

II.4.3.3.3

Diagramme de squence Mise jour dun produit :


Titre : Mettre jour un produit. Rsum : Dcrire les tapes suivre par ladministrateur afin de mettre jour un

produit. Acteurs : ladministrateur.

Description des scnarios : 1. Pr condition :


Dans linterface du back-office on trouve un menu qui contient des modules, on choisit le module Produits 2. Scnario Normal :

a. Ladministrateur entre dans le back-office et choisi le module produits b. Lcran du produit affiche tout les produits.

c. Ladministrateur appuie sur le bouton mise jour du produit quil veut le


modifier.

d. Lcran du produit affiche tout les informations du produit concern. e. Ladministrateur modifie les informations du produit et valide son choix. f. Le system enregistre les modifications ralis par ladministrateur dans la base
de donnes.

g. Lcran du produit affiche un message de mise jour avec succs.


3. Scnario derreur : Des Informations errones ou des champs vides.

Lcran du produit affiche un massage derreur qui indique


ladministrateur que les informations saisis sont errones ou indique quil ya des champs vides et quil doit les remplis (Le scnario normal reprend au point 5).

Figure II.5 : Diagramme de squence Mise jour dun produit

II.4.3.3.4 Diagramme de squence Ajout dun nouveau produit :


Titre : Ajouter un nouveau produit. Rsum : Dcrire les tapes suivre par ladministrateur afin dajouter un produit. Acteurs : ladministrateur.

Description des scnarios : 1. Pr condition :


Dans linterface du back-office on trouve un menu qui contient des modules, on choisit le module Produits 2. Scnario Normal :

a. Ladministrateur entre dans le back-office et choisi le module produits b. Lcran du produit affiche tout les produits. c. Ladministrateur appuie sur le bouton ajouter un produit. d. Lcran du produit affiche un formulaire dajout dun nouveau produit. e. Ladministrateur remplie le formulaire du produit et valide son choix. f. Le system enregistre le nouveau ajout par ladministrateur dans la base de
donnes.

g. Lcran du produit affiche un message dajout avec succs.


3. Scnario derreur : Des Informations errones ou des champs vides.

Lcran du produit affiche un massage derreur qui indique


ladministrateur que les informations saisis sont errones ou indique quil ya des champs vides et quil doit les remplis(Le scnario normal reprend au point 4).

Figure II.6 : Diagramme de squence Ajout dun nouveau produit

II.4.3.3.5

Diagramme de squence suppression dun produit :


Titre : Supprimer un produit. Rsum : Dcrire les tapes suivre par ladministrateur afin de supprimer un produit. Acteurs : ladministrateur.

Description des scnarios : 1. Pr condition :


Dans linterface du back-office on trouve un menu qui contient des modules, on choisit le module Produits 2. Scnario Normal :

a. Ladministrateur entre dans le back-office et choisi le module produits


b. Lcran du produit affiche tout les produits.

c. Ladministrateur appuie sur le bouton supprimer du produit quil veut le


supprimer.

d. Lcran du produit affiche un message qui demande la confirmation de la


suppression.

e. Ladministrateur confirme son choix. f. Le system supprime le produit dans la base de donnes. g. Lcran du produit affiche un message de suppression avec succs.

Figure II.7 : Diagramme de squence Suppression dun produit

II.4.3.3.6 Diagramme de squence Gestion du Panier


Titre : Grer un panier.

Rsum : Dcrire les tapes suivre par le client afin de grer son panier lors dune opration dachat. Acteurs : Le client.

Description des scnarios : 1. Pr condition :


Dans linterface du front-office on trouve les catalogues des produits offerts, alors il suffit de choisir le produit acheter. 2. Scnario 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) sajout dans le panier.


c. Le client accde son panier en appuyant sur licone panier.

d. Le client peut modifier les quantits des produits dans le panier. e. Le client peut supprimer des lignes dans le panier. f. Le client peut passer la commande aprs avoir terminer la gestion de son panier.
3. Scnario derreur : Des Informations errones ou des champs vides.

Lcran du produit affiche un massage derreur qui indique au client que les
informations saisis lorsque il a modifi son panier sont errones, ou indique quil ya des champs vides et quil doit les remplis(Le scnario normal reprend au point 4).

Figure II.8 : Diagramme de squence Gestion du panier

II.5. Conclusion
Ce chapitre nous a permis de couvrir tous les cas d'utilisations concernant les diffrents utilisateurs de notre systme et de dfinir les besoins non fonctionnels prendre en considrations afin de satisfaire les utilisateurs. La spcification des besoins tant tablie, nous essayerons dans le chapitre suivant de concevoir clairement les diffrentes technologies existantes pouvant tre utilises pour llaboration du projet.

Chapitre III. tat de lart


III.1. Introduction
Dans ce chapitre, nous allons dtailler les diffrentes architectures existantes pouvant tre utilises pour llaboration de notre projet, en suite nous allons prsenter les diffrents moyens techniques qui peuvent tre utilises dans la ralisation de notre projet.

III.2.Architecture de lapplication
III.2.1.
III.2.1.1.

Architecture client-serveur
Prsentation :
Les architectures client-serveur constituent une tape importante dans l'volution des

systmes d'informations. Ce type d'architecture est constitu uniquement de deux parties: un client qui gre la prsentation et la logique applicative est un serveur qui stocke les donnes de faon cohrente et gre 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 indpendance du client par rapport au serveur. La programmation du client peut s'effectuer sans se proccuper de la mise en place de la base de donnes. En particulier, les questions concernant l'administration des donnes ne concerneront pas le dveloppeur du client (dimensionnement des disques, rpartition des donnes sur le systme, optimisation des accs aux donnes, sauvegarde des donnes,...).

Figure III.1 : Architecture client-serveur

III.2.1.2.

Avantages de larchitecture client-serveur :


Les principaux avantages de larchitecture client-serveur sont :

L'Atomicit : permet la transaction d'avoir un comportement indivisible; soit


toutes les modifications sur les donnes effectues dans la transaction sont effectives, soit aucune n'est ralise. La Cohrence des donnes de la base est permanente. L'Isolation des transactions : signifie que les modifications effectues 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, mme en cas de problmes graves tel que la perte d'un disque.

III.2.1.3.

Inconvnients de larchitecture client-serveur :


L'architecture client-serveur possde toutefois des inconvnients. Ce sont ces

inconvnients qui poussent les entreprises utiliser d'autres technologies. Les deux inconvnients principaux sont la difficult grer correctement les questions de scurit et le cot du dploiement. La scurit d'un systme en architecture client-serveur est gre au niveau du SGBDR. Celui-ci contrle l'accs aux donnes en attribuant des autorisations d'accs aux diffrents utilisateurs du systme. Le problme vient du fait que cette attribution de droit ne peut pas tenir compte des spcificits du logiciel ralis. L'autre problme est souvent considr comme beaucoup plus important par les entreprises car il est beaucoup plus visible. Il s'agit des dures et cots de dploiement des logiciels. En effet un logiciel classique, dvelopp en architecture client-serveur, ncessite une installation et une ventuelle configuration sur chaque poste utilisateur. Le dplacement d'un technicien cote dj trs cher aux entreprises. Mais ce qui reste le plus laborieux est la ncessit de mettre jour rgulirement le logiciel. Dans une architecture client-serveur, chaque mise jour du logiciel ncessite un nouveau dploiement accompagn de nombreux cots.

III.2.2.
III.2.2.1

Architecture 3-tiers:
Prsentation :

Le principe d'une architecture 3-tiers est relativement simple: il consiste sparer la ralisation des trois parties vues prcdemment (stockage des donnes, logique applicative, prsentation). Nous avons dj pu entrevoir la possibilit de sparer la conception de ces trois subdivisions, ici il s'agit de sparer leur implantation. Tout comme dans le client-serveur, cette sparation signifie qu'il est possible de dployer chaque partie sur un serveur indpendant, 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 systme. Il est ainsi possible de commencer par dployer les deux serveurs sur la mme machine, puis de dplacer le serveur applicatif sur une autre machine lorsque la charge devient excessive. Les lments permettant la ralisation classique d'un systme en architecture 3- tiers sont les suivants:

Systme de gestion de base de donnes relationnel (SGBDR) pour le stockage des donnes, Serveur applicatif pour la logique applicative, Navigateur Web pour la prsentation.

Figure III.2 : Architecture 3-tiers

III.2.2.2.

Avantages de larchitecture 3-tiers :


Les avantages de l'architecture 3-tiers sont principalement au nombre de quatre : Les requtes clients vers le serveur sont d'une plus grande flexibilit que dans celles de l'architecture 2-tiers bases 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 dveloppement, la sparation qui existe entre le client, le serveur et le SGBD permet une spcialisation des dveloppeurs 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 grs des besoins volutifs au sein d'une entreprise.

III.2.2.3.

Inconvnients de larchitecture 3-tiers :


Les inconvnients de larchitecture 3-tiers sont :

Les cots de dveloppements d'une architecture 3-tiers sont plus levs que pour
du 2-tiers.

Plus de charge sur le serveur et le rseau.

III.2.3. Architecture n-tiers


III.2.3.1. Prsentation :
Une architecture n-tiers va plus loin dans le dcoupage de l'application sur diffrents serveurs. Une architecture n-tiers est galement appele architecture distribue du fait de la distribution des traitements et des donnes sur diffrents serveurs. Le dcoupage de base du systme reste toujours le mme: une partie gestion de donnes, une partie gestion de la logique applicative et bien entendu le client assurant la prsentation. Toutefois les deux parties dveloppes cot serveur vont pouvoir tre dployes chacune sur plusieurs serveurs. L'objectif gnral de ce type d'architecture est de permettre l'volutivit du systme sous plusieurs aspects: la quantit de donnes stocke, la disponibilit du serveur, le nombre d'utilisateurs Il existe deux types de rpartition possibles dans une architecture distribue. Il est possible de rpartir les donnes et de rpartir la logique applicative. Chacune de ces deux rpartitions permet de rsoudre des problmes de natures diffrentes. Elles peuvent donc tre mises en place soit sparment, soit en parallle sur le mme systme.

Figure III.3 : Architecture N-tiers

III.2.4. Architecture adopte


Vu que notre application ncessite un serveur Web pour fonctionner, alors larchitecture la plus adopte au systme raliser est larchitecture 3-tiers. Donc les lments qui constituent larchitecture de notre application sont les suivant :

La prsentation : Cest la partie la plus immdiatement visible pour l'utilisateur. On parle d'Interface Homme Machine. En informatique, elle peut tre ralise par une application graphique ou textuelle ou en WML pour tre utilise par un tlphone portable.., et pour notre cas il est reprsente en HTML pour tre exploite par un navigateur web.

La logique applicative : Elle correspond la partie fonctionnelle de l'application, celle qui implmente la logique , et qui dcrit les oprations que l'application opre sur les donnes en fonction des requtes des utilisateurs, effectues au travers de la couche prsentation.

La couche accs aux donnes : La fonction principale de cette couche est de


grer les donnes. La faon dont elle organise, manipule et stocke les donnes est transparente vis--vis des applications externes et des utilisateurs.

III.3.

Choix techniques

III.3.1. SGBD utilis :


III.3.1.1. MYSQL
MySQL est un systme de gestion de base de donnes relationnelle. Une base de donnes relationnelle augmente la vitesse et la flexibilit, en stockant des donnes dans des tables spares plutt que de mettre toutes les donnes dans un secteur. Ces tables sont lies par des relations dfinies permettant de combiner des donnes de plusieurs tables sur demande. Employer une SGBDR signifie qu'il est possible d'ajouter, d'accder, et de traiter les donnes stockes dans votre base de donnes. SQL est "Structured Query Language" - le langage normalis le plus commun pour accder des bases de donnes.

III.3.1.1. 1. Communication du MySQL avec le serveur web :


La totalit du dialogue avec une base de donnes seffectue en passant des messages au serveur MySQL. Ces messages peuvent tre envoys de plusieurs faons. Les requtes faites sont formules dans le langage SQL (Strutured Query Language). PHP, lui ne comprend pas ce langage, mais cela nest pas utile car PHP est l seulement pour passer de faon transparente MySQL les requtes crites en SQL. Le serveur web les interprte, les excute, et renvoie un message contenant le rsultat de cette excution ou un diagnostic derreur si la requte ntait pas correcte.

III.3.1.2 Les autres SGBD face MYSQL : PostgreSQL


PostgreSQL est un Systme de Gestion de Base de Donnes open source bas sur POSTGRES dvelopp l'universit de Californie au dpartement des sciences informatiques de Berkeley. Ce systme est concurrent d'autres systmes de gestion de base de donnes, qu'ils soient libres (comme MySQL et Firebird), ou propritaires (comme Oracle, Sybase, DB2 et Microsoft SQL Server). Comme les projets libres Apache et Linux, PostgreSQL n'est pas contrl par une seule entreprise, mais est fond sur une communaut mondiale de dveloppeurs et d'entreprises.

- Principales caractristiques :

PostgreSQL peut stocker plus de types de donnes que les types traditionnels entiers,

caractres, etc. L'utilisateur peut crer des types, des fonctions, utiliser l'hritage de type etc. Il fonctionne sur diverses plates-formes matrielles et sous diffrents systmes d'exploitation.

III.3.1.3. SGBD adopte (MySQL)


On a choisie MySQL car il est trs rapide, fiable, et facile employer. MySQL a galement un ensemble de dispositifs trs pratiques dvelopps en coopration avec ses utilisateurs. C'est galement 'Open Source' et donc librement accessible. MySQL est employ pour accder des bases de donnes sur Internet d sa connectivit, sa vitesse et sa scurit. Il a t l'origine dvelopp pour contrler de grandes bases de donnes une vitesse beaucoup plus rapide que les solutions qui ont prcdemment exist. MySQL a pendant plusieurs annes prospr dans les secteurs compliqus de la production.

III.3.2. les langages utiliss :


III.3.2.1. Le langage JQuery :
JQuery est une librairie JavaScript, et cest un langage conu pour simplifier les scripts du cot client dans le navigateur. Il a t cre par John Resig au Barcamp de New-York en 2006. Cest un logiciel open source sous les licences combines du MIT et GPL. Le slogan de jQuery est Coder moins pour en faire plus est parfaitement adapt, et on peut faire de beaux effets avec quelques lignes de code. Sa syntaxe est trs facile comprendre, et on code de manire transparente une fois quon a compris les concepts de base. JQuery est particulirement adapt pour : Crer des animations Grer les vnements du navigateur Slectionner les lments DOM Crer des programmes AJAX

- Avantages dutiliser jQuery


Premirement, cest beaucoup plus rapide de programmer une fonctionnalit avec jQuery que de lcrire partir de rien. Il permet donc de rehausser la valeur de vos projets de conception web en diminuant le temps consacr ou bien en vous permettant dimplmenter des fonctionnalits plus pousses. Ensuite, il est conu pour fonctionner dans tous les navigateurs rcents. Si vous programmez souvent en JavaScript vous savez quel point chaque navigateur offre une version diffrente de JavaScript et quel point a peut rendre le code complexe et illisible.

Aussi, le fait dutiliser une librairie aussi pousse peut vous viter davoir recours Flash, qui est une technologie propritaire

III.3.2.2. Le langage PHP :


PHP est un langage interprt, de scripts et libre. Il connat un succs toujours croissant sur le Web. L'environnement Linux est sa plateforme de prdilection. Combin avec le serveur Web Apache et la base de donnes MySQL, PHP offre une solution particulirement robuste, stable et efficace, offrant en outre l'avantage d'tre gratuite, tous ces logiciels viennent du monde des logiciels libres. Il est conu pour le dveloppement d application Web interactive et dynamique. PHP possde un grand nombre de fonctions permettant des oprations sur le systme de fichiers, la gestion de la base de donnes telle que MySQL et de pouvoir le grer dynamiquement. Cest un langage qui sinclut dans le HTML. Il est principalement conu pour servir de langage de scripts ct serveur. Il est rapide (le serveur na pas besoin dtre rinitialis souvent) et stable (ne change pas radicalement dune version une autre).

III.3.2.3.

Les autres langages face PHP : ASP (Active Server Pages) :


ASP est un standard mis au point par Microsoft en 1996. Son syntaxe est un peu

diffrente de celui de PHP mais les bases sont les mme. Il supporte pratiquement tous les standards du Web et maintenant il est support par le serveur Web Apache. En fait, cest un langage VB script. PHP est lun des langages les plus utilis dans le monde et est pass devant la technologie ASP de Microsoft. En effet, PHP possde plusieurs avantages par rapport ASP. Les principaux sont :

La portabilit. La rutilisabilit.
La modularit. Lextensibilit. Un faible cot.

La simplicit d'utilisation.

III.3.2.4.

Coopration de PHP et MySQL :

MySQL et PHP, le couple parfait : ils sont frquemment utiliss conjointement. On les appelle parfois le duo dynamique. MySQL assure la gestion de la base de donnes, PHP langage de programmation dans lequel sont crites les applications de bases de donnes sur le Web.

III.4. Conclusion
Dans ce chapitre, nous avons prsent larchitecture adopter pour notre application ainsi quune comparaison avec les autres architectures. Aussi, nous avons dtaill les technologies utilises pour la programmation et la base de donnes. Dans ce qui suit nous allons effectuer la conception du projet Reprsent dans le diagramme de class et dans le schma relationnel, ce dont nous allons aborder au cours du prochain chapitre.

Chapitre IV. Conception


IV.1. Introduction
La phase de conception permet de dcrire de manire non ambigu, le plus souvent en utilisant un langage de modlisation, le fonctionnement futur du systme, afin d'en faciliter la ralisation. Cette phase englobe la conception de la base de donnes et celle des applications. Dans ce chapitre nous exposons notre conception du systme raliser et qui a pour but de rendre flexible la tche de dveloppement de notre application.

En premier lieu, on va prsenter l'architecture du systme par la suite, vu la diversit des mthodes de conception qui nont cess dvoluer, nous prsentons en deuxime lieu notre choix qui est la mthode objet base sur le langage de modlisation unifi UML. Ensuite, nous dcrivons la conception du projet avec UML en prsentant les diffrents diagrammes issus de lapplication et enfin on va dcrire larchitecture de la base de donnes et les relations entre ses tables.

IV.2. Conception de lapplication


IV.2.1. Diagramme de classes
Le diagramme de classes constitue un lment trs important de la modlisation : il permet de dfinir quelles seront les composantes du systme final : il ne permet pas en revanche de dfinir le nombre et ltat des instances individuelles. Nanmoins, on constate souvent quun diagramme de classes proprement ralis permet de structurer le travail de dveloppement de manire trs efficace; il permet aussi, dans le cas de travaux raliss en groupe (ce qui est pratiquement toujours le cas dans les milieux industriels), de sparer les composantes de manire pouvoir rpartir le travail de dveloppement entre les membres du groupe.

Figure IV.1 : Diagramme de classes

IV.3. Conception de la base de donnes


IV.3.1. Passage un modle relationnel partir dun diagramme de classes :
Dans le but de se manifester le plus possible de lapproche orient objet, on a dcid dadopter le modle objet dans la conception de la base de donnes. Ce modle est bas sur le diagramme de classes (Figure IV.1) pour le passage vers le modle entit relation. Pour cela, les rgles de passages de modle objet au modle relationnel sont les suivants : Chaque classe se transforme en une table. Chaque attribut de classe se transforme en un champ de cette table. Rgle1: Prsence de la Cardinalit (? .. 1) dun ct de lassociation : Lidentifiant de la classe qui est associe la cardinalit (?...1) devient la cl trangre de lautre classe. Rgle 2: prsence de (? .. N) des deux cts de lassociation : Lassociation se transforme en une table. Cette table a comme champs lidentifiant de chacune des deux classes, plus dventuels autres attributs. Rgle 3: prsence dune gnralisation : Crer une table pour chaque sous type, chaque table se compose des attributs gnriques et dattributs spcifiques. [B1]

IV.3.2.

Schma Relationnel de la base de donnes :


En se basant sur les rgles de passage du modle objet utilis tout au long de notre

conception vers un modle relationnel qui va schmatiser notre base de donnes on a aboutit aux transformations suivantes :

Figure IV.2 : Schma relationnel de la base de donnes

IV.4. Conclusion
Dans ce chapitre, nous avons prsent le diagramme de class de notre projet puis nous avons prcis les rgles de passage suivre pour arriver au schma relationnel de la base de donnes de notre projet. Dans le chapitre suivant, nous exposons l'environnement logiciel et matriel utilis pour raliser notre application.

Projet de fin dtudes

Anne universitaire : 2010/2011

Chapitre V. Ralisation et implmentation


V.1. Introduction
La ralisation du systme est faite sur une machine ddie au projet sur une plateforme de dveloppement incluant un serveur dapplication Apache et un serveur gestion de base de donnes MYSQL, laide des outils de dveloppement et de tests ncessaires. Cette phase est aussi critique que les prcdentes puisquelle est pratiquement la dernire tape avant de livrer lapplication aux futurs utilisateurs. Cette phase repose sur la phase de conception pour implmenter les algorithmes dfinis par les diagrammes de squences.

V.2.

Environnement de travail
Environnement matriel
ordinateur

V.2.1.
portable :

Dans la ralisation de notre application nous avons travaill avec un

HP Compaq 610

Processeur : Intel Core 2 Duo T5870 (2 GHz). Mmoire : 2 GO de RAM. Disque dur : 320Go. Systme dexploitation : Microsoft Windows 7

V.2.2.

Environnement logiciel

Projet de fin dtudes

Anne universitaire : 2010/2011

Outils de dveloppement :

Dreamweaver 8 :
Cest lEnvironnement de dveloppement qui nous a permis de crer les interfaces, les menus, les boutons et dutiliser les langages PHP, HTML, CSS, JAVASCRIPT pour coder notre application. [N4] Serveur dapplication :

Wamp 5 :
Regroupe un serveur dapplication Apache, un serveur gestion de base de donnes MySQL, ainsi que des outils facilitant le dveloppement de notre application. [N6] Outil pour la conception :

Edraw max 5.6


Utilis tout au long de la phase de spcification et de conception pour la modlisation des besoins non fonctionnels en des besoins fonctionnels. [N7] Outil pour le graphique et le dsigne :

Adobe Photoshop CS 5
Cest un logiciel de retouche, de traitement et de dessin assist par ordinateur qui nous a permet de dsigner notre application. [N8] Autre :

Gantt Project 2.0.4


Utilis pour la ralisation du diagramme de GANTT dans la phase de gestion de projet, pour modliser le planning de notre projet. [N9]

Projet de fin dtudes

Anne universitaire : 2010/2011

V.3.

Architecture du Systme
Diagramme de composants

V.3.1.

Les diagrammes de composants permettent de dcrire l'architecture physique et statique d'une application en termes de modules : fichiers sources, librairies, excutables, etc. Ils montrent la mise en uvre physique des modles de la vue logique avec l'environnement de dveloppement. Les dpendances entre composants permettent notamment d'identifier les contraintes de compilation et de mettre en vidence la rutilisation de composants. Les composants peuvent tre organiss en paquetages, qui dfinissent des soussystmes. Les sous-systmes organisent la vue des composants (de ralisation) d'un systme. Ils permettent de grer la complexit, par encapsulation des dtails d'implmentation. Ce diagramme de composante est bas sur larchitecture que nous avons utilise pour llaboration de notre projet (Voir chapitre III tat de lart).

Figure V.1 : Diagramme de composants

Projet de fin dtudes

Anne universitaire : 2010/2011

V.4.

Choix techniques

Comme nous avons bien justifi les choix technique adopt dans le chapitre tat de lart. De ce fait, les choix techniques sont :

Langages de programmation : PHP, HTML, CSS, JQUERY. [N1], [N2], [N3] SGBD : MySQL. [N5] Serveur : Apache.
Ces choix satisfont les besoins ncessaires pour raliser lapplication. Donc, nous avons approuv ces choix et ralis les diffrents modules dans ces conditions.

V.4.1. Choix de la technologie de scurit


V.4.1.1. Protection contre les attaques dinjection SQL
Pour assurer la scurit de notre application, nous allons appliquer la fonction qui va permettre dviter les injections SQL via PHP.

Figure V.2 : Protection contre les attaques dinjection SQL


Une injection SQL est un type d'exploitation d'une faille de scurit d'une application interagissant avec une base de donnes, en injectant une requte SQL non prvue par le systme et pouvant compromettre sa scurit.

V.4.1.2. Les sessions


Pour assurer la scurit de notre application, nous allons utiliser les sessions qui vont nous permettre dassurer la scurit et lintgrit des donnes.

Projet de fin dtudes

Anne universitaire : 2010/2011

Figure V.3 : Protection des donnes avec Les sessions


Une session est un mcanisme technique permettant de sauvegarder temporairement sur le serveur des informations relatives un internaute. Ce systme a notamment t invent pour palier au fait que le protocole HTTP agit en mode non connect. Nous avons implment les sessions particulirement dans : Les espaces membres et accs scuriss avec authentification.

La Gestion du panier par le client. Stockage d'informations relatives la navigation de l'utilisateur.


Les informations seront quant elles transfres de page en page par le serveur et non par le client. Ainsi, la scurit et l'intgrit des donnes s'en voient amliores ainsi que leur disponibilit tout au long de la session. Une session peut contenir tout type de donnes : nombre, chane de caractres et mme un tableau. [N2]

V.4.1.3. Mcanisme de hachage de mot de passe


Pour assurer la scurit de notre application, nous avons utilis la fonction MD5 qui va nous permettre dassurer la scurit des donnes contre le piratage.

Figure V.4 : Protection de mot de passe avec le mcanisme de hachage

Projet de fin dtudes

Anne universitaire : 2010/2011

Tous les mots de passe sont hachs au niveau de base de donnes laide de lalgorithme MD5 qui est une fonction de hachage cryptographique qui permet d'obtenir pour chaque fichier, une empreinte numrique.

V.4.2. Autres choix technologiques


A fin de donner notre application un aspect convivial nous avons utilis la technologie jquery qui est une bibliothque JavaScript libre, qui permet, grce ses plugins, dintgrer bon nombres deffets assez poustouflants sur vos pages (x)HTML. (Voir chapitre III Etat de lart). Nous avons mis ce script dappel des plugins de jquery dans les pages HTML :

Figure V.5 : Script d'appel des plugins de jquery


Puis avons utilis ces plugins dans les animations :

Figure V.6 : Menu slider

V.5.

Diagramme de GANTT

Le diagramme de Gantt est un outil utilis (souvent en complment d'un rseau PERT) en ordonnancement et gestion de projet et permettant de visualiser dans le temps les diverses tches lies composant un projet (il s'agit d'une reprsentation d'un graphe connexe, valu et orient). Il permet de reprsenter graphiquement l'avancement du projet.

Projet de fin dtudes

Anne universitaire : 2010/2011

Cet outil rpond deux objectifs : planifier de faon optimale et communiquer sur le planning tabli et les choix qu'il impose.

Figure V.7 : Diagramme de GANTT

V.6.

Phase dimplmentation

Limplmentation de lapplication est une phase trs importante dans le cycle de vie dun projet. Et comme toute autre phase, cette tape est soumis des contraintes soit voqus dans les besoins fonctionnels et non fonctionnels au niveau de la Spcification (chapitre II) soit quils sont poss implicitement par les langages utilises ou explicitement de la part de notre responsable.

V.6.1.

Contraintes

Pour adapter le modle de conception au modle d'implmentation nous devons en premier lieu identifier les contraintes techniques avec lesquelles notre systme doit tre construit. L'implmentation doit rpondre des contraintes qui lui sont propres notamment le temps dimplmentation. - La modularit : Cest une approche structurante qui spare un logiciel en petites units qui, rassembles, composeront l'ensemble du logiciel.

Projet de fin dtudes

Anne universitaire : 2010/2011

- La portabilit : Cest la capacit du systme fonctionner plus ou moins facilement dans diffrents environnements d'excution. - La maintenabilit : Cest la capacit de pouvoir maintenir de manire cohrente et moindre cot certains composants de lapplication. Elle dsigne la capacit d'un systme tre simplement et rapidement rpar; et ainsi diminuer les temps d'interventions. La maintenabilit d'un systme est souvent caractrise lors de sa conception.

V.6.2.

Pratiques adoptes

Tout au long de la phase de ralisation, nous avons appliqu des diffrentes rgles et de techniques de codage : - Rgles de nommage : donner un nom explicite et facile retenir pour les noms des tables, des attributs, des packages, nom des mthodes... - Rgles de prsentation : commenter clairement tous modules au niveau de la base de donnes, le code de lapplication. - Rgles Syntaxique : vit les structures syntaxiques complexes qui rduisent la facilit de comprhension du code afin de rduire les risques de dysfonctionnement.

V.7.

Phase de tests et validation

Les tests et validations se sont drouls pratiquement tout au long du projet et se sont diviss en cinq parties : - Tests unitaires : Ces tests sont faits pour chaque fonction, ou avancement de travail, et sont raliss en premier lieu par le mme membre qui a ralis le travail, et par lautre membre en deuxime lieu et sont synthtiss dans un rapport de tests dans ltiquette de la version courante. Ce rapport contient les rsultats indsirables des tests ainsi que des remarques dordre gnral. - Tests dIntgration : Ces tests son effectus pour chaque page, module ou grande partie termine. Ils ont pour but de clore la partie en question et vrifier la compatibilit des diffrentes fonctions et modules. Les rsultats, ainsi que les remarques, sont mentionns dans un rapport de tests.

Projet de fin dtudes

Anne universitaire : 2010/2011

- Tests Alpha et Bta : Ces tests sont effectus lors de la fin de chaque module et la fin de toute lapplication. Ils sont aussi effectus en parallle et ont pratiquement le mme principe que les tests dintgration, sauf quils ont de plus une tendance sur les incommodassions de manipulation, linterface graphique (couleurs, textes, ) et sont effectus ensuite par les futurs utilisateurs. - Tests de fonctionnalits : Les tests de fonctionnalit ont pour objectif dune part de vrifier le bon fonctionnement de lapplication ainsi que la qualit de restitution des mdias sur diffrentes plates-formes matrielles (CPU, cartes graphiques, OS, Ram), et dautre part de dterminer ainsi la configuration minimale. - Tests de qualit : Par un parcours exhaustif du produit, chaque testeur met en vidence les problmes lis la restitution des mdias. Cela permet de sassurer que la configuration minimale a t correctement value. Images : rendu des couleurs. Textes : typographie, lisibilit.

V.7.1.

Jeux de tests et Validation

Suite la ralisation du travail demand, nous avons essay de faire le maximum de jeux de tests possibles permettant de valider notre application. Profile Administrateur Administrateur Administrateur Administrateur Administrateur Administrateur Administrateur Administrateur Administrateur Internaute, Client Internaute, Client Administrateur Administrateur Administrateur Administrateur Administrateur Administrateur Scnario Authentification pour au back-office Ajout dun nouveau produit Suppression dun produit Modification dun produit Ajout dune nouvelle marque Modification dune marque Suppression dune marque Consultation dun message de contact Suppression dun message de contact Lenvoi dun message de contact Inscription dans la newsletter Consultation des inscrits dans la newsletter Lenvoi dun mail aux inscrits dans la newsletter (mailing list). Suppression dun inscrit dans la newsletter Ajout dune nouvelle catgorie de newsletter Modification dune catgorie de newsletter Suppression dune catgorie de newsletter Validation OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK

Projet de fin dtudes

Anne universitaire : 2010/2011

Administrateur Administrateur Administrateur Administrateur Administrateur Administrateur Client Administrateur Administrateur Client Administrateur Administrateur Client Administrateur Administrateur Administrateur Client Administrateur Client Client Client Client

Ajout dun nouveau media (logo, bannire) Modification dun media (logo, bannire) Suppression dun media (logo, bannire) Ajout dun nouvel utilisateur (cre un compte) Modification dun utilisateur (login, mot de passe) Suppression dun utilisateur Inscription dans lespace membre Recherche des clients Consultation des clients Modification des informations concernant le client Consultation des factures Recherche des factures Ajout des factures Suppression des factures Consultation des commandes Recherche des commandes Confirmation de la commande Suppression des commandes Consultation des produits Recherche des produits Ajout dun produit au panier Mise jour du panier

OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK

Figure V.8 : Tableau jeux de tests et validation

V.8.

Conclusion

En dpit de certains problmes que nous avons rencontrs, nous avons pu les surmonter et raliser le travail qui nous a t propos, en outre nous avons acquis certains apports au cours de cette phase. En plus des nouvelles technologies de dveloppement des applications et la familiarisation avec certains logiciels, notamment en matire de maintenance du code, la ralisation de cette application nous a permis dacqurir une exprience concernant le processus de dveloppement.

Projet de fin dtudes

Anne universitaire : 2010/2011

Chapitre VI. Interfaces de lapplication


VI.1. Introduction
Dans ce chapitre, nous allons prsenter notre application travers quelques captures d'cran.

VI.2. Interfaces de lapplication


VI.2.1.
VI.2.1.1.

Back-office

Page dauthentification
Cette interface prsente un formulaire de connexion permettant l'utilisateur de

s'identifier avec un login et un mot de passe pour qu'il soit autoris accder au back-office du site.

Figure VI.1 : Page de connexion de lutilisateur

Projet de fin dtudes

Anne universitaire : 2010/2011

Lorsque le login ou le mot de passe est invalide, un message derreur sera affich lutilisateur :

Figure VI.2 : Message derreur lorsque le login ou le mot de passe est invalide

VI.2.1.2.

Session administrateur
Aprs avoir sauthentifier, ladministrateur sera redirectionn vers la page daccueil du

back-office :

VI.2.1.2.1.

Page daccueil du back-office


Elle contient un menu de navigation, composer de plusieurs rubriques permettant de

grer le contenu du site, le processus dachat, la relation avec les clients

Figure VI.3 : Page daccueil du back-office

VI.2.1.2.2. Page gestion des produits

Projet de fin dtudes

Anne universitaire : 2010/2011

Elle contient tous les produits offerts, cette page nous permet de grer les produits soit par la consultation, lajout, la modification, ou la suppression.

Figure VI.4 : Page gestion des produits

VI.2.1.2.3.

Page ajout dun nouveau produit (pop-up)


Pour ajouter un nouveau produit, on clique sur le bouton Ajout dun nouveau produit,

ensuite on saisie les informations ncessaire du produit puis on valide.

Figure VI.5: Page ajout dun nouveau produit

Projet de fin dtudes

Anne universitaire : 2010/2011

On a mis des contrles de saisie pour viter tout type derreurs (champs vide, informations erron.), lorsquon fait une erreur, un message dalerte saffiche et nous indique le type derreur.

Figure VI.6: Contrle de saisie dans lajout dun nouveau produit

VI.2.1.2.4.

Suppression dun produit

Pour supprimer un produit, on clique sur le bouton supprimer un produit, un message de confirmation sera afficher et nous demande de confirmer notre choix ou dannuler.

Figure VI.7 : Supprimer un produit

Projet de fin dtudes

Anne universitaire : 2010/2011

VI.2.2.

Front-office

VI.2.2.1 Page daccueil du front-office


Cette page est destiner aux clients et aux internautes, elle contient un moteur de recherche, un catalogue des produits offerts, un menu de navigation, les nouveauts dans chaque catgorie de produit, une newsletter, top des ventes, les offres spciales, un panier et les publicits.

Figure VI.8 : Page daccueil du back-office - Pour acheter un produit le client doit tout dabord choisir le produit dsir et lajouter au panier. Pour ajouter un produit au panier, il suffit de cliquer licne chariot.

Projet de fin dtudes

Anne universitaire : 2010/2011

Figure VI.9 : Ajout dun produit au panier - Avant dajouter un produit au panier, le client peut voir les dtails concernant le produit dsir. Pour voir les dtails dun produit il suffit de cliquer sur le lien plus de dtails.

Figure VI.10 : Page dtails dun produit

Projet de fin dtudes

Anne universitaire : 2010/2011

VI.2.2.2 Page gestion de panier


-Cette page est destine la gestion de panier, Le client peut ici grer son panier soit par la modification des quantits des produits acheter ou la suppression des produits.

Figure VI.11 : Page Gestion de panier - Aprs avoir grer son panier, le client peut valider ces achats, et il sera rdirectionner vers cette page ou il va sauthentifier sil est dj inscrit, sinon il doit sinscrire pour continuer le processus dachat.

Figure VI.12 : Page dauthentification

Projet de fin dtudes

Anne universitaire : 2010/2011

Figure VI.13 : Formulaires dinscription dun nouveau client

VI.2.2.3. Page choix de mthode dexpdition


- Aprs lauthentification le client sera rdirectionner vers la page choix de mthode dexpdition, ou il va choisir la mthode dont la quel le produit va tre expdi a lui.

Figure VI.14 : Page Choix de mthode dexpdition

Projet de fin dtudes

Anne universitaire : 2010/2011

- Dans la page choix de mthode dexpdition, le client a la possibilit de modifier ladresse dexpdition. Pour modifier ladresse dexpdition il suffit de cliquer sur le bouton changer dadresse.

Figure VI.15 : Formulaire de modification de ladresse dexpdition

VI.2.2.4. Page choix de mthode de payement


Aprs avoir choisir la mthode dexpdition le client sera rdirectionner vers la page choix de mthode de payement, dans cette page le client va choisir la mthode avec la quelle il va payer ces achats.

Projet de fin dtudes

Anne universitaire : 2010/2011

Figure VI.16 : Page Choix de mthode de payement

VI.2.2.5. Page confirmation commande


Dans cette page on trouve tout les dtails concernant la commande (Adresse du client, mthode dexpdition, les produits achets avec leurs quantits et leurs prix, le prix total des achats, mthode de payement, frais de livraison, montant payer). Il ne reste que la confirmation de la commande aprs avoir vrifier les dtails de la commande.

Projet de fin dtudes

Anne universitaire : 2010/2011

Figure VI.17 : Page confirmation de la commande

VI.2.2.6. Page de payement


Ds que le client confirme la commande, il est envoy vers le serveur de paiement SPS qui est un Systme de Paiement Scuris qui permet doffrir les autorisations sur les cartes bancaires, dans un environnement scuris. Toutes les cartes de paiement locales ou trangres sont acceptes.

Projet de fin dtudes

Anne universitaire : 2010/2011

Figure VI.18 : Page de payement

Projet de fin dtudes

Anne universitaire : 2010/2011

VI.3. Conclusion
Nous avons essay au cours de ce chapitre de vous prsenter les interfaces illustrant les diffrentes fonctionnalits fournies par notre projet. Pour assurer une meilleure qualit de notre travail et garantir sa fiabilit, nous tions amens augmenter le nombre de test, en prenant en compte le maximum de cas particulier, et en adaptant les diffrentes interfaces pour une utilisation gnral.

Projet de fin dtudes

Anne universitaire : 2010/2011

Conclusion Gnrale
Le projet que nous avons ralis a consist en la conception et le dveloppement dun site web marchand pour vente de matriel informatique en ligne rpondant, dune part, aux besoins de ce concept qui vient tout juste de faire son apparition dans notre march et dautre part, aux besoins dIMS. Entre les objectifs fixs, les attentes de la socit, nous avons, toutefois, russis atteindre nos principaux objectifs dont la ralisation dun site web marchand compose de plusieurs modules contenant les fonctionnalits ncessaires pour le bon droulement des diffrentes gestions ct client (panier, commande, profils, ) et ct marchand (administration, produits, catalogue, marques, medias ). Le dernier mot est consacr pour dire que notre parcours durant ce projet nous a retourn plus davantages que dinconvnients en nous rapprochant de lenvironnement professionnel et en faisant connaissance avec ses acteurs. Ceci dit, nous souhaitons que notre travail puisse tre un une contribution au dveloppement du concept e-commerce.

Perspectives :
Nous tenons prciser que durant tout le projet, on avait cherch dtailler et perfectionner notre travail. Toutefois, des amliorations peuvent bien tre rajoutes par exemple : - Comparateur de prix. - Module de produit similaire. - Dveloppement dun module de payement. - Statistiques.

Projet de fin dtudes

Anne universitaire : 2010/2011

Glossaire
AJAX ASP CSS CMS CPU CRM DAO DOM DTO ERP GPL HTML HTTP IHM MIT PERT PHP RAM SGBD SGBDR SSII SQL TIC UML VB script WAMP WML
Asynchronous JavaScript and XML. Active Server Pages. Cascading Style Sheets. Content management system. Central processing unit. Customer relationship management. Data access object. Document Object Model. Data transfer object. Enterprise resource planning. General Public License. HyperText Markup Language. Hypertext Transfer Protocol. Interface homme-machine. Massachusetts Institute of Technology. Program Evaluation and Review Technique. Hypertext Preprocessor. Random-access memory. Systme de Gestion de Bases de Donnes. Systme de Gestion de Bases de Donnes Relationnelles. Socit de services et dingnierie informatique. Structured Query Language. Technologies de l'information et de la communication. Unified Modeling Language. Visual Basic script. Windows, Apache, MySQL, and PHP. Wireless Markup Language.

Projet de fin dtudes

Anne universitaire : 2010/2011

Bibliographie et Ntographie
- Bibliographie :
[B1] : Modlisation des donnes et notation UML, Bruno Cremilleux et Jacque Madelaine, Universit de Caen Basse-Normandie (mars 2010).

- Ntographie :
[N1] : (Jeff, Prsentation du HTML, octobre 2008) www.commentcamarche.net/ /contents/html/htmlintro.php3 [N2] : (Jeff, Introduction PHP, avril 2009) www.commentcamarche.net /contents/php/phpintro.php3. [N3] : (Jeff, Feuilles de style, mars 2011) www.commentcamarche.net/contents/css/cssintro.php3 [N4]: (Nariman Mohammed, Dreamweaver 8, October 2005) www.slideserve.com/presentation/54984/Dreamweaver-8 [N5]: (Paul Dubois, Stefan Hinz, Carsten Pedersen, MySQL - Guide official, 2004) fr.wikipedia.org/wiki/MySQL [N6] : (damien, WAMP serveur, november 2008) www.6ma.fr/tuto/wamp+server+0-454 [N7]: (EDrawSoft, Edraw Max, mars 2011) windows.podnova.com/trends/edraw_max_home_network.html [N8]: (jolie, Prsentation de Photoshop, septembre 2009) gass.forumgratuit.fr/t17presentation-photoshop [N9] : (Paoh, Prsentation de GanttProject, juin 2010) www.framasoft.net/article2071.html

Projet de fin dtudes

Anne universitaire : 2010/2011

Annexe A
Langages
1. HTML
Le HTML ( HyperText Mark-Up Language ) est un langage dit de marquage (de structuration ou de balisage ) dont le rle est de formaliser l'criture d'un document avec des balises de formatage. Les balises permettent d'indiquer la faon dont doit tre prsent le document et les liens qu'il tablit avec d'autres documents. Le langage HTML permet notamment la lecture de documents sur Internet partir de machines diffrentes, grce au protocole HTTP, permettant d'accder via le rseau des documents reprs par une adresse unique, appele URL. On appelle World Wide Web (not WWW) ou tout simplement Web (mot anglais signifiant toile) la "toile virtuelle" forme par les diffrents documents (appels pages web ) lis entre eux par des hyperliens. Les pages web sont gnralement organises autour d'une page d'accueil, jouant un point central dans la navigation l'aide des liens hypertextes. Cet ensemble cohrent de pages web lies par des liens hypertextes et articules autour d'une page d'accueil commune est appele site web. Le Web est ainsi une norme archive vivante compose d'une myriade de sites web proposant des pages web pouvant contenir du texte mis en forme, des images, des sons, des vido, etc. [N.1]

2. PHP
PHP est un langage interprt (un langage de script) excut du ct serveur (comme les scripts CGI,ASP, ...) et non du ct client (un script crit en JavaScript ou une applet Java s'excute sur votre ordinateur...). La syntaxe du langage provient de celles du langage C, du Perl et de Java. Ses principaux atouts sont : Une grande communaut de dveloppeurs partageant des centaines de milliers d'exemples de script PHP ; La gratuit et la disponibilit du code source (PHP est distribu sous licence GNU GPL) ; La simplicit d'criture de scripts ;

69

Projet de fin dtudes

Anne universitaire : 2010/2011

La possibilit d'inclure le script PHP au sein d'une page HTML (contrairement aux
scripts CGI, pour lesquels il faut crire des lignes de code pour afficher chaque ligne en langage HTML) ;

La simplicit d'interfaage avec des bases de donnes (de nombreux SGBD sont
supports, mais le plus utilis avec ce langage est MySQL, un SGBD gratuit disponible sur de nombreuses plateformes :Unix, Linux, Windows, MacOs X, Solaris, etc...) ;

L'intgration au sein de nombreux serveurs web (Apache, Microsoft IIS, etc.). [N.2] 3. CSS
Le concept de feuilles de style est apparu en 1996 avec la publication par le W3C d'une nouvelle recommandation intitule Cascading StyleSheets (feuilles de style en cascade), note CSS. Le principe des feuilles de style consiste regrouper dans un mme document des caractristiques de mise en forme associes des groupes d'lments. Il suffit de dfinir par un nom un ensemble de dfinitions et de caractristiques de mise en forme, et de l'appeler pour l'appliquer un texte. Il est ainsi possible de crer un groupe de titres en police Arial, de couleur verte et en italique. Les feuilles de style ont t mises au point afin de compenser les manques du langage HTML en ce qui concerne la mise en page et la prsentation. En effet, le HTML offre un certain nombre de balises permettant de mettre en page et de dfinir le style d'un texte, toutefois chaque lment possde son propre style, indpendamment des lments qui l'entourent. Grce aux feuilles de style, lorsque la charte graphique d'un site compos de plusieurs centaines de pages web doit tre change, il suffit de modifier la dfinition des feuilles de style en un seul endroit pour changer l'apparence du site tout entier ! Elles sont appeles feuilles de style en cascade (en anglais Cascading Style Sheets ) car il est possible d'en dfinir plusieurs et que les styles peuvent tre hrits en cascade. Les feuilles de style permettent notamment : d'obtenir une prsentation homogne sur tout un site en faisant appel sur toutes les pages une mme dfinition de style ; de permettre le changement de l'aspect d'un site complet entier par la seule modification de quelques lignes ; une plus grande lisibilit du HTML, car les styles sont dfinis part ;

70

Projet de fin dtudes

Anne universitaire : 2010/2011

des chargements de page plus rapides, pour les mmes raisons que prcdemment ;

un positionnement plus rigoureux des lments. [N3]

Editeur web

1. Dreamweaver 8
Il est un diteur HTML dvelopp par Macromedia. Il tait l'origine destin aux concepteurs de sites Web professionnels et offre un systme de montage qui combine la fois la productivit de la conception WYSIWYG avec le contrle du mode d'dition de code HTML. Cette combinaison a t tout fait unique en fin des annes 1990 et a aid Dreamweaver une adoption gnralise. Dreamweaver peut masquer les dtails du code HTML page de l'utilisateur, ce qui permet aux non-experts de crer facilement des pages web et de sites Permet aux utilisateurs de rcuprer la plupart des navigateurs installs sur son ordinateur vers des sites de prvisualisation. Permet aux utilisateurs de se connecter aux bases de donnes (comme MySQL) pour filtrer et afficher du contenu en utilisant les technologies de scripts tels que PHP, ASP, ASP.net et, sans aucune exprience de programmation prcdente. [N4]

SGBD
1. MYSQL
MySQL est un systme de gestion de base de donnes (SGBD). Selon le type d'application, sa licence est libre ou propritaire. Il fait partie des logiciels de gestion de base de donnes les plus utiliss au monde, autant par le grand public (applications web principalement) que par des professionnels, en concurrence avec Oracle et Microsoft SQL Server. [N5]

Serveur

71

Projet de fin dtudes

Anne universitaire : 2010/2011

1. WAMPSERVER
WampServer est une plate-forme de dveloppement Web sous Windows. Il vous permet de dvelopper des applications Web dynamiques l'aide du serveur Apache2, du langage de scripts PHP et d'une base de donnes MySQL. Il possde galement PHPMyAdmin et SQLite Manager pour grer plus facilement vos bases de donnes. [N6]

Autres
Edraw max EDraw Max est un programme de diagramme et de prsentation destin aux tudiants
et aux professionnels. Avec elle, les utilisateurs peuvent crer n'importe quel type de dessins comme les organigrammes, diagrammes de rseau, des prsentations, des plans de construction, dessins de mode, des flux de travail, structures de programmes, UML, design web, l'ingnierie lectrique, des schmas de base de donnes, et plus encore. [N7]

Adope Photoshop CS5


Photoshop est un logiciel de retouche, de traitement et de dessin assist par ordinateur dit par Adobe. Il est principalement utilis pour le traitement de photographies numriques, mais sert galement la cration dimages ex nihilo (hors source photographique). Photoshop est un logiciel travaillant sur images matricielles (galement appeles "bitmap", ne pas confondre avec le format denregistrement Windows bitmap) car les images sont constitues dune grille de points appels pixels. Lintrt de ces images est de reproduire des graduations subtiles de couleurs. Photoshop possde son propre format de projet (PSD), qui est plus quun simple format de fichier. Le programme accepte galement dimporter et dexporter des fichiers dimage dans les formats les plus courants (GIF, JPEG, TIFF, PNG, ILBM, etc.). Il offre :

un systme de tri et dorganisation des fichiers permettant lapplication dune opration

sur plusieurs fichiers simultanment.

des outils de dessin en mode bitmap : pinceau, crayon, formes gomtriques

72

Projet de fin dtudes

Anne universitaire : 2010/2011

des outils de slection de zones de travail (ou zones dintrt) : lasso, rectangle de

slection, slection par plage de couleur

des outils de copie, collage et duplication de zones de travail des outils de manipulation de calques : par lempilement de zones graphiques et

lutilisation de transparence et autres effets, on peut construire lquivalent de photomontages complexes.

des outils de manipulation de la palette de couleurs : changement de palette, rglages

colorimtriques, de luminosit, de contraste, de saturation

des filtres pour appliquer divers effets des zones dintrt : textures, ombres,

renforcement des contours, estampage, flou, etc. [N8]

GANTT PROJECT
GanttProject est logiciel qui permet la planification de projets laide du diagramme de Gantt. Il propose les fonctionnalits de base de ce type doutil, comme la cration des tches, laffectation des ressources, la gestion des dpendances et de lavancement, mais dispose galement de proprits plus avances comme lexportation des documents en HTML/PDF et le travail collaboratif distance sur internet... [N9]

73

Vous aimerez peut-être aussi