Conception et développement d’une place de marché B2C

Introduction générale

Dédicace

Je dédie ce travail à mes parents, à ceux qui m’ont aidé pour atteindre ce niveau cognitif actuel, et finalement à tous ceux qui m’aiment.

Nassim


2

Dédicace

Je dédie ce travail à mes parents, à ceux qui m’ont aidé pour atteindre ce niveau cognitif actuel, et finalement à tous ceux qui m’aiment.

Mohamed Salah


3

Remerciements

Nous adressons nos remerciements au centre de tri de la poste

tunisienne de nous avoir permis d’effectuer notre stage au sein du

service informatique.

Nous remercions plus particulièrement :

Les membres de jury qui ont accepté de juger ce travail.

Monsieur Malek Chouchan notre maître de stage pour ses

encouragement et de nous avoir fait confiance dans la réalisation de

ce projet.

Monsieur Mohamed Anis Bach Tobji et Madame Hadia Traoui nos

encadrant à l’ESCE pour leur encouragement qu’ils ont su nous

prodiguer pendant toute la durée de ce travail.

Nos remerciement s’adressent également au cadre de l’Ecole Supérieur

de Commerce Electronique qui nous ont accueilli et encadré et qui nous

ont fourni un environnement favorable pour accomplir ce travail.

Nassim & Mohamed


4

Table des matières Introduction générale. ...................................................................................................................... 1

Chapitre I : Étude de projet ........................................................................................................................... 3

Introduction ........................................................................................................................................ 3

I. présentation de l'organisme d'accueil ................................................................................................ 3

I.1 Présentation de l’office national des postes ....................................................................................... 3

I.2 Les services de la Poste tunisienne............................................................................................................ 4

I.3 Le réseau commercial de la Poste tunisienne………………………………………..……………………....5

II Le champ d’études………………………………………………….………………………………………….6

II.1 Le commerce électronique……………………………………………...…………………………………....6

II.1.1 Définition……………………………………………………………………………………………………6

II.1.2 Les différentes formes du commerce électronique……………………………………………………….6

II.1.3 Les atouts du commerce électronique…………………………………………………………………….7

II.2 Les place de marchés …………………………………………………………………………….……….….7

II.2.1 Définition …………………………………………………………………………………….….…………7

II.2.2 Fonctionnalités…………………………………………………………………………….…….………….7

II.3 L’E-logistique…...............................................................................................................................................7

II.4 Présentation du projet……………………………………………………………………………………….8

II.4.1 Présentation …………………………………………………………………………….……….…………8

II.4.2 La cible de notre projet……………………………………………………………………………………8

II.4.3 Apport du projet…………………………………………………………………………………………...9

III. Analyse de l’existant…………………………………………………………..………………………..…….9

III.1 Analyse de l’environnement……………………………………………………………………..…………9

III.1.1 Environnement concurrentiel :………………………………………...…………………………..…….9

III.1.2 La matrice SWOT……………………………………………………………………………….………11

IV. Cadre du projet……………………………………………………………………………………………..12

IV.1 Contexte du système…………………………………………………………………………………..…...12

IV.2 Contenue du système…………………………………………………………………………………..…..14

V. Méthodologie de conception……………………………………………………………………………..…..14


5

Conclusion………………………………………………………………………………………………………..15

Chapitre II : la phase d’incubation……………………………………………………………………………16

Introduction…………………………………………………………………………………………………….16

I Capture des besoins…………………………………………..……………………………………………….16

I.1 Les besoins fonctionnels……………………………………………………………………………………16

I.1.1 Besoins fonctionnels de l’internaute………………………………………………………….…………..16

I.1.2 Besoins fonctionnels du client…………………………………………………………………………..…16

I.1.3 Besoins fonctionnels de l’entreprise………………..…………………………………………………….17

I.1.4 Besoins fonctionnels de superviseur……………………………………………...………………………17

I.1.5 Besoins fonctionnels de l'administrateur……………………………………………..…………………..17

I.2 Les besoins non fonctionnels……………………………………………………………………………..….17

II. Le modèle initial des cas d'utilisation……………………………………………………………………….18

II.1 Diagramme des cas d'utilisations initiaux……………………………………………………………...….18

II.2 Planning de traitement des cas d'utilisation………………………………………….………………..….19

II.2.1 Priorités…………………………………..…………………………………………………………..……19

II.2.2 Risque……………………………………………………………………………………………...………19

II.2.3 Classement des cas d'utilisations……………………………………………………..………………….21

II.3 Description détaillés des cas d'utilisation initiaux………………………………...………………...…….22

II.3.1 Description détaillés des cas d'utilisation initiaux de l'internaute……………………………….…….22

II.3.2 Description détaillés des cas d'utilisation initiaux des clients……………………….…………..……..25

II.3.3 Description détaillés des cas d'utilisation initiaux de l'entreprise……………………………………..26

II.3.4 Description détaillés des cas d'utilisation initiaux du superviseur…………………………………....29

II.3.5 Description détaillés des cas d'utilisation initiaux de l'administrateur………………………………..30

III. Prototypes…………………………………………………………………...………………………...……..32

IV. Analyse des cas d'utilisation prioritaire…………………………………………………...……………….34

Iv.1 Analyse du cas d'utilisation "créer catégorie vitrine"………………………………….…………….….34

IV.1.1 Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "créer

catégorie vitrine " …………………………………………………………………………..……………...……34

IV.1.2 Digramme de classe du modèle d’analyse pour cas d’utilisation « créer

catégorie vitrine »…………………………………………………………………………..……………………35


6

IV.2 Analyse du cas d'utilisation 'créer catégorie produit"……………………………….…….……………36

IV.2.1 Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation 'créer catégorie produit"……………………………………………………………..………………………….……..36

IV.2.2 Diagramme de classe de modèle d'analyse de cas d'utilisation "Créer catégorie produit"………………………………………………………………………………………….....................….37

IV.3 Analyse du cas d'utilisation "créer catégorie vitrine"………………………………………………..….37

IV.3.1 Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour les cas d'utilisation "créer vitrine"……………………..…………………………………………………………………………….37

IV.3.2 Diagramme de classe de modèle d'analyse pour le cas d'utilisation "créer vitrine"……………………………………………………………………………………………………...……38

IV.4 Analyse du cas d'utilisation "authentification"…………………………..…………………………...…39

IV.4.1 Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "authentification"……………………………………………………………………………………………….39

IV.4.2 Diagramme de classe du modèle d'analyse pour le cas d'utilisation "authentification" ……………………………………………………………………………………………………………..……..40

Conclusion……………………………………………………………………………………………………….40

Chapitre III : la phase d’élaboration………………………………………………………………………….41

Introduction………………………………………………………………..…………………………………….41

I. capture des besoins secondaires……………………………………………………………………………...41

I.1 Les besoins secondaires de l'internaute…………………………...………………………………………..41

I.2 Les besoins secondaires de l'entreprise……………………………………………………………………..41

I.3 Les besoins secondaires de l'administrateur………………………...…………………………………..…41

I.4 Les besoins secondaires du superviseur….…………………………………………………………………42

I.5 Les besoins secondaire du client…………………………………….………………………………………42

I.6 Les besoins d l'unité commerciale…………………………………….…………………………………….42

II. Le modèle final des cas d'utilisation………………………………………………………………………..42

II.1 Diagramme de cas d'utilisation final………………………………………………………………………42

II.2 Description détaillé des cas d'utilisation secondaire…………………..………………………………….42

II.2.1 Description des cas d'utilisation de l'internaute……………………..………………………………….42

II.2.2 Description des cas d'utilisation de l'entreprise………………………..……………………………….42

II.2.3 Description des cas d'utilisation du superviseur………………………..………………………………45

II.2.4 Description des cas d'utilisation de l'administrateur……………………….…………………………..45


7

II.2.5 Description des cas d'utilisation du client…………………………………...…………………………..47

II.2.6 Description des cas d'utilisation de l'unité commercial………………………..……………………….47

III. Analyse de cas d'utilisation secondaire…………………………………………………………………….48

III.1 Analyse du cas d'utilisation "consulter la liste des vitrines"…………………….……………………...48

III.1.1 Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "consulter

la liste des vitrines "……………………………..………………………………………………………………48

III.1.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation " consulter liste des vitrines "…………………………………………………………………………………………………………49

III.2 Analyse du cas d’utilisation "ajouter un produit "……………………………………………………..50

III.2.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation " ajouter un produit "…………………………………………………………………………………………….………..50

III.2.2 Diagramme de classe du modèle d’analyse du cas d’utilisation " ajouter un produit "………..…...50

III.3 Analyse du cas d’utilisation « supprimer un produit »……………………………………….…………51

III.3.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation "supprimer un produit "…………………………………………………………………………….………….51

III.3.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation " supprimer un produit "…...51

III.4 Analyse du cas d’utilisation " modifier un produit "……………………………………………..……..52

III.4.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation " modifie

un produit "………………………………………………………………………………………….…………..52

III.4.2 Diagramme de classe du modèle d’analyse du cas d’utilisation " modifier un produit "…….…….52

III.5 Analyse du cas d’utilisation " valider/annuler un produit "……………………………………………53

III.5.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation " valider/annuler un produit "………………………………………………………………………………….53

III.5.2 Diagramme de classe du modèle d’analyse du cas d’utilisation « annuler/valider un produit »………………………………………………………………………………………………………….53

III.6 Analyse du cas d’utilisation " créer compte "…………………...………………………………………54

III.6.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation " créer

compte "……………………………………………………………...…………………………………………..54

III.6.2 Diagramme de classe du modèle d’analyse du cas d’utilisation " créer compte "……...…………..55

III.7 Analyse du cas d’utilisation " consulter liste des produit "…………………………………………….55

III.7.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation " consulter liste des produit "…………………………………………………..………………………………55


8

III.7.2 Diagramme de classe du modèle d’analyse du cas d’utilisation " consulter liste des produit "………………………………………………………………………………………………...………..56

III.8 Analyse du cas d’utilisation " remplir le panier "……………………..………………………………...57

III.8.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation " remplir le panier "…………………….……………………………………………………..……………………………57

III.8.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation " remplir le panier "…………………………………………………………………………………………………………..57

III.9 Analyse du cas d’utilisation " consulter liste des client inscrit "……………………………………….58

III.9.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation " consulter liste des clients inscrit……………..………………………………………………………………..58

III.9.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation " consulter liste des clients ….59

III.10 Analyse du cas d’utilisation « consulter le panier »………………………………………..…………..59

III.10.1 Traçabilité entre le diagramme de cas d’utilisation et le modèle d’analyse du cas d’utilisation « consulter le panier »………………………………………………………...…………………………………59

III.10.2 Diagramme de classe du modèle d’analyse du cas d’utilisation « consulter le panier »……...……60

III.11 Analyse du cas d’utilisation « supprimer un produit du panier »……………………………...……..60

III.11.1 Traçabilité entre le modèle de cas d’utili0sation et le modèle d’analyse du cas d’utilisation « supprimer un produit du panier »………………………………………………….………………………..60

III.11.2 Diagramme de classe du modèle d’analyse du cas d’utilisation « supprimer un produit du panier »………………………………………………………………………………………………………..…61

III.12 Analyse du cas d’utilisation « modifier quantité du produit »………………………………………..62

III.12.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « modifier quantité du produit »……………………………………………………………….………………62

III.12.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation « modifier quantité du produit »………………………………………………………………………………………………………….62

III.13 Analyse du cas d’utilisation « vider le panier »………………………...………………………………63

III.13.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « vider le panier »…………………………………………………………………..………………....................63

III.13.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation « vider le panier »…………………………………………………………………………………………………………...64

III.14 Analyse du cas d’utilisation " passer une commande "…………………….………………………….65

III.14.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation " passer une commande "……………………………………………………..………………………………..65

III.14.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation « passer une commande »………………………………………………………………………………………………….…..65


9

III.15 Analyse du cas d’utilisation « consulter les commande »………………………...……………………66

III.15.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « consulter les commandes »…………………………………………………………………………………….66

III.15.2 Digramme de classe du modèle d’analyse pour le cas d’utilisation « consulter les commandes »………………………………………………………………………………………………….…67

III.16 Analyse du cas d’utilisation « payer la commande »…………………………………..………………68

III.16.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « payer la commande »…………………………………………………………………………………………68

III.16.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation « payer la commande »……………………………………………………………………………………………………..68

III.17 Analyse du cas d’utilisation « faire une recherche rapide »………………………….……………….69

III.17.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « faire une recherche rapide »…………………..……………………………………………………………...69

III.17.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation « faire une recherche rapide »………………………………………………………………………………………………………..…70

III.18 Analyse du cas d’utilisation « faire une recherche avancée »……………..…………………………..71

III.18.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « faire une recherche avancée »………………………………………...………………………………………71

III.18.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation « faire une recherche avancée »…………………………………………………………………………………………………………71

III.19 Analyse du cas d’utilisation « ajouter superviseur »………………...…………………………………72

III.19.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « ajouter superviseur »……………………………..…………………………………………………………...72

III.19.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation « ajouter un superviseur »……………………………………………………………………………………………………..73

III.20 Analyse du cas d’utilisation « supprimer un superviseur »……………..……………………………..73

III.20.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « supprimer superviseur »………………………….……………………………………………………...........73

III.20.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation « supprimer superviseur »……………………………………………………………………………………………………..74

III.21 Analyse du cas d’utilisation « consulter les unités commerciales »……….…………………………..74

III.21.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « consulter les unités commerciales »……………………..……………………………………………………74

III.21.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation « consulter les unités

commerciales »…………………………………...………………………………………………………………75


10

III.22 Analyse du cas d’utilisation « ajouter unité commerciale »………………….………………………..75

III.22.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « ajouter unité commerciale »…………………………………..………………………………………………75

III.22.2 Diagramme de classe du modèle d’analyse du cas d’utilisation « ajouter unité commerciale »……………………………………………………………………………………………….…...76

III.23 Analyse du cas d’utilisation « collecter commande »…………………………………………………..76

III.23.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « collecter comman………………………………………………………………………………………………76

III.23.2 Diagramme de classe du modèle d’analyse pour le cas d’utilisation « collecter commande »…………………………………………………………………………………………………..….77

IV Conception ……………………..……………………………………………………………………………77

IV.1 Conception des cas d’utilisations prioritaires……………………………………...…………………….78

IV.1.1 Diagramme de séquence du cas d’utilisation « créer catégorie produit »……………………………78

IV.1.2 Diagramme de séquence du cas d’utilisation « authentification »……………………..……………..80

IV.1.3 diagramme de séquence du cas d’utilisation « créer vitrine »…………………………..…………….80

IV.2 Conception des cas d’utilisations secondaires ……………………….…………………………………..82

IV.2.1 Diagramme de séquence du cas d’utilisation « créer compte »…………………………...…………..82

IV.2.2 Diagramme de séquence du cas d’utilisation « ajouter un produit »………………………..………..83

IV.2.3 Diagramme de séquence du cas d’utilisation « modifier un produit »……………………….………84

IV.2.4 Diagramme de séquence du cas d’utilisation « supprimer un produit »……………………………..85

IV.2.5 Diagramme de séquence du cas d’utilisation « consulter liste des vitrines »…………………….…..85

IV.2.6 Diagramme de séquence du cas d’utilisation « valider/annuler un produit »………………………..86

IV.2.7 Diagramme de séquence du cas d’utilisation « consulter liste des commande »………………….….87

IV.2.8 Diagramme de séquence du cas d’utilisation « ajouter superviseur »…………………….………….88

IV.2.9 Diagramme de séquence du cas d’utilisation « supprimer superviseur »……………………………89

IV.2.10 Diagramme de séquence du cas d’utilisation « remplir le panier »…………………….…………...90

IV.2.11 Diagramme de séquence du cas d’utilisation « mise à jour du panier »………………….…………91

IV.2.12 Diagramme de séquence du cas d’utilisation « vider le panier »…………………..…….…………..92

IV.2.13 Diagramme de séquence du cas d’utilisation « passer une commande »………………….….……..94

IV.2.14 Diagramme de séquence du cas d’utilisation « payer la commande »…………….……….………..95


11

IV.2.15 Diagramme de séquence du cas d’utilisation «collecter commande»…………………….…………96

Conclusion………………………………………………………………………………………………………..96

Chapitre VI : Phase de construction……………………………………………………………………….97

Introduction…………………………………….……………………………………………………………….97

I Modélisation de la navigation………………………………………………………………………………...97

I.1 Diagramme d’activité de navigation pour l’internaute et le client ………………………………………97

I.2 Diagramme d’activité de navigation pour l’administrateur et le superviseur …………………...…….100

I.3 Diagramme d’activité de navigation pour l’entreprise ………………………..………………………...100

II. Diagramme de classe global………………………………….…………………………………………….101

III. Traitement des méthodes………………………………………………………………………………….104

IV. Implémentation………………………………..…………………………………………………………...106

IV.1 Base de données…………………………………………..………………………………………………106

IV.1.1 Règles de passage du modèle conceptuel vers le modèle logique ……………………………………106

IV.1.2 Schéma final de la base de données ……………………………………….…………………………..109 IV.2 Implémentation………………………………………………………………..………………………….113 IV.2.1 Environnement de développement…………………………………………………………………….113 IV.2.2 Diagramme de déploiement………………………….………………………………………………...113

V. Les tests……………………………………………………...………………………………………………114

V.1 Principe………………………………………………..…………………………………………………...114

V.2 Construction des jeux de tests………………………………………………………….…………………114 V.2.1 Test du cas d’utilisation « imprimer étiquette »………………………………………….....................115

V.2.2 Test du cas d’utilisation « supprimer un produit »…………………………………...……………….116

V.2.3 Test des cas d’utilisation « ajouter un produit » et « valider un produit »…………………….…….117

Conclusion et perspectives …………………………………………………………………………………….120

Bibliographie……………………………………………………………………………………………………122

Webographie……………………………………………………………………………………………………122

Annexe A………………………………………………………………………………………………………..123

I. Le processus unifié……………………………………………………………………………………..…….123

I.1 définition ……………………………………………………………………………………………………123

I.2 Caractéristique du processus unifié……………………………………………………………...………..123

I.2.1 Le processus unifié est itératif…………………………………………………………………….……..123


12

I.2.2 Le processus unifié est centré sur l’architecture……………………………………………..…………124

I.2.3 Le processus unifié est piloté par le cas d’utilisation…………………………………………………...124

I.3 les différentes phases du processus unifié ………………………………………………………...………124

II. UML (Unified Modeling Language)…………………………………………………………………...…..125

II.1 Definition……………………………………………………………………………………………..…….125

II.2 Différent diagrammes UML………………………………………………………………………………125

Annexe B…………………………………………………………………………………..……………………128

I .Netbeans………………………………………………………………………………………………………128

II PHP5………………………………………………………………………………………………………….128

II.1.Présentation……………………………………………………………………………..…………………128

II.2.Fonctionnement …………………………………………………………………………………….……..129

III.Jquery……………………………………………………………………………………………………….130

IV. Oracle……………………………………………………………………………………………………….131

IV.1.Présentation……………………………………………………………………………………………….131

IV.2.Fonctionnalités……………………………………………………………………………………………132


13

Table de figure

