Post on 20-Jan-2015
description
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
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
Introduction générale
19
Introduction générale
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
Introduction générale
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).
Chapitre I : Etude du projet
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.
Chapitre I : Etude du projet
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
Chapitre I : Etude du projet
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
Chapitre I : Etude du projet
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
Chapitre I : Etude du projet
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
Chapitre I : Etude du projet
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
Chapitre I : Etude du projet
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"
Chapitre I : Etude du projet
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é
Chapitre I : Etude du projet
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.
Chapitre I : Etude du projet
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
Chapitre I : Etude du projet
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.
Chapitre I : Etude du projet
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
Chapitre II : La phase d’incubation
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.
Chapitre II : La phase d’incubation
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.
Chapitre II : La phase d’incubation
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.
Chapitre II : La phase d’incubation
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
Chapitre II : La phase d’incubation
38
Figure 7 : diagramme des cas d'utilisation initiaux
Clientinterface commande
ctr_commande
commande
sous_commande
Chapitre II : La phase d’incubation
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
Chapitre II : La phase d’incubation
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
Acteurs principaux: Internaute
Pré-condition : NEANT
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"
Chapitre II : La phase d’incubation
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é
Acteurs : Internaute
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"
Chapitre II : La phase d’incubation
42
vider le panier :
Cas d’utilisation : Vider le panier
Acteurs : Internaute
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
Acteurs : Internaute
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
2a-2-retour à l’étape 1 du scénario nominal
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"
Chapitre II : La phase d’incubation
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
Pré-condition : Pas de pré-condition
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
2a-1-le système affiche un message d’erreur
Chapitre II : La phase d’incubation
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
2-le système vérifie les données saisies
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
2a-1-le système affiche un message d’erreur
2a-2-retour à l’étape 1 du scénario nominal
2b-l’entreprise saisit des données anormales
2b-1-le système affiche un message de type « vérifier les données
saisies »
2b-2-retour à l’étape 1 du scénario nominal
Tableau 11 : description textuelle du cas d'utilisation "ajouter produit"
Chapitre II : La phase d’incubation
45
Supprimer produit :
Cas d’utilisation : Supprimer produit
Acteurs : Entreprise
Pré-condition : L’entreprise doit s’authentifier
Post-condition : Produit supprimé
Scénario nominal : 1-l’ entreprise sélectionne le produit et le supprime
2-le système affiche un message de confirmation
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
Acteurs : Entreprise
Pré-condition : L’entreprise doit s’authentifier
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
4-le système vérifie les données saisies
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 »
4a-2-retour à l’étape 3 du scénario nominal
4b-le prix saisi inférieur à 0
4b-1-le système affiche un message d’erreur
4b-1-retour à l’étape 3 du scénario nominal
4c-la quantité saisit inférieur à 0
Chapitre II : La phase d’incubation
46
4a-1-le système affiche un message d’erreur
4a-2-retour à l’étape 3 du scénario nominal
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
Acteurs : Entreprise
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
Acteurs : Entreprise
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"
Chapitre II : La phase d’incubation
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
Acteurs : Superviseur
Pré-condition : Le superviseur doit d’authentifier
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
Acteurs : Superviseur
Pré-condition : Le superviseur doit d’authentifier
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"
Chapitre II : La phase d’incubation
48
Cas d’utilisation « consulter liste des produits » :
Cas d’utilisation : consulter liste des produits
Acteurs : Superviseur
Pré-condition : Le superviseur doit d’authentifier
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
Acteurs : Superviseur
Pré-condition : Le superviseur doit d’authentifier
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
2-le système vérifie les données saisies
3- le système enregistre la nouvelle catégorie
Scénario alternatif : 2a-l’administrateur saisie des données manquantes
2a-1-le système affiche un message d’erreur
Chapitre II : La phase d’incubation
49
2a-1-retour à l’étape 3 du scénario nominal
2b-la catégorie de vitrine existe
2b-1-le système affiche un message de type « cette catégorie
existe déjà »
2b-2-retour à l’étape 3 du scénario nominal
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
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
2-le système vérifie les données saisies
3- le système enregistre la nouvelle catégorie
Scénario alternatif : 2a-l’administrateur saisie des données manquantes
2a-1-le système affiche un message d’erreur
2a-1-retour à l’étape 3 du scénario nominal
2b-la catégorie de produit existe
2b-1-le système affiche un message de type « cette catégorie
existe déjà »
2b-2-retour à l’étape 3 du scénario nominal
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
Acteurs : Administrateur
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
2-le système vérifie les données saisies
3-le système enregistre la nouvelle vitrine et envoie un mail vers
l’entreprise
Chapitre II : La phase d’incubation
50
Scénario alternatif 2a-l’administrateur saisie des données manquantes
2a-1-le système affiche un message d’erreur
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
Pré-condition : Pas de pré-condition
Post-condition : L’utilisateur est connecté
Scénario nominal : 1-l’utilisateur saisit ses informations de connexion
2-le système vérifie les données saisies
3- le système affiche la page d’accueil
Scénario alternatif : 2a-l’utilisateur saisit des données manquantes
2a-1-le système affiche un message d’erreur
2a-2-retour à l’étape 1 du scénario nominal
2b-les données saisies sont invalides
2b-1-le système affiche un message de type « vérifier vos données
saisies »
2b-2-retour à l’étape 1 du scénario nominal
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
Chapitre II : La phase d’incubation
51
Figure 8: prototype interface authentification du back-office
Figure 9: prototype interface gestion des superviseurs
Chapitre II : La phase d’incubation
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
Chapitre II : La phase d’incubation
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
Chapitre II : La phase d’incubation
54
IV.2. Analyse du cas d’utilisation « créer catégorie produit »
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 »
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>>
Diagramme cas d'utilisation Modéle d'analyse
Administrateur
Créer catégorie produit
formulaire ajoutctr_ajout
categorie_produi t
Chapitre II : La phase d’incubation
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 »
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 »
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
Administrateurformulaire ajout
ctr_ajoutcategorie_produit
Chapitre II : La phase d’incubation
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>>
Diagramme cas d'utilisation Modéle d'analyse
Administrateur
Créer vitrine
formulaire creationctr_creation
vitrine
Administrateurformulaire creation
ctr_creationvitrine
Chapitre II : La phase d’incubation
57
IV.4. Analyse du cas d’utilisation « authentification »
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 »
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.
Figure 16: traçabilité entre le modèle de cas d'utilisation et le modèle d'analyse pour le cas
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>>
Diagramme cas d'utilisation Modéle d'analyse
Utilisateur
Authentification
formulaire authentification
ctr_authentification
compte_user
Chapitre II : La phase d’incubation
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
Chapitre III : La phase d’élaboration
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
Chapitre III : La phase d’élaboration
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
Acteurs principaux: Internaute
Pré-condition : NEANT
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
Chapitre III : La phase d’élaboration
61
2a-1-le système affiche un message de type « aucune résultat
trouver »
2a-2-retour à l’étape 1 du scénario nominal
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
Acteurs principaux: Internaute
Pré-condition : NEANT
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 »
2a-2-retour à l’étape 1 du scénario nominal
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"
Chapitre III : La phase d’élaboration
62
Figure 18 : diagramme de cas d'utilisation final
Clientinterface commande
ctr_commande
commande
sous_commande
Chapitre III : La phase d’élaboration
63
Cas d’utilisation « imprimer étiquette »
Cas d’utilisation : Imprimer étiquette
Acteurs principaux: Entreprise
Pré-condition : L’entreprise doit s’authentifier
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
Pré-condition : L’administrateur doit s’authentifier
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"
Chapitre III : La phase d’élaboration
64
Cas d’utilisation « ajouter une unité commerciale »
Cas d’utilisation : Ajouter une unité commerciale
Acteurs principaux: Administrateur
Pré-condition : L’administrateur doit s’authentifier
Post-condition : Une nouvelle unité commerciale enregistrée
Scénario nominal : 1-l’administrateur remplis le formulaire d’ajout
2-le système vérifie les données saisies
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 »
2a-2-retour à l’étape 1 du scénario nominal
Tableau 31 : description textuelle du cas d'utilisation "ajouter une unité commerciale"
Cas d’utilisation « ajouter un superviseur » :
Cas d’utilisation : Ajouter un superviseur
Acteurs principaux: Administrateur
Pré-condition : L’administrateur doit s’authentifier
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
Scénario alternatif : 2a-l’administrateur saisie des données manquantes
2a-1-le système affiche un message d’erreur
2a-2-retour à l’étape 1 du scénario nominal
2b-l’adresse mail existe déjà
2b-1-le système affiche un message de type « adresse mail
existant »
2b-2-retour à l’étape 1 du scénario nominal
Tableau 32 : description textuelle du cas d'utilisation "ajouter un superviseur"
Chapitre III : La phase d’élaboration
65
Cas d’utilisation « supprimer un superviseur »
Cas d’utilisation : supprimer un superviseur
Acteurs principaux: Administrateur
Pré-condition : L’administrateur doit s’authentifier
Post-condition : Le superviseur est supprimé
Scénario nominal : 1-l’administrateur sélectionne un superviseur et demande sa
suppression
2-le système affiche un message de confirmation
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
Chapitre III : La phase d’élaboration
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.
Chapitre III : La phase d’élaboration
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>>
Diagramme cas d'utilisation Modéle d'analyse
Superviseur
Consulter l iste des vitrines
interface vitrine ctr_vitrine
vitrine
Superviseurinterface vitrine
ctr_vitrinevitrine
Chapitre III : La phase d’élaboration
68
III.2. Analyse du cas d’utilisation « ajouter un produit »
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 »
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
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"
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>>
Diagramme cas d'utilisation Modéle d'analyse
Entreprise
Ajouter un produit
interface ajout ctr_ajout
produit
Entrepriseinterface ajout
ctr_ajoutproduit
Chapitre III : La phase d’élaboration
69
III.3. Analyse du cas d’utilisation « supprimer un produit »
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 »
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.
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"
III.3.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation
« supprimer un produit »
Figure 24: diagramme de classe du modèle d'analyse pour le d'utilisation "supprimer un
produit"
<<Trace>>
Diagramme cas d'utilisation Modéle d'analyse
Entreprise
Supprimer un produit
interface produit ctr_suppression
produit
Entrepriseinterface produit
ctr_suppressionprodui t
Chapitre III : La phase d’élaboration
70
III.4. Analyse du cas d’utilisation « modifier un produit »
III.4.1. Traçabilité entre le modèle de cas d’utilisation et le modèle
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"
III.4.2. Diagramme de classe du modèle d’analyse du cas d’utilisation
« modifier un produit »
Figure 26: diagramme de classe du modèle d'analyse du cas d'utilisation "modifier un produit"
<<Trace>>
Diagramme cas d'utilisation Modéle d'analyse
Entreprise
Modifier un produit
formulaire modification ctr_modification
produit
Entrepriseformulai re modi fication
ctr_modificationprodui t
Chapitre III : La phase d’élaboration
71
III.5. Analyse du cas d’utilisation « valider/annuler un produit »
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 »
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"
III.5.2. Diagramme de classe du modèle d’analyse du cas d’utilisation
« annuler/valider un produit »
<<Trace>>
Diagramme cas d'utilisation Modéle d'analyse
Superviseur
valider / annuler un produit
interface produit ctr_val idation
produit
Chapitre III : La phase d’élaboration
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 »
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 »
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.
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"
Superviseurinterface produit
ctr_validationproduit
<<Trace>>
Diagramme cas d'utilisation Modéle d'analyse
Internaute
Créer compte
formulaire_inscription ctr_inscription Cl ient
compte_user
Chapitre III : La phase d’élaboration
73
III.6.2. Diagramme de classe du modèle d’analyse du cas d’utilisation
« 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 »
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 »
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
Chapitre III : La phase d’élaboration
74
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"
III.7.2. Diagramme de classe du modèle d’analyse du cas d’utilisation
« consulter liste des produit »
Figure 32: diagramme de classe du modèle d'analyse du cas d'utilisation "consulter liste des
produits"
<<Trace>>
Diagramme cas d'utilisation Modéle d'analyse
Superviseur
consulter la liste des produits
interface produit ctr_produit
produit
Superviseurinterface produit
ctr_produitproduit
Chapitre III : La phase d’élaboration
75
III.8. Analyse du cas d’utilisation « remplir le panier »
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 »
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"
III.8.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation
« remplir le panier »
<<Trace>>
Diagramme cas d'utilisation Modéle d'analyse
Internaute
Rempl ir le panier
interface panier ctr_panier
panier
produi t_panier
Chapitre III : La phase d’élaboration
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 »
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 »
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>>
Diagramme cas d'utilisation Modéle d'analyse
Superviseur
Consul ter liste des clients
interface client ctr_client
client
Chapitre III : La phase d’élaboration
77
III.9.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation
« 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
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"
Superviseurinterface client
ctr_clientclient
<<Trace>>
Diagramme cas d'utilisation Modéle d'analyse
Internaute
consulter le panier
interface panier ctr_panier
panier
produi t_panier
Chapitre III : La phase d’élaboration
78
III.10.2. Diagramme de classe du modèle d’analyse du cas d’utilisation
« 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 »
III.11.1. 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 »
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.
Internauteinterface panier
ctr_panierproduit_panier
panier
Chapitre III : La phase d’élaboration
79
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"
III.11.2. Diagramme de classe du modèle d’analyse du cas d’utilisation
« 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>>
Diagramme cas d'utilisation Modéle d'analyse
Internaute
supprimer un produit du panier
interface panier ctr_panier
panier
produit_panier
Internauteinterface panier
ctr_panierproduit_panier
panier
Chapitre III : La phase d’élaboration
80
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 »
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.
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"
III.12.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation
« modifier quantité du produit »
<<Trace>>
Diagramme cas d'utilisation Modéle d'analyse
Internaute
modifier quanti té du produit
interface panier ctr_panier
panier
produit_panier
Chapitre III : La phase d’élaboration
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 »
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 »
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
Internauteinterface panier
ctr_panierproduit_panier
panier
Chapitre III : La phase d’élaboration
82
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"
III.13.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation
« vider le panier »
Figure 44: diagramme de classe du modèle d'analyse pour le cas d'utilisation "vider le panier"
<<Trace>>
Diagramme cas d'utilisation Modéle d'analyse
Internaute
vider le panier
interface panier ctr_panier
panier
produit_panier
Internauteinterface panier
ctr_panierproduit_panier
panier
Chapitre III : La phase d’élaboration
83
III.14. Analyse du cas d’utilisation « passer une commande »
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 »
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.
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"
III.14.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation
« passer une commande »
<<Trace>>
Diagramme cas d'utilisation Modéle d'analyse
Client
passer une commande
interface commande
ctr_commande
commande
sous_commande
tari f
Chapitre III : La phase d’élaboration
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.
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 »
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.
Clientinterface commande
ctr_commande
tari fcommande sous_commande
Chapitre III : La phase d’élaboration
85
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"
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>>
Diagramme cas d'utilisation Modéle d'analyse
Superviseur
Consulter les commande
interface commande ctr_commande
commande
sous_commande
Superviseurinterface commande
ctr_commande
commande
sous_commande
Chapitre III : La phase d’élaboration
86
III.16. Analyse du cas d’utilisation « payer la commande »
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 »
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.
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"
III.16.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation
« payer la commande »
<<Trace>>
Diagramme cas d'utilisation Modéle d'analyse
Client
payer la commande
interface paiement ctr_paiement
commande
transaction
details_transaction
Chapitre III : La phase d’élaboration
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 »
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 »
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
Chapitre III : La phase d’élaboration
88
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"
III.17.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation
« faire une recherche rapide »
Figure 52: diagramme de classe du modèle d'analyse pour le cas d'utilisation "faire une
recherche rapide"
<<Trace>>
Diagramme cas d'utilisation Modéle d'analyse
Internaute
recherche rapide
formulaire recherchectr_recherche
produit
vi trine
Internauteformulaire recherche
ctr_rechercheproduit
vitrine
Chapitre III : La phase d’élaboration
89
III.18. Analyse du cas d’utilisation « faire une recherche avancée »
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 »
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.
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"
III.18.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation
« faire une recherche avancée »
<<Trace>>
Diagramme cas d'utilisation Modéle d'analyse
Internaute
recherche avancée
formulaire recherchectr_recherche
produit
vi trine
Chapitre III : La phase d’élaboration
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 »
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 »
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
Chapitre III : La phase d’élaboration
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>>
Diagramme cas d'utilisation Modéle d'analyse
Administrateur
Ajouter un superviseur
formulaire ajout ctr_superviseur
superviseur
Administrateurformulaire ajout
ctr_superviseursuperviseur
Chapitre III : La phase d’élaboration
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>>
Diagramme cas d'utilisation Modéle d'analyse
Administrateur
Supprimer un superviseur
interface superviseur ctr_superviseur
superviseur
Administrateurinterface superviseur
ctr_superviseursuperviseur
Chapitre III : La phase d’élaboration
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>>
Diagramme cas d'utilisation Modéle d'analyse
Administrateur
consulter l iste unités commerciales
interdace unite ctr_unite
unite_commerciale
Administrateurinterface unite
ctr_uniteunite_commerciale
Chapitre III : La phase d’élaboration
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>>
Diagramme cas d'utilisation Modéle d'analyse
Administrateur
ajouter unité commerciale
forlulaire ajout ctr_unite
unite_commerciale
Administrateurformulaire ajout
ctr_uniteunite_commerciale
Chapitre III : La phase d’élaboration
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"
III.23.2. Diagramme de classe du modèle d’analyse pour le cas d’utilisation
« 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>>
Diagramme cas d'utilisation Modéle d'analyse
Unite commerciale
collecter commande
interface_unite
ctr_commande
commande
Unite commercialeinterface_unite
ctr_commandecommande
Chapitre III : La phase d’élaboration
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 »
Chapitre III : La phase d’élaboration
97
Figure 65: diagramme de séquence du cas d'utilisation "créer catégorie produit"
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
Chapitre III : La phase d’élaboration
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
afficher_msg_erreur(message)
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
Chapitre III : La phase d’élaboration
99
Figure 67: diagramme de séquence du cas d'utilisation "créer vitrine"
Créer vitrine
afficher_msg_succes(message)
resultat
requette
afficher_msg_erreur(message)
verifier_donnees()
creer_vitrine(v1,v2,...)rempli r_formulaire(v1,v2,...)
Administrateur formulaire creation ctr_creation vi trine
ref
Authentification()
données manquantes
tous les champs sont remplis
alt
Chapitre III : La phase d’élaboration
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
afficher_msg_succes(message)
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
tous les champs sont remplis
alt
mail existant
mail innexistant
alt
Chapitre III : La phase d’élaboration
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
afficher_msg_erreur(message)
afficher_msg_erreur(message)
verifier_donnees()ajouter_produit(v1,v2,...)
remplir_formulaire(v1,v2,...)
Entreprise formulaire_ajout ctr_ajout produit
ref
Authentification()
donnees manquantes
tous les champs sont remplis
alt
données innormaux
données valides
alt
[l 'entreprise veut ajouter un produit]loop
Chapitre III : La phase d’élaboration
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
afficher_msg_erreur(message)
afficher_msg_erreur(message)
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
Chapitre III : La phase d’élaboration
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
Chapitre III : La phase d’élaboration
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()
Chapitre III : La phase d’élaboration
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
Chapitre III : La phase d’élaboration
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()
Chapitre III : La phase d’élaboration
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
afficher_msg_succes(message)
resul tat
requette
afficher_msg_erreur(message)
resultat
requette(mai l)
afficher_msg_erreur(message)
verifier_donnees()ajouter_superviseur(v1,v2,..)
rempli r_forulaire(v1,v2,..)
Administrateur formulaire_ajout ctr_superviseur superviseur
ref
Authentification()
données manquantes
tous les champs sont remplis
al t
mail existant
mail innexistant
alt
[l 'administrateur veut ajouter des nouveaux superviseurs]loop
Chapitre III : La phase d’élaboration
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
Chapitre III : La phase d’élaboration
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
afficher_msg_erreur(message)
resultat
veri fier_poid_vi trine()
afficher_msg_erreur(message)
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
Chapitre III : La phase d’élaboration
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
afficher_msg_erreur(message)
resultat
verifier_poid_vitrine()
afficher_msg_erreur(message)
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
Chapitre III : La phase d’élaboration
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
Chapitre III : La phase d’élaboration
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
Chapitre III : La phase d’élaboration
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
tous les champs sont remplis
alt
données erronées
sinon
alt
date expiré
sinon
al t
solde insuffisant
sinon
al t
Chapitre III : La phase d’élaboration
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()
afficher_msg_erreur(message)
afficher_msg_erreur(message)
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
Chapitre VI : La phase de construction
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
Chapitre VI : La phase de construction
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
Chapitre VI : La phase de construction
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
Chapitre VI : La phase de construction
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
Chapitre VI : La phase de construction
120
Figure 87 : diagramme de classe global
Clientinterface commande
ctr_commande
commande
sous_commande
Chapitre VI : La phase de construction
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.
Chapitre VI : La phase de construction
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
retourné Paramètres Description
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
Chapitre VI : La phase de construction
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
retourné Paramètres Description
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
retourné Paramètres Description
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 »
Méthodes Type retourné
Paramètres Description
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
Chapitre VI : La phase de construction
124
Description de la classe « promotion »
Méthodes Type retourné
Paramètres Description
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 »
Méthodes Type retourné
Paramètres Description
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
retourné Paramètres Description
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
Chapitre VI : La phase de construction
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
Chapitre VI : La phase de construction
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.
Chapitre VI : La phase de construction
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).
Chapitre VI : La phase de construction
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
Chapitre VI : La phase de construction
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 »
Chapitre VI : La phase de construction
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 »
Chapitre VI : La phase de construction
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 »
Chapitre VI : La phase de construction
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
Chapitre VI : La phase de construction
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
Chapitre VI : La phase de construction
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
Chapitre VI : La phase de construction
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é
Chapitre VI : La phase de construction
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
Chapitre VI : La phase de construction
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
Chapitre VI : La phase de construction
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