Figure 1 : Les services de la poste tunisienne ......................................................................................9 Figure 2: Le réseau commercial de la poste ....................................................................................... 10 Figure 3 : interface du site "www.placedumarche.fr" ......................................................................... 14 Figure 4 : interface du site "www.multistore.biz" .............................................................................. 14 Figure 5 : interface du site "www.multistore2002.info" ..................................................................... 15 Figure 6: Relation entre les différents acteurs .................................................................................... 23 Figure 7 : diagramme des cas d'utilisation initiaux ............................................................................. 24 Figure 8: prototype interface authentification du back-office ............................................................. 37 Figure 9: prototype interface gestion des superviseurs ....................................................................... 37 Figure 10: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour les d'utilisation "créer catégorie vitrine" .................................................................................................................... 39 Figure 11: diagramme de classe du modèle d'analyse pour le cas d'utilisation "créer catégorie vitrine" ......................................................................................................................................................... 39 Figure 12: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "créer catégorie produit" ................................................................................................................... 40 Figure 13: diagramme de classe du modèle d'analyse du cas d'utilisation "créer catégorie produit" .... 41 Figure 14: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "créer vitrine" ................................................................................................................................... 42 Figure 15: diagramme de classe du modèle d'analyse pour les cas d'utilisation "créer vitrine" ............ 42 Figure 16: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "authentification" .............................................................................................................................. 43 Figure 17: diagramme de classe du modèle d'analyse pour le cas d'utilisation "authentification" ........ 44 Figure 18 : diagramme de cas d'utilisation final ................................................................................. 48 Figure 19: traçabilité entre le modèle d'analyse et le modèle de cas d'utilisation pour le cas d'utilisation "consulter la liste des vitrines" .......................................................................................................... 53 Figure 20: diagramme de classe du modèle d'analyse pour le cas d'utilisation "consulter liste des vitrines" ............................................................................................................................................ 53 Figure 21: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "ajouter un produit" .......................................................................................................................... 54 Figure 22: diagramme de classe du modéle d'analyse du cas d'utilisation "ajouter un produit"............ 54 Figure 23: traçabilité entre le modéle de cas d'utilisation et le modéle d'analyse du cas d'utilisation "supprimer un produit" ...................................................................................................................... 55 Figure 24: diagramme de classe du modéle d'analyse pour le d'utilisation "supprimer un produit" ...... 55 Figure 25: traçabilité entre le diagramme de cas d'utilisation et le modéle d'analyse du cas d'utilisation "modifier un produit" ........................................................................................................................ 56 Figure 26: diagramme de classe du modèle d'analyse du cas d'utilisation "modifier un produit" ......... 56 Figure 27: Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "valider/annuler un produit" .............................................................................................................. 57


14

Figure 28: diagramme de classe du modèle d'analyse du cas d'utilisation "annuler/valider un produit" ......................................................................................................................................................... 58 Figure 29: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "créer compte" .................................................................................................................................. 58 Figure 30: diagramme de classe du modèle d'analyse du cas d'utilisation "créer compte" ................... 59 Figure 31: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "consulter liste des produit" .............................................................................................................. 60 Figure 32: diagramme de classe du modèle d'analyse du cas d'utilisation "consulter liste des produits" ......................................................................................................................................................... 60 Figure 33:traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "remplir le panier" ............................................................................................................................ 61 Figure 34: diagramme de classe du modèle d'analyse du cas d'utilisation "remplir le panier" ............. 62 Figure 35: traçabilité entre le modèle de cas d’utilisation et le modèle d'analyse du cas d'utilisation "consulter liste des clients inscrits".................................................................................................... 62 Figure 36: diagramme de classe du modèle d'analyse du cas d'utilisation "consulter liste des clients inscrits" ............................................................................................................................................ 63 Figure 37: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "consulter le panier" .......................................................................................................................... 63 Figure 38: diagramme de classe du modèle d'analyse du cas d'utilisation "consulter le panier" ........... 64 Figure 39: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "supprimer un produit du panier" ...................................................................................................... 65 Figure 40: diagramme de classe du modèle d'analyse pour le cas d'utilisation "supprimer un produit du panier" .............................................................................................................................................. 65 Figure 41: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "modifier quantité du produit" ........................................................................................................... 66 Figure 42: diagramme de classe du modèle d'analyse pour le cas d'utilisation "modifier quantité du produit" ............................................................................................................................................ 67 Figure 43: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "vider le panier" ................................................................................................................................ 68 Figure 44: diagramme de classe du modèle d'analyse pour le cas d'utilisation "vider le panier" .......... 68 Figure 45: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "passer une commande" .................................................................................................................... 69 Figure 46: diagramme de classe du modèle d'analyse du cas d'utilisation "passer une commande" ..... 70 Figure 47: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "consulter les commandes" ............................................................................................................... 71 Figure 48: diagramme de classe du modèle d'analyse pour le cas d'utilisation "consulter les commandes" ..................................................................................................................................... 71 Figure 49: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "payer la commande" ........................................................................................................................ 72 Figure 50: diagramme de classe du modèle d'analyse pour le cas d'utilisation "payer la commande" .. 73 Figure 51: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "faire une recherche rapide" .............................................................................................................. 74 Figure 52: diagramme de classe du modèle d'analyse pour le cas d'utilisation "faire une recherche rapide" .............................................................................................................................................. 74


15

Figure 53: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "faire une recherche avancée" ........................................................................................................... 75 Figure 54: diagramme de classe du modèle d'analyse pour le cas d'utilisation "faire une recherche avancée" ........................................................................................................................................... 76 Figure 55: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "ajouter un superviseur" .................................................................................................................... 77 Figure 56: diagramme de classe du modèle d'analyse pour le cas d'utilisation "ajouter un superviseur" ......................................................................................................................................................... 77 Figure 57: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "supprimer un superviseur" ............................................................................................................... 78 Figure 58: diagramme de classe du modèle d'analyse pour le cas d'utilisation "supprimer un superviseur" ...................................................................................................................................... 78 Figure 59: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "consulter les unités commerciales " ................................................................................................. 79 Figure 60: diagramme de classe du modèle d'analyse pour le cas d'utilisation "consulter les unités commerciales" .................................................................................................................................. 79 Figure 61: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "ajouter unité commerciale" .............................................................................................................. 80 Figure 62: diagramme de classe du modèle d'analyse pour le cas d'utilisation "ajouter unité commerciale" .................................................................................................................................... 80 Figure 63 : traçabilité entre le mdèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "collecter commande" ....................................................................................................................... 81 Figure 64 : diagramme de classe du modèle d'analyse pour le cas d'utilisation "collecter commande" 81 Figure 65: diagramme de séquence du cas d'utilisation "créer catégorie produit" ............................... 83 Figure 66: diagramme de séquence du cas d'utilisation "authentification" .......................................... 84 Figure 67: diagramme de séquence du cas d'utilisation "créer vitrine" ............................................... 85 Figure 68: diagramme de séquence du cas d'utilisation "créer compte" .............................................. 86 Figure 69: diagramme de séquence du cas d'utilisation "ajouter un produit" ....................................... 87 Figure 70: diagramme de séquence du cas d'utilisation "modifier un produit" .................................... 88 Figure 71: diagramme de séquence du cas d'utilisation "supprimer un produit" .................................. 89 Figure 72: diagramme de séquence du cas d'utilisation "consulter liste vitrines" ................................ 90 Figure 73: diagramme de séquence du cas d'utilisation "valider/annuler un produit" .......................... 91 Figure 74: diagramme de séquence du cas d'utilisation "consulter liste commande" ........................... 92 Figure 75: diagramme de séquence du cas d'utilisation "ajouter superviseur" ..................................... 93 Figure 76: diagramme de séquence du cas d'utilisation "supprimer un superviseur" ........................... 94 Figure 77: diagramme de séquence du cas d'utilisation "remplir le panier"......................................... 95 Figure 78: diagramme de séquence du cas d'utilisation "mise à jour du panier" .................................. 96 Figure 79: diagramme de séquence du cas d'utilisation "vider le panier" ............................................ 97 Figure 80: diagramme de séquence du cas d'utilisation "passer une commande" ................................ 98 Figure 81: diagramme de séquence du cas d'utilisation "payer la commande" .................................... 99 Figure 82 : diagramme de séquence du cas d'utilisation "collecter commande" ................................ 100 Figure 83: diagramme d'activité de navigation du cas d'utilisation" remplir le panier" ...................... 102 Figure 84: diagramme d'activité de navigation du cas d'utilisation "passer une commande" ............. 103 Figure 85: diagramme d'activité de navigation pour l'administrateur et le superviseur ...................... 104 Figure 86: diagramme d'activité de navigation pour l'entreprise ....................................................... 105


16

Figure 87 : diagramme de classe global ........................................................................................... 106 Figure 88: règle 1 du passage du modèle conceptuel vers le modèle logique .................................... 111 Figure 89:règle 2 du passage du modèle conceptuel vers le modèle logique ..................................... 112 Figure 90: règle 3 du passage du modèle conceptuel vers le modèle logique (premier cas) ............... 112 Figure 91: règle 3 du passage du modèle conceptuel vers le modèle logique (deuxième cas) ............ 113 Figure 92: règle 3 du passage du modèle conceptuel vers le modèle logique (troisième cas) ............ 113 Figure 93: règle 3 du passage du modèle conceptuel vers le modèle logique (quatrième cas) ........... 114 Figure 94: diagramme de déploiement ............................................................................................. 119 Figure 95: imprimer étiquette .......................................................................................................... 120 Figure 96: étiquette de la commande ............................................................................................... 120 Figure 97: supprimer un produit ...................................................................................................... 121 Figure 98: produit supprimé ............................................................................................................ 121 Figure 99: ajouter un produit ........................................................................................................... 122 Figure 100: produit en attente.......................................................................................................... 123 Figure 101: valider un produit ......................................................................................................... 123 Figure 102: produit valide ............................................................................................................... 124 Figure 103 : les phases du processus unifié...................................................................................... 130 Figure 104 : historique d'UML ........................................................................................................ 131 Figure 105 : fonctionnement de PHP5 ............................................................................................. 135 Figure 106 : jquery.......................................................................................................................... 135


17

Liste des tableaux

Tableau 1 : Analyse SWOT............................................................................................................... 13 Tableau 2 : Tableau des priorités des cas d’utilisations ...................................................................... 22 Tableau 3 : description textuelle du cas d'utilisation "remplir le panier" ............................................. 23 Tableau 4 : description textuelle du cas d'utilisation "consulter le panier" .......................................... 23 Tableau 5 : description textuelle du cas d'utilisation "supprimer un article du panier" ........................ 24 Tableau 6 : description textuelle du cas d'utilisation "modifier la quantité d'un article" ...................... 24 Tableau 7 : description textuelle du cas d'utilisation "vider le panier" ................................................ 25 Tableau 8 : description textuelle du cas d'utilisation "créer compte" .................................................. 25 Tableau 9 : description textuelle du cas d'utilisation "passer une commande"..................................... 26 Tableau 10 : description textuelle du cas d'utilisation "payer la commande" ...................................... 27 Tableau 11 : description textuelle du cas d'utilisation "ajouter produit" .............................................. 27 Tableau 12 : description textuelle du cas d'utilisation "supprimer produit" ......................................... 28 Tableau 13 : description textuelle du cas d'utilisation "modifier un produit" ...................................... 29 Tableau 14 : description textuelle du cas d'utilisation "consulter les commandes" .............................. 29 Tableau 15 : description textuelle du cas d'utilisation "consulter statistique" ...................................... 29 Tableau 16 : description textuelle du cas d'utilisation "valider/annuler produit" ................................. 30 Tableau 17 : description textuelle du cas d'utilisation "consulter liste des vitrines"............................. 30 Tableau 18 : description textuelle du cas d'utilisation "consulter liste des clients" .............................. 30 Tableau 19 : description textuelle du cas d'utilisation "consulter liste des produits"............................ 31 Tableau 20 : description textuelle du cas d'utilisation "consulter les commandes" .............................. 31 Tableau 21 : description textuelle du cas d'utilisation "créer catégorie vitrine" ................................... 32 Tableau 22 : description textuelle du cas d'utilisation "créer catégorie produit" .................................. 32 Tableau 23 : description textuelle du cas d'utilisation "créer vitrine" .................................................. 33 Tableau 24 : description textuelle du cas d'utilisation "authentification" ............................................ 33 Tableau 25 : description textuelle du cas d'utilisation "faire une rechercher rapide" ........................... 44 Tableau 26 : description textuelle du cas d'utilisation "faire une recherche avancé"............................ 44 Tableau 27 : description textuelle du cas d'utilisation "faire une demande de collecte" ....................... 44 Tableau 28 : description textuelle du cas d'utilisation "imprimer éthiquette" ...................................... 46 Tableau 29 : description textuelle du cas d'utilisation "consulter la statistique" .................................. 46 Tableau 30 : description textuelle du cas d'utilisation "consulter liste des unités commerciales" ......... 46 Tableau 31 : description textuelle du cas d'utilisation "ajouter une unité commerciale" ...................... 47 Tableau 32 : description textuelle du cas d'utilisation "ajouter un superviseur" .................................. 47 Tableau 33 : description textuelle du cas d'utilisation "supprimer un superviseur" ............................. 48 Tableau 34 : description textuelle du cas d'utilisation "consulter historique de commande" ................ 48 Tableau 35 : description textuelle du cas d'utilisation "collecter commande" ..................................... 49 Tableau 36 : description des méthodes de la classe "categorie_produit" ........................................... 105 Tableau 37 : description des méthodes de la classe "categorie_vitrine" ............................................ 105 Tableau 38 : description des méthodes de la classe "commande" ..................................................... 106 Tableau 39 : description des méthodes de la classe "entreprise" ....................................................... 106 Tableau 40 : description des méthodes de la classe "panier" ............................................................ 106 Tableau 41 : description des méthodes de la classe "produit" ........................................................... 106


18

Tableau 42 : description des méthodes de la classe "promotion" ...................................................... 107 Tableau 43 : description des méthodes de la classe "service" ........................................................... 107 Tableau 44 : description des méthodes de la classe "vitrine" ............................................................ 107 Tableau 45: table « COMPTE_USER » ........................................................................................... 110 Tableau 46 : table « CLIENT » ....................................................................................................... 111 Tableau 47 : table « ENTREPRISE » ............................................................................................. 111 Tableau 48 : Table « SUPERVISEUR » .......................................................................................... 111 Tableau 49 : Table « VITRINE » .................................................................................................... 111 Tableau 50 : Table « CATEGPRIE_VITRINE » ............................................................................. 112 Tableau 51 : Table « PRODUIT » ................................................................................................... 112 Tableau 52 : Table « CATEGPRIE_PRODUIT » ........................................................................... 112 Tableau 53 : Table « PROMOTION » ............................................................................................. 112 Tableau 54: Table « PANIER » ....................................................................................................... 112 Tableau 55 : Table « PRODUIT_PANIER » .................................................................................. 112


19


Durant les dernières années, on entend souvent parler du commerce électronique qui

occupe une place très importante dans le web.

Ce nouveau concept se caractérise par la gestion des flux tendus c'est-à-dire qu’une

commande client déclenche une commande fournisseur ce qui permet de minimiser les coûts

relatifs aux stockages. En effet, le commerce électronique présente plusieurs enjeux. Nous

pouvons citer à titre d’exemple, le manque de confiance dans les moyens de paiement

électronique, aussi le manque de confiance dans les produits vendus sur internet qui peuvent

être de mauvaise qualité et le plus grand enjeu qui reste se matérialise dans les retards de

livraison voire même la non-livraison à cause des systèmes d’E-logistique non efficace.

Généralement, dans le monde, les solutions E-commerce restent limitées principalement dans

les secteurs B2B1 et qui se matérialise dans l’EDI2, les extranets et les places de marchés. Ces

derniers se présentent comme des sites portails où ils mettent en relation les acteurs

économiques (acheteurs, vendeurs) en ligne afin de communiquer et de négocier pour

conclure leurs transactions commerciales. Un nouveau concept est né avec l’émergence du

commerce électronique dans les pays développés, c’est l’one-stop shopping qui désigne

l’achat de différents produits d’une même place.

C’est dans ce cadre que la poste tunisienne souhaite développer une place de marché B2C qui

présente une nouvelle approche du concept des places de marché traditionnelles, puisque cette

dernière ne concerne pas le domaine des professionnels (B2B) mais elle s’adresse au simple

consommateur, dans le but de développer leurs activités en premier lieu et d’intégrer le

concept du commerce électronique dans l’économie nationale dans le second.

Notre mémoire, qui traitera le projet décrit ci-dessus, se compose essentiellement de quatre

chapitres :

1 B2B : Business To Business, c’est un terme qui désigne le commerce inter-entreprise 2 EDI : Echange des Données Informatisées


20

Le premier chapitre « Etude de projet » traitera la présentation de l’organisme d’accueil, le

cadre de notre projet, l’analyse de l’environnement concurrentiel, et une présentation brève de

la méthodologie de développement.

Le second chapitre est consacré à « la phase d’incubation », où nous traiterons surtout les

besoins, et donc les fonctionnalités de notre application, formalisées en cas d’utilisation.

Le troisième chapitre est réservé à « la phase d’élaboration ». Il comporte les cas

d’utilisations secondaires ainsi que leurs descriptions textuelles, suivis par leurs conceptions.

Le dernier chapitre étudiera « la phase de construction ». C’est la phase qui comporte la

structure finale de notre système, le diagramme de classe ainsi que les tests.

Chapitre I : Etude du projet

21

Chapitre I : Étude du projet

Introduction

« Un projet est un effort complexe pour atteindre un objectif bien spécifique, devant

respecter un échéancier et un budget… » Celand et King (1983)

L’étude du projet est une démarche stratégique qui permet d’assurer le bon déroulement de

toutes les phases qui constituent un projet. Cette étude fera l’objet de notre premier chapitre

où nous allons consacrer la première section pour la présentation de l’organisme qui nous a

accueillis pour le stage de fin d’études. Ensuite dans les sections suivantes nous allons faire

une étude de l’existant, et nous finissons par la problématique et le cadre de notre stage.

I. Présentation de l’organisme d’accueil I.1. Présentation de l’office national des postes Notre stage a été effectué au sein du centre de Tri Tunis Carthage qui présente une filiale de

l’office National des Postes. Dans une première partie nous intéresserons à la présentation

l’office National des postes ensuite nous allons présenter l’organisme qui nous a accueillis.

D’abord, nous allons commencer par quelques dates clés dans l’évolution de cette

organisation :

1847 : création de la première distribution des Postes à Tunis.

Juillet 1888 : création de l'Office tunisien des Postes et des Télégraphes et émission du

premier timbre-poste Tunisien

27 mai 1918 : ouverture du service des Comptes courants postaux en Tunisie.

Mars 1968 : cette date présente le premier pas de la poste tunisienne dans le domaine de

la technologie avec introduction de l'informatique dans la post

juin 1998 : promulgation du Code de la Poste réglementant l'exercice de l'activité postale

et création de l'Office National des Postes, dénommé « La Poste tunisienne », sous la

forme d'une entreprise publique à caractère industriel et commercial doté de

L’autonomie financière et de la personnalité morale (démarrage de son activité le 1er janvier

1999).


22

2000 : la poste a lancé la première monnaie électronique tunisienne « E-Dinar » avant de

lancer dans la même date son portail sous l’adresse www.poste.tn

2008 : Lancement de la carte à puce E-Dinar SMART qui répond à la norme EMV3.

I.2. Les services de la Poste tunisienne

La poste tunisienne met à la disposition de ses clients, particuliers ou entreprises, divers

produits et services. D'abord, elle assure la collecte, le transport et la distribution des courriers

via ses différents services de distribution qui se matérialisent dans la lettre recommandée, le

Rapide Poste et les colis postaux. En outre, la poste offre à ses clients l’opportunité d’ouvrir

des comptes d’épargne, de les suivre en ligne aussi que le transfert d’argent au niveau national

et international à grâce a ses différents partenaires financiers qui sont : Western Union,

Money Gram et IFS4.

Cependant, les services de la poste ne s’arrêtent pas au niveau des prestations financières,

mais elles s’étirent pour atteindre la vente des timbres postaux, les bouquets de fleurs

naturelles, des cartes de vœux, cartes postales et même les billets de matchs de Football et des

festivals...

La figure 1 présente la part des différents services, postaux et financiers, dans le chiffre

d’affaires pour l’année 2009.

3 EMV : une norme qui a été mise en place par Eurocard, VisaCard et MasterCard et qui permet d’offrir une sécurisation et une fiabilité à la transaction électronique. Cette norme se matérialise généralement par l’adoption des cartes à puces. 4 IFS : international Financial system.


23

Figure 1 : Les services de la poste tunisienne

I.3. Le réseau commercial de la Poste tunisienne

La poste tunisienne dispose d’un réseau commercial largement étendu et qui couvre tout le

territoire tunisien dans toutes ses régions et ses zones urbaines et rurales. Cet organisme a

consacré beaucoup d’efforts dans la création des nouveaux bureaux de poste dans les zones

qui sont caractérisées par une forte concentration démographique dans le but d’améliorer ses

services et de mieux se rapprocher des citoyens.

Le nombre de bureaux de postes et d’agences spécialisées a atteint 1088 bureaux et agence

au cours de l’année 2009 ce qui a contribué à la couverture postale pour atteindre en moyenne

1 point de contact pour 7100 habitants.

La figure 2 présente le réseau commercial de la poste


24

Figure 2: Le réseau commercial de la poste

II. Le champ d’études II.1. Le commerce électronique

II.1.1. Définition

Le commerce électronique (souvent appelé E-commerce) est un terme qui désigne

l’ensemble des transactions commerciales effectuées sur des réseaux électroniques notamment

internet. La plus part du temps, il s’agit des ventes des biens ou des services sur internet.

Selon l’OMC5 (1998) le commerce électronique peut-être défini comme suit : « Le commerce

électronique désigne la production, la distribution, le marketing, la vente ou la livraison des

marchandises et la présentation de services par voie électronique ».

II.1.2. Les différentes formes du commerce électronique

Il existe plusieurs formes du commerce électronique, parmi lesquelles nous pouvons citer à

titre d’exemple :

B2B (Business To Business) :c’est le commerce interentreprises entre professionnels

B2C (Business To Customer) : englobe les transactions entre les entreprises et les

particuliers, cette forme du E-commerce se matérialise généralement dans les sites web

marchands 5 OMC : Organisation Mondiale de Commerce


25

C2C (Customer To Customer) : ce sont les transactions entre des particuliers

II.1.3. Les atouts du commerce électronique Le commerce électronique offre plusieurs avantages aux entreprises qu’aux clients, nous

pouvons citer :

Une meilleure flexibilité puisqu’internet offre aux cyberconsommateurs un accès 24/24 et

7/7

La suppression des intermédiaires traditionnelle entre les clients et les fournisseurs ce qui

permet de réduire les coûts et les prix des produits.

La rapidité de collecter des informations et à moindre coût.etc

II.2. Les places de marchés [1] II.2.1. Définition

Une place de marché est un site portail destiné au commerce interentreprises qui permet aux

plusieurs acheteurs et vendeurs de collaborer, négocier et conclure des transactions

commerciales.

II.2.2. Fonctionnalités

Les places de marchés offrent aux entreprises diverses fonctionnalités. Nous pouvons citer :

Les appels d’offres

Les enchères inversées6

Les achats sur catalogue

Les espaces de travail collaboratif

Certaines places de marché proposent des fonctionnalités d’E-procurement7 aux entreprises

qui n’en sont pas équipées en interne.

II.3. L’E-logistique

L’E-logistique représente l’évolution de la logistique traditionnelle afin de répondre aux

besoins des clients qui sont devenus de plus en plus exigeants. L’E-logistique vise à maîtriser

la gestion des stocks, de l’expédition, du service après-vente et des flux de retour.

6 Enchères en ligne qui consistent à donner la possibilité à un acheteur internaute de fixer un prix d'achat servant de base à la recherche du vendeur souhaitant vendre à ce prix [2] 7 E-procurement : c’est l’approvisionnement en ligne


26

La maitrise de l’E-logistique est souvent complexe et nécessite une stratégie claire et efficace.

II.4. Présentation du projet

II.4.1. Présentation

Notre travail consiste à concevoir et développer une place de marché destiné au grand public.

Contrairement aux places de marché traditionnelles, notre portail se spécialise dans le

commerce entre des entreprises et des particuliers dans le but de développer l’esprit d’achat

sur internet pour les simples consommateurs. Le concept de notre projet est assez simple

puisqu’il joue le rôle d’un portail qui met en relation les entreprises avec une grande masse de

clients. Ce dernier est composé de plusieurs vitrines dont chacune est relative à une entreprise

qui sera responsable de la gérer suite à un contrat avec la poste. Les objectifs de ce projet se

résume dans un premier lieu dans l’incitation des entreprise tunisienne a implémenter une

solution E-commerce afin d’augmenter leurs rentabilité et d’élargir leurs champ d’activité. En

outre la poste tunisienne cherche à rester le leader dans le domaine du commerce électronique

en Tunisie par l’investissement dans ce type de projet.

II.4.2. La cible de projet

La cible est la population que l’on souhaite toucher lors d’une action commerciale ou

marketing. La cible peut être constituée de clients ou prospects [3].

Notre portail touche deux catégories comme cibles. La première présente les entreprises que

nous pouvons les classer sur trois positions.

Dans la première position nous trouvons les entreprises qui ne possédant pas encore des sites

web marchand et qui souhaitent implémenter une solution de E-commerce.

Dans la deuxième position viennent les entreprises qui ont une expérience dans l’E-commerce

et qui souhaitent élargir leur champ d’activité et découvrir des nouveaux marchés.

La dernière position est occupée par les entreprises qui possèdent aussi une expérience dans le

commerce électronique mais qui souffle d’un système d’E-logistique peu adapté et qui opte

pour une utilisation plus efficace.

La deuxième cible de notre portail est les particuliers


27

II.4.3. Apport du projet

Ce projet a plusieurs apports pour les entreprises, les clients, la poste tunisienne et l’Etat.

Pour les entreprises : découvrir des nouveaux marchés et acquérir plusieurs clients

Pour les clients : augmenter leur rentabilité d’achat grâce à la suppression de

l’intermédiaire classique et les prix qui sont moins chère.

Pour la poste : augmenter leurs profils par la location des vitrines et les frais de transports

Pour l’Etat : développement et intégration du commerce électronique dans l’économie de

l’Etat

III. Analyse de l’existant III.1. Analyse de l’environnement

III.1.1. Environnement concurrentiel

« La concurrence est la situation dans laquelle les organisations sont en compétition les

unes avec les autres sur un même terrain d'échange qui peut être le marché (concurrence

directe) ou différents terrains (concurrence indirecte), entre secteurs (concurrence

intersectorielle) ou au sein même d'un secteur (concurrence intra sectorielle). »[4]

Elle se décompose en deux types : en local et à l’étranger. Nous étudions en premier lieu la

concurrence en local.

Concurrence locale

En Tunisie, jusqu'à ce jour, il n’existe aucune place de marché destiné pour le B2C8. En effet,

il n’existe aucun concurrent pour notre portail

Concurrence à l’étranger

A l’étranger, plusieurs portail de ce type existe sur le marché, nous pouvons citer par exemple

www.placedumarche.fr qui exerce ses activités en France et qui est spécialiser dans les

produits alimentaires. Cette dernière présente une filiale de www.toupargel.fr

8 B2C : Business To Customer est un terme qui désigne la vente des produits ou des services aux particuliers


28

Figure 3 : interface du site "www.placedumarche.fr"

Nous pouvons citer aussi http://www.multistore.biz/ qui est dédié pour la vente des produits

de la nouvelle technologie et présente les produits relatif à plusieurs fournisseur, à titre

d’exemple HP, DELL et ACER …

Figure 4 : interface du site "www.multistore.biz"


29

En fin le meilleur exemple qui peut refléter l’orientation notre portail est

http://www.multistore2002.info qui présente différents catégories de produits concernant

plusieurs fournisseurs.

Figure 5 : interface du site "www.multistore2002.info"

III.2. La matrice SWOT

« L'analyse SWOT (Strengths – Weaknesses – Opportunities – Threats) ou AFOM (Atouts –

Faiblesses – Opportunités – Menaces) est un outil d'analyse stratégique. Il combine l'étude des

forces et des faiblesses d'une organisation, d’un territoire, d’un secteur, etc. avec celle des

opportunités et des menaces de son environnement, afin d'aider à la définition d'une stratégie

de développement. »[5]

Le but de cette matrice est la prise en compte des facteurs internes et externes de l’entreprise

lors de le construction de sa stratégie afin d’anticiper tout résultat inattendu. Ansi, l’analyse

SWOT se présente comme suit :

Positive Négative

Interne Diversification des produits offerts

Paiement assuré par le serveur de

nouveau sur le marché


30

paiement sécurisé de la poste

Un système d’E-logistique très

performant

La possibilité de one stop

shopping

Externe augmentation du nombre

d’internaute

diversification des cartes bancaires

et des solutions de paiement en

ligne

encouragement de l’Etat par

l’investissement dans les nouveaux

projets

La méfiance des internautes

auprès des moyens de paiement

en ligne

Tableau 1 : Analyse SWOT

IV. Cadre du projet IV.1. Contexte du système

Notre portail peut être découpé en trois modules :

La gestion des vitrines

Après la conclusion d’un contrat écrit avec la poste tunisienne, l’entreprise obtient un espace

back-office qui lui permet de gérer ses propres vitrines.

Chaque entreprise est responsable de gérer ses vitrines, elle va faire la mise à jour des

produits, la suppression des produits, la consultation des statistiques et l’ajout de nouveaux

produits. À noter que cette dernière action ne peut se faire qu’avec la confirmation du

superviseur de la poste.

Exemple : une entreprise X ajoute un produit Y via l’interface d’administration de sa vitrine.

Ce produit reste dans un état « en attente » jusqu’à la confirmation ou l’annulation de l’ajout

auprès du superviseur de la poste. Une fois le superviseur valide ou annule l’ajout du

(des)produit(s) un mail sera envoyé à l’entreprise pour l’informer.


31

Le site va être composé de plusieurs catégories, chaque catégorie est composée de plusieurs

vitrines où chacune est relative à une entreprise. Enfin, chaque vitrine regroupe plusieurs

produits.

Exemple : On a une liste de catégories : produits alimentaires, produits cosmétiques, produits

électroniques…etc. Dans la catégorie de produits électroniques, on trouve une liste de vitrine :

vitrine de Sony, vitrine de Toshiba, vitrine d’HP…etc. Dans la vitrine de Toshiba, on trouve

un ensemble de produits : PC, Télévision, Home Cinéma, DVD…etc. Chaque produit est

représenté par son nom, son prix, une description…etc.

La gestion des commandes

Le client passe une commande sur le MarketPlace auprès de plusieurs entreprises et en

contrepartie les entreprises vont lui fournir le produit commandé via la poste. Le client ne

peut avoir qu’un seul panier et ce panier va être décomposé en sous-ensembles de

commandes, qui vont être passées aux entreprises correspondantes. Lors du remplissage du

panier, il faut vérifier que le poids des différents articles relatifs à un seul vendeur (vitrine) ne

dépasse pas 30Kg (la taille maximale de la commande).

Exemple : Un client passe une commande qui contient du yaourt auprès de « Délice », un

DVD auprès de « Sony » et du shampoing et gel doux auprès de « Souplesse ». Tous ces

produits vont être payés ensemble dans une seule commande puis cette dernière va être

décortiquée en trois sous commandes : une pour « Délice », une pour « Sony » et une pour «

Souplesse ».

Lorsque l’entreprise reçoit la commande qui lui concerne, elle doit la préparer. La préparation

de la commande se fait en lui donnant un numéro d’envoi qui dépend de la méthode de

livraison de la commande. Ensuite l’entreprise devra imprimer l’étiquette qui contient les

informations sur la commande et la coller sur elle. Enfin, l’entreprise a le choix soit de

prendre la commande vers le centre commercial avec laquelle elle est contractée, soit de faire

une demande de collecte.

La gestion de la livraison

Après la phase d’envoi des commandes aux différentes entreprises concernées, la Poste

tunisienne est chargée d’acheminer les commandes du fournisseur vers le consommateur final

via leurs unités commerciales qui sont contractées avec les entreprises. Chaque unité

commerciale possède un certain nombre de tournées qui sont dédiées pour la livraison dans


32

des différents types de voies. Par exemple nous avons une tournée X qui ne livre que dans les

rue dont le numéro est pair et qui commence par 2 et se termine par 40, aussi une tourné Y qui

ne livre que dans les avenues dont le numéro est impair et qui commence par 1 et se termine

par 37.

Lorsque l’entreprise fait une demande de collecte pour une commande, un message sera

envoyé à un facteur, qui est employé d’une tournée, selon l’adresse de la vitrine.

IV.2. Contenu du système

Notre système se compose principalement par quatre parties. La première partie constitue le

front-office du portail. C’est la partie visible par le simple client et qui lui permet de naviguer

dans les différentes vitrines et de passer par la suite des commandes.

La deuxième partie constitue l’espace entreprise. C’est un espace d’administration des vitrines

et il est restreint aux entreprises qui sont contractées avec la poste.

La troisième partie est la back-office pour le superviseur et l’administrateur et qui permet de

gérer toute la place de marché.

La dernière partie de notre portail est un espace réservé aux unités commerciales de la poste

qui sont chargées par l’E-logistique de notre place de marché et de l’acheminement des

commandes vers leurs destinations

V. Méthodologie de conception

Pour la conception de notre système nous avons choisi UML comme langage de modélisation.

Notre choix s’est basé principalement sur les points forts que présente ce langage. UML est

un langage formalisé et standard qui joue le rôle d’un support de communication performant

puisqu’il facilite la compréhension des représentations complexe. Bien entendu UML n’est ni

une méthode, ni un processus, c’est pour cette raison que nous sommes obligés de choisir une

méthodologie de conception. Parmi les méthodologies existantes nous pouvons citer le

processus unifié, la méthode agile et l’extrême programming qui sont les plus connus. Pour

notre cas, la méthodologie la plus adaptée à notre système est le processus unifié qui est

itératif et incrémental, il permet de définir des objectifs a court terme (des objectifs pour une

itération) ce qui permet d’accélérer le rythme de développement ainsi, il permet de minimiser

les risques dès le départ.


33

Cependant, pour des contraintes de temps nous avons préféré s’inspirer du processus unifié, et

non l’appliquer intégralement, puisque son application consomme beaucoup de ressources

temporelles et humaines.

Conclusion

Dans ce chapitre, nous avons présenté le cadre, le contexte du projet ainsi que l’organisme

d’accueil. Dans le chapitre suivant, nous allons entamer la première phase du processus

unifié afin de mieux cerner la problématique posée.

Chapitre II : La phase d’incubation

34


Introduction

L’incubation est la première phase dans le cycle de développement d’une application via le

processus unifié. Elle sert à comprendre le contexte du système, préciser les différents acteurs

et identifier les cas d’utilisations initiaux.

En effet, durant cette phase de développement nous allons essayer de spécifier le plus grand

nombre de besoins et de les modéliser tout en précisant les risques majeurs.

I. Capture des besoins I.1. Les besoins fonctionnels

Les besoins fonctionnels expriment une action que doit effectuer le système en réponse suite

à une demande (sorties qui sont produites pour un ensemble donné d’entrées)[6]. Dans cette

section nous allons classer les besoins par acteur.

I.1.1. Besoins fonctionnels de l’internaute Remplir son panier : l’internaute doit posséder le droit de remplir son panier en y ajoutant

des articles tout en précisant la quantité voulu

Créer un compte : pour devenir par la suite un client et avoir la possibilité de passer des

commandes l’internaute doit créer son compte. En fournissant les informations

nécessaires, un mail de validation sera envoyé pour sa boite mail.

Faire la mise à jour de son panier : après l’ajout des articles dans son panier, l’internaute

doit être capable de la mise à jour en modifiant la quantité d’un produit, de le supprimer

ou même de vider complètement son panier.

I.1.2. Besoins fonctionnels du client Passé une commande : une fois que son panier n’est pas vide le client peut passer des

commandes sur notre site.

Payer la commande : pour que la commande soit enregistrée le client doit la payer.


35

I.1.3. Besoins fonctionnels de l’entreprise Gérer ses vitrines : la gestion des vitrines se fait par l’ajout, la suppression ou la

suppression des produits. Aussi l’entreprise a la possibilité de mettre des produits en

promotion en précisant la date de début et la date de fin.

Gestion des commandes : l’entreprise peut accéder aux différentes commandes qui

concernent ses vitrines.

Consulter les statistiques de ses vitrines : afin de donner une vue globale sur la rentabilité

de ses vitrines, un module de statistique est proposé au entreprise qui leurs permet de

vérifier l’état de leurs vitrines et de leurs produits.

I.1.4. Besoins fonctionnels du superviseur Consulter la liste des produits : le superviseur est capable de consulter la liste des produits

valides ou en attentes de validation.

Valider ou annuler les nouveaux produits ajoutés : après la consultation des produits en

attente, le superviseur peut soit annuler ou valider un produit ajouté après la vérification

de certaines informations.

Consulter liste des vitrines : afin d’avoir une idée sur les vitrines inscrites sur notre portail

le superviseur peut afficher les informations relatives à chaque vitrine

Consulter liste des clients inscrits

Consulter les commandes passées et vérifier leur état

I.1.5. Besoins fonctionnels de l’administrateur Créer des catégories de vitrines : l’administrateur doit posséder le droit de créer des

catégories de vitrines.

Créer des catégories de produits

Créer des vitrines

I.2. Les besoins non fonctionnels Les besoins non fonctionnels sont des besoins qui ont un aspect visible par l’usager, mais

qui ne sont pas reliés directement avec le comportement du système. Pour notre système, ces

besoins peuvent être décrits comme suit :

Besoins de disponibilité : en effet, vu que notre système est une place de marché, c'est-à-

dire qu’il présente la vente des produits en ligne, il est indispensable que ce dernier soit

disponible 7j/7j et 24h/24h pour que les clients puissent réaliser leurs achats à tout

moment.


36

Besoins d’utilisabilité : Comme il est le cas pour tous les sites web, notre système doit

prendre en compte les aspects généraux de l’interface utilisateur, d’une part l’ergonomie

web et d’autre part la facilité de navigation sur le site.

II. Le modèle initial des cas d’utilisations

Dans cette section nous présentons les besoins de notre application de manière formelle,

c'est-à-dire à l’aide du diagramme de cas d’utilisation du langage de modélisation UML. Il

s’agit du diagramme de cas d’utilisation initiale.

II.1. Diagramme des cas d’utilisations initiaux

« La technique des cas d’utilisation est la pierre angulaire de cette étape. Elle va nous

permettre de préciser l’étude du contexte fonctionnel du système, en décrivant les différentes

façons qu’auront les acteurs d’utiliser le futur système. »9

Avant de passer à la représentation du diagramme de cas d’utilisation initial (voir figure 2),

et pour faciliter sa compréhension et le rendre plus lisible, nous schématisons dans la figure 3

la relation entre les différents acteurs du système. Nous pouvons présenter les acteurs de notre

système comme suit :

Internaute : est l’acteur le plus général, qui peut être un simple visiteur du site.

Client : c’est un internaute qui possède un compte et qui a le droit de passer des

commandes et de les payer

Responsable entreprise : c’est un individu qui est chargé de gérer ses propres vitrines

après avoir inscrit.

Superviseur : c’est un employé de la poste dont ses tâches résident dans la consultation de

quelques informations et la validation des produits ajoutés par les responsables

d’entreprises.

Administrateur : c’est aussi un employé de la poste et ses tâches résident dans la gestion

du back-office du site et la modification de système.

9 Pascal Rocques & Franck Vallée. UML en action de l’analyse des besoins à la conception en java. 2è édition, 2003.


37

Figure 6: Relation entre les différents acteurs

II.2. Planning de traitement des cas d’utilisation

II.2.1. Priorité

Le choix du niveau de priorités dans cette section est imposé par l'entreprise d'accueil pour

des raisons d'administrations. Généralement, un cas d’utilisation A est prioritaire, si sa

réalisation accélère la stabilisation du système.

II.2.2. Risque

L'identification des risques critiques est une étape indispensable lors du développement

d'une application avec le processus unifié. En effet, il existe deux types de risques qui peuvent

nous empêcher de réaliser la totalité de notre projet.

Risques techniques : en faite, nous sommes novices avec le processus unifié qui présente

le risque le plus majeur vu la complexité de son exécution et son ambiguïté.

Risques non techniques : ces risques sont liés principalement à la durée du stage qui

semble très courte par rapport à la complexité du projet et à notre état d’avancement.

Internaute

ClientSuperviseurEntreprise

Administrateur


38

Figure 7 : diagramme des cas d'utilisation initiaux

Clientinterface commande

ctr_commande

commande

sous_commande


39

II.2.3. Classement des cas d’utilisation

Dans cette section un tableau des priorités est dressé pour classifier dans l’ordre les cas

d’utilisations tout en tenant compte de leurs priorités et leurs risques estimés

Cas d’utilisation Priorités Risques

Créer catégorie vitrine

Créer catégorie produit

Créer vitrine

Authentification

Consulter liste des vitrines

Gérer les vitrines

Valider/annuler un produit

Créer compte

Consulter liste des produits

Remplir le panier

Consulter liste des clients

Consulter le panier

Mise à jour du panier

Passer une commande

Consulter les commandes

Payer la commande

Consulter statistiques

Elevé

Elevé

Elevé

Elevé

Elevé

Elevé

Elevé

Moyenne

Moyenne

Moyenne

Moyenne

Faible

Faible

Faible

Faible

Faible

Faible

Faible

Faible

Faible

Faible

Faible

Faible

Faible

Faible

Faible

Moyen

Moyen

Faible

Faible

Moyen

Moyen

Fort

Fort

Tableau 2 : Tableau des priorités des cas d’utilisations

Le processus unifié incite les développeurs à commencer par l’analyse, la conception et

l’implémentation des cas d’utilisation les plus risqués et les plus prioritaires, afin de réduire

dés le départ les risques majeurs qui menacent la faisabilité du système. Or, nous sommes à

notre premier PFE10. Etant donné que nous sommes novices avec le processus unifié et le

langage de programmation (le PHP5), nous allons commencer par les cas d’utilisation les plus

prioritaires et les moins risqués ce qui nous permettra de découvrir les outils de conception,

ainsi que le langage de programmation pas à pas.

10 PFE :projet de fin d’étude


40

Bref, nous allons commencer par la conception et l'implémentation des cas d'utilisation

suivant : « créer catégorie vitrine», « créer catégorie produit », « créer vitrine », « créer

vitrine » et « authentification » qui ont une priorité élevée et un risque faible.

II.3. Description détaillée des cas d’utilisation initiaux

II.3.1. Description des cas d’utilisations initiaux de l’internaute Cas d’utilisation « Remplir le panier » :

Cas d’utilisation : Remplir le panier

Acteurs principaux: Internaute

Pré-condition : NEANT

Post-condition : Produit ajouté dans le panier

Scénario nominal : 1-l’internaute sélectionne le produit et l’ajoute au panier en

précisant la quantité

2-le produit est ajouté au panier

Scénario alternatif : 2a-le produit existe dans le panier

2a-1-la quantité du produit est mise à jour

2a-la quantité du stock est insuffisante

2a-1-le système affiche un message de type « quantité

insuffisante »

Tableau 3 : description textuelle du cas d'utilisation "remplir le panier"

Cas d’utilisation « consulter le panier » :

Cas d’utilisation : consulter le panier



Post-condition : Le panier détaillé est affiché

Scénario nominal : 1-l’internaute demande l’affichage de son panier

2-le système affiche le panier détaillé

Scénario alternatif : 2a-le panier est vide

2a-1-le système affiche un message de type « votre panier est

vide »

Tableau 4 : description textuelle du cas d'utilisation "consulter le panier"


41

Cas d’utilisation « mise à jour du panier» :

Le cas d’utilisation « mise à jour du panier » englobe 3 sous cas d’utilisation qui peuvent

êtres décomposés comme suit :

Supprimer un article du panier

Cas d’utilisation : Supprimer un article

Acteurs : Internaute

Pré-condition : Le Panier n’est pas vide

Post-condition : Le produit est supprimé

Scénario nominal : 1-l’internaute clique sur le bouton de suppression

2-le système affiche un message de confirmation

3-l’internaute confirme son choix

4-le système affiche le panier mis à jour

Tableau 5 : description textuelle du cas d'utilisation "supprimer un article du panier"

Modifier la quantité d’un article:

Cas d’utilisation : Modifier la quantité


Pré-condition : Le produit existe dans le panier

Post-condition : Quantité mise à jour

Scénario nominal : 1-l’internaute modifie la quantité et valide

2-le système vérifie la quantité saisie

3-le système affiche le panier mis à jour

Scénario alternatif : 2a-la quantité saisie est égal à 0

4a-1-le système supprime l’article concerné

4a-2-retour à l’étape 3 du scénario nominal

2b-la quantité saisie supérieure au stock

4b-1-le système affiche un message de type « quantité

insuffisante »

Tableau 6 : description textuelle du cas d'utilisation "modifier la quantité d'un article"


42

vider le panier :

Cas d’utilisation : Vider le panier


Pré-condition : Le panier n’est pas vide

Post-condition : Le panier est vide

Scénario nominal : 1-l’internaute clique sur le bouton « vider »

2-le système affiche un message de vérification

3-l’internaute valide son choix

4-le système affiche un message de type « votre panier est vide »

Scénario alternatif 4a-l’internaute annule son choix de vider le panier

4a-1-le système affiche les détails du panier

Tableau 7 : description textuelle du cas d'utilisation "vider le panier"

Cas d’utilisation « créer compte » :

Cas d’utilisation : Créer compte


Pré-condition : Pas de pré-condition

Post-condition : Internaute possède un compte

Scénario nominal : 1-l’internaute saisit ses informations et valide

2-le système vérifie les données saisies

3-le système envoie un mail de validation pour l’internaute

4-l’internaute clique sur le lien de validation

5-le système enregistre l’internaute

Scénario alternatif : 2a-l’internaute saisit des informations manquantes

2a-1-le système affiche un message d’erreur


2b-l’adresse mail saisie existe déjà

2b-1-le système demande une autre adresse mail

2b-2- retour à l’étape 1 du scénario nominal

Tableau 8 : description textuelle du cas d'utilisation "créer compte"


43

II.3.2. Description détaillée des cas d’utilisations initiaux du client Cas d’utilisation « Passer une commande » :

Cas d’utilisation : Passer une commande

Acteurs : Client

Pré-condition : Le client doit s’identifier

Post-condition : Commande enregistrée

Scénario nominal : 1-l’internaute valide son panier

2-le système affiche une page contenant les coordonnées de

livraisons

3-l’internaute valide ses coordonnées

4-le système affiche une page qui contient les services de livraison

5-l’internaute choisie son mode de livraison

6-le système affiche le montant de la commande et les modes de

paiement possible

7-l’internaute choisie un mode et passe à l’étape de paiement

Scénario alternatif : 3a-le client veut changer ses coordonnées de livraison

3a-1-le client saisie les nouvelles coordonnées et valide

3a-2-le système passe à l’étape 4 du scénario nominal

7a-le client annule la commande

7a-1-le système affiche le panier

Tableau 9 : description textuelle du cas d'utilisation "passer une commande"

Cas d’utilisation « Payer la commande » :

Cas d’utilisation : Payement

Acteurs : Client


Post-condition : Affichage de la facture et enregistrement de la commande

Scénario nominal : 1-l’internaute saisie ses coordonnées bancaires

2-le système vérifie ces coordonnées avec les serveurs concernés

3-le système enregistre la commande et affiche la facture

Scénario alternatif : 2a-le client saisie des données manquantes



44

2a-2retour à l’étape 1 du scénario nominal

2b-les données saisies sont erronées

2b-1-le système affiche un message d’erreur

2b-2-retour à l’étape 1 du scénario nominal

2c-la carte est expirée

2c-1-le système affiche un message de type « carte expirée »

2d-le solde du client est insuffisant

2d-1-le système affiche un message de type « solde insuffisant »

Tableau 10 : description textuelle du cas d'utilisation "payer la commande"

Description des cas d’utilisations initiaux de l’entreprise Cas

d’utilisation « gérer les vitrines » :

Le cas d’utilisation « gérer les vitrines » englobe 3 sous cas d’utilisation qui peuvent êtres

décomposés comme suit :

Ajouter produit :

Cas d’utilisation : Ajouter produit

Acteurs : Entreprise

Pré-condition : L’entreprise doit s’authentifier

Post-condition : Le produit reste en attende de validation auprès du superviseur

Scénario nominal : 1-l’entreprise saisit les informations relatives au produit et valide


3-le système enregistre le produit avec un état « en attente » et

affiche un message de succès

Scénario alternatif : 2a-l’entreprise saisit des données manquantes



2b-l’entreprise saisit des données anormales

2b-1-le système affiche un message de type « vérifier les données

saisies »


Tableau 11 : description textuelle du cas d'utilisation "ajouter produit"


45

Supprimer produit :

Cas d’utilisation : Supprimer produit



Post-condition : Produit supprimé

Scénario nominal : 1-l’ entreprise sélectionne le produit et le supprime


3-l’ entreprise valide son choix

4-le système supprime le produit

Scénario alternatif : 3a-l’ entreprise annule son choix

3a-1-le système reste dans la même page

Tableau 12 : description textuelle du cas d'utilisation "supprimer produit"

Modifier un produit :

Cas d’utilisation : Modifier un produit



Post-condition : Le produit est modifié

Scénario nominal : 1-l’ entreprise sélectionne un produit

2-le système affiche les détails du produit sélectionné

3-l’ entreprise modifie les informations du produit


5-le système enregistre la modification et affiche la page des

produits

Scénario alternatif : 4a-le prix saisi n’est pas un nombre

4a-1-le système affiche un message de type « données saisies non

valides »


4b-le prix saisi inférieur à 0

4b-1-le système affiche un message d’erreur


4c-la quantité saisit inférieur à 0


46



Tableau 13 : description textuelle du cas d'utilisation "modifier un produit"

NB : lorsque le produit est valisé par le superviseur l’entreprise ne peut modifier que le prix

ou la quantité de ce produit.

Cas d’utilisation « consulter les commandes » :

Cas d’utilisation : Consulter les commandes


Pré-condition : L’entreprise doit d’authentifier

Post-condition : Liste de commandes affichées

Scénario nominal : 1-l’ entreprise demande l’affichage des commandes

2-le système affiche la liste des commandes correspondantes

3-l’ entreprise sélectionne une commande

4-le système affiche le détail de la commande

Scénario alternatif : 2a-il n’ya pas encore de commande

2a-1-le système affiche un message de type « vous n’avez pas

encore reçu des commandes »

Tableau 14 : description textuelle du cas d'utilisation "consulter les commandes"

Cas d’utilisation « consulter statistique »

Cas d’utilisation : Consulter statistique


Pré-condition : L’entreprise doit d’authentifier

Post-condition : Statistiques affiché

Scénario nominal : 1-l’ entreprise demande l’affichage de la statistique

2-le système affiche la statistique

Scénario alternatif : 2a-Aucune données existante

2a-1-le système affiche un message de type « vous n’avez pas

encore de statistique »

Tableau 15 : description textuelle du cas d'utilisation "consulter statistique"


47

II.2.4. Description détaillée des cas d’utilisation initiaux du superviseur Cas d’utilisation « Valider/annuler produit » :

Cas d’utilisation : Valider/annuler produit

Acteurs : Superviseur

Pré-condition : Le superviseur doit d’authentifier

Post-condition : État du produit changé

Scénario nominal : 1-le superviseur sélectionne le produit

2-le système affiche les détails du produit

3-le responsable modifie l’état du produit

2-le système enregistre la modification et retourne au page de

produit

Scénario alternatif : 1a-le superviseur annule le produit

1a-1-le système supprime l’article

1a-2-le système affiche la page de produit

Tableau 16 : description textuelle du cas d'utilisation "valider/annuler produit"

Cas d’utilisation « consulter liste des vitrines » :

Cas d’utilisation : consulter liste des vitrines



Post-condition : La liste des vitrines est affichée

Scénario nominal : 1-le superviseur demande l’affichage des vitrines

2-le système affiche la liste des vitrines

Tableau 17 : description textuelle du cas d'utilisation "consulter liste des vitrines"

Cas d’utilisation « consulter liste des clients » :

Cas d’utilisation : consulter liste des clients



Post-condition : La liste des clients est affichée

Scénario nominal : 1-le superviseur demande l’affichage des clients

2-le système affiche la liste des clients

Tableau 18 : description textuelle du cas d'utilisation "consulter liste des clients"


48

Cas d’utilisation « consulter liste des produits » :

Cas d’utilisation : consulter liste des produits



Post-condition : La liste des produits est affichée

Scénario nominal : 1-le superviseur demande l’affichage des produits

2-le système affiche la liste des produits

Tableau 19 : description textuelle du cas d'utilisation "consulter liste des produits"

Cas d’utilisation « consulter les commandes » :

Cas d’utilisation : consulter les commandes



Post-condition : La liste des commandes est affichée

Scénario nominal : 1-le superviseur demande l’affichage de commandes passées

2-le système affiche la liste des commandes

3-le superviseur sélectionne une commande

4-le système affiche le détails de la commande

Tableau 20 : description textuelle du cas d'utilisation "consulter les commandes"

II.2.5. Description détaillée des cas d’utilisations initiaux de

l’administrateur Cas d’utilisation « créer catégorie vitrine» :

Cas d’utilisation : Créer catégorie vitrine

Acteurs : Administrateur

Pré-condition : L’administrateur doit s’authentifier

Post-condition : La nouvelle catégorie est enregistrée

Scénario nominal : 1-l’administrateur saisi les informations et valide


3- le système enregistre la nouvelle catégorie

Scénario alternatif : 2a-l’administrateur saisie des données manquantes



49


2b-la catégorie de vitrine existe

2b-1-le système affiche un message de type « cette catégorie

existe déjà »


Tableau 21 : description textuelle du cas d'utilisation "créer catégorie vitrine"

Cas d’utilisation « créer catégorie produit» :

Cas d’utilisation : Créer catégorie



Post-condition : La nouvelle catégorie est enregistrée

Scénario nominal : 1-l’administrateur saisi les informations et valide


3- le système enregistre la nouvelle catégorie




2b-la catégorie de produit existe

2b-1-le système affiche un message de type « cette catégorie

existe déjà »


Tableau 22 : description textuelle du cas d'utilisation "créer catégorie produit"

Cas d’utilisation « créer vitrine » :

Cas d’utilisation : Créer vitrine


Pré-condition : l’administrateur doit d’authentifier

Post-condition : Vitrine affectée à une entreprise

Scénario nominal : 1-l’administrateur saisit les informations sur la vitrine


3-le système enregistre la nouvelle vitrine et envoie un mail vers

l’entreprise


50

Scénario alternatif 2a-l’administrateur saisie des données manquantes


2a-2-le système retourne à l’étape 1 du scénario nominal

Tableau 23 : description textuelle du cas d'utilisation "créer vitrine"

Cas d’utilisation « Authentification » :

Cas d’utilisation : Authentification

Acteurs : Superviseur, administrateur, entreprise, client


Post-condition : L’utilisateur est connecté

Scénario nominal : 1-l’utilisateur saisit ses informations de connexion


3- le système affiche la page d’accueil

Scénario alternatif : 2a-l’utilisateur saisit des données manquantes



2b-les données saisies sont invalides

2b-1-le système affiche un message de type « vérifier vos données

saisies »


Tableau 24 : description textuelle du cas d'utilisation "authentification"

NB : nous voulons dire par « utilisateur » les acteurs suivants : administrateur, entreprise,

client, superviseur.

III. Les prototypes d’interfaces

Dans cette partie, nous avons commencé par la réalisation de quelques prototypes des

interfaces utilisateurs dans le but de mesurer la satisfaction du responsable de l’entreprise et

de l’encourager à nous aider dans la réalisation de ce projet. En effet, ce dernier a été très

satisfait par ce travail et il nous a motivés en nous donnant des remarques et des informations

utiles.

Les images suivantes présentent les premiers prototypes réalisés


51

Figure 8: prototype interface authentification du back-office

Figure 9: prototype interface gestion des superviseurs


52

IV. Analyse des cas d’utilisations prioritaires

Durant cette section, nous allons faire la traçabilité entre le modèle de cas d’utilisation et le

modèle d’analyse des cas d’utilisation prioritaires, ensuite nous allons étudier le diagramme

de classe du modèle d’analyse de ces derniers.

La traçabilité entre le diagramme de cas d’utilisation et le modèle d’analyse permet de

distinguer les différentes classes qui interviennent dans ce cas. Ces classes peuvent être définit

comme suit :

Classe dialogue : ce sont les interfaces IHM11 et qui permet aux utilisateurs d’interagir

avec le système

Classe contrôle : ce sont les classes qui contiennent les opérations et permet de gérer le

comportement du système.

Classe entité : ce sont les classes qui contient les données et qui nous reverra par la suite

dans la construction de notre diagramme de classe

IV.1. Analyse du cas d’utilisation « créer catégorie vitrine »

IV.1.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse

du cas d’utilisation « créer catégorie vitrine »

Pour ajouter une nouvelle catégorie de vitrine, l’administrateur remplis le formulaire

d’ajout par les informations nécessaire. Ces informations serons transmises vers la classe

contrôle qui sera chargé de les vérifier et par la suite l’enregistrer dans l’entité

categorie_vitrine.

11 IHM : Interface Homme Machine


53

Figure 10: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour les

d'utilisation "créer catégorie vitrine"

IV.1.2. Digramme de classe du modèle d’analyse pour cas d’utilisation

« créer catégorie vitrine »

Figure 11: diagramme de classe du modèle d'analyse pour le cas d'utilisation "créer catégorie

vitrine"

<<Trace>>

Diagramme cas d'utilisation Modéle d'analyse

Administrateur

Créer catégorie vitrine

formulaire ajout ctr_ajouter

categorie_vi trine

Administrateurformulaire ajout

ctr_ajoutcategorie_vitrine


54

IV.2. Analyse du cas d’utilisation « créer catégorie produit »


du cas d’utilisation « créer catégorie produit »

Pour ajouter une nouvelle catégorie de produit, l’administrateur remplis le formulaire

d’ajout par les informations nécessaire. Ces informations serons transmises vers la classe

contrôle qui sera chargé de les vérifier et par la suite l’enregistrer dans l’entité

categorie_produit.

Figure 12: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas

d'utilisation "créer catégorie produit"

<<Trace>>


Administrateur


formulaire ajoutctr_ajout

categorie_produi t


55

IV.2.2. Diagramme de classe du modèle d’analyse de cas d’utilisation

« créer catégorie produit »

Figure 13: diagramme de classe du modèle d'analyse du cas d'utilisation "créer catégorie

produit"

IV.3. Analyse du cas d’utilisation « créer vitrine »


pour les cas d’utilisation « créer vitrine »

Pour ajouter une nouvelle vitrine, l’administrateur remplis le formulaire d’ajout par les

informations nécessaire. Ces informations serons transmises vers la classe contrôle qui sera

chargé de les vérifier les données et par la suite l’enregistrer dans l’entité vitrine


ctr_ajoutcategorie_produit


56

Figure 14: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas

d'utilisation "créer vitrine"

IV.3.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation

« créer vitrine »

Figure 15: diagramme de classe du modèle d'analyse pour les cas d'utilisation "créer vitrine"

<<Trace>>


Administrateur

Créer vitrine

formulaire creationctr_creation

vitrine

Administrateurformulaire creation

ctr_creationvitrine


57

IV.4. Analyse du cas d’utilisation « authentification »


pour le cas d’utilisation « authentification »

Pour passer vers la page d’accueil l’utilisateur passe en premier lieu par un formulaire

d’authentification où il met son mail et son mot de passe. Ces données sont transférer vers la

classe contrôle ctr_authentification qui sera chargé de les vérifier avec la classe entité

compte_user, et par la suite rediriger l’utilisateur vers la page d’accueil ou afficher un

message d’erreur.


d'utilisation "authentification"

NB : Dans le schéma précédant, nous voulons dire par utilisateur les acteurs suivants : le

superviseur, le responsable de l’entreprise, le client et l’administrateur.

<<Trace>>


Utilisateur

Authentification

formulaire authentification

ctr_authentification

compte_user


58

IV.3.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation

« authentification »

Figure 17: diagramme de classe du modèle d'analyse pour le cas d'utilisation "authentification"

Conclusion

Dans ce chapitre nous avons énuméré les besoins fonctionnels et non fonctionnels. Nous

avons aussi identifié les différents acteurs qui interagirent avec notre système, et enfin, nous

avons commencé l’analyse des cas d’utilisation prioritaires.

Maintenant, nous pouvons passer à la prochaine phase du cycle de développement avec le

processus unifié où nous allons présenter le digramme de cas d’utilisation finale et

commencer la conception de notre système.

Util isateurformulaire authentification

ctr_authentificationcompte_user

Chapitre III : La phase d’élaboration

59


Introduction

L’élaboration est la phase la plus importante dans le cycle de développement d’une

application conçue via le processus unifié. Elle a pour objectif d’identifier la majeure partie

des besoins des utilisateurs et aussi de concevoir l’architecture du futur système.

Durant cette phase, nous allons spécifier les différents cas d’utilisation secondaires qui n’ont

pas été identifiés dans la phase précédente. Ensuite nous allons étudier et réaliser le

diagramme de séquence détaillé de chaque cas.

I. Capture des besoins secondaires

Dans cette première section de ce chapitre, nous allons identifier les cas d’utilisation

secondaires et nous allons les classer par acteur :

I.1. Les besoins secondaires de l’internaute Faire une recherche : la recherche peut être soit rapide par mot clé, soit une recherche

avancée.

I.2. Les besoins secondaires de l’entreprise Faire une demande de collecte : lorsque le responsable reçoit une commande, il a le choix

soit de l’envoyer vers le centre de distribution correspondant pour qu’il l’achemine vers le

client final, soit de faire une demande de collecte pour que le centre soit chargé de

recevoir la commande.

Imprimer étiquette : l’entreprise doit avoir le droit d’imprimer une étiquette qui devra être

collé sur la commande afin de savoir les données concernant sa livraison par la suite.

Imprimer bordereau de dépôt : après la préparation de ses commandes, l’entreprise devra

imprimer un bordereau de dépôt qui lui permettra de déposer ses commandes par la suite

chez les unités commerciales de la poste.

I.3. Les besoins secondaires de l’administrateur Gérer les superviseurs : l’administrateur du site a le droit de créer ou de supprimer des

superviseurs


60

Consulter liste des unités commerciale : ces unités sont soit des agences rapide poste, soit

des agences colis postaux ou des bureaux de poste qui sont chargé de la livraison.

Ajouter une unité commerciale : l’administrateur a le droit d’ajouter une nouvelle unité

qui se chargera de la livraison des commandes selon un contrat avec les vitrines.

I.4. Les besoins secondaires du superviseur Consulter la statistique

I.5. Les besoins secondaires du client Consulter son historique de commande : le client peut consulter l’historique de ses

commandes passé ou en cour. Si une commande en cour avec un mode de livraison rapide

poste, le client peut la suivre par son numéro d’envoie.

I.6. Les besoins de l’unité commerciale

L’unité commerciale est un nouveau acteur qui a été identifier dans cette phase. Ce dernier

possède un seul rôle dans notre système c’est la collecte des commandes.

II. Le modèle final des cas d’utilisations Dans cette section, nous allons schématiser le diagramme de cas d’utilisation final en

première partie, ensuite nous allons faire la description détaillée de ces cas d’utilisation

secondaire. II.1. Diagramme de cas d’utilisation final

Dans ce qui suit nous illustrons le diagramme de cas d’utilisation initial (voir figure 18)

II.2. Description détaillée des cas d’utilisations secondaires

II.2.1. Description des cas d’utilisation de l’internaute Cas d’utilisation « faire une recherche rapide » :

Cas d’utilisation : Faire une recherche rapide



Post-condition : Le résultat est affiché

Scénario nominal : 1-l’internaute saisie le mot clé

2-le système affiche le résultat de recherche

Scénario alternatif : 2a-Aucune résultat trouver


61

2a-1-le système affiche un message de type « aucune résultat

trouver »


Tableau 25 : description textuelle du cas d'utilisation "faire une rechercher rapide"

Cas d’utilisation « faire une recherche avancé » :

Cas d’utilisation : Faire une recherche avancée



Post-condition : Le résultat est affiché

Scénario nominal : 1-l’internaute saisie les critères de recherche

2-le système affiche le résultat de recherche

Scénario alternatif : 2a-Aucune résultat trouver

2a-1-le système affiche un message de type « aucune résultat

trouver »


Tableau 26 : description textuelle du cas d'utilisation "faire une recherche avancé"

II.2.2. Description des cas d’utilisation de l’entreprise Cas d’utilisation « faire une demande de collecte » :

Cas d’utilisation : Faire une demande de collecte

Acteurs principaux: Responsable d’entreprise

Pré-condition : Le responsable doit s’authentifier

Post-condition : La demande sera envoyée au centre de distribution

Scénario nominal : 1-le responsable sélectionne la commande

2-le système affiche les détails de la commande

3-le responsable demande la collecte de la commande

4-le système envoie la demande au centre de distribution

Tableau 27 : description textuelle du cas d'utilisation "faire une demande de collecte"


62

Figure 18 : diagramme de cas d'utilisation final


ctr_commande

commande

sous_commande


63

Cas d’utilisation « imprimer étiquette »

Cas d’utilisation : Imprimer étiquette

Acteurs principaux: Entreprise


Post-condition : La demande sera envoyée au centre de distribution

Scénario nominal : 1-l’entreprise sélectionne une commande et demande l’impression

de son étiquette

2-le système imprime l’étiquette de la commande

Tableau 28 : description textuelle du cas d'utilisation "imprimer étiquette"

II.2.3. Description des cas d’utilisations du superviseur Cas d’utilisation « consulter la statistique » :

Cas d’utilisation : Consulter la statistique

Acteurs principaux: Superviseur

Pré-condition : Le superviseur doit s’authentifier

Post-condition : La statistique est affichée

Scénario nominal : 1-le superviseur demande l’affichage de la statistique

2-le système affiche la statistique

Tableau 29 : description textuelle du cas d'utilisation "consulter la statistique"

II.2.4. Description des cas d’utilisation de l’administrateur Cas d’utilisation « consulter liste des unités commerciales »

Cas d’utilisation : Consulter liste des unités commerciales

Acteurs principaux: Administrateur


Post-condition : La liste des unités commerciales est affichée

Scénario nominal : 1-l’administrateur demande l’affichage de la liste des unités

commerciales

2-le système affiche toutes les unités commerciales enregistrées

Tableau 30 : description textuelle du cas d'utilisation "consulter liste des unités commerciales"


64

Cas d’utilisation « ajouter une unité commerciale »

Cas d’utilisation : Ajouter une unité commerciale



Post-condition : Une nouvelle unité commerciale enregistrée

Scénario nominal : 1-l’administrateur remplis le formulaire d’ajout


3-le système enregistre la nouvelle unité et affiche un message de

succès

Scénario alternatif 2a-l’administrateur saisie des données manquantes

2a-1-le système affiche un message de type « vous devez remplir

tous les champs »


Tableau 31 : description textuelle du cas d'utilisation "ajouter une unité commerciale"

Cas d’utilisation « ajouter un superviseur » :

Cas d’utilisation : Ajouter un superviseur



Post-condition : Le superviseur est enregistré

Scénario nominal : 1-l’administrateur saisie les informations relatif au nouveau

superviseur

2-le système vérifie les donnés saisies

3-le système enregistre le nouveau superviseur et envoie un mail qui

contient le login et le mot de passe du superviseur




2b-l’adresse mail existe déjà

2b-1-le système affiche un message de type « adresse mail

existant »


Tableau 32 : description textuelle du cas d'utilisation "ajouter un superviseur"


65

Cas d’utilisation « supprimer un superviseur »

Cas d’utilisation : supprimer un superviseur



Post-condition : Le superviseur est supprimé

Scénario nominal : 1-l’administrateur sélectionne un superviseur et demande sa

suppression


3-l’administrateur valide son choix

4-le système supprime le superviseur et retourne vers la page des

superviseurs

Scénario alternatif : 3a-l’administrateur annule son choix

2a-1-le système affiche la page des superviseurs

Tableau 33 : description textuelle du cas d'utilisation "supprimer un superviseur"

II.2.5. Description des cas d’utilisation du client Cas d’utilisation « consulter historique de commande » :

Cas d’utilisation : Consulter historique de commande

Acteurs principaux: Client

Pré-condition : Le client doit s’authentifier

Post-condition : Les commandes passées par ce client sont affichés

Scénario nominal : 1-l’internaute demande l’affichage de ses commandes

2-le système affiche les commandes concerné par ce client

Scénario alternatif : 2a-aucune commande trouver

2a-1-le système affiche de type « vous n’avez pas encore passé de

commande »

Tableau 34 : description textuelle du cas d'utilisation "consulter historique de commande"

II.2.6.Description des cas d’utilisation de l’unité commerciale Cas d’utilisation « collecter commande » :

Cas d’utilisation : Collecter commande

Acteurs principaux: Unité commerciale


66

Pré-condition : L’unité commerciale doit s’authentifier

Post-condition : L’état de la commande est changé

Scénario nominal : 1-l’unité commerciale saisie le numéro d’envoie

2-le système vérifie le numéro saisie et change l’état de la

commande à « collecter »

Scénario alternatif : 2a-le numéro d’envoie n’existe pas

2a-1-le système affiche de type « cette commande n’appartient

pas à notre place de marché »

2a-2-le système retourne à l’étape 1 du scénario nominal

2b-la commande st déjà collecté

2b-1-le système affiche un message de type « cette commande est

déjà collecté »

2b-2-le système retourne à l’étape 1 du scénario nominal

Tableau 35 : description textuelle du cas d'utilisation "collecter commande"

III. Analyse des cas d’utilisations secondaire

Durant cette section, nous allons faire la traçabilité entre le modèle de cas d’utilisation et le

modèle d’analyse des cas d’utilisation secondaire, ensuite nous allons étudier le diagramme de

classe du modèle d’analyse de ces derniers, tout en respectant l’ordre des priorité qui a été

identifier lors du chapitre précédant.

III.1. Analyse du cas d’utilisation « consulter la liste des vitrines »

III.1.1. Traçabilité entre le modèle de cas d’utilisation et le modèle

d’analyse du cas d’utilisation « consulter la liste des vitrines »

Lorsque le superviseur demande l’affichage de la liste des vitrines, la classe contrôle

ctr_vitrine sera chargé de récupérer les vitrines qui existe dans l’entité vitrines et affiche

l’interface qui contient la liste des vitrines et leurs informations respectives.


67

Figure 19: traçabilité entre le modèle d'analyse et le modèle de cas d'utilisation pour le cas

d'utilisation "consulter la liste des vitrines"

III.1.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation

« consulter liste des vitrines »

Figure 20: diagramme de classe du modèle d'analyse pour le cas d'utilisation "consulter liste des

vitrines"

<<Trace>>


Superviseur

Consulter l iste des vitrines

interface vitrine ctr_vitrine

vitrine

Superviseurinterface vitrine

ctr_vitrinevitrine


68

III.2. Analyse du cas d’utilisation « ajouter un produit »


d’analyse du cas d’utilisation « ajouter un produit »

Pour ajouter un produit l’entreprise devra remplir le formulaire d’ajout. Les informations

saisies seront transférer vers le classe contrôle ctr_ajout afin les vérifier et par la suite les

enregistrer dans l’entité produit


d'utilisation "ajouter un produit"

III.2.2. Diagramme de classe du modèle d’analyse du cas d’utilisation

« ajouter un produit »

Figure 22: diagramme de classe du modéle d'analyse du cas d'utilisation "ajouter un produit"

<<Trace>>


Entreprise

Ajouter un produit

interface ajout ctr_ajout

produit

Entrepriseinterface ajout

ctr_ajoutproduit


69

III.3. Analyse du cas d’utilisation « supprimer un produit »


d’analyse pour le cas d’utilisation « supprimer un produit »

L’entreprise choisie le produit a supprimé depuis l’interface produit. Les informations serons

transférer vers la contrôle ctr_suppression qui sera chargé de le supprimer le l’entité produit.


d'utilisation "supprimer un produit"


« supprimer un produit »

Figure 24: diagramme de classe du modèle d'analyse pour le d'utilisation "supprimer un

produit"

<<Trace>>


Entreprise

Supprimer un produit

interface produit ctr_suppression

produit

Entrepriseinterface produit

ctr_suppressionprodui t


70

III.4. Analyse du cas d’utilisation « modifier un produit »


d’analyse du cas d’utilisation « modifier un produit »

Lorsque l’entreprise choisi le produit a modifier, le système affiche un formulaire qui contient

les informations relative à ce produit. L’entreprise donc modifie ces informations qui seront

transmis vers la classe ctr_modification pour les vérifier et l’enregistrer par la suite dans

l’entité produit.

Figure 25: traçabilité entre le diagramme de cas d'utilisation et le modèle d'analyse du cas

d'utilisation "modifier un produit"


« modifier un produit »

Figure 26: diagramme de classe du modèle d'analyse du cas d'utilisation "modifier un produit"

<<Trace>>


Entreprise

Modifier un produit

formulaire modification ctr_modification

produit

Entrepriseformulai re modi fication

ctr_modificationprodui t


71

III.5. Analyse du cas d’utilisation « valider/annuler un produit »


d’analyse pour le cas d’utilisation « valider/annuler un produit »

Lorsque le superviseur choisie de valider un produit, il le sélectionne depuis l’interface

produit et choisie l’action à appliquer (annuler ou valider). Les informations serons transmise

vers la classe ctr_validation qui selon l’action du superviseur valide ou annule le produit

depuis l’entité produit.

Figure 27: Traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas

d'utilisation "valider/annuler un produit"


« annuler/valider un produit »

<<Trace>>


Superviseur

valider / annuler un produit

interface produit ctr_val idation

produit


72

Figure 28: diagramme de classe du modèle d'analyse du cas d'utilisation "annuler/valider un

produit"

III.6. Analyse du cas d’utilisation « créer compte »


d’analyse du cas d’utilisation « créer compte »

Lorsque le client demande la création d’un compte, le système lui fournit un formulaire où il

devra saisir ses informations. Les informations saisies seront transmises vers la contrôle

ctr_inscription qui sera chargé de les vérifier et les enregistrer par la suite dans l’entité client.


d'utilisation "créer compte"

Superviseurinterface produit

ctr_validationproduit

<<Trace>>


Internaute

Créer compte

formulaire_inscription ctr_inscription Cl ient

compte_user


73


« créer compte »

Figure 30: diagramme de classe du modèle d'analyse du cas d'utilisation "créer compte"

III.7. Analyse du cas d’utilisation « consulter liste des produit »


d’analyse du cas d’utilisation « consulter liste des produit »

Lorsque le responsable demande l’affichage des produits, la classe contrôle ctr_produit sera

chargé de les récupérer depuis l’entité produit et les affiche dans l’interface produit/

Internauteformulaire_inscription

ctr_inscriptionclient

compte_user


74


d'utilisation "consulter liste des produit"


« consulter liste des produit »

Figure 32: diagramme de classe du modèle d'analyse du cas d'utilisation "consulter liste des

produits"

<<Trace>>


Superviseur

consulter la liste des produits

interface produit ctr_produit

produit

Superviseurinterface produit

ctr_produitproduit


75

III.8. Analyse du cas d’utilisation « remplir le panier »


d’analyse du cas d’utilisation « remplir le panier »

Lorsque l’internaute ajoute un produit au panier, la classe contrôle ctr_panier sera chargé de

vérifier la quantité du produit et par la suite d’ajouter ses informations dans les deux entités

panier et produit_panier.

Figure 33:traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas

d'utilisation "remplir le panier"


« remplir le panier »

<<Trace>>


Internaute

Rempl ir le panier

interface panier ctr_panier

panier

produi t_panier


76

Figure 34: diagramme de classe du modèle d'analyse du cas d'utilisation "remplir le panier"

III.9. Analyse du cas d’utilisation « consulter liste des client inscrit »


d’analyse du cas d’utilisation « consulter liste des clients inscrit »

Lorsque le superviseur demande l’affichage de la liste des clients, la classe contrôle ctr_client

sera chargé de la récupérer depuis l’entité client.

Figure 35: traçabilité entre le modèle de cas d’utilisation et le modèle d'analyse du cas

d'utilisation "consulter liste des clients inscrits"

Internauteinterface panier

ctr_panierproduit_panier

panier

<<Trace>>


Superviseur

Consul ter liste des clients

interface client ctr_client

client


77


« consulter liste des clients inscrits »

Figure 36: diagramme de classe du modèle d'analyse du cas d'utilisation "consulter liste des

clients inscrits"

III.10. Analyse du cas d’utilisation « consulter le panier »

III.10.1. Traçabilité entre le diagramme de cas d’utilisation et le modèle

d’analyse du cas d’utilisation « consulter le panier »

Lorsque l’internaute demande l’affichage des détails de son panier, une classe contrôle

ctr_panier sera chargé de récupérer tous ses informations à partir des deux entités panier et

produit_panier


d'utilisation "consulter le panier"

Superviseurinterface client

ctr_clientclient

<<Trace>>


Internaute

consulter le panier


panier

produi t_panier


78


« consulter le panier »

Figure 38: diagramme de classe du modèle d'analyse du cas d'utilisation "consulter le panier"

III.11. Analyse du cas d’utilisation « supprimer un produit du panier »


d’analyse du cas d’utilisation « supprimer un produit du panier »

Pour supprimer un produit, l’internaute devra consulter son panier et sélectionner par la suite

le produit à supprimer. Les données seront transférer par le contrôle ctr_panier qui se chargera

de la suppression du produit de l’entité produit_panier et mettre à jour les données de l’entité

panier.



panier


79


d'utilisation "supprimer un produit du panier"


« supprimer un produit du panier »

Figure 40: diagramme de classe du modèle d'analyse pour le cas d'utilisation "supprimer un

produit du panier"

III.12. Analyse du cas d’utilisation « modifier quantité du produit »

<<Trace>>


Internaute

supprimer un produit du panier


panier

produit_panier



panier


80


d’analyse du cas d’utilisation « modifier quantité du produit »

Lorsque l’internaute souhaite modifier la quantité d’un produit existant dans son panier, ce

dernier consulte son panier et modifie la quantité d’un produit qu’il choisi. Ces données

serons transférer vers la classe contrôle ctr_panier qui sera chargé de faire la mise à jour des

deux entités panier et produit_panier.


d'utilisation "modifier quantité du produit"


« modifier quantité du produit »

<<Trace>>


Internaute

modifier quanti té du produit


panier

produit_panier


81

Figure 42: diagramme de classe du modèle d'analyse pour le cas d'utilisation "modifier quantité

du produit"

III.13. Analyse du cas d’utilisation « vider le panier »


d’analyse pour le cas d’utilisation « vider le panier »

Lorsque l’internaute souhaite vider son panier, le contrôle ctr_panier se chargera de cette

action et de faire la mise à jour des deux entités panier et produit_panier



panier


82


d'utilisation "vider le panier"


« vider le panier »

Figure 44: diagramme de classe du modèle d'analyse pour le cas d'utilisation "vider le panier"

<<Trace>>


Internaute

vider le panier


panier

produit_panier



panier


83

III.14. Analyse du cas d’utilisation « passer une commande »


d’analyse pour le cas d’utilisation « passer une commande »

Lors du passage d’une commande le client passe par une interface commande où il devra

saisir ses information et choisir le mode de livraison. Ces informations serons transférer vers

la classe contrôle ctr_commande qui se chargera d’enregistrer la commande dans les deux

entités commande et sous_commande.


d'utilisation "passer une commande"


« passer une commande »

<<Trace>>


Client

passer une commande

interface commande

ctr_commande

commande

sous_commande

tari f


84

Figure 46: diagramme de classe du modèle d'analyse du cas d'utilisation "passer une

commande"

III.15. Analyse du cas d’utilisation « consulter les commande »

Le cas d’utilisation « consulter les commandes » du superviseur est similaire celui de

l’entreprise et du client. C’est pour cette raison nous n’allons traiter que cas d’utilisation juste

pour le superviseur.


d’analyse pour le cas d’utilisation « consulter les commandes »

Lorsque le superviseur demande l’affichage des commandes, la contrôle ctr_commande sera

chargé de les récupérer depuis les deux entités commande et sous_commande.


ctr_commande

tari fcommande sous_commande


85


d'utilisation "consulter les commandes"

III.15.2. Digramme de classe du modèle d’analyse pour le cas d’utilisation

« consulter les commandes »

Figure 48: diagramme de classe du modèle d'analyse pour le cas d'utilisation "consulter les

commandes"

<<Trace>>


Superviseur

Consulter les commande

interface commande ctr_commande

commande

sous_commande

Superviseurinterface commande

ctr_commande

commande

sous_commande


86

III.16. Analyse du cas d’utilisation « payer la commande »


d’analyse pour le cas d’utilisation « payer la commande »

Lorsque le client passe sa commande et arrive à l’étape de paiement, ce dernier doit saisir ses

informations bancaires dans un formulaire de paiement. La contrôle ctr_paiement se chargera

de vérifier ses informations avec le serveur de paiement sécurisé et par la suite enregistre les

données de transaction dans les entités transaction et détails_transaction.


d'utilisation "payer la commande"


« payer la commande »

<<Trace>>


Client

payer la commande

interface paiement ctr_paiement

commande

transaction

details_transaction


87

Figure 50: diagramme de classe du modèle d'analyse pour le cas d'utilisation "payer la

commande"

III.17. Analyse du cas d’utilisation « faire une recherche rapide »


d’analyse pour le cas d’utilisation « faire une recherche rapide »

Pour chercher un produit ou une vitrine sur notre portail, l’internaute devra saisir le mot clé

dans un formulaire de recherche. La classe ctr_recherche récupère les données saisie et

cherche le produit ou la vitrine demandé selon l’action de l’internaute sans les deux entités

produit et vitrines. Le résultat sera affiché dans une interface résultat de recherche

Clientinterface paiement

ctr_panier

commande

transaction

details_transaction


88


d'utilisation "faire une recherche rapide"


« faire une recherche rapide »

Figure 52: diagramme de classe du modèle d'analyse pour le cas d'utilisation "faire une

recherche rapide"

<<Trace>>


Internaute

recherche rapide

formulaire recherchectr_recherche

produit

vi trine

Internauteformulaire recherche

ctr_rechercheproduit

vitrine


89

III.18. Analyse du cas d’utilisation « faire une recherche avancée »


d’analyse pour le cas d’utilisation « faire une recherche avancée »

Lorsque l’internaute souhaite effectuer une recherche avancée, ce dernier accède à un

formulaire de recherche où il va préciser les critères de se recherche. Par la suite la classe

ctr_recherche sera chargé d’afficher le résultat dans une autre interface.


d'utilisation "faire une recherche avancée"


« faire une recherche avancée »

<<Trace>>


Internaute

recherche avancée

formulaire recherchectr_recherche

produit

vi trine


90

Figure 54: diagramme de classe du modèle d'analyse pour le cas d'utilisation "faire une

recherche avancée"

III.19. Analyse du cas d’utilisation « ajouter superviseur »


d’analyse pour le cas d’utilisation « ajouter superviseur »

Pour ajouter un nouveau superviseur, l’administrateur doit remplir un formulaire d’ajout par

les informations nécessaires. Par la suite les informations saisies seront transmise vers la

contrôle ctr_superviseur qui se chargera d’enregistrer le nouveau superviseur.

Internauteformulaire recherche

ctr_rechercheproduit

vitrine


91

Figure 55: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "ajouter un superviseur"

III.19.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation « ajouter un superviseur »

Figure 56: diagramme de classe du modèle d'analyse pour le cas d'utilisation "ajouter un superviseur"

III.20. Analyse du cas d’utilisation « supprimer un superviseur » III.20.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « supprimer superviseur »

Lorsque l’administrateur souhaite supprimer un superviseur, il le sélectionne depuis la page

des superviseurs. Par la suite la classe ctr_superviseur se chargera se supprimer le superviseur.

<<Trace>>


Administrateur

Ajouter un superviseur

formulaire ajout ctr_superviseur

superviseur


ctr_superviseursuperviseur


92

Figure 57: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "supprimer un superviseur"

III.20.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation « supprimer superviseur »

Figure 58: diagramme de classe du modèle d'analyse pour le cas d'utilisation "supprimer un superviseur"

III.21. Analyse du cas d’utilisation « consulter les unités commerciales » III.21.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « consulter les unités commerciales »

Lorsque l’administrateur demande l’affichage des unités commerciales enregistrés, la classe contrôle ctr_unite se chargera de les récupérer depuis l’entité unite_commerciale

<<Trace>>


Administrateur

Supprimer un superviseur

interface superviseur ctr_superviseur

superviseur

Administrateurinterface superviseur

ctr_superviseursuperviseur


93

Figure 59: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "consulter les unités commerciales "

III.21.1. Diagramme de classe du modèle d’analyse pour le cas d’utilisation « consulter les unités commerciales »

Figure 60: diagramme de classe du modèle d'analyse pour le cas d'utilisation "consulter les unités commerciales"

III.22. Analyse du cas d’utilisation « ajouter unité commerciale » III.22.1. Traçabilité entre le modèle de cas d’utilisation et le modèle

d’analyse pour le cas d’utilisation « ajouter unité commerciale »

Lorsque l’administrateur remplis le formulaire d’ajout, les informations saisies serons

transmise vers la contrôle ctr_unite qui sera chargé de les vérifier et de les enregistrer par la

suite dans l’entité unite_commerciale

<<Trace>>


Administrateur

consulter l iste unités commerciales

interdace unite ctr_unite

unite_commerciale

Administrateurinterface unite

ctr_uniteunite_commerciale


94

Figure 61: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse du cas d'utilisation "ajouter unité commerciale"

III.22.2. Diagramme de classe du modèle d’analyse du cas d’utilisation « ajouter unité commerciale »

Figure 62: diagramme de classe du modèle d'analyse pour le cas d'utilisation "ajouter unité commerciale"

III.23. Analyse du cas d’utilisation « collecter commande » III.23.1. Traçabilité entre le modèle de cas d’utilisation et le modèle

d’analyse pour le cas d’utilisation « collecter commande »

Lors de la collecte d’une commande, l’unité commerciale accéde à un interface dans laquelle

elle devra saisir le numéro d’envoie de la commande. Ansi la classe contôle ctr_commande se

chargera de vérifier l’existance de la commande et de changer son état par la suite.

<<Trace>>


Administrateur

ajouter unité commerciale

forlulaire ajout ctr_unite

unite_commerciale


ctr_uniteunite_commerciale


95

Figure 63 : traçabilité entre le mdèle de cas d'utilisation et le modèle d'analyse pour le cas d'utilisation "collecter commande"


« collecter commande »

Figure 64 : diagramme de classe du modèle d'analyse pour le cas d'utilisation "collecter commande"

IV. Conception

Dans cette section nous allons commencer la conception de notre système en utilisant le

langage de modélisation objet UML. En premier lieu, nous commençons par la schématisation

<<Trace>>


Unite commerciale

collecter commande

interface_unite

ctr_commande

commande

Unite commercialeinterface_unite

ctr_commandecommande


96

de la vue comportementale de notre système avec le diagramme de séquence détaillé, ensuite

nous illustrons le diagramme de navigation correspondant.

IV.1. Conception des cas d’utilisations prioritaires

Nous commençons dans cette section par la conception des cas d’utilisations prioritaires déjà

identifier dans le chapitre « incubation » en utilisant le diagramme de séquence puisqu’il

permet de nous fournir une représentation graphique des interactions entre le système et

l’utilisateur (acteur) selon un point de vue temporel.

IV.1.1. Diagramme de séquence du cas d’utilisation « créer catégorie

produit »

Le diagramme de séquence du cas d’utilisation « créer catégorie produit » est similaire à celui

de « créer catégorie vitrine ». C’est pour cette raison nous n’allons étudier que le diagramme

de séquence du cas « créer catégorie produit »


97

Figure 65: diagramme de séquence du cas d'utilisation "créer catégorie produit"


afficher_msg_succes(message)succees

ajouter_categorie (nom)

afficher_msg_erreur (message)

resultat()

verifier_categorie()

afficher_msg_erreur (message)

veri fier_donnee()

transferer données

remplir le formulaire

Administrateur formulaire ajout ctr_ajout categorie_produit

ref

Authentification()

données manquantes

sinon

alt

categorie existe

sinon

al t


98

IV.1.2. Diagramme de séquence du cas d’utilisation « authentification »

Figure 66: diagramme de séquence du cas d'utilisation "authentification"

IV.1.3. diagramme de séquence du cas d’utilisation « créer vitrine »

Authentification

afficher()

afficher_msg_erreur(message)

resultat

requette


verifier_donnees()

connexion (login,password)

saisie_donnee(login,password)

uti l isateur formulaire_authentification ctr_authentification compte_user acceuil

données manquantes

tous les champs sont remplis

alt

aucune résultat

sinon

alt


99

Figure 67: diagramme de séquence du cas d'utilisation "créer vitrine"

Créer vitrine

afficher_msg_succes(message)

resultat

requette


verifier_donnees()

creer_vitrine(v1,v2,...)rempli r_formulaire(v1,v2,...)

Administrateur formulaire creation ctr_creation vi trine

ref

Authentification()

données manquantes


alt


100

IV.2. Conception des cas d’utilisations secondaires

IV.2.1. Diagramme de séquence du cas d’utilisation « créer compte »

Figure 68: diagramme de séquence du cas d'utilisation "créer compte"

Créer compte


resultat2

resultat1

requette2

requette1

redirection()

cl iquer_sur_l ien()

envoyer_l ien_validation()

resultat()

afficher_message_erreur(message)

verifier mail(mail)

afficher_message_erreur(message)

verifier_donnees()

creer_compte(v1,v2,...)

saisie information(v1,v2,...)

Internaute formulaire inscription ctr_inscription compte_user boite_mailcl ient

données manquantes


alt

mail existant

mail innexistant

alt


101

IV.2.2. Diagramme de séquence du cas d’utilisation « ajouter un produit »

Figure 69: diagramme de séquence du cas d'utilisation "ajouter un produit"

Ajouter un produit

afficher_msg_succes(message)resultat

requette



verifier_donnees()ajouter_produit(v1,v2,...)

remplir_formulaire(v1,v2,...)

Entreprise formulaire_ajout ctr_ajout produit

ref

Authentification()

donnees manquantes


alt

données innormaux

données valides

alt

[l 'entreprise veut ajouter un produit]loop


102

IV.2.3. Diagramme de séquence du cas d’utilisation « modifier un produit »

Figure 70: diagramme de séquence du cas d'utilisation "modifier un produit"

Modifier un produit

afficher_msg_succes(message)resultat

requette



verifier_information()

modifier(v1,v2..)modifier_produit(v1,v2,...)

Entreprise detail produit ctr_modification produit

ref

Authentification()

type de données non conforme

sinon

alt

prix ou stock inférieur à 0

sinon

alt


103

IV.2.4. Diagramme de séquence du cas d’utilisation « supprimer un

produit »

Figure 71: diagramme de séquence du cas d'utilisation "supprimer un produit"

IV.2.5. Diagramme de séquence du cas d’utilisation « consulter liste des

vitrines »

Le diagramme de cas d’utilisation « consulter liste des vitrines » est similaire aux cas

d’utilisation « consulter liste des client », « consulter liste des produit » et « consulter liste

des unités commerciales ». C’est pour cette raison nous n’allons étudier que le diagramme de

séquence du premier cas.

supprimer un produit

resultat

requette

affiche()

affiche()

afficher_message_confirmation()

demande_suppression()selectionner_produti()

Entreprise interface produit ctr_suppression produit

ref

Authentification()

le responsable confirme son choix

le responsable annule son choix

alt

[l 'entreprise veut supprimer un produit]opt


104

Figure 72: diagramme de séquence du cas d'utilisation "consulter liste vitrines"

IV.2.6. Diagramme de séquence du cas d’utilisation « valider/annuler un

produit »

consulter l iste des vitrines

transfert()

afficher_vitrine()

requette

resultat

affiche()

Superviseur interface vitrine ctr_vitrine vitrine

ref

Authentification()


105

Figure 73: diagramme de séquence du cas d'utilisation "valider/annuler un produit"

IV.2.7. Diagramme de séquence du cas d’utilisation « consulter liste des

commande »

De même, le cas d’utilisation « consulter liste des commande » est similaire pour l’entreprise,

le superviseur et le client. C’est pour cette raison nous n’allons étudier que le diagramme du

premier acteur.

Valider un produit

resultat

requette

resultat

requette

afficher()

transfert()anuuler_produit()

transfert()valider_produit()

afficher()

selectiooner un produit

Superviseur interface produitdetail produit ctr_valider_produit produit

ref

Authentification()

produit conforme

non conforme

alt


106

Figure 74: diagramme de séquence du cas d'utilisation "consulter liste commande"

IV.2.8. Diagramme de séquence du cas d’utilisation « ajouter superviseur »

consulter les commandes

afficher()

resultat

requettetransfert()

afficher detai l

Entreprise interface commande ctr_get_commande sous_commandedetail_commande

ref

Authentification()


107

Figure 75: diagramme de séquence du cas d'utilisation "ajouter superviseur"

IV.2.9. Diagramme de séquence du cas d’utilisation « supprimer

superviseur »

Ajouter un superviseur


resul tat

requette


resultat

requette(mai l)


verifier_donnees()ajouter_superviseur(v1,v2,..)

rempli r_forulaire(v1,v2,..)

Administrateur formulaire_ajout ctr_superviseur superviseur

ref

Authentification()

données manquantes


al t

mail existant

mail innexistant

alt

[l 'administrateur veut ajouter des nouveaux superviseurs]loop


108

Figure 76: diagramme de séquence du cas d'utilisation "supprimer un superviseur"

IV.2.10. Diagramme de séquence du cas d’utilisation « remplir le panier »

Supprimer un superviseur

resultat

requette

afficher()

transfert()annuler()

afficher()

transfert()confirmer()

afficher_message_confirmation

selectionner un superviseur

Administrateur interface superviseur ctr_superviseur superviseur

ref

Authentification()

l 'administrateur valide la suppression

l'administrateur annule la suppression

alt

[l 'administrateur souhaite supprimer un superviseur]opt


109

Figure 77: diagramme de séquence du cas d'utilisation "remplir le panier"

IV.2.11. Diagramme de séquence du cas d’utilisation « mise à jour du

panier »

Dans ce qui suit, nous avons encapsulé les diagrammes de séquences des cas d’utilisation

« consulter le panier », « modifier quantité du produit » et « supprimer un produit » dans un

même diagramme intitulé « mise à jour du panier »

Rempl ir le panier

afficherresul tat2

requette2

resul tat1

requette1


resultat

veri fier_poid_vi trine()


resul tat

verifier_qte(quanti te)

ajouter_produi t_panier(quanti te,poid)selectionner(quantite)

Internaute interface_produit ctr_panier panier produi t_panierprodui t

stock insuffisant

stock suffisant

al t

poid d'une vitrine depasse 30 kg

sinon

alt

[l'internaute souhai te ajouter des produi ts dans son panier]loop


110

Figure 78: diagramme de séquence du cas d'utilisation "mise à jour du panier"

Mise a jour du panier

afficher()

afficher()

annuler()annuler

resultat

requette

resultat

requettesupprimer_produit()

valider()

message_confirmation()

selectionne_produit()

afficherresultat

requette

resultat

requette


resultat

verifier_poid_vitrine()


resultat

verifier_qte(quantite)

modifier(quantite)

modifier quantite(quantite)

afficher

resultat

requette

resultat

requette

resultat

requette

details()afficher_details_panier()

Internaute interface panier ctr_panier produit panier produit_panier

stock insuffisant

stock suffisant

alt

poid vitrine supérieur à 30 kg

sinon

alt

[l 'internaute souhaite modifier la quantité d'un produit]opt

valider la suppression

annuler la suppression

alt

[l 'internaute souhaite supprimer un produit]opt


111

IV.2.12. Diagramme de séquence du cas d’utilisation « vider le panier »

Figure 79: diagramme de séquence du cas d'utilisation "vider le panier"

Vider le panier

afficher()

afficher()

annuler()

annuler()

resultat

requette

resul tat

requettevider_panier()

val ider()

message_confi rmation()

vider_panier()

Internaute interface_panier ctr_panier panier produit_panier

val ider son choix

annule son choix

alt


112

IV.2.13. Diagramme de séquence du cas d’utilisation « passer une

commande »

Figure 80: diagramme de séquence du cas d'utilisation "passer une commande"

Passer une commande

choisir_mode_livraison()

afficher()

annuler()

annuler_commande()

modifier coordonnees(v1,v2,..)

afficher()validation()

val ider_panier()

client interface_panier ctr_commande interface_commande

[le cl ient veut modifier ses coordonnées de l ivraisons]opt

refAuthenti fication()

[le cl ient veut annuler la commande]opt


113

IV.2.14. Diagramme de séquence du cas d’utilisation « payer la

commande »

Figure 81: diagramme de séquence du cas d'utilisation "payer la commande"

Payer la commande

message_succes()resultat

requette

resultat

requette

message_erreur()

message_erreur()

message_erreur()

reponse

donnes_cryptes()

message_erreur()

veri fier_donnes()

payer

saisie_info(carte,pass)

Cl ient formulaire_paiement ctr_paiement commande sous_commande serveur_paiement

données manquantes


alt

données erronées

sinon

alt

date expiré

sinon

al t

solde insuffisant

sinon

al t


114

IV.2.15. Diagramme de séquence du cas d’utilisation «collecter commande»

Figure 82 : diagramme de séquence du cas d'utilisation "collecter commande"

Conclusion

A la fin de ce chapitre, nous avons fait la conception de tous les cas d’utilisation. Nous

pouvons maintenant dresser notre diagramme de classe et déduire par la suite notre base de

données.

collecter commande

afficher_msg_succees(message)

resultat

changer_etat()



resul tat

retourner(numero,etat)collecter(val)saisie_numero_envoie(val)

unite commerciale interface_unite ctr_commande commande

commande non trouvé

sinon

alt

etat_commande=col lecte

sinon

alt

refAuthentification()

[i l existe encore des commandes]loop

Chapitre VI : La phase de construction

115

Chapitre VI : Phase de construction

Introduction

La phase de construction est la phase dans laquelle nous obtenons un produit final, qui

répond aux besoins du maître d'ouvrage12.

Tous au long de cette phase nous schématisons la structure de notre futur système par le

diagramme de navigation, ensuite nous allons présenter le diagramme de classe global.

I. Modélisation de la navigation

UML nous offre l’opportunité de modéliser la navigation sur un site web à l’aide d’un

diagramme, c'est le diagramme de navigation. Ce diagramme a pour objectif de présenter la

relation entre les différentes classes d’IHM13.

Dans ce qui suit, nous structurons la navigation par acteur. En effet, il est clair que la

navigation de l’internaute sur le site (partie front-office) est totalement différente de celle du

superviseur ou de l’administrateur (partie back-office), de même pour le responsable

d’entreprise qui possède une partie totalement différente à celle de l’internaute ou de

l’administrateur.

I.1. Diagramme d’activité de navigation pour l’internaute et le client :

Après avoir décomposé le diagramme de navigation par acteur, nous pouvons ensuite le

structurer en sous-ensemble de cas d’utilisation cohérente comme suit :

Diagramme de navigation du cas d’utilisation remplir le panier

12 Maître d'ouvrage (MOA): c’est l’entité porteuse du besoin et c’est tout simplement le client 13 IHM :Interface Homme Machine


116

Figure 83: diagramme d'activité de navigation du cas d'utilisation" remplir le panier"

Diagramme de navigation du cas d’utilisation passer une commande

promotion

nouveauté

contact

vitrine

Recherche

pas de résultat

resultat trouvé

details

detai ls

detai ls

detai ls

H

retour

ajouter au panier

ajouter au panier

ajouter au panier

ajouter au panier

ajouter au panier

recherche rapide recherche avancée

<<page>>acceuil internaute

<<page>>promotion

<<page>>nouveauté

<<page>>contact

<<page>>vitrine

<<page>>produit<<frame>>

recherche rapide<<page>>

recherche avancée

resultat ?<<exception>>aucune résultat trouvé

<<page>>resultat recherche

<<page>>details produit

<<connector>>panier


117

Figure 84: diagramme d'activité de navigation du cas d'utilisation "passer une commande"

vider le panier

supprimer un article

OUI NON

OUI

NON

valider la commande

NON

modifier quantité

OUI

NON

OUI

val ider les coordonnées de livraison

choisir le mode de l ivraison

NONpayement à la livraison

payer en l igne

commande

paiement

fin commande

<<page>>panier

<<exception>>votre panier est vide

panier vide ?

quanti té disponible<<exception>>

quanti té demandé est indisponible

<<page>>commande

inscrit ?<<page>>

creer compte<<page>>

authenti fication

données val ides ?

<<page>>coordonnées de livraison

<<page>>mode livraison

<<page>>paiement

<<page>>coordonnées bancaires

coordonnées valides

<<page>>historique commandes


118

I.2. Diagramme d’activité de navigation pour l’administrateur et le

superviseur

Figure 85: diagramme d'activité de navigation pour l'administrateur et le superviseur

I.3. Diagramme d’activité de navigation pour l’entreprise :

NON

OUI

statistique

modifier

valider

afficher catalogue

affichermodifier

gerer uti l isateur

afficherafficherafficher

ajouter

ajouter

commande

afficher commande

afficher commande

imprimer

details

imprimer

details

imprimerdetails

<<page>>authentification

données valides

<<page>>acceuil

<<page>>statistique

<<page>>vitrine

<<page>>modifier vitrine

<<page>>catalogue

<<page>>produit en attente

<<page>>modifier produit

<<page>>uti lisateur

<<page>>employée

<<page>>responsable entreprise

<<page>>client

<<page>>ajouter responsable

<<page>>ajouter employée

<<page>>commande

<<page>>ethiquette

<<page>>commande préparer

<<page>>commande non préparer

<<page>>details commande


119

Figure 86: diagramme d'activité de navigation pour l'entreprise

II. Diagramme de classe global

Après avoir identifié les différentes classes qui interviennent dans notre application, il est

temps de modéliser le diagramme de classe global de notre site.

contacter

NON

OUI

statistique

afficher catalogue

ajouter

modifier

commande

afficher commande

afficher commande

imprimer

details

imprimer

details

imprimerdetails

<<page>>authentification

données valides

<<page>>acceuil

<<page>>statistique

<<page>>vitrine

<<page>>catalogue

<<page>>ajouter produit

<<page>>modifier produit

<<page>>commande

<<page>>ethiquette

<<page>>commande préparer

<<page>>commande non préparer

<<page>>details commande

<<page>>contact


120

Figure 87 : diagramme de classe global


ctr_commande

commande

sous_commande


121

En effet, le diagramme de classe permet de présenter la vue structurelle de notre application

sous forme de classe contenant des attributs et des méthodes et aussi des relations

sémantiques.

Avant de franchir cette étape, il faut assurer la validation de notre diagramme de classe. En

faite, selon GILLES ROY dans son livre « conception d’une base de données avec UML », et

par analogie avec le modèle conceptuel de données (notation MERISE), la validation d’un

diagramme de classe se conclut en cinq points qui peuvent être décrits comme suit :

Règle 1 d’identité : chaque entité doit posséder un identifiant. Cet identifiant est généralement

explicite. Il peut être implicite dans trois cas. Soit :

a-pour une entité d’association où il est formé par défaut de la combinaison des identifiants

des entités de l’association

b-une entité de type composant où il est formé de la combinaison de l’identifiant du

composant avec celui de son composite

c-pour une association d’héritage où une entité qui hérite des attributs d’une autre reçoit par

conséquent l’identifiant de cette dernière et ne possède jamais d’identifiant qui lui est propre.

Il faut éviter de faire d’apparaître explicitement un identifiant qui soit en fait implicite. Cela

conduit à la transgression des règles 3 et 4

Règle 2 de description : chaque attribut ne peut avoir qu’une seule valeur à la fois et cette

donnée doit avoir un caractère élémentaire, c’est-à-dire posséder un type de données simple.

Règle 3 de non-redondance : un attribut ne peut figurer qu’une seule fois dans le diagramme

entité association.

Règle 4 de construction : Les attributs d’une entité décrivent bien cette entité et lui

appartiennent en propre. Aucun ne peut. Appartenir à une autre entité. Là. Valeur de

chaque attribut est déterminée de manière

unique par la valeur de l’identifiant .cette règle possède un corollaire : il faut éviter de

répliquer un attribut dans une entité provenant d’une deuxième entité pour signifier

qu’elles sont liées pour ce faire, il faut employer une association.


122

Règle 5 de décomposition : Il est souhaitable de décomposer les associations de degré

supérieur le cas échéant. Deux situations se prêtent à la décomposition :

1. Une des multiplicités maximales est égalé à 1

2. Il existe une dépendance. Fonctionnel entre-deux identifiant parmi les entités associées

Maintenant, après la validation de notre diagramme de classe, nous pouvons déduire notre

base de données.

III. Traitement des méthodes

L’environnement orienté objet se caractérise par l’encapsulation des données et les

traitements. Dans cette section nous traitons les méthodes de nos classes de conception et par

la suite nous déduirons le schéma final de notre base de données dans la section suivante.

Description des méthodes de la classe « categorie_produit »

Méthodes Type

retourné Paramètres Description

Get_Categorie_Produit Cursor $bdd,$fields,$cond,$tab Retourner la liste des catégories produits

Add_Categorie_Produit Boolean $bdd,$val Ajouter une nouvelle catégorie de produit

Delete_Categorie_Produit Boolean $bdd,$id Supprimer une catégorie de produit

Description des méthodes de la classe « categorie_vitrine »

Méthodes Type


Get_Categorie_Vitrine Cursor $bdd,$fields,$cond,$tab Retourner la liste des catégories vitrines

Add_Categorie_Vitrine Boolean $bdd,$val Ajouter une nouvelle catégorie de vitrine

Delete_Categorie_Vitrine Boolean $bdd,$id Supprimer une catégorie de vitrine


123

Description des méthodes de la classe « commande »

Méthodes Type retourné

Paramètres Description

Get_Commande Cursor $bdd,$fields,$tab,$cond Retourner les commandes passées

Add_Commande Boolean $bdd,$fields,$seq Ajouter une nouvelle commande

Description des méthodes de la classe « entreprise »

Méthodes Type


Add_Entreprise Void $bdd,$fields,$id Ajouter une nouvelle entreprise

Get_Entreprise Cursor $bdd,$fields,$cond,$table Retourner les entreprises enregistrées

Description des méthodes de la classe « panier »

Méthodes Type


Create_Card Boolean $bdd Création du panier Find_Product Boolean $bdd,$id Chercher un produit

dans le panier Update_Card Void $bdd Mise à jour du

panier Add_Product Void $bdd,$id,$qte,$poid,$prix Ajouter un produit

dans le panier Delete_Product Void $bdd,$id,$qte,$poid,$prix Supprimer un

produit du panier Update_Product Void $bdd,$id,$qte,$poid Modifier un produit

dans le panier

Description des méthodes de la classe « produit »



Add_Produit Boolean $bdd,$fields,$fp Ajouter un nouveau produit

Get_Produit Cursor $bdd,$fields,$table,$cond Retourner les produits

Validation_Produit Void $bdd,$id,$val Valider ou annuler un produit

Delete_Produit Boolean $bdd,$id Supprimer un produit


124

Description de la classe « promotion »



Add_Promotion Void $bdd,$id,$n_prix,$debut,$fin Ajouter une nouvelle promotion

Description des méthodes de la classe « service »

Méthodes Type retourné Paramètres Description Get_Service Cursor $bdd,$fields,$table,$cond Retourner les

services

Description des méthodes de la classe « sous_commande »



Add_Sous_Commande Boolean $bdd,$id,$fields,$seq Ajouter une nouvelle sous commande

Get_Sous_Commande Cursor $bdd,$fields,$table,$cond Retourner les sous commande enregistrées

Preparer Int $bdd,$id,$prefixe Attribuer un numéro d’envoie a une sous commande

Get_Numero String $bdd,$prefixe Calculer le numero d’envoie

Description des méthodes de la classe « vitrine »

Méthodes Type


Get_Vitrine Cursor $bdd,$fields,$table,$cond Retourner les vitrines

Delete_Vitrine Boolean $bdd,$id Supprimer une vitrine

Créer_Vitrine Boolean $bdd,$fields,$fp Créer une nouvelle vitrine


125

IV. Implémentation

IV.1. Base de données

Nous consacrons cette section pour la présentation des règles permettant de décrire le schéma

logique de notre application (les tables de notre base de données) à partir d’un diagramme

entité/association (diagramme de classe).

IV.1.1. Règles de passage du modèle conceptuel vers le modèle logique :14

La déduction du schéma relationnel se base sur quatre règles qui sont présenté comme suit :

Règle 1 : transformation des entités/classes

Chaque classe du diagramme UML devient une relation. Il faut choisir un attribut de la classe

pouvant jouer le rôle d’identifiant.

Si aucun attribut ne convient en tant qu’identifiant, il faut en ajouter un de telle sorte que la

relation dispose d’une clé primaire (les outils proposent l’ajout de tels attributs).

Figure 88: règle 1 du passage du modèle conceptuel vers le modèle logique

Règle 2 : transformation des associations :

Les règles de transformation des associations dépendent de leurs cardinalités maximale.

Association un à plusieurs :

Il faut ajouter un attribut de type clé étrangère dans la relation fils de l’association. L’attribut

porte le nom de la clé primaire de la relation père de l’association.

14 Ces règles sont prises du livre UML2 pour les bases de données de Christian Soutou


126

Figure 89:règle 2 du passage du modèle conceptuel vers le modèle logique

Les associations plusieurs à plusieurs :

L’association (ou la classe classe-association) devient une relation dont la clé primaire est

composée par la concaténation des identifiants des classes connectés à l’association. Chaque

attribut devient clé étrangère si classe connectée dont il provient devient une relation en vertu

de la règle R1.

Les attributs de l’association (ou la classe-association) doivent être ajoutés à la nouvelle

relation. Ces attributs ne sont ni clé primaire, ni clé étrangère.

Figure 90: règle 3 du passage du modèle conceptuel vers le modèle logique (premier cas)

Association un à un :

il faut ajouter un attribut clé étrangère dans la relation dérivée de la classe ayant la multiplicité

minimale égale à un. L’attribut porte le nom de la clé primaire de la relation dérivée de

l’entité (classe) connectée à l’association.


127

Si les deux cardinalités (multiplicités) minimales sont à zéro, le choix est donné entre les deux

relations dérivées de la règle R1. Si les deux cardinalités minimales sont à un, il est sans doute

préférable de fusionner les deux entités (classes) en une seule.

Figure 91: règle 3 du passage du modèle conceptuel vers le modèle logique (deuxième cas)

Transformation de l’héritage :

S’il existe une contrainte de totalité ou de partition sur l’association, il est possible de ne pas

traduire la relation issue de la surclasse. Il faut alors faire migrer tous ses attributs dans la (les)

relation(s) issue(s) de la (des) sous-classe(s).

Dans le cas contraire, il faut faire migrer tous ses attributs dans la ou les relation(s) issue(s)

de la (des) sous-classe(s) dans la (les) relation(s) issue(s) de la (des) sous-classe(s).

Figure 92: règle 3 du passage du modèle conceptuel vers le modèle logique (troisième cas)

Transformation de la composition :

La clé primaire des relations déduites des classes composantes doit contenir l’identifiant de la

classe composite (quelles que soient les multiplicités).


128

Figure 93: règle 3 du passage du modèle conceptuel vers le modèle logique (quatrième cas)

IV.1.2. Schéma final de la base de données Dans ce qui suit nous présentons les tables de notre base de données, tout en tenant compte de

type et des contraintes de leurs attributs.

Champ Type de données contraintes

ID_COMPTE NUMBER PRIMARY_KEY

MAIL VARCHER2 UNIQUE

PASSWORD VARCHAR2 NOT_NULL

TYPE_USER VARCHAR2 NOT_NULL

Tableau 36: table « COMPTE_USER »

Champ Type de données contraintes ID_INTERNAUTE NUMBER PRIMARY_KEY NOM VARCHAR2 NOT_NULL PRENOM VARCHAR2 NOT_NULL MAIL VARCHAR2 UNIQUE PAYS VARCHAR2 NOT_NULL VILLE VARCHAR2 NOT_NULL CODE_POSTALE NUMBER NOT_NULL NUMERO_VOIE NUMBER NOT_NULL TYPE_VOIE VARCHAR2 NOT_NULL NOM_VOIE VARCHAR2 NOT_NULL

Tableau 37 : table « CLIENT »

Champ Type de données Contraintes ID_INTERNAUTE VARCHAR2 PRIMARY_KEY MAIL VARCHAR2 NOT_NULL TEL NUMBER NOT_NULL NOM_ENTREPRISE VARCHAR2 NOT_NULL FAX NUMBER NOT_NULL SIEGE VARCHAR2 NOT_NULL FORME_JURIDIQUE VARCHAR2 NOT_NULL CAPITAL NUMBER NOT_NULL REGISTRE_DE_COMMERCE VARCHAR2 NOT_NULL CODE_TVA VARCHAR2 NOT_NULL PAYS VARCHAR2 NOT_NULL


129

CODE_POSTALE VARCHAR2 NOT_NULL VILLE VARCHAR2 NOT_NULL

Tableau 38 : table « ENTREPRISE »

Champ Type de données Contraintes ID_INTERNAUTE NUMBER PRIMARY_KEY MAIL VARCHAR2 NOT_NULL TEL NUMBER(8) NOT_NULL NOM VARCHAR2 NOT_NULL PRENOM VARCHAR2 NOT_NULL

Tableau 39 : Table « SUPERVISEUR »

Champ Type de données Contraintes ID_VITRINE NUMBER PRIMARY_KEY NOM VARCHAR2 NOT_NULL TEMPLATE VARCHAR2 NOT_NULL LOGO BLOB NOT_NULL TEL_CONTACT NUMBER UNIQUE VILLE_DEPOT VARCHAR2 NOT_NULL NIMERO_VOIE NUMBER NOT_NULL TYPE_VOIE VARCHAR2 NOT_NULL NOM_VOIE VARCHAR2 NOT_NULL ID_INTERNAUTE NUMBER FOREIGN_KEY ID_CATEGORIE NUMBER FOREIGN_KEY DEBUT_CONTRAT DATE NOT_NULL FIN_CONTRAT DATE NOT_NULL GOUVERNERAT VARCHAR2 NOT_NULL

Tableau 40 : Table « VITRINE »

Champ Type de données Contraintes ID_CATEGORIE NUMBER PRIMARY_KEY LIBELLE VARCHAR2 UNIQUE

Tableau 41 : Table « CATEGPRIE_VITRINE »

Champ Type de données Contraintes ID_PRODUIT NUMBER PRIMARY_KEY NOM VARCHAR2 NOT_NULL ETAT NUMBER NOT_NULL, DEFAULT 0 PRIX NUMBER NOT_NULL POID NUMBER NOT_NULL QUANITE_STOCK NUMBER NOT_NULL DESCRIPTION VARCHAR2 NOT_NULL IMAGE BLOB NOT_NULL ID_VITRINE NUMBER FOREIGN_KEY ID_CAT_PRODUIT NUMBER FOREIGN_KEY

Tableau 42 : Table « PRODUIT »


130

Champ Type de données Contraintes ID_CAT_PRODUIT NUMBER PRIMARY_KEY CATEGPRIE_PRODUIT VARCHAR2 NOT_NULL ID_CATEGORIE NUMBER FOREIGN_KEY, PRIMARY_KEY

Tableau 43 : Table « CATEGPRIE_PRODUIT »

Champ Type de données Contraintes ID_PROMO NUMBER PRIMARY_KEY DATE_DEBUT DATE NOT_NULL DATE_FIN DATE NOT_NULL PRIX NUMBER NOT_NULL ID_PRODUIT NUMBER FOREIGN_KEY

Tableau 44 : Table « PROMOTION »

Champ Type de données Contraintes ID_PANIER NUMBER PRIMARY_KEY NB_ARTICLE NUMBER ---------------------- MONTANT NUMBER ---------------------- POIDS NUMBER ---------------------- DATE_CREATION DATE NOT_NULL ETAT NUMBER NOT_NULL, DEFAULT 0

Tableau 45: Table « PANIER »

Champ Type de données Contraintes QUENITE NUMBER ID_PANIER NUMBER FOREIGN_KEY, PRIMARY_KEY ID_PRODUIT NUMBER FOREIGN_KEY, PRIMARY_KEY

Tableau 46 : Table « PRODUIT_PANIER »

Champ Type de données Contraintes ID_SOUS_COMMANDE NUMBER PRIMARY_KEY MONTANT NUMBER NOT_NULL POIDS NUMBER NOT_NULL NB_ARTICLE NUMBER NOT_NULL NUMERO_ENVOIE VARCHAR2 ----------------- ETAT VARCHAR2 DEFAULT 0 DATE_COMMANDE DATE NOT_NULL NUMERO NUMBER FOREIGN_KET,PRIMARY_KEY CODE_SERVICE VARCHAR2 NOT_NULL NUM_VOIE_LIVRAISON NUMBER ----------------- VILLE_LIVRAISON VARCHAR2 NOT_NULL TYPE_VOIE VARCHAR2 NOT_NULL NOM_VOIE_LIVRAISON VARCHAR2 NOT_NULL ID_PANIER NUMBER FOREIGN_KEY ID_INTERNAUTE NUMBER FOREIGN_KEY

Tableau 14 :Table « COMMANDE »


131

Champ Type de données Contraintes CODE_SERVICE VARCHAR2 NOT_NULL LIBELLE VARCHAR2 UNIQUE PREFIXE VARCHAR2 UNIQUE DUREE_LIVRAISON_NAT VARCHAR2 NOT_NULL DUREE_LIVRAISON_INTER VARCHAR2 NOT_NULL

Tableau 15 : Table « SERVICE »

Champ Type de données Contraintes CODE_UNITE VARCHAR2 PRIMARY_KEY LIBELLE VARCHAR2 NOT_NULL NOM_RESPONSABLE VARCHAR2 NOT_NULL ADRESSE VARCHAR2 NOT_NULL VILLE VARCHAR2 NOT_NULL TEL NUMBER NOT_NULL FAX NUMBER NOT_NULL MAIL VARCHAR2 NOT_NULL CODE_IPS VARCHAR2 NOT_NULL CODE_GOUVERNERAT VARCHAR2 FOREIGN_KEY

Tableau 16 : Table « UNITE_COMMERCIALE »

Champ Type de données Contraintes CODE_TOURNE VARCHAR2 PRIMARY_KEY PARITE VARCHAR2 NOT_NULL DEBUT NUMBER NOT_NULL FIN NUMBER NOT_NULL NOM_TOURNE VARCHR2 NOT_NULL TYPE_VOIE VARCHAR2 NOT_NULL CODE_UNITE NUMBER FOREIGN_KEY

Tableau 17 : Table « TOURNE »

Champ Type de données Contraintes MATRICULE VARCHAR2 PRIMARY_KEY NOM VARCHAR2 NOT_NULL PRENOM VARCHAR2 NOT_NULL GSM NUMBER NOT_NULL CODE_TOURNE VARCHAR2 FOREIGN_KEY MOYEN_TRANSPORT VARCHAR2 NOT_NULL

Tableau 18 : Table « FACTEUR »

Champ Type de données Contraintes ID_VITRINE NUMBER FOREIGN_KEY, PRIMARY_KEY CODE_UNITE NUMBER FOREIGN_KEY, PRIMARY_KEY

Tableau 19 : Table « PARTENAIRE »


132

Champ Type de données Contraintes CODE_UNITE VARCHAR2 FOREIGN_KEY, PRIMARY_KEY CODE_SERVICE VARCHAR2 FOREIGN_KEY, PRIMARY_KEY

Tableau 20 : Table « UNITE_SERVICE »

Champ Type de données Contraintes CODE_GOUVERNERAT NUMBER PRIMARY_KEY NOM VARCHAR2 UNIQUE

Tableau 21 : Table « GOUVERNERAT »

IV.2. Implémentation IV.2.1. Environnement de développement

Nous avons choisi comme environnement de développement PHP5 et Oracle 10g. Le choix de

PHP5 comme langage de développement s’est basé sur ses avantages. Premièrement ce

langage est open source. Il est très facile à manipuler par rapport aux autres langages de

programmation orienté objet. Ainsi PHP ne nécessite pas d’être compilé comme le J2EE ou

ASP.NET.

Le choix d’Oracle est parce qu’il est le leader du marché des SGBDR, avec une part de

marché allant jusqu’à 48.6% en 2007 (Gartner Group). Aussi oracle est l’un des plus robuste

SGBD (voir annexe 2).

IV.2.1. Diagramme de déploiement

Le diagramme de déploiement permet de représenter la répartition géographique des

composants matériels de notre système sous forme de nœuds


133

Figure 94: diagramme de déploiement

V. Les tests V.1. Principe

Le test présente la dernière activité dans tous cycles de développement d’un logiciel. En effet,

cette activité vise à la recherche des anomalies dans le comportement du logiciel et mettre en

évidence les erreurs afin de les corriger et d’arriver à un produit zéro défaut.

La construction des jeux de tests se classe selon trois approches. La première dite approche

aléatoire dont le principe est de sélectionner au hasard sur le domaine de définition des entrées

du programme. La deuxième approche est l’approche fonctionnelle ou boite noire qui

considère seulement les spécifications de ce que doit faire un programme sans considérer sa

structure interne. Et enfin, l’approche structurelle ou boite blanche est la dernière et qui tient

en compte la structure interne du module.

V.2. Construction des jeux de tests Pour tester notre portail nous avons choisir d’adapter l’approche fonctionnelle ou boite noire

puisqu’elle s’appuie principalement sur la vérification des résultats attendus par rapport a

celle obtenue. En premier lieu, nous commençons par les tests unitaires qui nous permettent

de vérifier le bon fonctionnement des différents modules de notre portail, et ainsi de suite

TCP/IP

Requette HTTP

Requette HTTPRequette HTTP

Requette HTTP

serveur web

appache

serveur base de données

oracle 10g

base de données

client

navigateur web

superviseur

navigateur web

administrateur

navigateur web

responsable entreprise

navigateur web


134

nous finissons par les tests d’intégration qui nous assure de vérifier la complémentarité entre

les différents modules.

V.2.1. Test du cas d’utilisation « imprimer étiquette »

Figure 95: imprimer étiquette

Figure 96: étiquette de la commande

Lorsque l’entreprise demande l’impression d’une étiquette, elle a le choix soit d’imprimer

une étiquette collante ou une étiquette au format A5.

L’entreprise choisit d’imprimer une étiquette


135

V.2.2. Test du cas d’utilisation « supprimer un produit »

Lorsque l’entreprise demande la suppression d’un produit, le système lui affiche un message

de confirmation.

Figure 97: supprimer un produit

Lorsque l’entreprise valide son choix, le produit sera supprimé.

Figure 98: produit supprimé


136

V.2.3. Test des cas d’utilisation « ajouter un produit » et « valider un

produit »

Nous allons tester ces deux cas ensemble parce qu’ils sont complémentaires. Lorsque

l’entreprise ajoute un produit, ce dernier reste en attente de sa validation auprès du

superviseur de la poste.

Figure 99: ajouter un produit

Maintenant le produit est ajouté avec un état 0 (en attente)

Le poids du produit ne doit pas dépasser 30 kg


137

Figure 100: produit en attente

Ainsi, lorsque le superviseur consulte la liste des produits en attentes, il a le choix soit de les

valider soit de les annuler.

Figure 101: valider un produit

Maintenant le produit est valide et peut être vendu sur notre place de marché

Le produit est en attente de validation

Le superviseur valide le produit


138

Figure 102: produit valide

L’état du produit est changé

Conclusion et perspective

139

Conclusion et perspectives

Dans le cadre de notre stage effectué au sein du centre de tri de la poste tunisienne, nous

avons conçu et réalisé une place de marché B2C qui présente une nouvelle approche de la

notion des places de marché traditionnelles. L’idée de ce projet est inspirée principalement de

quelques entreprises brick and mortar15 existant sur le marché tunisien comme « Géant » et

« Carrefour ». Pour la réalisation de ce projet, nous avons adopté différents outils de

conception et de développement.

D’un point de vue technique, ce projet a été très intéressant sur plusieurs axes. Premièrement,

avant ce stage, nous ne possédions que des connaissances théoriques sur les outils de

développement (PHP5, Oracle, JQuery, etc.) et les méthodologies de conception (UML2,

processus unifié) que nous avons adoptées pour la réalisation de notre portail. Ainsi, ce stage

nous a permis d’acquérir des connaissances approfondies sur les environnements de

développement aussi que la découverte du monde professionnel.

Notre projet ne s’arrête jamais à ce niveau puisque nous possédons plusieurs idées qui

peuvent améliorer sa valeur.

Durant la phase de conception et de réalisation de notre portail, nous avons choisi de limiter le

poids des commandes relatif à une même vitrine à 30 kg pour des contraintes liées aux

réseaux de distribution de la poste. Toute fois nous pouvons éliminer cette contrainte à

condition que la poste améliore son réseau dans le futur. En outre, nous pouvons donner aussi

aux entreprises inscrites, qui possèdent un réseau de logistique, le droit de s’occuper de la

livraison de leurs propres commandes si elles le désirent.

Ainsi, lors de l’étape de commande, le client est obligé de s’identifier ou d’ouvrir un compte

s’il ne le possède pas encore. Le problème qui se pose ici est comment s’assurer que les

informations données par le client lors de son inscription sont justes, et comment suivre ce

client par la suite s’il utilise une carte qui n’est pas propre à lui. Une solution développée par

la poste peut être intégrée pour s’assurer de la conformité de ces données, c’est le mailpost.

Le principe est très facile, lors de l’étape d'authentification, il suffit que les clients saisissent

15 Brick and mortar : un terme qui désigne les entreprises de vente traditionnelle, c'est-à-dire avec des points de vente physique

Conclusion et perspective

140

son adresse mail et son mot de passe et notre système soit capable de récupérer les données

nécessaires auprès du serveur de la poste. Les avantages de cette solution est que seulement

les personnes qui possèdent un compte mailpost peuvent acheter de notre place de marché ce

qui implique que tous les clients sont certifiés par la poste qui augmente le volet de sécurité de

notre système.

Enfin, face à l’émergence du m-commerce nous pouvons transformer notre place de marché

en une application mobile et intégrant une solution qui permet au client de suivre l’état de sa

commande en temps réel. Ceci peut faire l’objet d’ultérieures recherches.

Bibliographie

141

Bibliographie

Pascal Roques. UML2 modéliser une application web. Éditions Eyrolles, 4è édition, 2008.

Christian Soutou. UML2 pour les bases de données. Éditions Eyrolles, 2007.

Gilles Roy. Conception de la base de données avec UML. Presses de l'Université du Québec, 2007.

[1] Kooli Walid. Les places de marchés. Ecole supérieure de commerce électronique Manouba, 2009

[7] Jacques Lonchamp. Génie logicien Les techniques de vérification. CNAM - CRA Nancy, 2003

Webographie

[2] http://encyclopedie.linternaute.com/definition/566/1/enchere_inversee.shtml. Consulté le 25/04/2011.

[3] http://www.definitions-marketing.com/Definition-Cible. Consulté le 06/03/2011

[4] http://www.marketing-etudiant.fr/definitions/c/concurrence.php. Consulté le 06/03/2011

[5] http://ec.europa.eu/europeaid/evaluation/methodology/examples/too_swo_res_fr.pdf. Consulté le 27/04/2011

[6]http://www.grosmax.uqam.ca/nguyen_tho/INF7215/PDF/La%20sp%C3%A9cification%20des%20besoins.pdf. Consulté le 06/05/2011

Annexe A

142

Annexe A

I. Le processus unifié

I.1. Définition Le processus unifié est un processus de développement logiciel itératif, centré sur

l'architecture, piloté par des cas d'utilisation et orienté vers la diminution des risques.

C'est un patron de processus pouvant être adaptée à une large classe de systèmes logiciels, à

différents domaines d'application, à différents types d'entreprises, à différents niveaux de

compétences et à différentes tailles de l'entreprise.

I.2. Caractéristique du processus unifié

I.2.1. Le processus unifié est itératif L'itération est une répétition d'une séquence d'instructions ou d'une partie de programme un

nombre de fois fixé à l'avance ou tant qu'une condition définie n'est pas remplie, dans le but

de reprendre un traitement sur des données différentes.

Elle qualifie un traitement ou une procédure qui exécute un groupe d'opérations de façon

répétitive jusqu'à ce qu'une condition bien définie soit remplie.

Figure 103 : caractéristique du processus unifié

Une itération prend en compte un certain nombre de cas d'utilisation et traite en priorité les risques majeurs.

Annexe A

143

I.3.1. Le processus unifié est centré sur l’architecture Tout système complexe doit être décomposé en parties modulaires afin de garantir une

maintenance et une évolution facilitées. Cette architecture (fonctionnelle, logique, matérielle,

etc.) doit être modélisée en UML et pas seulement documentée en texte.

I.3.2. Le processus unifié est piloté par les cas d’utilisation Le but principal d'un système informatique est de satisfaire les besoins du client. Le processus

de développement sera donc accès sur l'utilisateur. Les cas d'utilisation permettent d'illustrer

ces besoins.

Ils détectent puis décrivent les besoins fonctionnels (du point de vue de l'utilisateur), et leur

ensemble constitue le modèle de cas d'utilisation qui dicte les fonctionnalités complètes du

système.

I.4. Les différents phases du processus unifié

Analyse des besoins L'analyse des besoins donne une vue du projet sous forme de produit fini.

Cette phase porte essentiellement sur les besoins principaux (du point de vue de l'utilisateur),

l'architecture générale du système, les risques majeurs, les délais et les coûts .On met en place

le projet.

Elle répond aux questions suivantes :

que va faire le système ? par rapport aux utilisateurs principaux, quels services va-t-il

rendre?

quelle va être l'architecture générale (cible) de ce système

quels vont être : les délais, les coûts, les ressources, les moyens à déployer?

Elaboration L'élaboration reprend les éléments de la phase d'analyse des besoins et les précise pour arriver

à une spécification détaillée de la solution à mettre en oeuvre.

L'élaboration permet de préciser la plupart des cas d’utilisation, de concevoir l’architecture du

système et surtout de déterminer l'architecture de référence.

Au terme de cette phase, les chefs de projet doivent être en mesure de prévoir les activités et

d’estimer les ressources nécessaires à l’achèvement du projet. Les taches à effectuer dans la

phase élaboration sont les suivantes :

créer une architecture de référence

identifier les risques, ceux qui sont de nature à bouleverser le plan, le coût et le calendrier

Annexe A

144

définir les niveaux de qualité à atteindre- formuler les cas d'utilisation pour couvrir les

besoins fonctionnels et planifier la phase de construction

élaborer une offre abordant les questions de calendrier, de personnel et de budget

construction La construction est le moment où l’on construit le produit. L’architecture de référence se

métamorphose en produit complet.

Le produit contient tous les cas d’utilisation que les chefs de projet, en accord avec les

utilisateurs ont décidé de mettre au point pour cette version.

Transition Le produit est en version bêta. Un groupe d’utilisateurs essaye le produit et détecte les

anomalies et défauts.

Cette phase suppose des activités comme la formation des utilisateurs clients, la mise en

œuvre d’un service d’assistance et la correction des anomalies constatées.

Figure 104 : les phases du processus unifié

II. UML (Unified Modeling Language)

II.1. Définition UML se définit comme un langage de modélisation graphique et textuel destiné à comprendre

et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures

logicielles, concevoir des solutions et communiquer des points de vue.

Annexe A

145

UML unifie à la fois les notations et les concepts orientés objet. Il ne s’agit pas d’une simple

notation graphique, car les concepts transmis par un diagramme ont une sémantique précise et

sont porteurs de sens au même titre que les mots d’un langage.

Figure 105 : historique d'UML

II.2. Différents diagramme UML UML 2 s’articule autour de treize types de diagrammes, chacun d’eux étant dédié à la

représentation des concepts particuliers d’un système logiciel. Ces types de diagrammes sont

répartis en deux grands groupes :

Six diagrammes structurels

Diagramme de classes : Il montre les briques de base statiques : classes, associations,

interfaces, attributs, opérations, généralisations, etc.

Diagramme d’objets : Il montre les instances des éléments structurels et leurs liens à

l’exécution.

Annexe A

146

Diagramme de packages : Il montre l’organisation logique du modèle et les relations entre

packages.

Diagramme de structure composite : Il montre l’organisation interne d’un élément statique

complexe.

Diagramme de composants : Il montre des structures complexes, avec leurs interfaces

fournies et requises.

Diagramme de déploiement : Il montre le déploiement physique des « artefacts » sur les

ressources matérielles.

Sept diagrammes comportementaux

Diagramme de cas d’utilisation : Il montre les interactions fonctionnelles entre les acteurs

et le système à l’étude.

Diagramme de vue d’ensemble des interactions : Il fusionne les diagrammes d’activité et

de séquence pour combiner des fragments d’interaction avec des décisions et des flots.

Diagramme de séquence : Il montre la séquence verticale des messages passés entre objets

au sein d’une interaction.

Diagramme de communication : Il montre la communication entre objets dans le plan au

sein d’une interaction.

Diagramme de temps : Il fusionne les diagrammes d’états et de séquence pour montrer

l’évolution de l’état d’un objet au cours du temps.

Diagramme d’activité : Il montre l’enchaînement des actions et décisions au sein d’une

activité.

Diagramme d’états : Il montre les différents états et transitions possibles des objets d’une

classe.

Annexe B

147

Annexe B

I. Netbeans NetBeans est un environnement de développement intégré (EDI), placé en open source par Sun en juin 2000 sous licence CDDL et GPLv2 (Common Development and Distribution License). En plus de Java, NetBeans permet également de supporter différents autres langages, commePython, C, C++, JavaScript, XML, Ruby, PHP et HTML. Il comprend toutes les caractéristiques d'un IDE moderne (éditeur en couleur, projetsmulti-langage, refactoring, éditeur graphique d'interfaces et de pages Web).

Conçu en Java, NetBeans est disponible sous Windows, Linux, Solaris (sur x86 et SPARC), Mac OS X ou sous une version indépendante des systèmes d'exploitation (requérant une machine virtuelle Java). Un environnement Java Development Kit JDK est requis pour les développements en Java.

NetBeans constitue par ailleurs une plate forme qui permet le développement d'applications spécifiques (bibliothèque Swing (Java)). L'IDENetBeans s'appuie sur cette plate forme.

L'IDE Netbeans s'enrichit à l'aide de plugins.

II. PHP5

II.1. Présentation Le langage PHP est utilisé principalement en tant que langage de script côté serveur, ce qui veut dire

que c'est le serveur (la machine qui héberge la page Web en question) qui va interpréter le code PHP et

générer du code (constitué généralement d'XHTML ou d'HTML, de CSS, et parfois de JavaScript) qui

pourra être interprété par un navigateur. PHP peut également générer d'autres formats en rapport avec

le Web, comme le WML, le SVG, le format PDF, ou encore des images bitmap telles

que JPEG, GIF ou PNG.

Il a été conçu pour permettre la création d'applications dynamiques, le plus souvent dédiées au Web.

PHP est très majoritairement installé sur un serveur Apache, mais peut être installé sur les autres

principaux serveurs HTTP du marché, par exemple IIS. Ce couplage permet de récupérer des

informations issues d'une base de données, d'un système de fichiers (contenu de fichiers et de

l'arborescence) ou plus simplement des données envoyées par le navigateur afin d'être interprétées ou

stockées pour une utilisation ultérieure.

Annexe B

148

C'est un langage peu typé et souple et donc facile à apprendre par un débutant mais, de ce fait, des

failles de sécurité peuvent rapidement apparaître dans les applications. Pragmatique, PHP ne

s'encombre pas de théorie et a tendance à choisir le chemin le plus direct. Néanmoins, le nom des

fonctions (ainsi que le passage des arguments) ne respecte pas toujours une logique uniforme, ce qui

peut être préjudiciable à l'apprentissage.

Son utilisation commence avec le traitement des formulaires puis par l'accès aux bases de données.

L'accès aux bases de données est aisé une fois l'installation des modules correspondant effectuée sur le

serveur. La force la plus évidente de ce langage est qu'il a permis au fil du temps la réalisation aisée de

problèmes autrefois compliqués et est devenu par conséquent un composant incontournable des offres

d'hébergements.

Il est multiplate-forme : autant sur Linux qu'avec Windows il permet aisément de reconduire le même

code sur un environnement à peu près semblable (prendre en compte les règles d'arborescences de

répertoires qui peuvent changer).

Libre, gratuit, simple d'utilisation et d'installation, ce langage nécessite comme tout langage de

programmation une bonne compréhension des principales fonctions usuelles ainsi qu'une connaissance

aiguë des problèmes de sécurité liés à ce langage.

La version 5.3 a introduit de nombreuses fonctionnalités : les espaces de noms – un élément

fondamental de l'élaboration d'extensions, de bibliothèques et de frameworks structurés –,

les fonctions anonymes , les fermetures, etc.

La version 6 introduira en interne la bibliothèque ICU donnant au langage la faculté de

traiter Unicode de manière native.

II.2. Fonctionnement PHP appartient à la grande famille des descendants du C, dont la syntaxe est très proche. En

particulier, sa syntaxe et sa construction ressemblent à celles des langages Java et Perl, à la

différence que du code PHP peut facilement être mélangé avec du code HTML au sein d'un

fichier PHP.

Dans une utilisation Web, l'exécution du code PHP se déroule ainsi : lorsqu'un visiteur

demande à consulter une page Web, son navigateur envoie une requête au serveur

HTTP correspondant. Si la page est identifiée comme un script PHP (généralement grâce à

l'extension .php), le serveur appelle l'interprète PHP qui va traiter et générer le code final de la

page (constitué généralement d'HTMLou de XHTML, mais aussi souvent de CSS et de JS).

Ce contenu est renvoyé au serveur HTTP, qui l'envoie finalement au client.

Annexe B

149

Ce schéma explique ce fonctionnement :

Figure 106 : fonctionnement de PHP5

III. Jquery

Figure 107 : jquery

jQuery est une petite bibliothèque JavaScript facilitant l'écriture de scripts.

Ses principaux avantages sont:

la compatibilité avec tous les navigateurs: plus besoin de truffer votre code de tests pour

l'adapter au navigateur, jQuery s'occupe de tout;

jQuery est compacte (pas plus de 15ko, ça ne surcharge pas vos pages) et rapide (son

créateur, John Resig est une grosse tête, demi-dieu du JavaScript. C'est un des principaux

développeurs du moteur JavaScript de Firefox);

sa syntaxe est élégante, puissante, peu verbeuse, et s'apprend très rapidement;

jQuery est extensible: des centaines de plugins existent, en particuliers de très

nombreux effets graphiques;

Le principe de base est le suivant: vous créez un objet jQuery pointant vers un ou plusieurs

éléments de votre document, et vous appelez ses méthodes. La plupart de celles-ci renvoient

un objet jQuery, ce qui permet de chaîner les actions.

Annexe B

150

IV. Oracle

IV.1. Présentation Oracle est un SGBD (système de gestion de bases de données) édité par la société du même

nom (Oracle Corporation - http://www.oracle.com), leader mondial des bases de données.

La société Oracle Corporation a été créée en 1977 par Lawrence Ellison, Bob Miner, et Ed

Oates. Elle s'appelle alors Relational Software Incorporated (RSI) et commercialise un

Système de Gestion de Bases de données relationnelles (SGBDR ou RDBMS pour Relational

Database Management System) nomméOracle.

En 1979, le premier prototype (RDBMS - RSI1) intégrant la séparation des espaces

d'adressage entre les programmes utilisateurs et le noyau Oracle est commercialisé. Cette

version est entièrement développée en langage assembleur. La seconde version (RDBMS -

RSI2) est un portage de l'application sur d'autres plates-formes.

En 1983 la troisième version apporte des améliorations au niveau des performances et une

meilleure prise en charge du SQL. Cette version est entièrement codée en langage C. A la

même époque RSI change de raison sociale et devient Oracle.

En 1984 la première version d'Oracle (Oracle 4) est commercialisée sur les machines IBM.

En 1985 Oracle 5 permet une utilisation client-serveur grâce au middleware SQL*Net.

En 1986 Oracle a été porté sur la plateforme 8086.

En 1988 Oracle 6 est disponible sur un grand nombre de plates-formes et apporte de

nombreuses nouvelles fonctionnalités ainsi qu'une amélioration notable des performances.

En 1991, Oracle 6.1 propose une option Parallel Server (dans un premier temps sur la DEC

VAX, puis rapidement sur de nombreuses autres plates-formes).

En 1992, Oracle 7 sort sur les plates-formes UNIX (elle ne sortira sur les plates-formes

Windows qu'à partir de 1995). Cette version permet une meilleure gestion de la mémoire, du

CPU et des entrées-sorties. La base de données est accompagnée d'outils d'administration

(SQL*DBA) permettant une exploitation plus aisée de la base. En 1997, la version Oracle 7.3

(baptisée Oracle Universal Server) apparaît, suivie de la version 8 offrant des capacités objet à

la base de données

Oracle est écrit en langage C et est disponible sur de nombreuses plates-formes matérielles

(plus d'une centaine) dont :

AIX (IBM)

Annexe B

151

Solaris (Sun)

HP/UX (Hewlett Packard)

Windows NT (Microsoft)

Oracle depuis la version 8.0.5 est disponible sous Linux

IV.2. Fonctionnalités La définition et la manipulation des données

La cohérence des données

La confidentialité des données

L'intégrité des données

La sauvegarde et la restauration des données

La gestion des accès concurrents

Documents

Conception et développement d’une place de marché B2C